@loneexile/omp-superpowers 7.0.1-omp.2 → 7.0.1-omp.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +19 -1
- package/README.md +121 -47
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,22 @@ A version is `<upstream version>-omp.<n>`: the upstream release this fork is syn
|
|
|
6
6
|
|
|
7
7
|
## [Unreleased]
|
|
8
8
|
|
|
9
|
+
## [7.0.1-omp.4] - 2026-10-24
|
|
10
|
+
|
|
11
|
+
### Removed
|
|
12
|
+
|
|
13
|
+
- **The post-compaction note from 7.0.1-omp.3.** After a compaction, the bootstrap no longer names the superpowers skills read before it and the SDD ledger, and `session.compacting` no longer hands those lines to the summarizer; the extension is back to 7.0.1-omp.2's. The note never changed behavior in testing on omp 18.12.6, with memory and the advisor off. With and without it, a brainstorm-then-build run compacted mid-conversation re-read the brainstorming skill in 5 of 5 runs. A six-task subagent-driven-development run compacted after its first wave re-read the SDD skill and the ledger before its next dispatch, redid no finished task and finished the plan in 2 of 2 runs, both with the usual summary and with a summary told to leave out skills, plans and ledgers plus a 1,000-token kept window. The note's only visible effect was an extra read of every skill it listed: both of those last runs also re-read `using-git-worktrees`. It has little to add on omp: each compaction method tried kept the list of files the session wrote, which in an SDD run includes the ledger under `.superpowers/sdd/`. With a plain-text summary that named the skill nowhere, the model still named the SDD skill and the ledger path from memory, without tools.
|
|
14
|
+
|
|
15
|
+
## [7.0.1-omp.3] - 2026-10-24
|
|
16
|
+
|
|
17
|
+
### Added
|
|
18
|
+
|
|
19
|
+
- **After a compaction, the bootstrap names the superpowers skills read before it and the plan's ledger.** The extension reads them from the session branch, so the note holds whatever the compaction method and after `omp -c`; it also hands the same lines to the compaction summarizer through `session.compacting`. Checked live on omp 18.12.6 from the installed plugin path: the note was computed at compaction and sent with the bootstrap on each request of the next turn. It has not yet been shown to change behavior. In a short brainstorm-then-build run compacted mid-conversation, agents re-read the brainstorming skill and kept the small-change path in 5 of 5 runs with and without this change. In a six-task subagent-driven-development run compacted with `/compact` after its first wave (`remote` summary compaction, memory and the advisor off), the controller re-read the SDD skill and the ledger before anything else, redid no finished task and finished the plan in 2 of 2 runs with and without it; the note named the SDD skill and the ledger, but that summary already did too. It is aimed at a compaction whose summary drops a skill's rules.
|
|
20
|
+
|
|
21
|
+
### Changed
|
|
22
|
+
|
|
23
|
+
- **The README is easier to read.** It opens with what the fork is and a short get-started section, adds a diagram of how a request flows by its size, and folds the reference material (other install routes, how a seat's model is chosen, the file-by-file list of changes, maintenance) into expandable sections. No fact was dropped; the `task.isolation` notes are now marked as re-checked live on omp 18.12.6.
|
|
24
|
+
|
|
9
25
|
## [7.0.1-omp.2] - 2026-10-24
|
|
10
26
|
|
|
11
27
|
### Changed
|
|
@@ -133,7 +149,9 @@ First release, synced to upstream [v6.4.2](https://github.com/obra/superpowers/b
|
|
|
133
149
|
- The fork's rewritten subagent-driven-development text invokes its helper scripts through `bash` as well, so a package extractor that drops exec bits cannot break them.
|
|
134
150
|
- `sdd-final-reviewer` carries upstream's new review rules from `code-reviewer.md`, the template it replaces in SDD's final review: the spec is a vision document (behavior it is silent on is graded by what a reasonable person expects), and a "Declined to judge" section that the controller rules on and ledgers like a plan conflict.
|
|
135
151
|
|
|
136
|
-
[Unreleased]: https://github.com/LoneExile/omp-superpowers/compare/v7.0.1-omp.
|
|
152
|
+
[Unreleased]: https://github.com/LoneExile/omp-superpowers/compare/v7.0.1-omp.4...HEAD
|
|
153
|
+
[7.0.1-omp.4]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.1-omp.4
|
|
154
|
+
[7.0.1-omp.3]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.1-omp.3
|
|
137
155
|
[7.0.1-omp.2]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.1-omp.2
|
|
138
156
|
[7.0.1-omp.1]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.1-omp.1
|
|
139
157
|
[7.0.0-omp.4]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.0-omp.4
|
package/README.md
CHANGED
|
@@ -1,22 +1,44 @@
|
|
|
1
1
|
# omp-superpowers
|
|
2
2
|
|
|
3
|
-
[obra/superpowers](https://github.com/obra/superpowers) adapted for **omp (Oh My Pi)**.
|
|
3
|
+
[obra/superpowers](https://github.com/obra/superpowers), adapted for **omp (Oh My Pi)**.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
Superpowers gives your coding agent a way of working: it talks an idea through with you, writes a plan, builds it task by task with fresh subagents, reviews the work, and wraps up the branch. This fork keeps those skills and makes them fit omp.
|
|
6
|
+
|
|
7
|
+
## Why a fork
|
|
8
|
+
|
|
9
|
+
Upstream ships a Pi/omp compatibility layer, and on omp it is wrong:
|
|
10
|
+
|
|
11
|
+
- It tells the agent there is no subagent tool and no todo tool. omp has both.
|
|
12
|
+
- Its *Model Selection* rules use a `model:` field that the omp `task` tool does not have. Under those rules every subagent silently inherits the slowest configured model, with the widest tool set. In a real 157-subagent session, that was where most of the wall-clock time went.
|
|
6
13
|
|
|
7
14
|
This fork keeps the skills and fixes the omp side:
|
|
8
15
|
|
|
9
|
-
-
|
|
10
|
-
- **
|
|
11
|
-
- subagent-driven-development is rewritten around them
|
|
12
|
-
-
|
|
16
|
+
- **The tool mapping tells the truth** about `task`, `todo` and `read`/`grep`/`glob`.
|
|
17
|
+
- **Five omp agents** (`agents/sdd-*.md`) give every subagent-driven-development seat its own model, thinking level and tool set.
|
|
18
|
+
- **subagent-driven-development is rewritten around them:** a three-round fix loop, structured reviewer output, independent tasks in parallel worktrees, and a task review only where a task's risk earns it.
|
|
19
|
+
- **Fewer stops for approval.** A small change skips the design document, plan and subagents, and a project asks for one approval of design, plan and execution method together.
|
|
13
20
|
|
|
14
|
-
##
|
|
21
|
+
## Get started
|
|
22
|
+
|
|
23
|
+
Install it:
|
|
15
24
|
|
|
16
25
|
```bash
|
|
17
26
|
omp plugin install npm:@loneexile/omp-superpowers
|
|
18
27
|
```
|
|
19
28
|
|
|
29
|
+
Check that it loaded. Your `task` tool's roster should now include the five `sdd-*` agents:
|
|
30
|
+
|
|
31
|
+
```bash
|
|
32
|
+
omp -p --no-session --no-skills --model anthropic/claude-haiku-4-5 \
|
|
33
|
+
'List the agent type names your `task` tool offers, comma-separated, nothing else.'
|
|
34
|
+
# scout, reviewer, security-reviewer, sonic, task, sdd-implementer, sdd-reviewer, sdd-rereviewer, sdd-escalation-implementer, sdd-final-reviewer
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
That's all. The skills drive themselves once loaded: start a new omp session and ask for what you want to build.
|
|
38
|
+
|
|
39
|
+
<details>
|
|
40
|
+
<summary><b>Versions, upgrading and other ways to install</b></summary>
|
|
41
|
+
|
|
20
42
|
Releases are versioned `<upstream version>-omp.<n>`: `6.4.2-omp.1` is upstream v6.4.2 plus this fork's first iteration on it. [CHANGELOG.md](CHANGELOG.md) lists each release. To move to another one, uninstall and install it pinned:
|
|
21
43
|
|
|
22
44
|
```bash
|
|
@@ -24,23 +46,34 @@ omp plugin uninstall @loneexile/omp-superpowers
|
|
|
24
46
|
omp plugin install npm:@loneexile/omp-superpowers@<version>
|
|
25
47
|
```
|
|
26
48
|
|
|
27
|
-
|
|
49
|
+
**After an upgrade, restart omp.** Agent definitions are read **per dispatch**, so a reinstall takes effect on the next `task` call in a running session. The injected tool mapping and the skill catalog are read at process start, so they need the restart. The bootstrap is injected at the start of each session, including `/new`, `/resume` and `/fork`, until that session's first agent run ends, and again after compaction. Main session only; subagents never get it.
|
|
28
50
|
|
|
29
|
-
|
|
51
|
+
**Unreleased `main`** installs from GitHub under the same plugin name, pinned to a commit: `omp plugin install github:LoneExile/omp-superpowers#<sha>`.
|
|
30
52
|
|
|
31
|
-
|
|
53
|
+
**Coming from before 6.4.2-omp.1?** Those installs used the plugin name `superpowers`; run `omp plugin uninstall superpowers` before installing this package.
|
|
32
54
|
|
|
33
|
-
|
|
34
|
-
omp -p --no-session --no-skills --model anthropic/claude-haiku-4-5 \
|
|
35
|
-
'List the agent type names your `task` tool offers, comma-separated, nothing else.'
|
|
36
|
-
# scout, reviewer, security-reviewer, sonic, task, sdd-implementer, sdd-reviewer, sdd-rereviewer, sdd-escalation-implementer, sdd-final-reviewer
|
|
37
|
-
```
|
|
55
|
+
**Marketplace or `--plugin-dir` installs.** npm and `github:` installs keep each seat's model. For a marketplace or `--plugin-dir` install of the repo root, the repo carries `.omp-plugin/plugin.json`: omp 18.4.10's agent discovery treats a root that has `.claude-plugin/plugin.json` as Claude dialect, and drops every agent's `model:` line, unless that file is present. This was read from omp's source; a marketplace install has not been exercised.
|
|
38
56
|
|
|
39
|
-
|
|
57
|
+
</details>
|
|
40
58
|
|
|
41
|
-
##
|
|
59
|
+
## How work flows
|
|
42
60
|
|
|
43
|
-
|
|
61
|
+
How much process a request gets depends on its size:
|
|
62
|
+
|
|
63
|
+
```mermaid
|
|
64
|
+
flowchart TD
|
|
65
|
+
R["your request"] --> B["brainstorming: what do you actually want?"]
|
|
66
|
+
B -->|"a quick, clear task"| Q["done right away"]
|
|
67
|
+
B -->|"a small change"| S["you approve it in chat; the session builds it on a branch, test first, one commit"]
|
|
68
|
+
B -->|"a project"| D["a written design"]
|
|
69
|
+
D --> P["writing-plans: the plan, then one approval of design, plan and method"]
|
|
70
|
+
P -->|"subagents"| SDD["subagent-driven-development"]
|
|
71
|
+
P -->|"Native"| EP["executing-plans: the session does every task itself"]
|
|
72
|
+
SDD --> F["finishing-a-development-branch: merge, PR or discard"]
|
|
73
|
+
EP --> F
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
The usual path, skill by skill:
|
|
44
77
|
|
|
45
78
|
1. `read skill://brainstorming` — turn an idea into a design. A small change stops here: after you approve it in chat, the session builds it itself, test first, and commits once
|
|
46
79
|
2. `read skill://writing-plans` — produce `docs/plans/<date>-<name>.md`, pick the execution method, and ask once for approval of the design, the plan and the method together
|
|
@@ -49,9 +82,16 @@ The skills drive themselves once loaded. The usual path:
|
|
|
49
82
|
|
|
50
83
|
On omp the agent invokes a skill by reading it (`read skill://<name>`); you can also invoke one explicitly with `/skill:<name>`.
|
|
51
84
|
|
|
52
|
-
|
|
85
|
+
<details>
|
|
86
|
+
<summary><b>Vibe mode</b></summary>
|
|
87
|
+
|
|
88
|
+
After `/vibe` the session is a director of `fast`/`good` workers and has no `task`, `bash` or file-writing tool, so it cannot run subagent-driven-development or executing-plans itself. Both skills tell it to hand the whole run to one `good` worker, which dispatches the `sdd-*` seats through its own `task` tool. Each worker brief names the tests to run, because omp 18.4.12 workers skip them otherwise. Vibe refuses `/move` and `/wt`, so create the worktree and `/move` into it first; for a long plan set `task.softRequestBudget: 0`. Details are in the *Vibe mode* section of [`pi-tools.md`](skills/using-superpowers/references/pi-tools.md).
|
|
53
89
|
|
|
54
|
-
|
|
90
|
+
</details>
|
|
91
|
+
|
|
92
|
+
## Running a plan with subagents
|
|
93
|
+
|
|
94
|
+
subagent-driven-development hands each task to a fresh implementer, reviews it where its risk calls for that, and records every step in a ledger, so a long run can pick up where it stopped. Per task:
|
|
55
95
|
|
|
56
96
|
```mermaid
|
|
57
97
|
flowchart TD
|
|
@@ -82,7 +122,7 @@ flowchart TD
|
|
|
82
122
|
|
|
83
123
|
Blue nodes are the five omp agents this fork ships. A reviewer that cannot read its package yields the `package_gap` verdict value (with what it tried) instead of inventing one, and the controller regenerates and re-dispatches.
|
|
84
124
|
|
|
85
|
-
### The
|
|
125
|
+
### The five seats
|
|
86
126
|
|
|
87
127
|
| Seat | agent | shipped default · thinking | falls back to | tools |
|
|
88
128
|
|---|---|---|---|---|
|
|
@@ -92,15 +132,44 @@ Blue nodes are the five omp agents this fork ships. A reviewer that cannot read
|
|
|
92
132
|
| fix round 3 / ruled strongest-tier task | `sdd-escalation-implementer` | claude-opus-5-5 · max | `@slow` | same as implementer |
|
|
93
133
|
| final whole-branch review (subagent-driven or Native) | `sdd-final-reviewer` | claude-opus-5-5 · max | `@slow` | read, grep, glob, bash, lsp, ast_grep |
|
|
94
134
|
|
|
135
|
+
The shipped defaults are Anthropic: sonnet for the seats that run on every task, opus for the two that run once per plan or once per stuck task. The tiers are a **thinking ladder** as much as a model ladder — re-reviews reason at `low`, escalation and the final review at `max`.
|
|
136
|
+
|
|
95
137
|
`lsp` and `ast_grep` are listed for the seats that benefit, but omp only activates them in subagents when `task.enableLsp` / `astGrep.enabled` are on (both default off).
|
|
96
138
|
|
|
139
|
+
<details>
|
|
140
|
+
<summary><b>Which model a seat actually runs on</b></summary>
|
|
141
|
+
|
|
97
142
|
omp takes the first list entry whose provider has credentials. If the pin has none, the seat runs on your `modelRoles.task` / `modelRoles.slow` model at that role's own level. An unset `@task` drops out, and the seat then silently runs on the controller's model; an unset `@slow` expands to omp's built-in strong-model ranking. The list is also the retry chain on rate-limit and usage-limit errors, gated by `retry.modelFallback` (default on); there is no switch on context overflow. Turn on `task.showResolvedModelBadge`, or read `session_init.resolvedModel` in a subagent transcript, to see what actually ran.
|
|
98
143
|
|
|
99
|
-
|
|
144
|
+
</details>
|
|
145
|
+
|
|
146
|
+
<details>
|
|
147
|
+
<summary><b>What the reviewer seats can and can't do</b></summary>
|
|
100
148
|
|
|
101
149
|
The two reviewer seats have no `bash`, `edit`, or filesystem `write`: the review package (`git diff -U10` written to a file) is their whole view of the change, and they return a structured result (`spec_compliance`, `task_quality`, `findings[]`, `cannot_verify[]`; `finding_verdicts[]`, `new_breakage[]`, `round_verdict`) plus `package_gap` when they could not read the package. Note the honest boundary: an agent's `tools:` list limits built-in tools only. Extension tools and MCP tools (mounted as `xd://` devices and run through a device-only `write`) still attach to every subagent; memory tools attach only when the agent's `tools:` list names them. On omp 18.4.10 a read/grep/glob reviewer ran a shell command through an MCP device. Read-only is by instruction, not a sandbox.
|
|
102
150
|
|
|
103
|
-
|
|
151
|
+
</details>
|
|
152
|
+
|
|
153
|
+
## Changing models (no file edits)
|
|
154
|
+
|
|
155
|
+
Set `task.agentModelOverrides` in `~/.omp/agent/config.yml`, or use `/agents` in any session (it edits the same map). It applies on the next dispatch; delete a line to fall back to the agent file.
|
|
156
|
+
|
|
157
|
+
Example — every seat on one flat-rate model, mapped onto that model's own thinking ladder:
|
|
158
|
+
|
|
159
|
+
```yaml
|
|
160
|
+
task:
|
|
161
|
+
agentModelOverrides:
|
|
162
|
+
sdd-implementer: opencode-go/deepseek-v4.1-flash:high
|
|
163
|
+
sdd-reviewer: opencode-go/deepseek-v4.1-flash:high
|
|
164
|
+
sdd-rereviewer: opencode-go/deepseek-v4.1-flash:low
|
|
165
|
+
sdd-escalation-implementer: opencode-go/deepseek-v4.1-flash:max
|
|
166
|
+
sdd-final-reviewer: opencode-go/deepseek-v4.1-flash:max
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
**Use the exact catalog id and a level the model actually offers.** `omp models ls <provider>` shows each model's ladder. A level that is not on it is silently clamped to the nearest valid one — `deepseek-v4.1-flash` offers only `low, high, max`, so `:medium` would run at `low` and `:xhigh` at `high`, collapsing the ladder without any error. Check `session_init.resolvedModel` in a subagent transcript if in doubt: it shows the level that actually ran. Catalog ids also get renamed (this one was `deepseek-flash` a day earlier, and the old string now matches an empty placeholder row).
|
|
170
|
+
|
|
171
|
+
<details>
|
|
172
|
+
<summary><b>How omp resolves a seat's model and thinking level</b></summary>
|
|
104
173
|
|
|
105
174
|
omp resolves each seat's model and thinking level in a fixed order. The override map is the layer meant for you:
|
|
106
175
|
|
|
@@ -119,25 +188,10 @@ flowchart LR
|
|
|
119
188
|
class M1 you
|
|
120
189
|
```
|
|
121
190
|
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
Example — every seat on one flat-rate model, mapped onto that model's own thinking ladder:
|
|
125
|
-
|
|
126
|
-
```yaml
|
|
127
|
-
task:
|
|
128
|
-
agentModelOverrides:
|
|
129
|
-
sdd-implementer: opencode-go/deepseek-v4.1-flash:high
|
|
130
|
-
sdd-reviewer: opencode-go/deepseek-v4.1-flash:high
|
|
131
|
-
sdd-rereviewer: opencode-go/deepseek-v4.1-flash:low
|
|
132
|
-
sdd-escalation-implementer: opencode-go/deepseek-v4.1-flash:max
|
|
133
|
-
sdd-final-reviewer: opencode-go/deepseek-v4.1-flash:max
|
|
134
|
-
```
|
|
135
|
-
|
|
136
|
-
**Use the exact catalog id and a level the model actually offers.** `omp models ls <provider>` shows each model's ladder. A level that is not on it is silently clamped to the nearest valid one — `deepseek-v4.1-flash` offers only `low, high, max`, so `:medium` would run at `low` and `:xhigh` at `high`, collapsing the ladder without any error. Check `session_init.resolvedModel` in a subagent transcript if in doubt: it shows the level that actually ran. Catalog ids also get renamed (this one was `deepseek-flash` a day earlier, and the old string now matches an empty placeholder row).
|
|
137
|
-
|
|
138
|
-
Measured on a real fix-round re-review with identical inputs: a grok-4.6 seat took 9.7 min / 4 turns, sonnet-5 about 50 s / 1 turn, the DeepSeek flash seat 100 s / 4 turns — same verdict, full structured result, all three.
|
|
191
|
+
</details>
|
|
139
192
|
|
|
140
|
-
|
|
193
|
+
<details>
|
|
194
|
+
<summary><b>Rules that are easy to get wrong</b></summary>
|
|
141
195
|
|
|
142
196
|
- A **bare model** (`anthropic/claude-haiku-4-5`) keeps the agent file's own `thinkingLevel`. Add `:level` (`…:high`) to change reasoning too.
|
|
143
197
|
- **Delete a line** to fall back to the agent file's default for that seat. Overrides apply on the next dispatch — no restart.
|
|
@@ -146,7 +200,11 @@ Rules that are easy to get wrong:
|
|
|
146
200
|
- `effort` on a dispatch (when `task.enableEffort` is on) accepts only `"lo"`, `"med"`, `"hi"`. `"hi"` maps to the model's top supported level, capped by `task.maxEffort`; SDD uses `effort: "hi"` for high-risk task reviews, and for escalation only when a host override lowers that seat.
|
|
147
201
|
- Discovery-only model ids (the OpenCode Go catalog, for example) accept `:level` in config and in overrides but not on the `--model` CLI flag.
|
|
148
202
|
|
|
149
|
-
|
|
203
|
+
Measured on a real fix-round re-review with identical inputs: a grok-4.6 seat took 9.7 min / 4 turns, sonnet-5 about 50 s / 1 turn, the DeepSeek flash seat 100 s / 4 turns — same verdict, full structured result, all three.
|
|
204
|
+
|
|
205
|
+
</details>
|
|
206
|
+
|
|
207
|
+
## Settings worth knowing
|
|
150
208
|
|
|
151
209
|
| setting | why |
|
|
152
210
|
|---|---|
|
|
@@ -158,6 +216,11 @@ Rules that are easy to get wrong:
|
|
|
158
216
|
|
|
159
217
|
## What changed from upstream
|
|
160
218
|
|
|
219
|
+
In short: the omp extension and `pi-tools.md` describe omp's real tools; five `sdd-*` agents are new; subagent-driven-development, executing-plans, writing-plans and brainstorming are reworked as described above; requesting-code-review, using-git-worktrees and finishing-a-development-branch get small edits; and specs and plans live in `docs/specs/` and `docs/plans/`.
|
|
220
|
+
|
|
221
|
+
<details>
|
|
222
|
+
<summary><b>File by file</b></summary>
|
|
223
|
+
|
|
161
224
|
- `.pi/extensions/superpowers.ts` — the injected mapping names `task`, `todo`, the `sdd-*` roster, and the no-`model:`-field rule; it also re-arms on `session_switch`, skips subagent sessions, and ignores an `agent_end` that will auto-continue; it tells a dispatching session to name the checks each subagent must run, since omp 18.4.12 tells subagents to leave builds, tests and smoke runs to the main agent unless their assignment explicitly instructs them; its last paragraph points a vibe-mode director (tools include `vibe_spawn` but not `task`) at the *Vibe mode* section of `pi-tools.md`
|
|
162
225
|
- `.omp-plugin/plugin.json` — new. Marks the repo root as an omp-native plugin so a marketplace or `--plugin-dir` install keeps each agent's `model:` line
|
|
163
226
|
- `skills/using-superpowers/references/pi-tools.md` — same, as the reference doc; it also gains a *Checks* subsection (the 18.4.12 subagent hand-off rule, and why every dispatch names its checks) and a *Vibe mode* section: what a director keeps and lacks, how skill actions map onto `vibe_*` and workers, and the worktree and request-budget limits
|
|
@@ -176,11 +239,14 @@ Rules that are easy to get wrong:
|
|
|
176
239
|
- Spec and plan paths — `docs/specs/` and `docs/plans/` instead of upstream's `docs/superpowers/specs/` and `docs/superpowers/plans/`: brainstorming's *Where it goes*, writing-plans' save path and handoff lines, and the example plan paths in executing-plans, subagent-driven-development and requesting-code-review. `.superpowers/` (the SDD workspace, brainstorm companion files) is unchanged. `scripts/check-npm-package.sh` fails if a shipped file names `docs/superpowers/`
|
|
177
240
|
- `CHANGELOG.md`, `.github/workflows/` (CI, npm release), `scripts/check-npm-package.sh` — new
|
|
178
241
|
|
|
242
|
+
</details>
|
|
243
|
+
|
|
179
244
|
Everything else is upstream, unmodified.
|
|
180
245
|
|
|
181
|
-
##
|
|
246
|
+
## Maintaining the fork
|
|
182
247
|
|
|
183
|
-
|
|
248
|
+
<details>
|
|
249
|
+
<summary><b>Syncing with upstream</b></summary>
|
|
184
250
|
|
|
185
251
|
```bash
|
|
186
252
|
git fetch upstream --tags
|
|
@@ -194,7 +260,10 @@ A clean rebase is not the whole sync. Upstream's edits to text this fork replace
|
|
|
194
260
|
|
|
195
261
|
The fork changes upstream's `docs/superpowers/specs` and `docs/superpowers/plans` lines in brainstorming, writing-plans, executing-plans, subagent-driven-development and requesting-code-review. When upstream edits around one of them, `-X theirs` keeps the fork's whole conflicting hunk, so read upstream's diff of those lines and port the rest of the hunk. New upstream text naming `docs/superpowers/` fails `check-npm-package.sh` until it says `docs/specs/` or `docs/plans/`.
|
|
196
262
|
|
|
197
|
-
|
|
263
|
+
</details>
|
|
264
|
+
|
|
265
|
+
<details>
|
|
266
|
+
<summary><b>Releasing</b></summary>
|
|
198
267
|
|
|
199
268
|
1. Set `version` in `package.json`, move CHANGELOG.md's *Unreleased* entries under that version, commit, push, and wait for CI.
|
|
200
269
|
2. Publish a GitHub release for the tag `v<version>`; the [release workflow](.github/workflows/release.yml) publishes it to npm through Trusted Publishing, with provenance:
|
|
@@ -205,9 +274,14 @@ awk -v h="## [$v]" 'index($0, h) == 1 {f = 1; next} f && /^(## )?\[/ {exit} f' C
|
|
|
205
274
|
gh release create "v$v" --target main --title "v$v" --notes-file /tmp/notes.md
|
|
206
275
|
```
|
|
207
276
|
|
|
208
|
-
|
|
277
|
+
</details>
|
|
278
|
+
|
|
279
|
+
<details>
|
|
280
|
+
<summary><b>Checking a new omp version</b></summary>
|
|
281
|
+
|
|
282
|
+
Before trusting a new omp release, re-check the harness facts this fork depends on — against the **running binary**, not an npm source tree that may lag it. `~/.bun/install/global/node_modules/@oh-my-pi/pi-coding-agent/src` routinely lags `omp --version` (a 17.4.2 tree sat beside an 18.1.17 binary while this README was written, and the isolation setting had been renamed in between). The fork was last verified against omp 18.4.10; its vibe-mode text and the subagent check rule were re-checked against 18.4.12, and the `task.isolation` notes against 18.11.0 and again, live, on 18.12.6. To read the exact running version's source, pack it into a temp dir: `cd "$(mktemp -d)" && npm pack @oh-my-pi/pi-coding-agent@$(omp --version | cut -d/ -f2) && tar xzf *.tgz` (source under `package/src`). The live oracles are `omp config list --json` (every setting and its default), the `task` tool's own description in a session (agent roster, item fields), a `session_init.resolvedModel` line in a subagent transcript (what actually resolved), and `grep -a` on the binary for an exact string when you need to know whether a code path exists.
|
|
209
283
|
|
|
210
|
-
|
|
284
|
+
</details>
|
|
211
285
|
|
|
212
286
|
## License
|
|
213
287
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@loneexile/omp-superpowers",
|
|
3
|
-
"version": "7.0.1-omp.
|
|
3
|
+
"version": "7.0.1-omp.4",
|
|
4
4
|
"description": "obra/superpowers adapted for Oh My Pi (omp): a truthful task/todo tool mapping and five subagent-driven-development agents, each with its own model, thinking level, and tools.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"keywords": [
|