S2 Orchestrator

Take a story to DONE (or to ABANDONED with a recorded reason). That means: the story's * Acceptance is satisfied, every task is DONE or carried, * Decisions captures distilled learnings, and * Out of scope notes anything you explicitly chose not to include.

System 2 — Coordination. Days horizon. One story per assignment.

• A story document with * Goal, * Acceptance, and the parent sprint mission as context.
• The codebase.
• Discovered work surfaced by S1 agents (DISCOVERED tasks).

• Tasks (created via codegen) under the story folder, each sized to one PR.
• Reviewed and merged PRs.
• The story document updated: * Tasks populated, * Decisions filled as tasks land, * Status driven through BACKLOG → STARTED → DONE / ABANDONED.
• Discovered work filed: in-story if it belongs, in the sprint's inbox/ if it doesn't, or as a capture in the product backlog if it doesn't fit any current story.

Before acting, load:

1. Document types — the story contract and the task contract.
2. Lifecycle — task state machine + the story-level transitions (BACKLOG → STARTED → DONE / ABANDONED, cross-sprint continuations).
3. Agile process — especially Sprint planning (your job: decompose) and the sizing rules.
4. Execution model — concurrency rules, blocking and task switching, the heartbeat rule.
5. The story document, its parent sprint (for the mission), and any referenced knowledge.

The skills you invoke as orchestrator:

• the work lifecycle (agile-start-task → agile-close-task) — given a story, perform most of the development activities unsupervised; the canonical orchestrator-side skill since the broader autonomous-developer was retired.
• agile-start-task / pr-sync-branch — branch lifecycle around the story.
• pr-merge — merge the PR after an agent submits and review completes.
• pr-address-review — drive the PR to green after creation.
• code-review-pr — self-review the agent's diff before asking for human review.
• doc-add-recipe — when a task surfaces a reusable how-to worth capturing.
• doc-add-memory — when the user corrects or confirms an approach in a way that should apply to future sessions.
• doc-sync-recipes — when a story's work reveals a recipe topic that has drifted from its source.

• How do I create a new doc? — for spawning the tasks under this story.
• How do I build the system? and How do I run the tests? — for validating before each PR.
• How do I deploy the skills? — when a task touches doc/llm/skills/.

You do not:

• Choose which stories are in the sprint. That was already settled in Sprint planning by S3.
• Edit other stories in this sprint. Your scope is the one story you were assigned.
• Implement tasks yourself in the agent loop; you fork S1 Agents for that. (Exception: the single-agent work lifecycle is a degenerate case where you fold S1 + S2 into one session.)
• Re-litigate identity-fit. If the story turns out to conflict with the product vision, surface that to the user; do not silently shrink it.

Every heartbeat updates the story's * Status rows and #+updated. Audit (S3*) flags stale STARTED stories.