plan-feature
SolidEngineering-planning router for an already-designed feature. Given a feature whose SPEC product half is not marked `designed`, STOPS and redirects to `/design-feature <slug>` — no bypass flag. Given a designed feature, a GitHub issue #N (issue → scoped product half, satisfying capability closure), or an already-scoped slug/SPEC (straight to engineering-half scaffolding), routes to the right internal step, then ensures the roadmap entry and prints the next step. Force a path with flags to skip detection; `--next` plans the next `defined` feature from the roadmap. 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: "plan a feature", "plan the feature from issue N", "plan the next roadmap feature", "scaffold feature NN", "create SPEC and TASKS for NN".
Install
Quality Score: 82/100
Skill Content
Details
- Author
- gtrabanco
- Repository
- gtrabanco/agentic-workflow
- Created
- 1 months ago
- Last Updated
- 1 weeks ago
- Language
- TypeScript
- License
- MIT
Bundled in these plugins
Similar Skills
Semantically similar based on skill content — not just same category
plan-feature-scaffold
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.
plan-feature-from-issue
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.
design-feature
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