dnlboxdnlbox/ai-protocol/.agents/skills/plan-implementation/SKILL.md

plan-implementation

Skill18 starsChanged 3 months agoMITView on GitHub

Create the minimum execution contract needed to implement accepted product intent.

8 other projects use a version of this.

Adopted by

Most recently taken up by

LongJohnSilver1504/claude-skillstheir own version, first seen Nov 8, 2026
dmzoneill/skillstheir own version, first seen Oct 24, 2026
pierrebelin/claude-code-toolkittheir own version, first seen Oct 21, 2026
Artmann/skillstheir own version, first seen Oct 13, 2026
santos-sanz/ai-dev-workflowtheir own version, first seen Oct 13, 2026
gtapps/skillstheir own version, first seen Sep 18, 2026

Other versions8 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 8
pierrebelin/claude-code-toolkit★ 7same name
dmzoneill/skills★ 2same name
gtapps/skills★ 2same name
nacif-software/skills★ 2same name
Artmann/skills★ 1same name
LongJohnSilver1504/claude-skills★ 1same name
JoaoAlavarse/cursor-config★ 0same name
santos-sanz/ai-dev-workflow★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- AGENTS.mdAGENTS.md
- concept-intakeSkill
- consolidate-stateSkill
- shape-conceptSkill
- sync-protocolSkill

The file

Show its rules and text

We split this skill into the rules it gives an agent

38 rules. 0 are common, 24 are distinctive, and 14 are very specific to this project.

0
Common
Most of the 8 edited versions we read keep these.
24
Distinctive
This author's own choices. Worth a look.
14
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Use this skill when the user explicitly requests operational planning or re-planning.
line 8
Distinctive:
Do not invoke this skill merely because implementation needs a lightweight internal plan.
line 10
Very specific:
Read every file in docs/concept/.
line 14
Distinctive:
Prefer a complete vertical feature over technical-layer phases.
line 29
Distinctive:
Avoid prescribing the number of agents.
line 35
Distinctive:
Avoid prescribing the execution order when dependencies do not require one.
line 36
Distinctive:
Avoid creating implementation packets for minor mechanical steps.
line 37
Distinctive:
Keep Project Specifics limited to stable repository rules.
line 42
Distinctive:
Avoid copying product intent into Project Specifics.
line 48
Distinctive:
Avoid copying the execution plan into Project Specifics.
line 49
Very specific:
Create BUILD_STATE.md when implementation needs durable continuity.
line 53
Very specific:
Keep BUILD_STATE.md focused on current verified truth.
line 54
Distinctive:
Keep completed detail in git history.
line 59
Very specific:
Avoid turning BUILD_STATE.md into a task transcript.
line 60
Very specific:
Create EXPERIENCE.md only when cross-feature interaction behaviour needs a durable contract.
line 64
Very specific:
Keep journey mechanics out of EXPERIENCE.md when tests express them clearly.
line 65
Very specific:
Create DESIGN.md only when presentation direction needs a durable contract.
line 66
Very specific:
Create GOVERNANCE.md only when the user approves a named delivery claim.
line 69
Very specific:
Create ROADMAP.md only when multiple objectives have material dependencies.
line 70
Very specific:
Keep live worker assignments out of ROADMAP.md.
line 71
Very specific:
Keep completed execution logs out of ROADMAP.md.
line 72
Distinctive:
Verify every declared command against the repository.
line 77
Distinctive:
Verify every objective has an observable completion condition.
line 78
Distinctive:
Verify every objective has a validation boundary.
line 79
Distinctive:
Verify every interaction objective has a natural-entry playtest path.
line 80
Distinctive:
Verify every unresolved external dependency is explicit.
line 81
Very specific:
Verify BUILD_STATE.md identifies the current objective.
line 82
Very specific:
Verify BUILD_STATE.md identifies the next meaningful action.
line 83
Distinctive:
Verify conditional artefacts do not duplicate one another.
line 84
Distinctive:
Verify the execution contract does not prescribe runtime orchestration choices.
line 85
Distinctive:
Stop before implementation when the user requested planning only.
line 95
Distinctive:
Avoid creating a separate kickoff prompt.
line 96
Distinctive:
Avoid product code during planning-only work.
line 100
Distinctive:
Avoid dependency installation during planning-only work.
line 101
Distinctive:
Avoid deployment during planning.
line 102
Distinctive:
Avoid committing planning-only work without approval.
line 103
Distinctive:
Avoid changing accepted product intent.
line 104
Very specific:
Use shape-concept when accepted product intent must change.
line 105

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Plan implementation

