# Workflow Feature Spec

> Run the full feature-spec pipeline for a new product / feature with commercial stakes — biz-brief (business context) → superpowers:brainstorming (technical spec) → superpowers:writing-plans (implementation plan). Use when the user says "let's build X", "I want to ship Y", "spec out this feature", "go from idea to plan for Z", or when starting any new feature with a user / market / business model. Do NOT use for purely internal tooling (skip biz-brief; go straight to brainstorming) or for bug fixes (use debugging-and-error-recovery instead).

- Skill: `slogsdon/workflow-feature-spec` (Agent Skill)
- Install (CLI): `npx skillmds@latest add slogsdon/workflow-feature-spec`
- Raw SKILL.md: https://api.skillmd.com/api/skills/slogsdon/workflow-feature-spec/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: slogsdon (https://skillmd.com/u/slogsdon)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/slogsdon/workflow-feature-spec

---


# Skill: /workflow-feature-spec

Pipeline that takes a fuzzy feature idea and ends with an executable implementation plan grounded in business intent + technical spec.

## When to use

- New feature / product / initiative with commercial stakes.
- The user is at the "let's build X" stage; no spec yet.

## When NOT to use

- Internal tooling with no user/market layer → call `superpowers:brainstorming` directly.
- Bug fix → use the debug-and-fix flow instead.
- Already have a spec → call `superpowers:writing-plans` directly.

## Steps

| Step name | Stage              | Invokes                       |
|-----------|--------------------|-------------------------------|
| `brief`   | Business context   | `biz-brief`                   |
| `spec`    | Technical spec     | `superpowers:brainstorming`   |
| `plan`    | Implementation plan| `superpowers:writing-plans`   |

### Stage 1: Business context — step `brief` — invokes `biz-brief`

Generates a 1-page Business Context Brief and saves it to `docs/superpowers/briefs/YYYY-MM-DD-<feature>.md`.

Output: brief file exists.
Checkpoint: confirm brief is accurate before brainstorming.

### Stage 2: Technical spec — step `spec` — invokes `superpowers:brainstorming`

Brainstorms the technical spec with the brief loaded as context. Saves spec to `docs/superpowers/specs/YYYY-MM-DD-<feature>.md`.

Output: spec file exists.
Checkpoint: confirm spec coverage before writing the plan.

### Stage 3: Implementation plan — step `plan` — invokes `superpowers:writing-plans`

Reads the spec and produces a task-by-task plan at `docs/superpowers/plans/YYYY-MM-DD-<feature>.md`.

Output: plan file exists, ready to hand off to `subagent-driven-development` or `executing-plans`.

## Resume protocol

Default: run `brief` → `spec` → `plan` in order, with checkpoints between each.

`--resume-from <step>`: skip every step before `<step>` and begin from `<step>`. The named step itself runs.

If `<step>` is not in `{brief, spec, plan}`, print:

    Invalid resume-from step: <step>
    Valid steps: brief, spec, plan

…and stop.

### Required state when resuming

Before running the resume step, confirm the listed inputs exist. If anything is missing, prompt the user for it.

- `--resume-from brief` — same as a fresh run; needs only the feature name.
- `--resume-from spec` — needs the brief at `docs/superpowers/briefs/YYYY-MM-DD-<feature>.md`. If absent, ask the user to paste it or run from `brief`. Brainstorming loads the brief as context.
- `--resume-from plan` — needs the spec at `docs/superpowers/specs/YYYY-MM-DD-<feature>.md`. If absent, ask the user to paste it or run from `spec`. Writing-plans operates on the spec.

Examples:

    /workflow-feature-spec --resume-from spec   # brief already exists, brainstorm from it
    /workflow-feature-spec --resume-from plan   # spec is approved, just write the plan

## Other flags

- `--no-pause` to run end-to-end (rare — usually you want the checkpoints here).

## Session open

Check for `docs/superpowers/STATE.md`. If it exists, read `Verified facts`, `General rules`, and `Last session` before starting — these carry forward what the last run learned so this run doesn't re-derive it.

## Stage quality gate

After each stage completes, before the checkpoint: does the output actually satisfy the stage goal (brief = business intent clear; spec = technical approach decided; plan = tasks are executable)? If it partially misses, retry the stage once with an explicit note on the gap. On second failure, surface the issue to the user rather than continuing.

Stage validation should use a separate verification pass (re-read the output with fresh eyes as a critic, not as the author) rather than the author confirming their own work.

## Session close

After the pipeline completes, append to `docs/superpowers/STATE.md`:
- Any decisions that were non-obvious and should not be re-derived next time
- Any stage that required a retry and why
- The resume pointer (last step completed, next step if interrupted)

If a stage consistently required retries across multiple runs, update this SKILL.md's stage description with the failure mode.

## Failure handling

Brainstorming and writing-plans both have their own surface-assumptions / push-back behaviors built in. The workflow does not paper over those — when a sub-skill asks a clarifying question, the workflow surfaces it to the user. If a stage errors, stop and print the failed step plus the resume command (`/workflow-feature-spec --resume-from <step>`).