Plan

Iterative deep planning with critiques and alternatives. Use when facing complex design decisions, architecture choices, or implementation strategies that require thorough analysis. Trigger for any request involving "how should I design", "what's the best approach", "help me plan", "architecture decision", "trade-offs between", or when a user is choosing between multiple technical approaches. Also trigger when a proposed plan needs critique or when the stakes of a wrong decision are high. Prefer this skill over a one-shot answer whenever the problem has meaningful complexity, multiple valid approaches, or non-obvious failure modes.From its SKILL.md

Install

npx -y skills add gokulkrishh/skills --skill plan

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.3 KB, as published. Nobody here has run it

Replan

Iterative design planning: plan → critique → refine. Repeat until robust.

Step 0: Calibrate scope

Before starting, assess complexity:

Signal	Iterations
Small change, low reversibility risk	1–2
New component, moderate coupling	2–3
System-wide change, high coupling, irreversible	3+

State your calibration explicitly: "This looks like a 2-iteration problem because..."

If unclear, ask one scoping question before proceeding.

Step 1: Understand & Frame

Read relevant code, docs, constraints
State assumptions explicitly
Frame the core tension — what is this design fundamentally trading off? (e.g., "consistency vs availability", "flexibility vs simplicity", "speed now vs maintainability later")

Step 2: Initial Plan

Design your first approach. Include:

Key decisions made and why
What this plan optimises for
What it deliberately sacrifices

Step 3: Critique (run every iteration)

For each iteration, work through all four lenses:

🔴 Failure modes

What breaks first under load or scale?
What's the hardest scenario to test?
What assumption, if wrong, invalidates the whole plan?
What would you regret in 6 months?

🟡 Complexity audit

What's the most "hand-wavy" part — where did you assume without verifying?
Where does accidental complexity sneak in (over-engineering, premature abstraction)?
What requires the most context to understand?

🟠 Coupling & cohesion

What breaks if requirements change 20%?
Is this testable in isolation? If not, why not?
Where are the hidden dependencies?

🔵 Reversibility

What decisions are hard to undo?
Is there a cheaper way to validate the risky assumptions first?

Step 4: Alternatives

Generate 2–3 alternatives. Each must directly address the critique from Step 3 — not just be stylistically different.

For each option:

Option [X]: [Name]

[1–2 sentence description]

Optimises for: [specific axis — simplicity, reversibility, performance, etc.] Sacrifices: [what it gives up] Kills which risk: [which critique item from Step 3 this resolves] Pros: ... Cons: ... Risks: ...

Step 5: Select & develop best alternative

Pick the option that best balances:

Resolves the highest-severity critique item
Most reversible if wrong
Simplest to test

State selection reasoning explicitly. Then develop it fully.

Step 6: Iterate

Repeat Steps 3–5 for the planned number of iterations (from Step 0).

After each iteration, pause and ask the user:

Does this feel right, or is there a constraint I'm missing?
Is there a decision here you want to make together?

Step 7: Final Plan

Synthesise the best features across all iterations. Structure:

Decision summary — key choices made and why
What this plan assumes — explicit assumptions
What would invalidate this plan — top 2–3 failure conditions to watch for
Implementation order — what to build/validate first
Open questions — things still worth investigating

Guidelines

Kent Beck's Simple Design rules are a useful north star: passes tests → reveals intent → no duplication → fewest elements
Honesty over confidence: say "I don't know how X works here, I'd need to check" rather than assuming
For novel libraries or APIs: flag uncertainty and recommend a spike/prototype before committing
Prefer reversible decisions over optimal-but-irreversible ones under uncertainty