القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | plan-feature-from-issue |
| user-invocable | false |
| version | 1.5.0 |
| author | Gabriel Trabanco <gtrabanco@users.noreply.github.com> |
| license | MIT |
| description | 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. |
Convert a feature-request issue into the project's planning artifacts, keeping a
clean issue → SPEC → PR(Closes #n) trace. Writes the SPEC's product half
(same two-halves convention design-feature uses) and must satisfy capability
closure before handing off — a thin issue does not get a shortcut around it.
plan-feature router calls this when the input is a GitHub issue (or
--from-issue N) that describes new product capability.If the issue is a bug or tech-debt, stop and route it: triage-issue to
classify, then plan-fix + execute-phase --fix. This skill is for
genuine features only.
Per the agent guide's Workflow conventions + documentation map, then read
what THIS skill needs: the feature SPEC template, the roadmap, and the issue/PR
templates (.github/ISSUE_TEMPLATE/, .github/PULL_REQUEST_TEMPLATE.md) so the
SPEC mirrors the fields reviewers expect. Then read the issue (forge CLI per the
project's Workflow conventions — examples use gh):
gh issue view <N> --json number,title,body,labels,state,comments
Classify first. Confirm it is a feature. Not a feature if it describes a
defect, regression, duplicated code, perf debt, or carries a "when to
fix / trigger" clause → hand to triage-issue. State the verdict explicitly.
Normalize language. If not in the project's docs language (this repo: English), translate before drafting any artifact.
Map to the roadmap. Assign the next number + slug. Identify dependencies and conflicts with existing features, coupling/migration risks, and whether it should instead extend an existing feature.
Close product-half gaps proactively. Compare the issue against what a
complete SPEC product half needs (goals, scope in/out, business goals,
i18n/SEO/a11y/pricing per the docs map, a UI design reference when the
feature has a UI surface), probing the same fixed vagueness rubric
design-feature's interview uses: affected users/roles · error & edge
states · data shape · boundaries & limits · out of scope · success
criteria — each slot filled or explicit n/a: <reason>. For each genuine
gap you can't safely default, ask the user one question per turn, never
batched, each with a recommended default; never ask what the issue or
docs already answer. Structural hand-off threshold: if ≥ 3 rubric
slots remain unfillable from the issue plus the answers so far, stop and
hand the feature to design-feature (the thin-issue rule below, now with
a fixed trigger) instead of continuing to interview here.
Satisfy capability closure. Walk the same fixed checklist
design-feature uses (per entity: CRUD + state transitions, each with UI +
API + test, or explicit n/a: <reason>; per capability: entry point + ACL;
per role: assigned/revoked/viewed where) into the SPEC's ## Capability closure and ## Acceptance criteria. A thin issue that doesn't carry
enough to fill it is not a shortcut around the gate — hand it to
design-feature (compose in-turn only at ≥ this skill's tier, per
Guardrails; otherwise hand off with run /design-feature <slug> and stop
here) rather than stamping designed on a hollow closure.
Size it. Estimate XS / S / M / L (scale defined in the SPEC template)
and record it in the SPEC. XS/S → the SPEC is the only planning artifact
(single-pass execution); M/L → full artifact set. If L, propose splitting.
Produce the SPEC product half. Fill it and stamp ## Design status: designed once closure is complete; set the roadmap row (added at idea
first if it didn't exist) to defined in the same edit — the same
idea → defined transition design-feature owns, performed here when this
skill is the one that satisfies closure. The plan-feature router then runs
plan-feature-scaffold for the engineering half + defined → planned
roadmap promotion.
Wire traceability. Record #N in the SPEC; the PR body must include
Closes #N so the issue closes on merge.
Hand off — return exactly (fixed completion report, back to the router):
ISSUE #<N> → SPEC <slug> — size: <XS|S|M|L>
Verdict: feature (not bug/debt — else this would have routed to triage-issue)
Gaps closed: <n> asked / <n> defaulted (logged) Closure: designed | handed to design-feature
Traceability: Closes #<N> wired
→ scaffold next (plan-feature-scaffold)
Closes #N link; an issue-born feature must close it.## Design status: designed with a blank Capability closure
row — the same rule design-feature follows; a thin issue hands off
instead of faking closure.design-feature in-turn for a thin issue is
allowed only when this skill is running at ≥ design-feature's tier
(planning-class — strongest model / highest effort); otherwise hand off
(run /design-feature <slug>) rather than under-power it.triage-issue — decides bug vs feature vs defer; call it if unsure.plan-fix — the fix-side sibling for bug/debt issues.design-feature — receives thin issues this skill cannot safely close
capability closure for; both write the SPEC's product half in the same format.plan-feature-scaffold — fills the engineering half once the product half
is designed.execute-phase — executes the phases; its PR carries Closes #N.design-feature instead of faking it) and ## Design status is accurate.defined (added at idea first if new) whenever
## Design status: designed was stamped — never defined on a hollow
closure, never left at idea once designed is stamped.#N is recorded and the PR plan includes Closes #N.Periodic, product-wide health check — the CTO's "where do we actually stand?" Sweeps the WHOLE codebase (not a diff, not a PR) across every applicable axis — correctness, architecture, security/cybersecurity, performance, tests, UX/UI, accessibility, SEO, brand, tech debt — PLUS process & docs (incomplete phases, aging issues, solvable known-issues, doc/workflow completeness) and roadmap coherence. Mines accumulated suggestions from feature docs. Output: a severity-ranked report and concrete PROPOSALS — issues to open, roadmap features to add or remove. Every run is persisted to docs/audits/<n>-<YYYY-MM-DD>.md with an incremental audit id and findings numbered F1, F2, … so any finding is addressable later as "triage-issue <audit-id> F<k>". NEVER auto-fixes; the user decides what to act on. On Claude Code and want hand-tuned per-skill model/effort tiers? Install the `#claude` branch instead (`npx skills add gtrabanco/agentic-workflow#claude`) — see the README. This branch is model-agnostic: the skill inherits
Classify an issue and take a defensible decision: fix-now, postpone (deferred/trigger-based), wontfix, or promote-to-feature. Reads the issue's own "when to fix"/trigger and severity, verifies the trigger against the CURRENT codebase (counts consumers, checks thresholds, measures), then routes or reports with a dated, auditable comment. Also triages product-audit findings ("triage-issue <audit-id> F<k>"): reads docs/audits/<audit-id>-*.md, verifies the finding, and opens the GitHub issue only if the verdict warrants it. On Claude Code and want hand-tuned per-skill model/effort tiers? Install the `#claude` branch instead (`npx skills add gtrabanco/agentic-workflow#claude`) — see the README. This branch is model-agnostic: the skill inherits whatever model and effort your agent session is already using. Triggers: "triage issue N", "should we fix #N now", "classify this issue", "is #N's trigger met", "what do we do with #N".
Turn an idea or a feature request into an exhaustive, checkable product definition — the stage before engineering planning. The core mechanism is **capability closure**: a checklist that forces every entity, capability, and role a feature introduces to be walked to its full surface (CRUD + state transitions + UI entry point + API + test, or an explicit design-time `n/a`), so non-frontier executor models stop silently omitting the implicit work ("auth with dashboard management and ACLs" must not collapse to a users table + a list view). Closure has three fixed checklists: **entity closure** (each entity to full surface), **integration closure** (the feature reconciled against every subsystem in the project's capability inventory, `docs/CAPABILITIES.md` — auth, ACL, navigation, notifications, …), and the **role matrix** (every inventory role explicitly allowed/denied per capability) — plus an **expectation sweep** that forces what a competent human would implicitly assume ("a blog has drafts") into in-scope/out
Implement one phase of a feature (default), or a small feature / a fix (--fix) by its SPEC's ## Phases ledger — one phase per invocation, the final phase is always Hardening & PR (the close-out); legacy SPECs without ## Phases run end-to-end in a single pass. Enforces branch safety, issue policy, the project's verification gate, and per-phase doc discipline. On Claude Code and want hand-tuned per-skill model/effort tiers? Install the `#claude` branch instead (`npx skills add gtrabanco/agentic-workflow#claude`) — see the README. This branch is model-agnostic: the skill inherits whatever model and effort your agent session is already using. Triggers: "execute phase P1 of NN", "implement the NN feature", "build NN from its spec", "execute-phase NN P2", "execute-phase --fix".
Bootstrap a project's way of working: fetch the agentic-workflow documentation scaffold (template/) and adapt it to THIS project by interview — fill the CLAUDE.md documentation map, gate commands and architecture, prune doc folders that don't apply, keep the SPEC/feature/fix and GitHub templates — then offer to install the skills. The adaptive counterpart to a raw `npx degit` copy. On a repo that already has the scaffold, detects it and switches to **upgrade mode**: diffs the project's substrate against the current template, reads `docs/workflow/MIGRATION.md`, and proposes only the blocks the project is missing — never clobbering a tailored one. On Claude Code and want hand-tuned per-skill model/effort tiers? Install the `#claude` branch instead (`npx skills add gtrabanco/agentic-workflow#claude`) — see the README. This branch is model-agnostic: the skill inherits whatever model and effort your agent session is already using. Triggers: "set up the agentic workflow here", "init-workspace", "scaffold this proje
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 hardening phase) and register the roadmap entry. Docs only — never code.