plan-feature-from-issue

Name: plan-feature-from-issue
Author: gtrabanco

35installs2forks

How to install plan-feature-from-issue?

gtrabanco/agentic-workflow/plan-feature-from-issue

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

Installs into the current project.

Summary

Internal step of plan-feature: turn a feature-request issue into a scoped, sized, roadmap-mapped SPEC product half (capability closure satisfied) with Closes #N traceability.

Files · 1

View on GitHub

SKILL.md

1	# Plan Feature — From Issue (internal)
2
3	Convert a feature-request issue into the project's planning artifacts, keeping a
4	clean issue → SPEC → PR(Closes #n) trace. Writes the SPEC's product half
5	(same two-halves convention `design-feature` uses) and must satisfy capability
6	closure before handing off — a thin issue does not get a shortcut around it.
7
8	## When to use
9
10	- The `plan-feature` router calls this when the input is a GitHub issue (or
11	`--from-issue N`) that describes new product capability.
12
13	If the issue is a bug or tech-debt, stop and route it: `triage-issue` to
14	classify, then `plan-fix` + `execute-phase --fix`. This skill is for
15	genuine features only.
16
17	## Step 0 — Discover the project (always first)
18
19	Per the agent guide's Workflow conventions + documentation map, then read
20	what THIS skill needs: the feature SPEC template, the roadmap, and the issue/PR
21	templates (`.github/ISSUE_TEMPLATE/`, `.github/PULL_REQUEST_TEMPLATE.md`) so the
22	SPEC mirrors the fields reviewers expect. Then read the issue (forge CLI per the
23	project's Workflow conventions — examples use `gh`):
24
25	```sh
26	gh issue view <N> --json number,title,body,labels,state,comments
27	```
28
29	## Process
30
31	1. Classify first. Confirm it is a feature. Not a feature if it describes a
32	defect, regression, duplicated code, perf debt, or carries a "when to
33	fix / trigger" clause → hand to `triage-issue`. State the verdict explicitly.
34	2. Normalize language. If not in the project's docs language (this repo:
35	English), translate before drafting any artifact.
36	3. Map to the roadmap. Assign the next number + slug. Identify dependencies
37	and conflicts with existing features, coupling/migration risks, and whether
38	it should instead extend an existing feature.
39	4. Close product-half gaps proactively. Compare the issue against what a
40	complete SPEC product half needs (goals, scope in/out, business goals,
41	i18n/SEO/a11y/pricing per the docs map, a UI design reference when the
42	feature has a UI surface), probing the same fixed vagueness rubric
43	`design-feature`'s interview uses: affected users/roles · error & edge
44	states · data shape · boundaries & limits · out of scope · success
45	criteria — each slot filled or explicit `n/a: <reason>`. For each genuine
46	gap you can't safely default, ask the user **one question per turn, never
47	batched**, each with a recommended default; never ask what the issue or
48	docs already answer. Structural hand-off threshold: if ≥ 3 rubric
49	slots remain unfillable from the issue plus the answers so far, stop and
50	hand the feature to `design-feature` (the thin-issue rule below, now with
51	a fixed trigger) instead of continuing to interview here.
52	5. Satisfy capability closure. Walk the same fixed checklist
53	`design-feature` uses (per entity: CRUD + state transitions, each with UI +
54	API + test, or explicit `n/a: <reason>`; per capability: entry point + ACL;
55	per role: assigned/revoked/viewed where) into the SPEC's `## Capability
56	closure` and `## Acceptance criteria`. **A thin issue that doesn't carry
57	enough to fill it is not a shortcut around the gate** — hand it to
58	`design-feature` (compose in-turn only at ≥ this skill's tier, per
59	Guardrails; otherwise hand off with `run /design-feature <slug>` and stop
60	here) rather than stamping `designed` on a hollow closure.
61	6. Size it. Estimate `XS / S / M / L` (scale defined in the SPEC template)
62	and record it in the SPEC. XS/S → the SPEC is the only planning artifact
63	(single-pass execution); M/L → full artifact set. If L, propose splitting.
64	7. Produce the SPEC product half. Fill it and stamp `## Design status:
65	designed` once closure is complete; set the roadmap row (added at `idea`
66	first if it didn't exist) to `defined` in the same edit — the same
67	`idea → defined` transition `design-feature` owns, performed here when this
68	skill is the one that satisfies closure. The `plan-feature` router then runs
69	`plan-feature-scaffold` for the engineering half + `defined → planned`
70	roadmap promotion.
71	8. Wire traceability. Record `#N` in the SPEC; the PR body must include
72	`Closes #N` so the issue closes on merge.
73	9. Hand off — return exactly (fixed completion report, back to the router):
74
75	```
76	ISSUE #<N> → SPEC <slug> — size: <XS\|S\|M\|L>
77	Verdict: feature (not bug/debt — else this would have routed to triage-issue)
78	Gaps closed: <n> asked / <n> defaulted (logged) Closure: designed \| handed to design-feature
79	Traceability: Closes #<N> wired
80	→ scaffold next (plan-feature-scaffold)
81	```
82
83	## Guardrails
84
85	- Don't silently

People who liked this also viewed

6 picks

Type

plan-feature-from-issue

35installs2forks

View on GitHub

How to install plan-feature-from-issue?

gtrabanco/agentic-workflow/plan-feature-from-issue

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

Installs into the current project.

Summary

Internal step of plan-feature: turn a feature-request issue into a scoped, sized, roadmap-mapped SPEC product half (capability closure satisfied) with Closes #N traceability.

Files · 1

View on GitHub

SKILL.md

1	# Plan Feature — From Issue (internal)
2
3	Convert a feature-request issue into the project's planning artifacts, keeping a
4	clean issue → SPEC → PR(Closes #n) trace. Writes the SPEC's product half
5	(same two-halves convention `design-feature` uses) and must satisfy capability
6	closure before handing off — a thin issue does not get a shortcut around it.
7
8	## When to use
9
10	- The `plan-feature` router calls this when the input is a GitHub issue (or
11	`--from-issue N`) that describes new product capability.
12
13	If the issue is a bug or tech-debt, stop and route it: `triage-issue` to
14	classify, then `plan-fix` + `execute-phase --fix`. This skill is for
15	genuine features only.
16
17	## Step 0 — Discover the project (always first)
18
19	Per the agent guide's Workflow conventions + documentation map, then read
20	what THIS skill needs: the feature SPEC template, the roadmap, and the issue/PR
21	templates (`.github/ISSUE_TEMPLATE/`, `.github/PULL_REQUEST_TEMPLATE.md`) so the
22	SPEC mirrors the fields reviewers expect. Then read the issue (forge CLI per the
23	project's Workflow conventions — examples use `gh`):
24
25	```sh
26	gh issue view <N> --json number,title,body,labels,state,comments
27	```
28
29	## Process
30
31	1. Classify first. Confirm it is a feature. Not a feature if it describes a
32	defect, regression, duplicated code, perf debt, or carries a "when to
33	fix / trigger" clause → hand to `triage-issue`. State the verdict explicitly.
34	2. Normalize language. If not in the project's docs language (this repo:
35	English), translate before drafting any artifact.
36	3. Map to the roadmap. Assign the next number + slug. Identify dependencies
37	and conflicts with existing features, coupling/migration risks, and whether
38	it should instead extend an existing feature.
39	4. Close product-half gaps proactively. Compare the issue against what a
40	complete SPEC product half needs (goals, scope in/out, business goals,
41	i18n/SEO/a11y/pricing per the docs map, a UI design reference when the
42	feature has a UI surface), probing the same fixed vagueness rubric
43	`design-feature`'s interview uses: affected users/roles · error & edge
44	states · data shape · boundaries & limits · out of scope · success
45	criteria — each slot filled or explicit `n/a: <reason>`. For each genuine
46	gap you can't safely default, ask the user **one question per turn, never
47	batched**, each with a recommended default; never ask what the issue or
48	docs already answer. Structural hand-off threshold: if ≥ 3 rubric
49	slots remain unfillable from the issue plus the answers so far, stop and
50	hand the feature to `design-feature` (the thin-issue rule below, now with
51	a fixed trigger) instead of continuing to interview here.
52	5. Satisfy capability closure. Walk the same fixed checklist
53	`design-feature` uses (per entity: CRUD + state transitions, each with UI +
54	API + test, or explicit `n/a: <reason>`; per capability: entry point + ACL;
55	per role: assigned/revoked/viewed where) into the SPEC's `## Capability
56	closure` and `## Acceptance criteria`. **A thin issue that doesn't carry
57	enough to fill it is not a shortcut around the gate** — hand it to
58	`design-feature` (compose in-turn only at ≥ this skill's tier, per
59	Guardrails; otherwise hand off with `run /design-feature <slug>` and stop
60	here) rather than stamping `designed` on a hollow closure.
61	6. Size it. Estimate `XS / S / M / L` (scale defined in the SPEC template)
62	and record it in the SPEC. XS/S → the SPEC is the only planning artifact
63	(single-pass execution); M/L → full artifact set. If L, propose splitting.
64	7. Produce the SPEC product half. Fill it and stamp `## Design status:
65	designed` once closure is complete; set the roadmap row (added at `idea`
66	first if it didn't exist) to `defined` in the same edit — the same
67	`idea → defined` transition `design-feature` owns, performed here when this
68	skill is the one that satisfies closure. The `plan-feature` router then runs
69	`plan-feature-scaffold` for the engineering half + `defined → planned`
70	roadmap promotion.
71	8. Wire traceability. Record `#N` in the SPEC; the PR body must include
72	`Closes #N` so the issue closes on merge.
73	9. Hand off — return exactly (fixed completion report, back to the router):
74
75	```
76	ISSUE #<N> → SPEC <slug> — size: <XS\|S\|M\|L>
77	Verdict: feature (not bug/debt — else this would have routed to triage-issue)
78	Gaps closed: <n> asked / <n> defaulted (logged) Closure: designed \| handed to design-feature
79	Traceability: Closes #<N> wired
80	→ scaffold next (plan-feature-scaffold)
81	```
82
83	## Guardrails
84
85	- Don't silently

People who liked this also viewed

6 picks

Type