orchestrated-execution

Executes work units through a 4-phase loop of implement, validate, adversarial review, and commit.

1|Updated Jun 23, 2026
One-click install
npx skills add https://github.com/seal-harness/seal-harness --skill orchestrated-execution-seal-harness
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: orchestrated-execution
Source: https://github.com/seal-harness/seal-harness/tree/main/.agents/skills/orchestrated-execution
Command: npx skills add https://github.com/seal-harness/seal-harness --skill orchestrated-execution-seal-harness

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Multi-agent coding workflows often rely on subagent self-reports of success, leading to unverified code, missed spec requirements, and silent failures. This Skill replaces linear implement-then-review flows with a rigorous 4-phase execution loop where the orchestrator independently validates every work unit and a fresh adversarial reviewer verifies compliance against the written spec contract. ## Core Features & Use Cases - 4-Phase Execution Loop: Every work unit passes through IMPLEMENT, VALIDATE, ADVERSARIAL REVIEW, and COMMIT phases with blocking quality gates (tests, coverage thresholds, type checking, lint, file scope verification) and a max-3-retry escalation protocol. - Adversarial Review with Fresh Reviewers: A separate review subagent checks each Definition of Done item with file:line evidence, returning binary PASS/FAIL verdicts; re-reviews always use a fresh reviewer instance to prevent anchoring bias. - Work Unit Decomposition & Parallel Execution: Plans are decomposed into a DAG of work units with explicit dependencies, file scopes, and human checkpoints, with fan-out/fan-in patterns for parallel execution and sequential commits. - Context Persistence & Recovery: Plans, project context, and execution state are persisted to docs/ so orchestration can resume after context compaction or session interruption. - Use Case: When implementing a multi-feature spec across several subagents, use this Skill to decompose the spec into work units, run each through the gated loop, pause at human checkpoints, and produce a final comprehensive review before PR creation. ## Quick Start Ask the AI to execute the approved implementation plan using the orchestrated execution 4-phase loop with adversarial review for each work unit.

Frequently Asked Questions about orchestrated-execution

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I orchestrate multi-agent code implementation with verification?▼

Decompose the spec into work units with DoD items and file scopes, then run each through the 4-phase loop: a coding subagent implements, the orchestrator independently runs tests and coverage gates, a fresh adversarial reviewer checks spec compliance, and only then is the work committed.

What is adversarial code review versus collaborative code review?▼

Adversarial review produces a binary PASS/FAIL verdict on spec compliance with mandatory file:line evidence for each DoD item, while collaborative review gives subjective APPROVED/CHANGES REQUIRED feedback. Adversarial reviewers never suggest improvements and must be fresh instances on every re-review.

When should I not use the orchestrated execution loop?▼

Do not use it for single-file bug fixes, copy changes, or tasks without a written spec. The 4-phase loop is designed for complex multi-work-unit tasks where self-reported success is insufficient and verification overhead is justified.

How does the orchestrator recover after context compaction or session loss?▼

The orchestrator persists the approved plan to docs/plans/active-plan.md and execution state to docs/context/execution-state.md after each phase transition. On recovery, it reads these files, reloads completed work units, and resumes from the recorded work unit and phase.

What happens when a work unit fails validation or review repeatedly?▼

Each quality gate allows a maximum of 3 retry attempts with fixes and fresh re-reviews. After 3 failures, the orchestrator escalates to a human with a full failure history table, root cause assessment, and recommended options.

Can work units run in parallel during orchestrated execution?▼

Yes, independent work units fan out for parallel implementation and review, then converge for validation and sequential commits. If one unit fails, only that unit's loop re-runs while passed units remain untouched.