plan-feature-scaffold

Name: plan-feature-scaffold
Author: gtrabanco

35installs2forks

How to install plan-feature-scaffold?

gtrabanco/agentic-workflow/plan-feature-scaffold

$npx -y skills add gtrabanco/agentic-workflow --skill plan-feature-scaffold

Installs into the current project.

Summary

Internal step of plan-feature: from an already-designed SPEC (product half designed), fill the engineering half and generate the planning artifact set scaled to the feature's size (XS/S → SPEC-only with ≥ 2 phases in the SPEC, last = Hardening & PR; M/L → full set with a ha

Files · 1

View on GitHub

SKILL.md

1	# Plan Feature — Scaffold (internal)
2
3	Turn a designed feature into the project's complete planning artifact set,
4	ready for phase-by-phase execution. Fills only the SPEC's engineering half
5	— the product half (goal, context, scope, capability closure) already exists
6	and is marked `designed` before this skill ever runs (`plan-feature`'s
7	redirect gate guarantees it). Docs only — never code.
8
9	## When to use
10
11	- The `plan-feature` router calls this once a feature's product half is
12	`designed` — from `design-feature`, `plan-feature-from-issue`, or an
13	already-scoped slug/SPEC — to fill the engineering half of its
14	`docs/features/<NN>-<slug>/SPEC.md` and the rest of the folder, then update
15	the roadmap.
16
17	Not for product definition (that is `design-feature`) or writing code (that is
18	`execute-phase`) or deciding whether to build (that is the `plan-feature`
19	router / `triage-issue`).
20
21	## Step 0 — Discover the project (always first)
22
23	Per the agent guide's Workflow conventions + documentation map, then read
24	what THIS skill needs: the feature SPEC template, the roadmap
25	(numbering/order/deps), 1–2 recent feature folders to mirror the artifact set, and
26	the architecture/domain docs the map points to. No template/roadmap → fall back to
27	the agent guide and state the assumption.
28
29	## Process
30
31	1. Verify the product half is designed. The SPEC's `## Design status` must
32	read `designed` and Capability closure must be filled — `plan-feature`'s
33	redirect gate already checked this before calling this skill, but confirm
34	before writing: an undesigned SPEC here is a caller bug, not something to
35	silently patch over.
36	2. Resolve identity. From the roadmap, confirm the number and kebab-case
37	slug the product half already used (or, for an already-scoped SPEC with no
38	prior roadmap entry, pick the next free number). Record dependencies
39	(features that must land first) and note ordering conflicts.
40	3. Fill the engineering half of the SPEC. In the existing
41	`docs/features/<NN>-<slug>/SPEC.md`, complete every Engineering-half
42	section — technical goals, architecture impact, design, decisions to
43	confirm, branch name (`feat/<NN>-<slug>` or per project convention), phases,
44	testing requirements, and dev scenarios (happy path and failure
45	modes: empty/degraded state, races, outages — plus how to reproduce each
46	locally). Never touch the Product half (goal, context, scope, capability
47	closure, `## Design status`) — that is `design-feature`'s content; if it
48	looks wrong or incomplete, stop and redirect rather than editing it here.
49	No unfilled placeholders; record genuinely-unknown values as open questions
50	in `decisions.md`, not blanks.
51	4. Scale the artifacts to the size.
52	- XS/S → the SPEC is the only planning artifact (skip the set below —
53	don't generate ceremony the feature doesn't need), but its `### Phases`
54	section must list ≥ 2 phases with checkbox tasks: `P1` implementation
55	(cut by the per-phase cheap-executability checklist below), final phase
56	`P2 — Hardening & PR` carrying the literal close-out tasks (fixed
57	wording — copy them from `docs/fix/_TEMPLATE/SPEC.md` `## Phases`, never
58	paraphrase). Register the roadmap entry and hand off to
59	`execute-phase <NN>` (it runs one phase per invocation, ticking the
60	SPEC's `### Phases` checkboxes as its ledger).
61	- Split — mandatory, not advisory. Before emitting the phase list for an
62	M/L feature, split this feature into `Depends on:`-chained features if
63	any holds: (a) the plan would exceed ~5 phases; (b) a phase
64	touches more than one layer/concern; (c) a phase requires a **design
65	decision not resolved** in `SPEC.md`/`decisions.md`. Use the existing
66	dependency infrastructure (transitive dependency gate + `workflow-status`
67	build order) — never invent a new mechanism. More, smaller, slower
68	features is the accepted trade; a phase a weak model cannot execute
69	without judgement is not well-cut.
70	- Per-phase cheap-executability checklist. Each phase you emit passes
71	only if: ✓ every task is independently checkable without judgement;
72	✓ zero open design decisions (all resolved in `SPEC.md`/
73	`decisions.md`); ✓ one layer/concern; ✓ its **verification gate runs
74	locally**. A phase failing any box is re-cut or split (feeds the split
75	rule above). State `n/a: <reason>`

People who liked this also viewed

6 picks

Type

plan-feature-scaffold

35installs2forks

View on GitHub

How to install plan-feature-scaffold?

gtrabanco/agentic-workflow/plan-feature-scaffold

$npx -y skills add gtrabanco/agentic-workflow --skill plan-feature-scaffold

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Plan Feature — Scaffold (internal)
2
3	Turn a designed feature into the project's complete planning artifact set,
4	ready for phase-by-phase execution. Fills only the SPEC's engineering half
5	— the product half (goal, context, scope, capability closure) already exists
6	and is marked `designed` before this skill ever runs (`plan-feature`'s
7	redirect gate guarantees it). Docs only — never code.
8
9	## When to use
10
11	- The `plan-feature` router calls this once a feature's product half is
12	`designed` — from `design-feature`, `plan-feature-from-issue`, or an
13	already-scoped slug/SPEC — to fill the engineering half of its
14	`docs/features/<NN>-<slug>/SPEC.md` and the rest of the folder, then update
15	the roadmap.
16
17	Not for product definition (that is `design-feature`) or writing code (that is
18	`execute-phase`) or deciding whether to build (that is the `plan-feature`
19	router / `triage-issue`).
20
21	## Step 0 — Discover the project (always first)
22
23	Per the agent guide's Workflow conventions + documentation map, then read
24	what THIS skill needs: the feature SPEC template, the roadmap
25	(numbering/order/deps), 1–2 recent feature folders to mirror the artifact set, and
26	the architecture/domain docs the map points to. No template/roadmap → fall back to
27	the agent guide and state the assumption.
28
29	## Process
30
31	1. Verify the product half is designed. The SPEC's `## Design status` must
32	read `designed` and Capability closure must be filled — `plan-feature`'s
33	redirect gate already checked this before calling this skill, but confirm
34	before writing: an undesigned SPEC here is a caller bug, not something to
35	silently patch over.
36	2. Resolve identity. From the roadmap, confirm the number and kebab-case
37	slug the product half already used (or, for an already-scoped SPEC with no
38	prior roadmap entry, pick the next free number). Record dependencies
39	(features that must land first) and note ordering conflicts.
40	3. Fill the engineering half of the SPEC. In the existing
41	`docs/features/<NN>-<slug>/SPEC.md`, complete every Engineering-half
42	section — technical goals, architecture impact, design, decisions to
43	confirm, branch name (`feat/<NN>-<slug>` or per project convention), phases,
44	testing requirements, and dev scenarios (happy path and failure
45	modes: empty/degraded state, races, outages — plus how to reproduce each
46	locally). Never touch the Product half (goal, context, scope, capability
47	closure, `## Design status`) — that is `design-feature`'s content; if it
48	looks wrong or incomplete, stop and redirect rather than editing it here.
49	No unfilled placeholders; record genuinely-unknown values as open questions
50	in `decisions.md`, not blanks.
51	4. Scale the artifacts to the size.
52	- XS/S → the SPEC is the only planning artifact (skip the set below —
53	don't generate ceremony the feature doesn't need), but its `### Phases`
54	section must list ≥ 2 phases with checkbox tasks: `P1` implementation
55	(cut by the per-phase cheap-executability checklist below), final phase
56	`P2 — Hardening & PR` carrying the literal close-out tasks (fixed
57	wording — copy them from `docs/fix/_TEMPLATE/SPEC.md` `## Phases`, never
58	paraphrase). Register the roadmap entry and hand off to
59	`execute-phase <NN>` (it runs one phase per invocation, ticking the
60	SPEC's `### Phases` checkboxes as its ledger).
61	- Split — mandatory, not advisory. Before emitting the phase list for an
62	M/L feature, split this feature into `Depends on:`-chained features if
63	any holds: (a) the plan would exceed ~5 phases; (b) a phase
64	touches more than one layer/concern; (c) a phase requires a **design
65	decision not resolved** in `SPEC.md`/`decisions.md`. Use the existing
66	dependency infrastructure (transitive dependency gate + `workflow-status`
67	build order) — never invent a new mechanism. More, smaller, slower
68	features is the accepted trade; a phase a weak model cannot execute
69	without judgement is not well-cut.
70	- Per-phase cheap-executability checklist. Each phase you emit passes
71	only if: ✓ every task is independently checkable without judgement;
72	✓ zero open design decisions (all resolved in `SPEC.md`/
73	`decisions.md`); ✓ one layer/concern; ✓ its **verification gate runs
74	locally**. A phase failing any box is re-cut or split (feeds the split
75	rule above). State `n/a: <reason>`

People who liked this also viewed

6 picks

Type