mirror of
https://github.com/obra/superpowers
synced 2026-07-21 10:04:30 +00:00
Compare commits
4 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 20d56c8a0e | |||
| 3bd7388b7d | |||
| 2711c26358 | |||
| 3472c5aecb |
@@ -133,6 +133,10 @@ a ledger file, not only in todos.
|
||||
plan's progress: leave it in place and start your own, fresh.
|
||||
- Create the ledger with its identity as the first line:
|
||||
`# SDD ledger — plan: <plan file path>`.
|
||||
- During that same Setup read, copy the plan's Global Constraints section
|
||||
verbatim into `<workspace>/constraints.md`. The global-constraints block
|
||||
you hand reviewers pastes from that file — the plan itself stays closed
|
||||
after Setup, even across compaction.
|
||||
- The ledger is your recovery map: the commits it names exist in git even
|
||||
when your context no longer remembers creating them. After compaction,
|
||||
trust the ledger and `git log` over your own recollection.
|
||||
@@ -140,7 +144,11 @@ a ledger file, not only in todos.
|
||||
that happens, recover from `git log`.
|
||||
|
||||
Read the plan once, note its context and Global Constraints, and create a
|
||||
todo per task.
|
||||
todo per task. That is the plan's one full read for the whole session:
|
||||
after Setup, the ledger and `scripts/task-brief` extracts are your working
|
||||
memory — re-reading the plan or spec late in the run (to "double-check"
|
||||
completion, to rebuild the final-review dispatch) re-buys context you
|
||||
already paid for and is forbidden.
|
||||
|
||||
Before dispatching Task 1, scan the plan once for conflicts:
|
||||
|
||||
@@ -195,7 +203,10 @@ that implementer. Single-file mechanical fixes also take the cheapest tier.
|
||||
|
||||
Everything you paste into a dispatch prompt — and everything a subagent
|
||||
prints back — stays resident in your context for the rest of the session
|
||||
and is re-read on every later turn. Hand artifacts over as files.
|
||||
and is re-read on every later turn. Hand artifacts over as files. The same
|
||||
tax applies to your own words: checkpoint in one short line, keep
|
||||
bookkeeping in the ledger file, and never paste back into the conversation
|
||||
what a file already holds.
|
||||
|
||||
### 1. Dispatch the implementer
|
||||
|
||||
@@ -399,7 +410,10 @@ on the most capable available model (see Model Selection), using
|
||||
superpowers:requesting-code-review's
|
||||
[code-reviewer.md](../requesting-code-review/code-reviewer.md). Point it at
|
||||
the ledger's deferred-minor and parked lines so it can triage which must be
|
||||
fixed before merge.
|
||||
fixed before merge. Build that dispatch from the ledger alone — the
|
||||
completion lines, parked rulings, and deferred minors are the whole-run
|
||||
summary; do not re-read the plan, the spec, or per-task reports to
|
||||
reconstruct what the ledger already states.
|
||||
|
||||
If the final whole-branch review returns findings, dispatch ONE fix subagent
|
||||
with the complete findings list — not one fixer per finding.
|
||||
|
||||
@@ -71,7 +71,11 @@ independently testable deliverable.
|
||||
[The spec's project-wide requirements — version floors, dependency limits,
|
||||
naming and copy rules, platform requirements — one line each, with exact
|
||||
values copied verbatim from the spec. Every task's requirements implicitly
|
||||
include this section.]
|
||||
include this section. Three things may never enter it: cosmetic absolutes
|
||||
on every commit (a fixed trailer or byline the work does not need), your
|
||||
own identity or model name promoted into a rule, and environment
|
||||
constraints (versions, platforms, paths) you have not verified against the
|
||||
environment the plan will execute in.]
|
||||
|
||||
---
|
||||
```
|
||||
@@ -125,6 +129,8 @@ git commit -m "feat: add specific feature"
|
||||
```
|
||||
````
|
||||
|
||||
Commit messages describe the change. Never mandate session boilerplate — trailers, bylines, model names — as a per-commit rule; what your session stamps on its commits is not a requirement of the work.
|
||||
|
||||
## No Placeholders
|
||||
|
||||
Every step must contain the actual content an engineer needs. These are **plan failures** — never write them:
|
||||
@@ -145,6 +151,8 @@ After writing the complete plan, look at the spec with fresh eyes and check the
|
||||
|
||||
**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.
|
||||
|
||||
**4. Constraint hygiene:** Does any Global Constraint mandate a per-commit cosmetic absolute, name the authoring model or session, or assert an environment fact (version floor, platform, path) you did not verify? Cut or verify it.
|
||||
|
||||
If you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task.
|
||||
|
||||
## Execution Handoff
|
||||
|
||||
Reference in New Issue
Block a user