Menu
Orchestrate task execution via fresh subagents with dispatch, monitoring, and result collection
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Strategy: Attack an isomorphism claim by demanding an explicit structure-preserving map and trying to break it. Targets any multi-language claim of the form 'X ≅ Y ≅ … across N mathematical languages'. Forces the claim to either earn the word 'isomorphism' or be demoted to 'analogy'. Methods: category theory (functor/natural-iso criteria), model theory, Lakatos monster-barring.
Strategy: Dialectic engine retuned for truth-seeking, not survival. A defender steelmans a claim into its MOST falsifiable form, a critic attacks to refute it, a judge classifies the exchange into BROKEN/CORROBORATED/UNFALSIFIABLE — the judge does NOT pick a winner or score persuasiveness. Methods: Irving debate (repurposed), Toulmin argumentation, Mayo severe testing.
Strategy: Run BEFORE building any validator (sandbox/simulation/benchmark). Builds a non-circularity matrix of theory-claim × validator-assumption to detect when a validator would 'confirm' a theory only because it was built on the theory's own premises. A circular validator's PASS carries zero evidential weight. Methods: Cartwright nomological machines, Winsberg sanctioning-of-simulations, tautology detection.
Strategy: Attack a beautiful unified result on the suspicion that its beauty is the bug. Distinguishes EARNED simplicity (forbids/predicts/subsumes) from DECORATIVE simplicity (re-describes/relabels/accommodates). Directly serves the Occam aesthetic by making it a falsifiable bar, not a vibe. Methods: Sober parsimony-as-evidence, MDL, Meehl risky prediction, accommodation-vs-prediction.
Campaign: Truth-seeking adversarial validation for scientific research artifacts (NOT publication defense). Core question: Where have we fooled ourselves, and is each load-bearing claim even falsifiable? Win-condition is INVERTED from survival/resilience to active refutation. Methods: Popper falsificationism, Lakatos Proofs and Refutations, Mayo severe testing, Platt strong inference.
Strategy: Attack the evidential weight of an 'independent convergence' claim. When N reasoning paths all reach the same conclusion, the confidence boost is real only if the paths were actually independent. Measures shared-prior / shared-blindspot contamination and corrects the over-counted confidence. Methods: Bayesian agreement-as-evidence, correlated-error analysis, jury theorem assumptions.
| name | subagent-execution-loop |
| description | Orchestrate task execution via fresh subagents with dispatch, monitoring, and result collection |
| version | 1.0.0 |
| category | experiment-execution |
| type | tactic |
| orchestrates | ["implementer-dispatch","execution-monitoring","result-collection"] |
| dependencies | {"sops":["execution-monitoring","implementer-dispatch","result-collection","ponytail:ponytail","ponytail:ponytail-review","superpowers:receiving-code-review","superpowers:requesting-code-review","superpowers:subagent-driven-development","superpowers:test-driven-development"]} |
执行循环直接 load superpowers:subagent-driven-development 当引擎，不再自写循环伪码。 每个任务在引擎内部按以下贯穿规则执行：
Skill load ponytail:ponytail —— 任务开始即开启精简反射。Skill load superpowers:test-driven-development —— 每任务 RED → GREEN → REFACTOR。Skill load superpowers:requesting-code-review —— 任务 diff 出来后派 reviewer 子代理。Skill load ponytail:ponytail-review —— code-review 之后，对 diff 再过一道
过度工程审（delete/stdlib/native/yagni/shrink）。Skill load superpowers:receiving-code-review —— 核验 review 反馈再落地，反馈错就反驳。DARE 原生的 implementer-dispatch / execution-monitoring / result-collection 作为 引擎内每任务的派单、盯状态、收结果三步保留。
| Condition | Action |
|---|---|
| model 选择 / retry / 超时 / 死锁 | 交给 superpowers:subagent-driven-development 引擎处理 |
| code-review 后 | 先 ponytail:ponytail-review 查过度工程，再 receiving-code-review 落地 |
| Budget < 10% remaining | 停，报告 partial（DARE 预算治理） |
| >50% 关键路径 BLOCKED | 中止执行（DARE 排程判据） |
Optional, no fixed order; the final leaf is always a sop.
| SOP | When to use |
|---|---|
| execution-monitoring | Monitor execution progress, detect anomalies, and report status |
| implementer-dispatch | Dispatch execution subagent — select model by complexity, construct prompt with full task context |
| ponytail:ponytail | Lazy-senior reflex: simplest thing that holds; mark every deliberate shortcut |
| ponytail:ponytail-review | Audit the diff for over-engineering (delete/stdlib/native/yagni/shrink) |
| result-collection | Collect experiment outputs — metrics, logs, artifacts — into structured result set |
| superpowers:receiving-code-review | Verify review feedback before applying; push back when wrong |
| superpowers:requesting-code-review | Dispatch a code-reviewer subagent after each task |
| superpowers:subagent-driven-development | Execute the plan via a fresh subagent per task with two-stage review |
| superpowers:test-driven-development | RED -> GREEN -> REFACTOR per task |