Feature
The broadest request type: feature builds a new capability end-to-end through the full staged pipeline. It runs in the pipeline layer with shape pipeline, so the orchestrator drives it as a pure conductor — clarify, brainstorm, plan, execute, test, document, review (optional), validate, each dispatched as a sub-agent — from a raw intake in jobs/0_new/ to a landed job in jobs/4_done/.
The registry at _processes/_shared/request-types.md and the preset at _processes/_shared/presets/feature.md are the source of truth for everything on this page.
The flow
A feature job runs the full eight-stage pipeline in canonical order. The orchestrator dispatches each enabled stage as a sub-agent, verifies its artifact on disk, parses its handoff, and writes the shared job-root state. Seven stages are enabled by the preset; review is off by default — you remove its (disabled) marker to turn it on before promoting.
For full stage-by-stage detail — inputs, outputs, and source prompts — see The eight pipeline stages.
What it is for
Choose feature when you are building something new — a capability that does not exist yet and warrants the full design-and-ship discipline: pressure-test the idea, explore approaches, plan the work in phases, write the code, test it, document it, and validate it against the mandate.
It produces
Working source changes on a feature branch, plus the stage artifacts (clarify report, dual brainstorm + consolidation, phased plan, execution notes, test notes, doc notes, validate report) and — by default — a commit and a PR.
When to choose it
A net-new capability or a substantial enhancement that benefits from brainstorming and a multi-phase plan. For a defect fix, prefer bug (lean pipeline, no brainstorm/document).
What it does not do
It is not a report-only type (that's brainstorm), not a batch of small independent fixes (that's quick_fix), and it does not skip stages by default — every stage except review is enabled.
The logic
At pickup the orchestrator reads JOB.md → Type, looks up its layer (pipeline) and shape (pipeline) in the registry, and — because the layer is pipeline — reads ## Stages and PROGRESS.md → Stages to build the run plan. For each of the eight stages in canonical order it skips the line if it carries (disabled), skips it if PROGRESS.md already shows [x], and otherwise marks it pending.
For each pending stage the orchestrator dispatches the standalone prompt under _processes/02_orchestrator/stages/ (or the helper prompts under _processes/04_brainstorm/ for brainstorm and _processes/10_review/ for review), verifies the declared artifact, parses the stage's STAGE_HANDOFF, and updates the shared job-root state itself. It never writes a stage's source, tests, docs, or report — it is a pure conductor (D-56).
Approval gates that apply
Gates are stop points the orchestrator honours when set to yes. The feature preset enables four of the seven:
| Gate | Preset | Fires |
|---|---|---|
after_creation | no | After creation/bootstrap writes the job into 1_creation/, before it advances to 2_ready/. |
after_clarify | yes | After the clarify report, before any downstream stage (skipped when the verdict is NO_CLARIFICATION_NEEDED). |
after_brainstorm | yes | After the consolidated brainstorm and its human recap, before plan. |
before_plan | no | Before the plan stage starts. |
before_execution | no | Before the first execute phase runs. |
before_commit | yes | At the post-validate git landing, before the change is committed (renders inside the Git section of the form; D-63). |
before_pr | yes | At the same landing, before the workflow opens the PR (renders inside the Git section of the form). |
The fields
A feature JOB.md carries the pipeline shape: header fields, a ## Git block, the eight ## Stages, the seven ## Approval gates, and a ## Per-stage config sub-section per enabled stage. The values below are the feature preset's defaults, grounded in _processes/_shared/presets/feature.md and the JOB.md contract.
Header
| Field | Meaning |
|---|---|
Type | feature — drives the preset defaults and the pipeline/pipeline route. |
Preset | feature — the preset the creation/bootstrap step seeded defaults from. |
Base branch | The branch work is based on (default main). |
Target branch | The created feature branch, e.g. feature/<slug>. |
## Git
| Line | Meaning |
|---|---|
Create branch: yes | The creation/bootstrap step creates the feature branch before any stage runs. |
Validate against main: yes | Validate cross-checks the change against main. |
Commit: yes | The change is committed at the post-validate git landing (orchestrator §I, gated by before_commit; D-63) — one commit per landing, <type>/<slug>: <job title>. |
PR: yes | The workflow opens the PR at the same landing (gated by before_pr) — push the job branch, then gh pr create to the resolved target; remote-aware fallback off GitHub. Merging stays user-owned — the workflow never merges. |
Push: yes | Pushes the job branch to origin immediately after the commit — a standalone landing step on every remote host, not just GitHub (D-82). PR: yes requires it. |
PR target branch: (blank) | The branch the PR merges INTO; blank ⇒ production (0.14, D-63). Distinct from Base branch (the branch the job branch is cut FROM, default main). |
## Stages (eight, canonical order)
| Stage | State | Meaning |
|---|---|---|
clarify | enabled | Pressure-test the mandate against the codebase; propose the canonical Mandate-body rewrite. |
brainstorm | enabled | Produce divergent design thinking, then consolidate (dual mode). |
plan | enabled | Turn the mandate + consolidated brainstorm into a phased PLAN.md. |
execute | enabled | Apply the plan to the source tree, one phase per dispatch. |
test | enabled | Run / author tests per the Test config. |
document | enabled | Update host / user docs per the Document config. |
review | (disabled) | Off by default — adversarial Codex code review; remove the marker to enable. |
validate | enabled | Cross-check the whole job against the mandate and acceptance criteria. |
## Approval gates
| Gate | Default | Meaning |
|---|---|---|
after_creation | no | Stop in 1_creation/ for review of the generated JOB.md. |
after_clarify | yes | Stop to review the clarify report (auto-skip on NO_CLARIFICATION_NEEDED). |
after_brainstorm | yes | Stop to review the consolidated brainstorm. |
before_plan | no | Stop before planning. |
before_execution | no | Stop before the first execute phase. |
before_commit | yes | Stop at the post-validate git landing, before committing (the staged-diff summary is shown). |
before_pr | yes | Stop right before gh pr create (the generated PR description + resolved target are shown). |
## Per-stage config
| Block | Default | Meaning |
|---|---|---|
Brainstorm | Mode: dual_consolidate, Agents: claude, codex, Consolidator: claude | Two independent writers (Claude and Codex) launched together, then a Claude consolidation. |
Plan | Multi-phase: yes | Break the work into atomic, session-sized phases. |
Execute | Delegate research to sub-agents: yes | Execute may spawn read-only research sub-agents for parallel reads. |
Test | Unit: yes | Run / author unit tests. |
Document | Internal: yes | Update internal / host documentation. |
Validate | Cross-check against mandate: yes, Agent: claude | Validate against the mandate; runtime claude (override to codex per job). |
Review | omitted by default | No config block while review is (disabled); add one when you enable the stage. |
feature job carries ### KISS mode / - Enabled: yes first under ## Per-stage config unless you un-tick the pre-ticked checkbox below the mandate textarea — the feature preset declares KISS on. The block is omitted when off, and creation derives the flag solely from a positive intake block, so un-ticking really produces a KISS-off job. When on, build stages follow _processes/_shared/kiss-mode.md §2 and review/validate follow §3. Section 1 keeps the mandate and app.md authoritative while allowing mandate-scoped, evidence-based removal of an existing control when no governing obligation or material risk is weakened; KISS alone is never sufficient authority. This optional absent-reads-as-off field does not bump workflow contract 0.15.
review is (disabled) by default, a feature JOB.md has no ### Review block until you enable the stage. A lingering config block for a disabled stage is a contract violation.
How to run it
Drop an intake describing the feature in jobs/0_new/, then send the orchestrator the prompt path below. It bootstraps the intake into a feature job, creates the branch, and runs the staged pipeline through to 4_done/, stopping at each enabled approval gate.
_processes/02_orchestrator/orchestrator.prompt.md