plan-implementation

Name: plan-implementation
Author: testdouble

122stars12forks

How to install plan-implementation?

testdouble/han/plan-implementation

$npx -y skills add testdouble/han --skill plan-implementation

Installs into the current project.

Summary

Builds a feature implementation plan from an existing feature specification (or equivalent context) through a project-manager-led team conversation. Use when the user wants to plan how to implement, build, deliver, or ship a feature that has already been specified. Does not speci

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
4	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
5
6	## Operating Principles
7
8	- *The feature specification is the ground truth for what.* This skill plans how. Do not re-open behavioral decisions the specification already settled; flag contradictions as Open Questions for the user.
9	- The han-core:project-manager is the coordinator, not the author of every section. It facilitates rounds of discussion among specialists, tracks claims and evidence, and decides when the plan is ready. Specialists own their domains.
10	- Always include `han-core:junior-developer` on the team. When decisions lack strong evidence, the han-core:junior-developer reframes the issue in plain terms first — that frequently unlocks a resolution without needing the user.
11	- Escalate to the user only when evidence and reframing have both failed. Every escalation surfaces with a full description, the evidence considered, and a recommended answer.
12	- Done is when the han-core:project-manager says so. The loop exits when the han-core:project-manager reports the plan is ready to commit, or that only user-input items remain. The user is not asked to keep iterating past that point.
13	- *YAGNI is a first-class operating principle, applied to implementation* choices.** The implementation plan inherits the spec's behavioral commitments but applies the evidence-based YAGNI rule from [../../references/yagni-rule.md](../../references/yagni-rule.md) independently to abstractions, configuration knobs, observability, runbooks, infrastructure, rollout machinery, test scaffolding, schema columns, indexes, and any other implementation artifact the plan recommends. Items that fail the evidence test get demoted to a `## Deferred (YAGNI)` section in `feature-implementation-plan.md` with the reopening trigger named; items where a strictly simpler implementation satisfies the same evidence get the simpler implementation recorded as the decision and the larger version under `Rejected alternatives:`. The Sentry-runbook-on-staging-only-Sentry pattern is the named project precedent — operational machinery shipped before the system that drives it actually produces the data, traffic, or failures it covers is YAGNI by default. Every committed implementation item is ongoing maintenance and a pattern future agents will copy.
14	- Keep the plan at planning altitude. Name and reference config and code artifacts; do not inline their full contents. Inline only the specific values that are themselves decisions (a flag default, a key name, a threshold). A full file block — a complete plist, a whole config file, a multi-line XML or JSON document — belongs in the file it configures, not in the plan. YAGNI gates whether an item is included; this principle gates how verbose an included item is.
15	- The plan lives in three cross-referenced files. `feature-implementation-plan.md` is the primary plan and lives at the root of `{folder}/`; `implementation-decision-log.md` records every decision and `implementation-iteration-history.md` records each round of discussion — both companion artifacts live in `{folder}/artifacts/` to keep the planning folder uncluttered. The main plan cites decisions with inline `([D-N](artifacts/implementation-decision-log.md#...))` links for non-obvious claims. The decision log and iteration history cross-link through `Driven by rounds:` / `Decisions produced:` fields (they sit as siblings inside `artifacts/`), and both link back into the plan through `Referenced in plan:` / `Changed in plan:` fields using `../feature-implementation-plan.md`. Any edit to one file requires updating the matching fields in the others.
16
17	# Plan an Implementation
18
19	## Step 1: Locate the Feature Specification
20
21	Read the user's argument and conversation context to identify the source artifact. The expected input is a `feature-specification.md` produced by the `plan-a-feature` skill, but any document describing what the feature should do is acceptable (PRD, design doc, product brief).
22
23	Resolve the source path:
24	- If the user provided a file path, use it.
25	- Otherwise, search for a recent `feature-specification.md` under `docs/features/`, `docs/plans/`, or other documentation roots

People who liked this also viewed

6 picks

Type

plan-implementation

122stars12forks

View on GitHub

How to install plan-implementation?

testdouble/han/plan-implementation

$npx -y skills add testdouble/han --skill plan-implementation

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
4	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
5
6	## Operating Principles
7
8	- *The feature specification is the ground truth for what.* This skill plans how. Do not re-open behavioral decisions the specification already settled; flag contradictions as Open Questions for the user.
9	- The han-core:project-manager is the coordinator, not the author of every section. It facilitates rounds of discussion among specialists, tracks claims and evidence, and decides when the plan is ready. Specialists own their domains.
10	- Always include `han-core:junior-developer` on the team. When decisions lack strong evidence, the han-core:junior-developer reframes the issue in plain terms first — that frequently unlocks a resolution without needing the user.
11	- Escalate to the user only when evidence and reframing have both failed. Every escalation surfaces with a full description, the evidence considered, and a recommended answer.
12	- Done is when the han-core:project-manager says so. The loop exits when the han-core:project-manager reports the plan is ready to commit, or that only user-input items remain. The user is not asked to keep iterating past that point.
13	- *YAGNI is a first-class operating principle, applied to implementation* choices.** The implementation plan inherits the spec's behavioral commitments but applies the evidence-based YAGNI rule from [../../references/yagni-rule.md](../../references/yagni-rule.md) independently to abstractions, configuration knobs, observability, runbooks, infrastructure, rollout machinery, test scaffolding, schema columns, indexes, and any other implementation artifact the plan recommends. Items that fail the evidence test get demoted to a `## Deferred (YAGNI)` section in `feature-implementation-plan.md` with the reopening trigger named; items where a strictly simpler implementation satisfies the same evidence get the simpler implementation recorded as the decision and the larger version under `Rejected alternatives:`. The Sentry-runbook-on-staging-only-Sentry pattern is the named project precedent — operational machinery shipped before the system that drives it actually produces the data, traffic, or failures it covers is YAGNI by default. Every committed implementation item is ongoing maintenance and a pattern future agents will copy.
14	- Keep the plan at planning altitude. Name and reference config and code artifacts; do not inline their full contents. Inline only the specific values that are themselves decisions (a flag default, a key name, a threshold). A full file block — a complete plist, a whole config file, a multi-line XML or JSON document — belongs in the file it configures, not in the plan. YAGNI gates whether an item is included; this principle gates how verbose an included item is.
15	- The plan lives in three cross-referenced files. `feature-implementation-plan.md` is the primary plan and lives at the root of `{folder}/`; `implementation-decision-log.md` records every decision and `implementation-iteration-history.md` records each round of discussion — both companion artifacts live in `{folder}/artifacts/` to keep the planning folder uncluttered. The main plan cites decisions with inline `([D-N](artifacts/implementation-decision-log.md#...))` links for non-obvious claims. The decision log and iteration history cross-link through `Driven by rounds:` / `Decisions produced:` fields (they sit as siblings inside `artifacts/`), and both link back into the plan through `Referenced in plan:` / `Changed in plan:` fields using `../feature-implementation-plan.md`. Any edit to one file requires updating the matching fields in the others.
16
17	# Plan an Implementation
18
19	## Step 1: Locate the Feature Specification
20
21	Read the user's argument and conversation context to identify the source artifact. The expected input is a `feature-specification.md` produced by the `plan-a-feature` skill, but any document describing what the feature should do is acceptable (PRD, design doc, product brief).
22
23	Resolve the source path:
24	- If the user provided a file path, use it.
25	- Otherwise, search for a recent `feature-specification.md` under `docs/features/`, `docs/plans/`, or other documentation roots

People who liked this also viewed

6 picks

Type