<< All versions
Skill v1.0.0
currentAutomated scan100/100sordi-ai/skill-everything/implementation-plan
──Details
PublishedSeptember 28, 2026 at 01:06 AM
Content Hashsha256:a2b04e912ba134c5...
Git SHA4e7dae3ff0c7
──Files
Files (1 file, 2.4 KB)
SKILL.md2.4 KBactive
SKILL.md · 53 lines · 2.4 KB
name: implementation-plan description: Apply when planning before writing code, defining scope, or producing an implementation plan for a feature or change. license: MIT version: 1.0.0 tokens_target: 1300 triggers:
- implementation plan
- planning before code
- scope definition
loads_after: [] supersedes: []
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