Menu
Writing implementation plans — small testable steps, dependency ordering, upfront risk identification.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Recognizing context pressure before it degrades output quality.
Evidence before claims, always — run verification commands and confirm output before making any completion or success claims.
Generate Architecture Decision Records — use when asked to document a decision, create an ADR, record why we chose X, or capture architectural rationale.
Generate a structured changelog from git history — use when asked to create a changelog, release notes, or summarize what changed between versions/tags/branches.
How to write pikit workflow YAML files — steps, loops, branches, interpolation.
Deep research with Analysis of Competing Hypotheses — use when asked to do deep research, deeply investigate, validate claims, or when correctness is critical and the user wants rigorous analysis with disconfirmation testing.
| name | planning |
| description | Writing implementation plans — small testable steps, dependency ordering, upfront risk identification. |
A plan is an ordered list of small steps. Each step should be:
parseConfig" not "improve error handling"Start from the end: What does "done" look like? Work backwards.
If a step feels large or vague, break it down further. If you can't describe how to verify a step, it's too abstract.
Before starting, ask:
Flag risks explicitly in the plan. A risk without a mitigation is just a wish.
## Plan: [Feature Name]
### Steps
1. [ ] Step description — how to verify
2. [ ] Step description — how to verify
3. [ ] Step description — how to verify
### Risks
- Risk description → mitigation
Apply these at decision points, not continuously:
Before finalizing, assume the plan has already failed. List the 3 most likely reasons — missing dependency, wrong decomposition, underestimated complexity — and add mitigation steps.
Verify the task breakdown is Mutually Exclusive, Collectively Exhaustive:
Identify the single hardest constraint — the thing that, if it doesn't work, makes everything else irrelevant. Schedule it as step 1 or 2, not last. If it involves an unfamiliar API or library, add a spike step before the main work.
For each significant decision, classify as REVERSIBLE (cheap to change later) or IRREVERSIBLE (requires migration, breaking changes). Spend analysis time proportional to irreversibility.
Re-read each step as if you've never seen this codebase. Is every noun unambiguous (which file? which function?)? Is every verb specific (add WHERE? modify HOW?)? If a step could be interpreted two ways, rewrite it.
Skip these for single-step plans or trivially obvious changes.
Every plan should identify its validation gates:
| Gate Type | When | What Happens |
|---|---|---|
| Pre-flight | Before starting | Check preconditions exist (files, deps, config). Block if unmet. |
| Revision | After producing output | Check quality, loop back with feedback if insufficient (cap iterations). |
| Escalation | When stuck | Surface to user with clear options. Don't spin. |
| Abort | When continuing would cause damage | Stop immediately, preserve state, report why. |
Not every plan needs all four. Simple changes need pre-flight at most. Multi-step work should have at least pre-flight and revision gates.
A plan is a starting hypothesis, not a contract. Update it as you learn. The goal is to think through the work upfront, not to predict the future perfectly.