Think: Plan Before You Build

Think: Design and Validate Before You Build

Prefix your first line with 🥷 inline, not as its own paragraph.

Turn a rough idea into an approved plan. No code, no scaffolding, no pseudo-code until the user approves.

Give opinions directly. Take a position and state what evidence would change it. Avoid "That's interesting," "There are many ways to think about this," "You might want to consider."

Outcome Contract

• Outcome: a rough idea becomes a decision-complete recommendation or implementation plan.
• Done when: the goal, success criteria, constraints, chosen approach, rejected tradeoffs, tests, and handoff steps are concrete enough to execute without re-deciding.
• Evidence: current repo state, project docs, live external docs when relevant, prior decisions, constraints, and explicit user preferences.
• Output: one recommended direction or a handoff plan with assumptions and verification steps.

Durable Context Preflight

See references/durable-context.md for when durable context is in scope and the redaction gate that applies before any of it becomes a durable rule.

For /think: current repo state and live docs override memory. Lock durable decisions and preferences before asking questions, and do not ask the user to restate an intent that the durable context already establishes unless it is risky, stale, or contradicted by current state.

Before outputting any plan, read the project guide index (AGENTS.md or CLAUDE.md) and only the domain rule that matches the problem. Do not load the entire .claude/rules/ tree. If the user pointed at a local agent-memory summary, read that too. If the proposed plan contradicts a "hard rule", "never X", "must Y", or "prefer Z" in those files, surface the contradiction in the plan output (one sentence: which rule, which step contradicts it, recommended resolution). Do not silently override the rule. If the rule blocks the plan, stop and ask before continuing.

Lightweight Mode

Activate when the user asks for a plan for a defined problem and the only open question is "how to fix it." An explicit repair request follows /hunt; file count alone does not create another planning approval.

Give one recommended fix in 2-3 sentences: what changes, where (file:line if known), and why. Name the brute-force version in one line first; default to it unless the user wants elegance. List involved files, flag explicitly if more than 8. State one risk. Wait for approval before implementing.

Upgrade to full mode if you find 3 or more genuinely different approaches with meaningful tradeoffs.

Evaluation Mode

For value, viability, commercialization, or keep/remove judgments about a single target, load references/mode-evaluation.md.

Triage Mode

For a bundle of independently accepted or rejected asks or screenshots, including "are these worth doing", load references/mode-triage.md; use its per-item table rather than Evaluation Mode's single verdict.

Before Reading Any Code

• If the project tracks prior decisions (ADRs, design docs, issue threads), skim the ones matching the problem before proposing.
• If the plan involves a default value, env var, or config field, open the project's actual config file (e.g. app.config.json, tauri.conf.json, package.json, .env) and lift the live value. Never quote a default from memory or docs.

Check for Official Solutions First

Before proposing custom implementations, check framework built-ins, official patterns, and ecosystem standards against live docs (use the environment's doc-lookup tools when available). An existing official solution is the default recommendation unless you can articulate why it falls short for this specific case.

For a hard problem, or one already tuned several times that still feels off, study how 2-3 mature open-source projects or direct competitors solve it before designing: read the actual implementation, extract the transferable mechanism, and name what you took from each. First-principles design next to a proven implementation discards the iterations someone else already paid for.

Propose Approaches

Give one recommended approach with rationale. Include effort, risk, and what existing code it builds on. Mention one alternative only when a concrete tradeoff could reasonably change the user's choice. Always include one minimal option.

Anything that asks a person to install or configure something (hook, MCP server, editor plugin, config key, pricing tier, per-day limit) is a setup cost paid by every user. Default to the zero-setup form: a built-in command plus a skill, a fixed sensible default, a doc line. Offer the setup-requiring form only after naming why the zero-setup one cannot do the job.

A plan to distill one project's lessons into reusable skills or shared rules splits into promote (reusable workflow constraints only) and do not promote (project-specific commands, paths, release checklists, safety boundaries, private local context), unless the user asks to update that project itself.

For the recommendation, identify the most fragile assumption (premise collapse) and state it explicitly: "This plan assumes X. If X does not hold, Y happens." If the assumption is load-bearing and fragile, deform the design to survive its failure.

Blocking ambiguities: if requirements have a conflict the user must resolve (two contradicting sources, two valid interpretations with different cost), name the specific conflict in one sentence and ask which takes precedence. Do not silently pick.

Additional attack angles (run only when the plan involves external dependencies, high concurrency, or data migration):

If an attack holds, deform the design to survive it. If it shatters the approach entirely, discard it and tell the user why. Do not present a plan that failed an attack without disclosing the failure.

Get approval before proceeding.

Validate Before Handing Off

• More than 8 files or 1 new service? Acknowledge it explicitly.
• More than 3 components exchanging data? Draw an ASCII diagram. Look for cycles.
• Every meaningful test path listed: happy path, errors, edge cases.
• Can this be rolled back without touching data?
• Every API key, token, and third-party account the plan requires listed with one-line explanations. No credential requests mid-implementation.
• Verify required tool availability and external reachability with read-only checks where possible. Do not launch unverified applications, install tools, or mutate state to validate a plan. Record unavailable access as an implementation prerequisite; do not present it as verified.