Imported from dayvidpham/pasture (.agents/skills/protocol/AGENTS.md). Install upstream with npx skills add dayvidpham/pasture --skill protocol. Copyright stays with the author.

Agent Roles and Phase Ownership

This document maps each agent role to its owned phases, available tools/skills, and handoff procedures.

See PROCESS.md for the full step-by-step workflow. See SKILLS.md for the complete command reference.

Role Summary

Epoch (Orchestrator)

Command: /pasture:epoch

Phases: All 12 (delegates to specialists)

Responsibility: Coordinates the full 12-phase workflow. Creates the initial REQUEST task, invokes the appropriate role skill for each phase, and ensures dependency chaining and audit trail preservation throughout. Orchestrates deferrals per C-uat-feedback-disposition — ALL deferred items (user- or agent-proposed) are raised to the user at the next user gate for confirmation.

Skills invoked:

• Phase 1: /pasture:user-request
• Phase 2: /pasture:user-elicit
• Phases 3-7: /pasture:architect
• Phases 5, 11: /pasture:user-uat
• Phases 7-10: /pasture:supervisor
• Phase 12: Manual git commit and push

Architect

Command: /pasture:architect

Phases owned: 1-7

Receives from: User (Phase 1 request) OR Supervisor via h6 (follow-up lifecycle: FOLLOWUP_URE + FOLLOWUP_URD for FOLLOWUP_PROPOSAL creation) Hands off to: Supervisor (Phase 7 h1 handoff document, or follow-up h1 after FOLLOWUP_PROPOSAL ratified)

Handoff: Authored in the HANDOFF Beads task body with full inline provenance — includes all task references (REQUEST, URD, PROPOSAL, ratified plan), key decisions with rationale, open items, and acceptance criteria.

Reviewer

Command: /pasture:reviewer

Phases owned: 4 (plan review), 10 (code review)

Plan Review (Phase 4)

Task title: PROPOSAL-N-REVIEW-{axis}-{round} (e.g., PROPOSAL-2-REVIEW-A-1)

Votes: Binary — ACCEPT or REVISE. No intermediate levels. All 3 must ACCEPT.

No severity tree for plan reviews — binary vote only.

Code Review (Phase 10)

Same 3 axes, applied to implementation slices.

Task title: SLICE-N-REVIEW-{axis}-{round} (e.g., SLICE-1-REVIEW-A-1)

Severity tree (EAGER creation): Always create 3 severity groups per review round:

• pasture:severity:blocker — Blocks the slice (dual-parent); must reach 0
• pasture:severity:important — Fixed in-wave; must reach 0 (NOT deferrable)
• pasture:severity:minor — Fixed in-wave; must reach 0 (NOT deferrable)

Empty groups are closed immediately. Configurable review-effort budget: iterate review → fix → re-review up to the budget chosen at Phase 8 (3 rounds / 1 round / 0 rounds / unlimited / custom) until a fix-free clean round confirms 0 BLOCKER + 0 IMPORTANT + 0 MINOR; on budget exhaustion without clean, surface the outstanding findings to the user at a gate. No review severity is routed to FOLLOWUP — the FOLLOWUP epic is fed only by user-DEFER'd UAT items.

Skills: /pasture:reviewer-review-plan, /pasture:reviewer-review-code, /pasture:reviewer-comment, /pasture:reviewer-vote

Receives from: Architect (Phase 4, including FOLLOWUP_PROPOSAL review) or Supervisor (Phase 10, including FOLLOWUP_SLICE code review) Hands off to: Architect (Phase 4 results) or Supervisor/Followup (Phase 10 findings)

Supervisor

Command: /pasture:supervisor

Phases owned: 7-12

Receives from: Architect (Phase 7 handoff document, or follow-up h1 after FOLLOWUP_PROPOSAL ratified) Hands off to: Workers (Phase 9 slice assignments), Reviewers (Phase 10), User (Phase 11 UAT), Architect via h6 (follow-up lifecycle)

Key constraints:

• Never implements code — always spawns workers
• Each production code path owned by exactly ONE worker
• Decomposes interface-first: prefers a FOUNDATION slice exporting shared identifiers before dependent slices (justifies any linear decomposition in the IMPL_PLAN)
• Drives the code-review wave to a fix-free clean round (0 BLOCKER + 0 IMPORTANT + 0 MINOR, up to the chosen review-effort budget; on exhaustion, surfaces to the user) before closing slices
• Requests the configurable review-effort budget from the user at Phase 8 (defaults: 3 rounds / 1 round / 0 rounds / unlimited / custom), like the Phase-1 research-depth gate
• Enforces the validation-case contract workers' tests verify (tests-first, red→green) — per C-validation-cases
• Creates the follow-up epic (pasture:epic-followup) at UAT when the user DEFERs items — fed ONLY by user-DEFER'd UAT items, never by review severities
• Initiates follow-up lifecycle: creates FOLLOWUP_URE, FOLLOWUP_URD, then hands off to Architect via h6 for FOLLOWUP_PROPOSAL

Worker

Command: /pasture:worker

Phases owned: 9

Receives from: Supervisor (Phase 9 slice assignment with handoff document, including FOLLOWUP_SLICE-N for follow-up lifecycle) Hands off to: Reviewer (Phase 10 via supervisor). For FOLLOWUP_SLICE-N, completion handoff reports which original leaf tasks were resolved.

Vertical slice ownership: Worker owns the full vertical — types, tests, implementation, and wiring. The slice's leaf tasks may take ANY shape (named after the real work units); the TDD layers below are one illustrative decomposition, not a required triple:

1. Layer 1: Types and schemas
2. Layer 2: Tests written FIRST (import production code — will fail initially). The tests ARE the executable verification of the validation-case contract agreed with the user during URE and Plan UAT (the universal validation cases — see C-validation-cases): definition of done plus correct/incorrect behaviours. Red-first is expected.
3. Layer 3: Implementation + wiring — drive the red Layer-2 tests progressively green (fewer failing each step) until all pass

Completion gates:

1. Type checking passes
2. Tests pass
3. Production code path verified via code inspection (no TODOs, real deps wired)
4. Update Beads task with completion comment

Handoff Matrix

Every handoff is authored inline in its own HANDOFF Beads task body (no filesystem path) and located by task ID:

Same-actor transitions (no handoff needed): Plan UAT → Ratify (Phase 5→6), Ratify → Handoff (Phase 6→7) — both performed by the architect. In the follow-up lifecycle, Supervisor creating FOLLOWUP_URE and FOLLOWUP_URD are also same-actor transitions.

See HANDOFF_TEMPLATE.md for the standardized template.

References

• PROCESS.md — Step-by-step workflow execution (single source of truth)
• SKILLS.md — Complete command reference
• CONSTRAINTS.md — Coding standards and naming conventions
• HANDOFF_TEMPLATE.md — Handoff document template