Orchestrate

Orchestrate

Coordinate one bounded step at a time with explicit role settings, durable reports, fresh reviewers and fixers, and controlled Git history. Review supplements tests; it never replaces them.

Intent gate

Determine whether the user wants execution, discussion/planning, or continuation of an existing run. Quoted trigger phrases and mentions of this skill are not execution requests. Even explicit invocation with “explain” or “plan only” must respect that scope. For discussion or skill authoring, answer that request without starting this workflow, asking execution setup questions, or spawning workers. For ambiguous intent, clarify before execution.

After milestone handoff, human walkthrough findings default to ordinary conversational fixes. Start a new orchestration repair run only when the user explicitly requests orchestrated repair or invokes $orchestrate to execute it. The earlier milestone invocation does not activate orchestration for later feedback, regardless of issue size.

Execution routing

1. Before a new run, read workflow.md, inspect available capabilities and project rules, and obtain missing model/reasoning choices for orchestrator, implementer/fixer, and reviewer. Reuse explicit choices in the current request; never silently reuse choices from a previous run. Resume the same run from its record instead.
2. Resolve authorization once at startup and persist its scope. Invocation alone does not grant Git, production, publishing, or deployment permissions. Process reports must stay out of version control: before writing them, ensure .gitignore excludes development-notes/, review-notes/, and any configured report directory, following git.md. This targeted ignore update is required; do not automatically change other project rules, Docker ignores, or installation/configuration.
3. Read and preserve the confirmed design's steps, dependencies, file ownership, and acceptance criteria; verify their prerequisites against the repository. Follow the design-gap rules in workflow.md before filling missing steps or resolving material conflicts. Delegate implementation only after startup is settled. Each review and each repair requires a new context without inherited conversation. Detect actual tools and supported parameters; do not assume any particular tool name or simulate a model switch with role text.
4. Read reports.md when creating the run record and handoff artifacts. First reviewers receive the original design and full step diff; rereviewers also receive the previous review report and repair delta. Reviewers must not receive or read implementation/fix reports. Follow the role-specific handoff rules in workflow.md; project rules and relevant source remain accessible. Never pass process chats, desired verdicts, or oral supplements.
5. Before any Git mutation or selecting an uncommitted snapshot, read git.md. The orchestrator owns Git writes in shared workspaces. Keep unrelated changes intact.
6. Follow implementation → saved report → fresh review → fresh repair if needed → fresh review → integration. Stop after five repair rounds per step if unresolved; after two failed repairs of the same issue, change strategy or escalate before another attempt. Preserve all rounds.
7. Finalize each step's history when authorized, verify the final diff and report mapping, and update the project's existing task/roadmap progress. Keep automated completion distinct from human acceptance; the run record does not replace project progress. For a whole-milestone request, advance automatically without routine per-step confirmation, pausing when a user decision is needed. Stop at the requested step/range/milestone boundary. Finish with handoff and human walkthrough instructions. Report incomplete checks and capability limits honestly.