| name | pipeline-spec |
| description | Use when turning a raw software feature idea into an approved specification before planning, tasks, implementation, review, or finalization. |
Pipeline Spec
Stage 1: idea -> spec.
Create .pipeline/<feature>/spec.md. The spec is the decision authority for
the rest of the pipeline. Do not write code or a commit/task plan in this stage.
Process
- Ground in the target repository before asking questions. Read project
instructions, manifests, existing docs, nearby code, tests, and CI/task
configuration.
- Separate discoverable facts from product intent. Ask only for decisions that
cannot be derived from the repo.
- Write a concise, testable spec with the shape below.
- Stop when the spec is complete enough to hand to
pipeline-plan.
Spec Shape
# Spec: <Feature>
## Objective
## Success Criteria
- Include observable user outcomes.
- Include expected human and agent/headless journeys.
## Users And Agent Surfaces
## Scope
- In:
- Out:
## Contracts And Interfaces
- APIs, CLIs, SDKs, schemas, UI routes, config, docs, generated artifacts, or
tool contracts that change.
## Decisions
- Decision:
- Why:
- Consequences:
## Test Journeys
- Human journey:
- Agent/headless journey:
## Open Questions
Handoff
.pipeline/<feature>/spec.md -> pipeline-plan.
