Subagent mode selection continuous vs review between
Use when starting a multi-task workflow via `superpowers:subagent-driven-development` (SDD) and the user must choose between two execution modes: (A) Continuous Execution — all tasks dispatched back-to-back without checkpoint (SDD default), or (B) Review-Between-Tasks — user inspects each task's output before authorizing the next. Mechanical-implementation tasks (TDD with complete code in plan, deterministic outcomes) are continuous-safe. Judgment-heavy tasks (forensics, interpretation of numbers, strategic decisions, architectural pivots based on subagent output) require review-between because the next task's prompt depends on prior outcome interpretation. Trigger phrases like "should I run continuous or with pauses between tasks", "review between steps", "subagent-driven with checkpoints", "pause after each task". Do NOT load for single-task workflows, non-SDD workflows, purely mechanical TDD with complete code in plan, or the very first task of a workflow.From its SKILL.md
npx -y skills add Ed3Design/ed3design-skill-bundles --skill subagent-mode-selection-continuous-vs-review-betweenAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
8.2 KB, ~1.8k tokens by cl100k_base, as published. Nobody here has run it
subagent-mode-selection-continuous-vs-review-between
What this skill does
When using superpowers:subagent-driven-development for a multi-task workflow, classify each task's risk-of-divergence-from-user-intent and propose either:
- Continuous Execution (default SDD behaviour, no user checkpoint between tasks)
- Review-Between-Tasks (user authorizes next task only after seeing prior-task output)
Wrong choice has real cost: continuous on judgment-heavy tasks wastes resources and produces drift; review-between on mechanical tasks creates 5+ wait cycles for the user.
Task-type classification
The 3-factor test for "is this task mechanical-enough for continuous?":
Factor 1 — Spec completeness
- ✅ Mechanical: Plan-Doc has complete code blocks for every step. Implementation = type-and-test.
- ❌ Judgment-heavy: Plan-Doc says "decide which filter to apply first" or "interpret the numbers and write recommendation"
Factor 2 — Outcome determinism
- ✅ Mechanical: Outcome is binary-checkable (test pass/fail, file exists, commit SHA produced)
- ❌ Judgment-heavy: Outcome is text interpretation, strategic implication, or downstream-task-influencing data
Factor 3 — Next-task dependency
- ✅ Mechanical: Next task in plan starts regardless of prior task's specifics
- ❌ Judgment-heavy: Next task's spec/prompt depends on what prior task found (e.g., "if D1 shows X is winner-dropper, then dispatch D2; if D1 shows otherwise, dispatch a different forensic")
All 3 ✅ → Continuous Execution safe. Any 1 ❌ → Review-Between.
The choice pattern (Genesis)
Three workflow segments illustrated the choice clearly:
Segment 1 — Backtest-Simulation Tasks 1-5 → Continuous ✅
| Task | All 3 factors? | Mode |
|---|---|---|
| 1: simulate_pause_periods + 6 tests | ✅✅✅ (complete code, test-pass binary, T2 uses T1's output spec) | Continuous |
| 2: apply_filters extension | ✅✅✅ | Continuous |
| 3: _load_full_history loader | ✅✅✅ | Continuous |
| 4: run_backtest integration | ✅✅✅ | Continuous |
| 5: Aggregate cross-commit review + fixes | ✅✅ (findings are textual but downstream-actionable per fixes routine) | Continuous |
Total continuous time: ~3h, no user wait cycles. Saved ~30-60 min of wait time per checkpoint.
Segment 2 — Tasks 6-8 (live-run, forensics, gate-review) → Continuous-with-end-presentation ⚠
| Task | Mechanical-enough? | Mode |
|---|---|---|
| 6: Live-run on server | ✅✅⚠ (mechanical, but output numbers drive Task 7 spec) | Continuous, but pause AFTER for user to direct Task 7-8 |
| 7: Forensics note (findings) | ⚠⚠⚠ (interpretation-heavy, judgment in writing) | Continuous (writing is mechanical), but pause at end for user review |
| 8: Gate-review forensics | ⚠⚠⚠ (verdict judgment) | Continuous |
The user was alerted before Task 6 (live-run): "Live-run numbers could be unexpected, then Tasks 7-8 want user direction". User chose: continuous, but pause-after-Task-6 if numbers surprising. → Numbers WERE surprising → orchestrator paused at end of Task 6 with a user-direction question.
Segment 3 — Phase 0 D1-D4 forensics → Review-Between ❌-Continuous
| Task | Factor failures | Mode |
|---|---|---|
| D1 AvgPnL-drop forensic | Factor 3 fail (D2 spec depends on D1 finding — if result = Winner-Dropper, D2 audits look-ahead; if Loser-Dropper, D2 skipped) | Review-Between |
| D2 anomaly forensic | Factor 3 fail (D3 spec depends on D1+D2 jointly) | Review-Between |
| D3 multi-run median stability | Factor 3 fail (D4 compound-gate values depend on D3 power analysis) | Review-Between |
| D4 compound-gate spec | mechanical given D3-confirmed values → could be continuous, but user explicitly asked "review between each step" | Review-Between |
User explicit: "Review between each step" — because each task's output meaningfully changed the next task's prompt.
How to apply
At workflow start
- Read the Plan-Doc: for each task, count factor checks (✅ or ❌)
- Classify each task as Mechanical / Hybrid / Judgment-heavy
- Propose modes per segment:
- Sequence of all-Mechanical tasks → continuous, end-presentation
- Hybrid tasks (✅✅⚠) → continuous-with-pause-AFTER for next-task direction
- Judgment-heavy tasks → review-between (default to "ask user after each")
- Surface the proposal to the user with AskUserQuestion: "I propose: Tasks 1-5 continuous, then pause after 5 for review. Tasks 6-8 each pause after for user direction. OK?"
Mid-workflow re-classification
If a task delivers an unexpected output (mechanical task suddenly looks judgment-heavy):
- STOP the continuous execution
- Present findings to the user
- Re-classify remaining tasks
- Resume per new mode choice
Example: D1 subagent found "winner-dropper" (+4.54% blocked-AvgPnL). That was subagent-output-INTERPRETATION-required → orchestrator correctly continuous-executed but paused-at-end for user direction.
Anti-patterns
- ❌ All-Continuous-by-Default without factor check — clearly shown: D1-D4 would have caused DRIFT had they run continuous (D2 prompt would not have reflected D1's finding)
- ❌ All-Review-Between-by-Default — for Tasks 1-5 above this would have been 5× wait cycles à 30 min = 2.5h lost
- ❌ Mode choice only at workflow start without re-classification — outputs can flip the classification
- ❌ Interpreting user choice 'continuous' as 'still continuous after unexpected outputs' — pausing after Task 6 due to output surprise was correct even though the segment was begun as 'continuous'
Complementary to superpowers:subagent-driven-development
This skill is a pre-workflow classification sub-routine for SDD. It does not replace the SDD skill but extends it with a mode-selection discipline before the Continuous execution default setting of the SDD workflow is blindly adopted.
The SDD skill states: "Continuous execution: Do not pause to check in with your human partner between tasks." That is the standard. This skill provides the classification of when that standard is NOT the right choice.
Future refinements
Non-blocking polish items that would tighten the workflow further:
- Integrate the 3-factor classification as a callable AskUserQuestion template
- Add concrete examples from at least 1 non-trading domain (e.g. a frontend-design feature, a deploy-pipeline refactor)
- Coordinate with
superpowers:subagent-driven-development— propose an upstream PR that integrates this as a section - Document the re-classification trigger ("STOP and re-classify when") as a hard rule
- Test in a session where the choice is ambiguous and verify the AskUserQuestion template surfaces it clearly
Genesis-session metadata
- Workflow domains: backtest engineering (8 tasks SDD), live-run forensics (4 D-tasks)
- ABC verdict: A ✅ Repeatable (3-factor check is mechanical), B ✅ Prevents error (all-continuous would have been wrong for D1-D4), C ✅ Transferable (any multi-task SDD workflow choice)
- Real-world impact estimate: through correct choice ~3h gained (Tasks 1-5 continuous instead of ~5 user wait cycles) AND DRIFT AVOIDED (D1-D4 as review-between instead of blind-continuous)
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most context ai engineering skills give in ~1.8k tokens
Counted across 1,193 of the 1,976 authors here whose files we hold, read 2026-08-07
- Dispatch a fresh implementer subagent per taskin 48 of 1193, across 19 files
- Dispatch a final code reviewer after all tasksin 33 of 1193, across 8 files
- Provide full task text to the subagentin 30 of 1193, across 9 files
- Review spec compliance before code qualityin 27 of 1193, across 10 files
- Make the hook script executablein 26 of 1193, across 8 files
- Re-snapshot after navigation or DOM changesin 25 of 1193, across 19 files
- Read files before editing themin 22 of 1193, across 11 files
- Answer subagent questions before proceedingin 22 of 1193, across 7 files
- Mark task complete in TodoWrite after approvalin 22 of 1193, across 6 files
- Merge hook into existing settingsin 21 of 1193, across 3 files
- Ask if installation is global or projectin 20 of 1193, across 2 files
- Copy the hook script to target locationin 20 of 1193, across 2 files
Said here and by no other author read
- Evaluate task spec completeness
- Evaluate task outcome determinism
- Evaluate next-task dependency
- Classify each task as mechanical or judgment-heavy
- Propose continuous execution for mechanical tasks
- Propose review-between-tasks for judgment-heavy tasks
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.