mirror of
https://github.com/obra/superpowers.git
synced 2026-06-14 14:49:04 +08:00
Compare commits
2 Commits
sdd-review
...
sdd-e27-st
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
35464d67c0 | ||
|
|
90b5433f59 |
@@ -11,6 +11,9 @@ Execute plan by dispatching a fresh implementer subagent per task, a task review
|
|||||||
|
|
||||||
**Core principle:** Fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration
|
**Core principle:** Fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration
|
||||||
|
|
||||||
|
**Narration:** between tool calls, narrate at most one short line — the
|
||||||
|
ledger and the tool results carry the record.
|
||||||
|
|
||||||
**Continuous execution:** Do not pause to check in with your human partner between tasks. Execute all tasks from the plan without stopping. The only reasons to stop are: BLOCKED status you cannot resolve, ambiguity that genuinely prevents progress, or all tasks complete. "Should I continue?" prompts and progress summaries waste their time — they asked you to execute the plan, so execute it.
|
**Continuous execution:** Do not pause to check in with your human partner between tasks. Execute all tasks from the plan without stopping. The only reasons to stop are: BLOCKED status you cannot resolve, ambiguity that genuinely prevents progress, or all tasks complete. "Should I continue?" prompts and progress summaries waste their time — they asked you to execute the plan, so execute it.
|
||||||
|
|
||||||
## When to Use
|
## When to Use
|
||||||
@@ -88,6 +91,8 @@ Use the least powerful model that can handle each role to conserve cost and incr
|
|||||||
**Integration and judgment tasks** (multi-file coordination, pattern matching, debugging): use a standard model.
|
**Integration and judgment tasks** (multi-file coordination, pattern matching, debugging): use a standard model.
|
||||||
|
|
||||||
**Architecture and design tasks**: use the most capable available model.
|
**Architecture and design tasks**: use the most capable available model.
|
||||||
|
The final whole-branch review is one of these — dispatch it on the most
|
||||||
|
capable available model, not the session default.
|
||||||
|
|
||||||
**Review tasks**: choose the model with the same judgment, scaled to the
|
**Review tasks**: choose the model with the same judgment, scaled to the
|
||||||
diff's size, complexity, and risk. A small mechanical diff does not need the
|
diff's size, complexity, and risk. A small mechanical diff does not need the
|
||||||
@@ -100,8 +105,10 @@ most expensive — which silently defeats this section.
|
|||||||
**Turn count beats token price.** Wall-clock and context cost scale with how
|
**Turn count beats token price.** Wall-clock and context cost scale with how
|
||||||
many turns a subagent takes, and the cheapest models routinely take 2-3× the
|
many turns a subagent takes, and the cheapest models routinely take 2-3× the
|
||||||
turns on multi-step work — costing more overall. Use a mid-tier model as the
|
turns on multi-step work — costing more overall. Use a mid-tier model as the
|
||||||
floor for implementers and reviewers; reserve the cheapest tier for
|
floor for reviewers and for implementers working from prose descriptions.
|
||||||
single-file mechanical fixes.
|
When the task's plan text contains the complete code to write, the
|
||||||
|
implementation is transcription plus testing: use the cheapest tier for
|
||||||
|
that implementer. Single-file mechanical fixes also take the cheapest tier.
|
||||||
|
|
||||||
**Task complexity signals (implementation tasks):**
|
**Task complexity signals (implementation tasks):**
|
||||||
- Touches 1-2 files with a complete spec → cheap model
|
- Touches 1-2 files with a complete spec → cheap model
|
||||||
|
|||||||
@@ -115,6 +115,11 @@ Subagent (general-purpose):
|
|||||||
"yes." A tight report that cites lines gives the controller everything
|
"yes." A tight report that cites lines gives the controller everything
|
||||||
it needs.
|
it needs.
|
||||||
|
|
||||||
|
Your final message is the report itself: begin directly with the
|
||||||
|
spec-compliance verdict. Every line is a verdict, a finding with
|
||||||
|
file:line, or a check you ran — no preamble, no process narration,
|
||||||
|
no closing summary.
|
||||||
|
|
||||||
## Calibration
|
## Calibration
|
||||||
|
|
||||||
Categorize issues by actual severity. Not everything is Critical.
|
Categorize issues by actual severity. Not everything is Critical.
|
||||||
|
|||||||
Reference in New Issue
Block a user