Plan change

Skill contextosai/skills/skills/plan-change

A collection of Agent Skills — self-contained folders that teach AI agents to perform specialized tasks. Includes a production-readiness harness-audit skill, a plugin marketplace, a SKILL.md spec, and CI validation.

Install

npx -y skills add contextosai/skills --skill plan-change

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

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.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

2.7 KB, 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:line evidence 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.