Plan change
Produce an implementation-ready plan for a software change by inspecting the actual repository, tracing affected execution paths, resolving material design decisions, and defining verification and rollout evidence. Use when the user asks for an implementation plan, technical approach, task breakdown, design proposal grounded in an existing codebase, or wants to know how a feature or fix should be built before editing begins. Do not use for generic product roadmaps or when the user has asked to implement immediately.From its SKILL.md
npx -y skills add contextosai/skills --skill plan-changeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 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
2.7 KB, 427 tokens by cl100k_base, as published. Nobody here has run it
Plan a Change
Create a plan another engineer can execute without rediscovering the system.
Protocol
- Read repository instructions and inspect worktree state. Preserve unrelated user changes.
- Restate the desired observable behavior, non-goals, and acceptance criteria. Infer only low-risk details; surface choices that materially change scope, compatibility, data, security, or user experience.
- Trace the current path from entry point to terminal effect. Locate runtime wiring, domain logic, state, tests, configuration, and operational controls.
- Identify the behavioral delta and invariants that must remain true. Include error, retry, authorization, concurrency, and rollback paths only when touched.
- Select the smallest coherent design. Explain important alternatives and why they lose in this repository; omit decorative option lists.
- Order steps by dependency and proof. Each step must name concrete files or symbols, the logic change, its contract with adjacent code, and verification.
- Include data/schema transition, compatibility, rollout, observability, and rollback steps when relevant. Never hide them under “update config.”
- Re-read the plan against acceptance criteria. Ensure every criterion maps to implementation and verification, and every risky mutation has a recovery path.
Plan quality bar
- Cite
path:lineevidence for the current architecture and chosen edit points. - Separate facts, decisions, assumptions, and unresolved questions.
- Avoid steps like “implement feature,” “add tests,” or “handle errors.” State which behavior changes, where, and how it is proven.
- Keep task granularity aligned with independently verifiable outcomes, not arbitrary file-by-file edits.
- Do not include code unless a small interface sketch resolves ambiguity.
Output
Use references/implementation-plan.md. Lead with the approach and key
decisions, then provide ordered implementation slices, verification, and
rollout. If one unresolved decision would produce substantially different
plans, stop and ask for it rather than pretending the branches are equivalent.
What ships with it: 2 files
1.3 KB alongside SKILL.md
agents/
- openai.yaml219 B
references/
- implementation-plan.md1.1 KB
Gives 0 of the 12 instructions most plan spec skills give in 427 tokens
Counted across 1,360 of the 2,617 authors here whose files we hold, read 2026-09-06
- Ask one question at a timein 73 of 1360
- Write the spec using the templatein 22 of 1360
- Ask clarifying questions if neededin 19 of 1360, across 18 files
- Wait for user confirmation before proceedingin 19 of 1360
- Save plans to the plans directoryin 17 of 1360, across 13 files
- Check for product marketing context firstin 16 of 1360, across 5 files
- Read the plan file completelyin 16 of 1360
- Order tasks by dependencyin 16 of 1360
- Gather context from the conversationin 15 of 1360, across 9 files
- Explore the codebase instead of askingin 15 of 1360, across 13 files
- Wait for explicit user approvalin 14 of 1360, across 13 files
- Quiz the user on the breakdownin 13 of 1360, across 7 files
Said here and by no other author read
- Read repository instructions and inspect worktree state
- Restate desired observable behavior and acceptance criteria
- Trace current path from entry point to terminal effect
- Identify behavioral delta and invariants
- Select the smallest coherent design
- Order steps by dependency and proof
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.