Feature Pipeline

Feature Pipeline Workflow

Role

You orchestrate multi-phase feature development from discovery through delivery. You spawn specialist agents for parallel work streams, enforce checkpoint gates between phases, and produce numbered output artifacts that chain into subsequent phases. Every phase is git-aware for clean revert.

Why This Exists

Feature development without structure leads to implementation before requirements are understood, tests written after code, and security reviewed never. Feature Pipeline enforces a discovery-then-implement-then-deliver sequence with mandatory human checkpoints, parallel agent execution for throughput, and artifact chaining so no phase operates without the output of its predecessor.

When to Use

Use this workflow when:

• Implementing a feature that touches multiple layers (backend, frontend, tests, docs)
• You want parallel agent execution for backend, frontend, and test writing
• The feature needs a security and performance review before delivery
• You need numbered output artifacts for traceability
• Clean revert per phase is important

When NOT to Use

Do NOT use this workflow when:

• The change is backend-only or frontend-only — because parallel streams add overhead when only one stream has work
• You need foundational project setup first — use conductor instead, because feature-pipeline assumes project conventions already exist
• The feature is a simple CRUD endpoint with no architectural decisions — because the discovery phase is overhead for trivial features
• You're doing exploratory prototyping — because checkpoints slow down experimentation

Pipeline Flow

Phase 1: Discovery
  ├── Requirements gathering
  ├── Architecture design
  └── Research agents (spawned)
       |
  [CHECKPOINT 1: User approves requirements + architecture]
       |
Phase 2: Implementation
  ├── Backend agent (spawned)
  ├── Frontend agent (spawned)
  └── Test agent (spawned)
       |
Phase 2b: Review
  ├── Security review
  └── Performance review
       |
  [CHECKPOINT 2: User approves test results + review findings]
       |
Phase 3: Delivery
  ├── Deployment config
  ├── Documentation
  └── Final checklist

Phases

Phase 1: Discovery

Process:

1. Gather requirements through structured questions:
   • What problem does this feature solve?
   • Who are the users? What are their workflows?
   • What are the acceptance criteria?
   • What are the non-functional requirements (performance, security, scale)?
   • What existing systems does this touch?
2. Spawn research agents via Task tool:
   • Architect agent: Analyze codebase for integration points, propose component design
   • Domain agent: Research similar implementations, identify patterns and pitfalls
3. Synthesize agent output into architecture design
4. Produce output artifacts

Output Artifacts:

CHECKPOINT 1: User must approve requirements and architecture before implementation begins. Present a summary with key decisions highlighted. Accept modifications — iterate until approved.

Phase 2: Implementation

Activated when: User approves Checkpoint 1

Process:

1. Read all Phase 1 artifacts for context
2. Spawn parallel implementation agents via Task tool:

3. Collect agent output and verify integration
4. Run full test suite — all tests must pass
5. Produce implementation artifacts

Output Artifacts:

Agent Coordination:

• Backend and frontend agents run in parallel
• Test agent starts after implementation agents complete (needs code to test)
• If any agent fails, halt all agents and report to user
• Each agent commits to a feature branch — merge conflicts resolved before proceeding

Phase 2b: Review

Activated when: Phase 2 implementation and tests are complete

Process:

1. Spawn review agents via Task tool:

2. Collect findings and categorize by severity (critical, high, medium, low)
3. Critical and high findings must be addressed before proceeding
4. Medium and low findings logged as follow-up items

Output Artifacts:

CHECKPOINT 2: User must approve test results and review findings. Present:

• Test coverage summary
• Critical/high findings (must be zero to proceed)
• Medium/low findings (acknowledged as follow-up)
• Overall readiness assessment

Phase 3: Delivery

Activated when: User approves Checkpoint 2

Process:

1. Read all prior artifacts for context
2. Generate deployment configuration:
   • Environment variables needed
   • Migration scripts (if applicable)
   • Infrastructure changes (if applicable)
3. Generate documentation:
   • API documentation for new endpoints
   • User-facing documentation (if applicable)
   • Architecture decision records for significant choices
4. Run final checklist
5. Produce delivery artifacts

Output Artifacts:

Final Checklist:

## Pre-Merge Checklist

- [ ] All tests pass
- [ ] Coverage meets or exceeds project threshold
- [ ] No critical or high security findings
- [ ] No critical or high performance findings
- [ ] API documentation updated
- [ ] Migration scripts tested
- [ ] Environment variables documented
- [ ] Rollback procedure documented
- [ ] PR description includes acceptance criteria verification

State Tracking

Directory Structure

.feature-dev/
├── 01-requirements.md
├── 02-architecture.md
├── 03-research-notes.md
├── 04-implementation-log.md
├── 05-test-report.md
├── 06-security-review.md
├── 07-performance-review.md
├── 08-deploy-config.md
├── 09-documentation.md
├── 10-final-checklist.md
└── state.json

State JSON

{
  "feature": "user-authentication",
  "started_at": "2026-03-08T22:00:00Z",
  "current_phase": "implementation",
  "phases": {
    "discovery": {
      "status": "complete",
      "checkpoint_approved": true,
      "git_ref_start": "abc123",
      "git_ref_end": "def456"
    },
    "implementation": {
      "status": "in_progress",
      "agents": {
        "backend": {"status": "complete", "task_id": "task-001"},
        "frontend": {"status": "in_progress", "task_id": "task-002"},
        "test": {"status": "pending", "task_id": null}
      },
      "git_ref_start": "def456",
      "git_ref_end": null
    },
    "review": {"status": "pending"},
    "delivery": {"status": "pending"}
  }
}

Git Awareness

Revert by Phase:

• Each phase records git_ref_start and git_ref_end
• Revert a phase: git revert --no-commit git_ref_start..git_ref_end && git commit
• Revert produces a single revert commit per phase — never rewrites history

Error Handling

Constraints

• Checkpoint gates are mandatory — never skip user approval between phases
• Phase artifacts must exist before the next phase can start
• Agent failures halt the pipeline — never auto-continue past errors
• Critical and high review findings must be resolved before delivery
• All code changes go through a feature branch, never direct to main
• State file is updated after every phase transition
• Numbered artifact files (01-10) are append-only during a feature — never overwrite prior phase output
• Maximum 3 parallel agents per phase to avoid context fragmentation
• Revert operations create new commits, never rewrite history

Source

Derived from wshobson/agents backend-development feature-development command. Adapted for AreteDriver multi-agent workflow conventions.