mirror of
https://github.com/obra/superpowers
synced 2026-07-21 18:14: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.
|
plan's progress: leave it in place and start your own, fresh.
|
||||||
- Create the ledger with its identity as the first line:
|
- Create the ledger with its identity as the first line:
|
||||||
`# SDD ledger — plan: <plan file path>`.
|
`# 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
|
- The ledger is your recovery map: the commits it names exist in git even
|
||||||
when your context no longer remembers creating them. After compaction,
|
when your context no longer remembers creating them. After compaction,
|
||||||
trust the ledger and `git log` over your own recollection.
|
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`.
|
that happens, recover from `git log`.
|
||||||
|
|
||||||
Read the plan once, note its context and Global Constraints, and create a
|
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:
|
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
|
Everything you paste into a dispatch prompt — and everything a subagent
|
||||||
prints back — stays resident in your context for the rest of the session
|
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
|
### 1. Dispatch the implementer
|
||||||
|
|
||||||
@@ -399,7 +410,10 @@ on the most capable available model (see Model Selection), using
|
|||||||
superpowers:requesting-code-review's
|
superpowers:requesting-code-review's
|
||||||
[code-reviewer.md](../requesting-code-review/code-reviewer.md). Point it at
|
[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
|
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
|
If the final whole-branch review returns findings, dispatch ONE fix subagent
|
||||||
with the complete findings list — not one fixer per finding.
|
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,
|
[The spec's project-wide requirements — version floors, dependency limits,
|
||||||
naming and copy rules, platform requirements — one line each, with exact
|
naming and copy rules, platform requirements — one line each, with exact
|
||||||
values copied verbatim from the spec. Every task's requirements implicitly
|
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
|
## No Placeholders
|
||||||
|
|
||||||
Every step must contain the actual content an engineer needs. These are **plan failures** — never write them:
|
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.
|
**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.
|
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
|
## Execution Handoff
|
||||||
|
|||||||
Reference in New Issue
Block a user