// Turns rough ideas into approved, decision-complete plans with validated structure before writing code. Covers new features, architecture decisions, and value judgments about whether to build, keep, or remove something. Not for bug fixes or small edits.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | think |
| description | Turns rough ideas into approved, decision-complete plans with validated structure before writing code. Covers new features, architecture decisions, and value judgments about whether to build, keep, or remove something. Not for bug fixes or small edits. |
| when_to_use | 出方案, 给方案, 深入分析, 怎么设计, 用什么方案, 判断一下, 有没有必要, 值不值得, what's the best approach, plan this, how should I, should we keep this |
| metadata | {"version":"3.17.0"} |
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."
Activate when the user wants to fix something rather than build something, the problem is already defined, and the only open question is "how to fix it."
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 5. State one risk. Wait for approval before implementing.
Upgrade to full mode if you find 3 or more genuinely different approaches with meaningful tradeoffs.
Activate when the user wants to judge whether something should exist, be kept, exposed, or removed. Typical triggers: "判断一下", "有没有必要", "值不值得", "should we keep this", "is this worth it", "我不想做", "商业前景", "有没有必要继续".
State the evaluation target and what kind of judgment is needed (value, risk, or tradeoff). Take a current-state snapshot: what it does, who uses it, what depends on it; grep and read before opining.
Output format (Kill/Keep/Pivot):
Line 1: one of Kill / Keep / Pivot as the verdict. No preamble.
Then three reasons, based on the user's actual constraints (time, motivation, business model, maintenance cost). Not generic tradeoffs.
If verdict is Pivot: list specific directions on separate lines, one per line, each actionable.
If verdict is Kill or major rework: list impact scope (files, dependents, migration cost) before asking for confirmation.
Do not use a build-plan template here. Do not list options. Give one verdict.
Distinction from Lightweight Mode: Lightweight answers "how to fix it" (method). Evaluation answers "should it exist" (value judgment).
pwd or git rev-parse --show-toplevel. Never assume ~/project and ~/www/project are the same.pake.json, tauri.conf.json, package.json, .env) and lift the live value. Never quote a default from memory or docs.Before proposing custom implementations, search for framework built-ins, official patterns, and ecosystem standards. Use Context7 MCP tools to query latest docs when available. If an official solution exists, it is the default recommendation unless you can articulate why it is insufficient for this specific case.
Give one recommended approach with rationale. Include effort, risk, and what existing code it builds on. Mention one alternative only if the tradeoff is genuinely close (>40% chance the user would prefer it). Always include one minimal option.
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):
| Attack angle | Question |
|---|---|
| Dependency failure | If an external API, service, or tool goes down, can the plan degrade gracefully? |
| Scale explosion | At 10x data volume or user load, which step breaks first? |
| Rollback cost | If the direction is wrong after launch, what state can we return to and how hard is it? |
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. If the user rejects, ask specifically what did not work. Do not restart from scratch.
No placeholders in approved plans. Every step must be concrete before approval. Forbidden patterns: TBD, TODO, "implement later," "similar to step N," "details to be determined." A plan with placeholders is a promise to plan later.
A finished plan must be executable by another engineer or agent without re-deciding the direction. Include:
When the user later says "Implement the plan", "可以干", "直接改", "整", or equivalent, treat that as approval of the written plan. Do not re-litigate the design. State which plan is being executed, check for obvious drift in the repo, and proceed. If the environment has changed enough that the plan is unsafe, name the specific drift and stop before editing.
| What happened | Rule |
|---|---|
Moved files to ~/project, repo was at ~/www/project | Run pwd before the first filesystem operation |
| Asked for API key after 3 implementation steps | List every dependency before handing off |
| User said "just do it" or equivalent approval | Treat as approval of the recommended option. State which option was selected, finish the plan. Do not implement inside /think. |
| Planned MCP workflow without checking if MCP was loaded | Verify tool availability before handing off, not mid-implementation |
| Rejected design restarted from scratch | Ask what specifically failed, re-enter with narrowed constraints |
| User said "just fix X" and skipped /think | If the fix touches 3+ files or needs a method choice, pause and run Lightweight Mode |
| User approved a concrete plan and the agent debated the plan again | Execute the approved plan. Only stop for repo drift, missing permissions, or unsafe external state |
| Picked a regional or locale-specific API variant without checking | List all regional or locale differences before writing integration code |
| Introduced a second language or runtime into a single-stack project | Never add a new language or runtime without explicit approval |
| User said "判断一下这个报错" and got Evaluation Mode | "判断一下" + error/bug context = debugging, route to /hunt. Evaluation Mode is for value/existence judgments only |
Approved design summary:
After the user approves the design, stop. Implementation starts only when requested.
When the plan is approved, output this guidance:
Plan approved. To implement: say "implement this plan". After implementation, run `/check` to review before merging or release follow-through.
Keep it concise (2-3 sentences max). The user decides when to start implementation.