Use this skill when the user explicitly requests operational planning or re-planning.

Do not invoke this skill merely because implementation needs a lightweight internal plan.

Start

Read every file in docs/concept/.
Inspect the existing implementation.
Inspect the existing execution contract.
Inspect the latest verified state.
Require accepted concept intent.
Identify unresolved product decisions.
Return unresolved product decisions to the user.
Resolve reversible technical choices during planning.
Preserve accepted implementation evidence during re-planning.
Preserve completed history during re-planning.
Change only the approved planning scope.

Plan by objective

Define objectives as observable product outcomes.
Prefer a complete vertical feature over technical-layer phases.
Include every required product layer in the objective.
Include the natural-entry playtest path in an interaction objective.
Define the completion condition for each objective.
Define the required validation boundary for each objective.
Record material dependencies between objectives.
Avoid prescribing the number of agents.
Avoid prescribing the execution order when dependencies do not require one.
Avoid creating implementation packets for minor mechanical steps.
Let the Leader decompose an approved objective during execution.

Execution contract

Keep Project Specifics limited to stable repository rules.
Record exact supported commands in Project Specifics.
Record required validation gates in Project Specifics.
Record material architecture boundaries in Project Specifics.
Record material security boundaries in Project Specifics.
Record material external-operation gates in Project Specifics.
Avoid copying product intent into Project Specifics.
Avoid copying the execution plan into Project Specifics.

State

Create BUILD_STATE.md when implementation needs durable continuity.
Keep BUILD_STATE.md focused on current verified truth.
Record one current objective in BUILD_STATE.md.
Record one next meaningful action in BUILD_STATE.md.
Record active ownership in BUILD_STATE.md.
Record material decisions in BUILD_STATE.md.
Keep completed detail in git history.
Avoid turning BUILD_STATE.md into a task transcript.

Conditional artefacts

Create EXPERIENCE.md only when cross-feature interaction behaviour needs a durable contract.
Keep journey mechanics out of EXPERIENCE.md when tests express them clearly.
Create DESIGN.md only when presentation direction needs a durable contract.
Include component-selection guidance in DESIGN.md for interface products.
Include representative component patterns in DESIGN.md for interface products.
Create GOVERNANCE.md only when the user approves a named delivery claim.
Create ROADMAP.md only when multiple objectives have material dependencies.
Keep live worker assignments out of ROADMAP.md.
Keep completed execution logs out of ROADMAP.md.
Omit every conditional artefact that does not earn a distinct responsibility.

Readiness

Verify every declared command against the repository.
Verify every objective has an observable completion condition.
Verify every objective has a validation boundary.
Verify every interaction objective has a natural-entry playtest path.
Verify every unresolved external dependency is explicit.
Verify BUILD_STATE.md identifies the current objective.
Verify BUILD_STATE.md identifies the next meaningful action.
Verify conditional artefacts do not duplicate one another.
Verify the execution contract does not prescribe runtime orchestration choices.

Delivery

Show the user the resulting execution contract.
Show the user the resulting objective plan.
Report every omitted conditional artefact.
Report every unresolved product decision.
Report the exact repository status.
Continue into implementation when the approved objective includes implementation.
Stop before implementation when the user requested planning only.
Avoid creating a separate kickoff prompt.

Boundaries

Avoid product code during planning-only work.
Avoid dependency installation during planning-only work.
Avoid deployment during planning.
Avoid committing planning-only work without approval.
Avoid changing accepted product intent.
Use shape-concept when accepted product intent must change.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free