develop-feature

Purpose

Take one feature request from words to a reviewed, tested, traceable change, with a human decision recorded in the middle. The workflow owns the order of work, the gate, and the artifact contract; the eight composed skills own the work itself. Nothing here restates a skill's procedure — each step is a reference to a skill ID.

When to use

• A feature or behavioural change needs requirements, a plan, and a recorded approval before anything is edited.
• The change must be defensible later: which requirement, which task, which file, which test, which verdict.
• Do not use when the change is a one-line fix with no requirement worth recording — the run bundle would cost more than the change.
• Do not use when the work is diagnosing a defect. Use the debug family; this workflow assumes the desired behaviour is known, not discovered.

Inputs

Values are substituted from the invocation; ask the user for any that are missing.

• feature_request (required) — $1. The change being asked for, in the requester's own words.
• scope_path (optional) — $2. Subtree to inspect and change when the repository is a monorepo.

Procedure

Each numbered item names the step alias, the skill it invokes, and what it must leave behind. The procedure is in the skill; the sequence is here.

1. inspect_repository → discover.repository.inspect. Reads the working tree, honouring scope_path when supplied. Leaves context.

2. analyze_feature → requirements.feature.analyze. Reads feature_request and context. Leaves the requirements and acceptance_criteria sections of traceability, plus decisions entries of kind ambiguity and assumption.

3. plan_implementation → plan.feature.implement. Leaves impact_analysis, implementation_plan, and the tasks section of traceability.

   GATE — approve-implementation. Present the four evidence items, ask the question in approver_behavior.prompt, and stop. Only a human may answer, and only the exact word APPROVE is an approval: silence is not, a restatement of the plan is not, and the agent's own judgement that the plan is sound is not. On rejection, return to step 3. Nothing outside .sdlc/runs/${run_id}/ may be written until the decision is in approvals.

STOP — gate approve-implementation (human-approval, risk: medium). Authorize implementation of the reviewed plan before any file outside the run bundle is edited. Do not proceed to execute_implementation. Do not create, modify or delete any file outside .sdlc/runs/<run-id>/ until a human has recorded the decision with sdlc approve approve-implementation --run <run-id>. If you cannot confirm that an approved entry for approve-implementation exists in .sdlc/runs/<run-id>/approvals.yaml, stop and ask the user. This gate is Tier 1 — Enforced (declared, not measured) on claude-code: a PreToolUse hook entry in .claude/settings.json runs sdlc gate-check and returns a deny decision for the matched tool call before it executes. This tier is declared from vendor documentation and has not been measured on a running tool. The open prototype task behind that claim is named in the install report and in the spine's "Declared verification gaps" section. Detection is after the fact: sdlc verify-run reports a violation when artifacts from a step after this gate exist while .sdlc/runs/<run-id>/approvals.yaml has no approved entry for approve-implementation.

4. execute_implementation → develop.feature.execute. Runs only after the recorded approval. Leaves source changes and the changed_files section of traceability.

5. validate_change → test.change.validate. Leaves tests, the tests and validations sections of traceability, and validation_results. Where the target cannot execute commands, each verdict is written not_run with a reason and a declared degradation — never omitted, and never reported as a pass.

6. review_code → review.code.perform. Appends review: code entries to findings.

7. review_security → security.change.review. Appends review: security entries to the same findings file.

8. summarize_change → document.change.summarize. Leaves change_summary and the final status in run_header.

Numbering note: docs/16 §3.2 numbers the same run as twelve execution steps, because three of these skills own more than one step there. The eight aliases above are the schema-level skills[] entries; the gate is docs/16's step 7.

Validation

• sdlc validate examples/workflows/develop.feature.md — the frontmatter validates against schemas/workflow.schema.json, and the linter resolves every skill ID, step reference, gate after/before, evidence ref, and completion.required_artifacts entry.
• sdlc run verify ${run_id} — required artifacts present, written by their declared owner, and pre-approval hashes unchanged since approval (RI-13, RI-15).
• sdlc trace check --run ${run_id} — the chain resolves end to end, no orphans (RI-1…RI-12).
• A structural lint asserts that no procedure text in this file appears in any composed skill.

Artifacts

Artifact	Approval side	Owner	Validation
run_header	pre-approval	cli	schema
context	pre-approval	agent	schema, ≤64 KiB
traceability	both	agent	schema
decisions	both	agent	schema, append-only
impact_analysis	pre-approval	agent	prose + machine frontmatter
implementation_plan	pre-approval	agent	prose
approvals	pre-approval (written at the gate)	human	schema, append-only
validation_results	post-approval	agent	schema, append-only
findings	post-approval	agent	schema, append-only
change_summary	post-approval	agent	prose
requirements_view	pre-approval	cli	generated view, optional
code_review_narrative	post-approval	agent	prose, optional
security_review_narrative	post-approval	agent	prose, optional
run_index	repo-level, derived	cli	schema

Failure modes

Symptom	Response
A step fails and has no transitions entry	failure_policy.default: halt. The run stops, the failure is recorded in run_header, and partial artifacts are kept and marked incomplete.
validate_change fails	Route to execute_implementation once (max_reentries: 1). A second failure halts — a retry loop hides the failure the run exists to surface.
The gate is rejected	Return to plan_implementation (on_gate_denied: return-to-preceding-step). Re-entering that step re-arms the gate; the earlier decision never carries forward.
The approver replies ambiguously	Treat it as a rejection. reject_ambiguous is not authorable as false.
Post-approval artifacts exist with no approval entry	A detected violation (RI-13), not a supported mode — bypass_policy.allowed: false. Report E_GATE_BYPASSED; never repair it by writing an approval.
The target cannot run commands	validate_change writes not_run verdicts with degradation_ref, run_header status becomes completed-degraded, and change_summary carries the UNVERIFIED banner.
An adapter cannot enforce the gate	Compile it at its declared tier and state that tier at install time. Never describe Tier 3 as enforced.

Safety

Prohibited at the workflow level, in addition to every composed skill's own ## Safety block:

• proceeding past a denied or unrecorded gate decision;
• writing, editing or backdating approvals.yaml — that file is the human's, and the agent recording its own approval is not authorable (self_approval is const false);
• editing a pre-approval artifact after its hash is recorded, or rewriting history in an append-only artifact;
• writing anything outside .sdlc/runs/${run_id}/ before the approval is recorded;
• deleting or pruning a run bundle — it is gate evidence.

Example

/develop-feature Stop attackers from brute-forcing the login endpoint. scope_path=services/api

1 writes context.yaml: Node 22 / TypeScript (services/api/package.json:14), test vitest run (package.json:31). 2 writes REQ-001, AC-001, AC-002 into traceability.yaml and one ambiguity into decisions.yaml (window length not stated). 3 writes impact-analysis.md (predicted_paths: 3, risk: medium), implementation-plan.md, and TASK-001/TASK-002.

GATE — approve-implementation. Presents the plan, the impact analysis, the three traceability sections and the one open ambiguity, then asks "Approve this implementation plan? Reply with the exact word APPROVE…" — and stops. The working tree is untouched. On Claude Code the first Edit attempted before that record exists is blocked by the hook, not merely discouraged; on Codex and Copilot nothing blocks it and the violation is found later.

The reviewer replies APPROVE. sdlc gate approve appends the entry with the approver, the timestamp, and the sha256 of all four pre-approval artifacts.

4–5 two source files and one test file change; TEST-001/TEST-002 cover both criteria; VAL-001 test_execution passed, VAL-002 build passed. 6–7 two findings, both severity: low. 8 change-summary.md written, run.yaml status completed.

Recommends release.readiness.assess next.