implementation-plan

Name: implementation-plan
Author: sordi-ai

17stars3forks

How to install implementation-plan?

sordi-ai/skill-everything/implementation-plan

$npx -y skills add sordi-ai/skill-everything --skill implementation-plan

Installs into the current project.

Summary

Apply when planning before writing code, defining scope, or producing an implementation plan for a feature or change.

Files · 1

View on GitHub

SKILL.md

1	# Sub-Skill: Implementation Plan
2
3	Purpose: Ensure every non-trivial change is planned before execution, reducing rework, missed files, and undetected regressions.
4
5	---
6
7	## Rules
8
9	### Scope & Files
10
11	1. List affected files first. Always list all files that will be modified before beginning implementation. Reference: ERR-2026-029
12	2. Define scope boundaries. Before writing code, explicitly state what is in scope and what is out of scope to prevent scope creep.
13	3. Map dependencies. Always identify which modules, services, or packages depend on the code being changed before touching it.
14
15	### Ordering & Safety
16
17	4. Order migrations before rollouts. Always sequence database migrations before application deployments in the plan; never assume they run together.
18	5. Write the rollback story. Before starting, define the rollback procedure: which commands revert the change and restore the previous state.
19	6. 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).
20
21	### Testing & Quality
22
23	7. Include a test plan. Always specify which tests will be added or modified and what scenarios they cover before writing implementation code.
24	8. 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.
25
26	### Communication & Completion
27
28	9. Estimate time per step. Always provide a rough time estimate for each implementation step so stakeholders can track progress.
29	10. Define done explicitly. Always write a definition of done (DoD) that includes passing tests, updated docs, and any required approvals before starting.
30	11. Communicate blockers immediately. After discovering a blocker during implementation, surface it immediately rather than working around it silently.
31	12. 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.
32
33	---
34
35	## See also
36
37	- `skills/review-deployment/SKILL.md`
38	- `skills/error-log/SKILL.md`

People who liked this also viewed

6 picks

Type

implementation-plan

17stars3forks

View on GitHub

How to install implementation-plan?

sordi-ai/skill-everything/implementation-plan

$npx -y skills add sordi-ai/skill-everything --skill implementation-plan

Installs into the current project.

Summary

Apply when planning before writing code, defining scope, or producing an implementation plan for a feature or change.

Files · 1

View on GitHub

SKILL.md

1	# Sub-Skill: Implementation Plan
2
3	Purpose: Ensure every non-trivial change is planned before execution, reducing rework, missed files, and undetected regressions.
4
5	---
6
7	## Rules
8
9	### Scope & Files
10
11	1. List affected files first. Always list all files that will be modified before beginning implementation. Reference: ERR-2026-029
12	2. Define scope boundaries. Before writing code, explicitly state what is in scope and what is out of scope to prevent scope creep.
13	3. Map dependencies. Always identify which modules, services, or packages depend on the code being changed before touching it.
14
15	### Ordering & Safety
16
17	4. Order migrations before rollouts. Always sequence database migrations before application deployments in the plan; never assume they run together.
18	5. Write the rollback story. Before starting, define the rollback procedure: which commands revert the change and restore the previous state.
19	6. 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).
20
21	### Testing & Quality
22
23	7. Include a test plan. Always specify which tests will be added or modified and what scenarios they cover before writing implementation code.
24	8. 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.
25
26	### Communication & Completion
27
28	9. Estimate time per step. Always provide a rough time estimate for each implementation step so stakeholders can track progress.
29	10. Define done explicitly. Always write a definition of done (DoD) that includes passing tests, updated docs, and any required approvals before starting.
30	11. Communicate blockers immediately. After discovering a blocker during implementation, surface it immediately rather than working around it silently.
31	12. 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.
32
33	---
34
35	## See also
36
37	- `skills/review-deployment/SKILL.md`
38	- `skills/error-log/SKILL.md`

People who liked this also viewed

6 picks

Type