Implementation plan
Git-versioned agent memory: agents that never make the same mistake twice. Anthropic-Skill folder standard, multi-runtime (Claude Code, Cursor, Gemini CLI, OpenCode).
npx -y skills add sordi-ai/skill-everything --skill implementation-planAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 17 stars17 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
Apply when planning before writing code, defining scope, or producing an implementation plan for a feature or change.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.4 KB, as published. Nobody here has run it
Sub-Skill: Implementation Plan
Purpose: Ensure every non-trivial change is planned before execution, reducing rework, missed files, and undetected regressions.
Rules
Scope & Files
- List affected files first. Always list all files that will be modified before beginning implementation. Reference: ERR-2026-029
- Define scope boundaries. Before writing code, explicitly state what is in scope and what is out of scope to prevent scope creep.
- Map dependencies. Always identify which modules, services, or packages depend on the code being changed before touching it.
Ordering & Safety
- Order migrations before rollouts. Always sequence database migrations before application deployments in the plan; never assume they run together.
- Write the rollback story. Before starting, define the rollback procedure: which commands revert the change and restore the previous state.
- Identify stop-the-line criteria. Always define explicit conditions that would cause you to halt implementation and reassess (e.g., test failure rate, latency spike).
Testing & Quality
- Include a test plan. Always specify which tests will be added or modified and what scenarios they cover before writing implementation code.
- Assess risk per change. For each file in the touch list, note the risk level (low/medium/high) based on blast radius and test coverage.
Communication & Completion
- Estimate time per step. Always provide a rough time estimate for each implementation step so stakeholders can track progress.
- Define done explicitly. Always write a definition of done (DoD) that includes passing tests, updated docs, and any required approvals before starting.
- Communicate blockers immediately. After discovering a blocker during implementation, surface it immediately rather than working around it silently.
- Verify the plan against the codebase. Before executing, confirm each file in the touch list exists and the planned change is compatible with its current state.
See also
skills/review-deployment/SKILL.mdskills/error-log/SKILL.md