orchestrated-execution
starsforks
How to install orchestrated-execution?
dsifry/metaswarm/orchestrated-execution
$npx -y skills add dsifry/metaswarm --skill orchestrated-execution4-phase execution loop for work units - IMPLEMENT, VALIDATE, ADVERSARIAL REVIEW, COMMIT
SKILL.md
| 1 | # Orchestrated Execution Skill |
| 2 | |
| 3 | **Core principle**: Trust nothing. Verify everything. Review adversarially. |
| 4 | |
| 5 | This skill defines a generalized 4-phase execution loop that any orchestrator can invoke when implementing work units. It replaces linear "implement then review" flows with a rigorous cycle that independently validates results and adversarially reviews against a written spec contract. |
| 6 | |
| 7 | --- |
| 8 | |
| 9 | ## Coordination Mode Note |
| 10 | |
| 11 | This skill is mode-agnostic — the 4-phase execution loop works identically in both Task Mode and Team Mode. The differences: |
| 12 | |
| 13 | - **Phase 1 (IMPLEMENT)**: In Team Mode, the coding subagent may be a persistent teammate (retains context across work units). In Task Mode, it's a fresh `Task()` per work unit. |
| 14 | - **Phase 3 (ADVERSARIAL REVIEW)**: ALWAYS a fresh `Task()` instance in BOTH modes. Never a teammate, never resumed. |
| 15 | - **All quality gates**: Unchanged regardless of mode. |
| 16 | |
| 17 | See `./guides/agent-coordination.md` for full mode detection and coordination details. |
| 18 | |
| 19 | --- |
| 20 | |
| 21 | ## Plan Review Gate |
| 22 | |
| 23 | After drafting an implementation plan (Step 1: Plan Validation), submit it to the **Plan Review Gate** before presenting to the user. The gate spawns 3 adversarial reviewers (Feasibility, Completeness, Scope & Alignment) — all must PASS. See `skills/plan-review-gate/SKILL.md` for details. |
| 24 | |
| 25 | --- |
| 26 | |
| 27 | ## When to Use This Skill |
| 28 | |
| 29 | - **Complex tasks** decomposed into multiple work units |
| 30 | - **Tasks with a written spec** containing Definition of Done (DoD) items |
| 31 | - **Multi-agent orchestration** where subagents produce work that needs verification |
| 32 | - **High-stakes changes** where self-reported "it works" is insufficient |
| 33 | |
| 34 | **Do NOT use for**: Single-file bug fixes, copy changes, or tasks without a spec. |
| 35 | |
| 36 | --- |
| 37 | |
| 38 | ## 1. Plan Validation (Pre-Flight Checklist) |
| 39 | |
| 40 | Before submitting a plan to the Design Review Gate, the orchestrator MUST verify every item on this checklist. This prevents expensive design review cycles on fundamentally broken plans. |
| 41 | |
| 42 | > **Note**: The `Plan` subagent type cannot write files (it has read-only access by design). If you spawn an Architect as a Plan subagent, it will return the plan as text in its response. The orchestrator must write the plan to `PLAN.md` itself. |
| 43 | |
| 44 | ### Architecture Checklist |
| 45 | - [ ] Every data access goes through a service layer (no direct DB calls from routes/handlers) |
| 46 | - [ ] Each work unit has a single responsibility (max ~5 files created/modified) |
| 47 | - [ ] Error handling strategy specified (typed error hierarchy, how errors cross layer boundaries) |
| 48 | - [ ] No hard-coded configuration — environment variables for all external service config |
| 49 | |
| 50 | ### Dependency Graph Checklist |
| 51 | - [ ] Each WU's dependencies are minimal (only depends on what it actually imports/uses) |
| 52 | - [ ] No unnecessary serialization — WUs that CAN be parallel ARE marked parallel |
| 53 | - [ ] No circular dependencies |
| 54 | - [ ] Integration WUs exist to wire components into the app shell (not just built in isolation) |
| 55 | |
| 56 | ### API Contract Checklist |
| 57 | If the plan includes HTTP endpoints or WebSocket protocols, verify: |
| 58 | - [ ] Every HTTP endpoint specifies: method, path, request schema, all response status codes, error response shapes |
| 59 | - [ ] WebSocket message types fully specified (client-to-server AND server-to-client message type tables) |
| 60 | - [ ] Protocol concerns documented: heartbeat, reconnection, acknowledgment strategy |
| 61 | - [ ] Response codes are explicit (not "returns the todo" but "returns 201 with the created todo") |
| 62 | |
| 63 | ### Security Checklist |
| 64 | - [ ] Trust boundaries identified (which inputs are untrusted?) |
| 65 | - [ ] Input validation specified for every endpoint/handler (schema, max size) |
| 66 | - [ ] Rate limiting specified for expensive operations (AI API calls, file uploads) |
| 67 | - [ ] Authentication/authorization requirements documented |
| 68 | - [ ] Secrets management documented (.env pattern, .gitignore verification) |
| 69 | |
| 70 | ### UI/UX Checklist |
| 71 | If the plan includes a user interface: |
| 72 | - [ ] User flows documented with trigger, steps, and visible outcome (see UI-FLOWS.md template) |
| 73 | - [ ] Text-based wireframes for each screen showing layout and interactive elements |
| 74 | - [ ] Empty states, loading states, and error states defined for each view |
| 75 | - [ ] Integration work units explicitly created to wire components into the app shell |
| 76 | - [ ] Component hierarchy documented (what renders what, where) |
| 77 | |
| 78 | ### External Dependencies Checklist |
| 79 | - [ ] All external services identified (APIs, SDKs, third-party services) |
| 80 | - [ ] Required credentials/config documented (env var names, how to obtain) |
| 81 | - [ ] Human checkpoint planned BEFORE work units that depend on external services |
| 82 | - [ ] Graceful degradation specified for when credentials are missing |
| 83 | - [ ] `.env.example` includes all required env vars |
| 84 | |
| 85 | ### Completeness Checklist |
| 86 | - [ ] All human checkpoints from the spec are included |
| 87 | - [ ] Al |
People who liked this also viewed
6 picksType
- paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026
- subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026
- dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026
- browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 2026
- wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 2026
- wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 2026
