think-before-coding

Evaluates three distinct solution approaches with trade-offs before implementing non-trivial code changes.

1|Updated Jun 3, 2026
One-click install
npx skills add https://github.com/tanveerriaz/Skillz --skill think-before-coding-tanveerriaz
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: think-before-coding
Source: https://github.com/tanveerriaz/Skillz/tree/main/skills/think-before-coding
Command: npx skills add https://github.com/tanveerriaz/Skillz --skill think-before-coding-tanveerriaz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI agents and developers often jump straight into implementing the first idea that comes to mind, producing code that ignores existing patterns, creates accidental complexity, and requires rewrites. This Skill forces a brief structured deliberation before any non-trivial code change. ## Core Features & Use Cases - Three-Approach Evaluation: Requires outlining three genuinely distinct approaches (different algorithms, logic placement, change levels, or libraries) before writing code. - Trade-off Comparison: Compares options on simplicity, performance, maintainability, and fit with the existing codebase. - Justified Selection: Produces a chosen approach with a one-line rationale tied to project fit, preferring minimal-change options that reuse existing patterns. - Use Case: Before adding debouncing to a search input, compare an inline setTimeout, a reusable useDebounce hook, and server-side filtering, then pick the option matching the project's existing hooks pattern. ## Quick Start Before implementing this feature, evaluate three distinct approaches with trade-offs and justify your choice based on fit with the existing codebase.

Frequently Asked Questions about think-before-coding

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose between multiple implementation approaches for a feature?▼

Outline three genuinely distinct approaches, such as different algorithms, logic placement, or change levels, then compare each on simplicity, performance, maintainability, and fit with existing code. Choose the minimal-change option that reuses existing patterns unless a heavier option is clearly warranted.

When should I evaluate alternatives before writing code?▼

Evaluate alternatives before any non-trivial change: new features, refactors, or decisions about where logic lives or which abstraction to use. Skip deliberation for trivial edits like typos, copy changes, or one-line config tweaks where analysis adds no value.

What counts as a genuinely distinct approach in design evaluation?▼

Distinct approaches differ in substance, such as different algorithms or data structures, different placement of logic (component vs. hook vs. service vs. backend), different change levels (minimal fix vs. refactor vs. new abstraction), or different libraries versus the existing stack.

What if only one viable approach exists for my code change?▼

State that only one approach is viable and explain why the alternatives do not apply. Do not pad the analysis with fake alternatives just to reach three, since distinctness matters more than hitting the count.

When should I skip pre-implementation design deliberation?▼

Skip deliberation for trivial changes like typo fixes, copy edits, and one-line configuration tweaks where analysis adds no value. Also avoid over-analyzing when all options are close; pick the smallest-footprint option and move on.