crew

name	crew
description	Use only when the user explicitly asks to use Crew for multi-agent work in Herdr, including named task tabs, role-based panes, parallel worktrees, or cross-vendor implementation review.

Crew — role-based Herdr orchestration

Crew runs only when the user explicitly asks to use it. The session that loads Crew is the orchestrator. It creates task tabs, writes task contracts, assigns roles, tracks every task, and advances task state. It does not do bulk exploration or implementation, and it is never closed.

Operating loop

1. Check worker capacity — use the available usage information. If Fable weekly usage exceeds 80%, route Claude implementation to Opus 5.
2. Create durable task state — each task has an ~/artifacts/ folder. Read artifacts.md before assigning work.
3. Assign research and planning — the planner decides whether the task needs a dependency graph, parallel slices, and worktrees.
4. Create named tabs and role panes — one named Herdr tab represents one logical task. Read panes.md before spawning or recycling a pane.
5. Run the implementation loop — implement, simplify, review, fix, simplify, and repeat until each finding has an agreed result. Read review.md before starting this loop.
6. Verify and integrate — a fresh verifier checks the complete contract and evidence. A separate integrator merges approved work into the starting branch. When the planner marks the integrated change large or high risk, the Final Review Lead runs the Scout fleet-review procedure before the final gate.
7. Monitor until terminal state — keep every task in the Persistent task registry until it is complete, parked, or blocked. A closed pane never removes its task from monitoring.
8. Close what is finished — the orchestrator closes each role pane once its role is complete and its record is durable, and closes the task tab once the task is terminal. Read panes.md before closing anything.

Roles

Role	Owns
Orchestrator	Tabs, task registry, assignments, state transitions, and user decisions.
Researcher	Current state, requirements, risks, and dependencies.
Planner	Execution approach, task slices, ownership, worktrees, merge order, and checks.
Implementer	One assigned change and focused evidence.
Reviewer	Review against the plan and contract. Prefer a different vendor from the implementer.
Verifier	Fresh independent check of the complete contract and evidence.
Integrator	Approved merges, final validation, final records, and worktree cleanup.
Final Review Lead	Large or high-risk integrated-branch review using the Scout fleet-review procedure.

Non-negotiable rules

• An implementer never reviews or verifies its own work.
• Every worker reads the task records before starting and updates progress.md and log.md before completion.
• Every worker sends an explicit completion or blocker signal to the orchestrator.
• After every signal, the orchestrator records the result and selects the next state: review, fix, verification, integration, user decision, or completion.
• A worker may use bounded subagents for reconnaissance, file discovery, or independent checks. Subagents do not create Herdr tabs or panes.
• Explain a complex workflow with an interactive HTML file in the task folder, not a Markdown-only deliverable.

References

• routing.md — role-to-model routing and fallback rules
• panes.md — tabs, worker context, subagents, and monitoring
• review.md — planning, implementation, review, verification, and integration
• final-review.md — Scout fleet review for large or high-risk integrated changes
• artifacts.md — durable task state and handoff records