opencode-thrum-pro 0.1.4 → 0.1.5

package/assets/skills/agent-messaging-protocol/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: agent-messaging-protocol
+description: "Use when forwarding or relaying information between parties, routing an owner answer, carrying a decision or request through an intermediary, summarizing another author's message, or adding interpretation to someone else's words."
+---
+
+# Agent Messaging Protocol for Forwarding and Relaying
+
+- Communicate directly with the intended party whenever possible.
+- Treat the original message as the authoritative source.
+- Forward a pointer to the original message instead of retyping or paraphrasing its body.
+- Include the original author, original message ID, intended recipient, and requested action.
+- Attach `message:<original-message-id>` as a message reference when supported.
+- Read the original message before acting: `thrum message get <message-id> --json`.
+- Reply against the original message: `thrum reply <message-id> ...`.
+- Do not route the response back through the intermediary.
+- Add commentary or interpretation only when requested or necessary.
+- Label added reasoning as `INTERPRETATION - @agent`.
+- Never present an interpretation, summary, or recommendation as words or authority from the original author.
+- Label a requested summary as `SUMMARY - @agent` and retain the original message ID.
+- Preserve the original scope, urgency, constraints, and requested action.
+- Do not introduce new requirements, decisions, risks, or authorization while routing.
+- Ask the original author directly when clarification is required.
+- Continue referencing the original message rather than an intermediary's summary.
+- Identify corrections by the exact message they supersede.
+- Distinguish delivery, acknowledgement, execution, and verification.
+- Preserve the original thread audience when replying unless a deliberately narrower audience is required.
+
+## Routing Envelope
+
+```text
+ROUTE POINTER
+From: @original-author
+Message: msg_...
+Action: Read and reply to the original message.
+```

package/assets/skills/brainstormer-staying-current/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: brainstormer-staying-current
+description: "Use when a long-lived brainstormer worktree may be behind its configured merge target, before review or handoff, or when asked to merge-forward and leave the worktree clean. Resolves the target and merge owner from Thrum config, preserves local work, and verifies freshness after the merge."
+---
+
+# Brainstormer: Stay Current with the Merge Target
+
+Keep a long-lived brainstorm branch current without landing it into the merge
+target. Every git write in this skill (commit, merge, revert, push) stays with
+you — never delegate a git write to a subagent. Every `fetch` also stays with
+you, the acting agent, per Preserve and Bind freshness below. If you delegate
+the read-only merge-base/status analysis, load `choosing-subagent-models`
+first and fence the subagent to `show`, `log`, `diff`, `grep`, `rev-parse`,
+`merge-base`, `status` — the same read-only git surface CLAUDE.md requires for
+every sub-agent — never `stash`, `reset`, `rebase`, `restore`, `clean`,
+`commit`, `push`, or `checkout`.
+
+## Resolve authority from config
+
+Locate the canonical config from the current worktree:
+
+```bash
+CONFIG=.thrum/config.json
+if [ ! -f "$CONFIG" ]; then
+  COMMON_DIR=$(git rev-parse --path-format=absolute --git-common-dir)
+  CONFIG="${COMMON_DIR%/.git}/.thrum/config.json"
+fi
+test -f "$CONFIG"
+TARGET=$(jq -er '.orchestration.merge_target | select(type == "string" and length > 0)' "$CONFIG")
+MERGE_KING=$(jq -r --arg target "$TARGET" '.orchestration.merge_kings[$target] // "unset"' "$CONFIG")
+```
+
+Treat an absent config or target as a blocker — merge-forward has nowhere to
+target without them. A merge-forward only brings `origin/$TARGET` into the
+brainstorm branch; it never grants permission to merge the brainstorm branch
+into `$TARGET`, so it needs no landing authority to run and an `unset`
+`MERGE_KING` never blocks it.
+
+`orchestration.merge_kings` may not be populated for every target yet: `unset`
+does NOT mean "nobody owns landing, proceed however" — it means the map
+hasn't caught up (same gap `coordinator-merging-code/SKILL.md` documents for
+branch-keyed lookups). `MERGE_KING` matters only when a conflict needs routing
+or at final report. With it `unset` at either point, fall back to whichever
+coordinator has actually been the merge authority for `$TARGET` in practice
+(check with your team, or the project's operational convention) and
+route/report to them the same as if the map had named them explicitly.
+
+## Preserve before merging
+
+Record the current branch, HEAD, status, and ahead/behind counts. Require an
+attached non-target feature branch. Fetch the target branch explicitly:
+
+```bash
+git fetch origin "refs/heads/$TARGET:refs/remotes/origin/$TARGET"
+git rev-list --left-right --count HEAD..."origin/$TARGET"
+```
+
+If the worktree is dirty, preserve tracked and untracked changes as a WIP
+commit and record its SHA — never `git stash`. `stash` is a single shared
+stack across every worktree on this box, not scoped to this worktree or to
+you; a stash push or pop here can silently destroy or restore another agent's
+uncommitted work, with no reflog entry and no recoverable blob for unstaged
+content. A commit is yours alone and fully recoverable.
+
+```bash
+git add -A
+git commit -m "wip: preserve <branch> before merge-forward <timestamp>"
+git rev-parse HEAD
+git status --short
+```
+
+Do not squash, drop, or revert the WIP commit when the requested outcome is a
+clean worktree — it is real history now, not something to discard.
+
+Stop if the worktree is still dirty after the WIP commit. Never use `stash`,
+reset, rebase, force checkout, clean, or force push to obtain a clean state —
+`stash` is banned here exactly like the others, with no worktree-scoped
+exception.
+
+## Merge-forward
+
+Merge the remote-tracking target into the brainstorm branch:
+
+```bash
+git merge --no-edit "origin/$TARGET"
+```
+
+Resolve a conflict only when the correct result is supported by current source
+and the branch's intended work. Otherwise stop with the conflict intact and
+send the branch, worktree, target, and conflicted paths to the user or
+`$MERGE_KING` for direction — falling back to the operational-convention
+authority per above if `$MERGE_KING` is `unset`.
+
+After a successful merge, run validation relevant to every resolved file and
+always run `git diff --check origin/$TARGET..HEAD`.
+
+## Bind freshness to handoff
+
+Immediately before reporting success, fetch the target branch explicitly again
+and verify the fetched target is an ancestor of HEAD:
+
+```bash
+git fetch origin "refs/heads/$TARGET:refs/remotes/origin/$TARGET"
+git rev-list --left-right --count HEAD..."origin/$TARGET"
+git merge-base --is-ancestor "origin/$TARGET" HEAD
+git status --short
+```
+
+If the target advanced, repeat the merge-forward and verification, up to three
+merge cycles in one run. After three moving-target results, stop and report the
+new target SHA instead of claiming the branch is current.
+
+Report the branch and target SHAs, ahead/behind counts, `$MERGE_KING` (or the
+fallback authority if `unset`), validation, clean status, and the WIP commit
+SHA if one was made. Do not push, squash, or drop the WIP commit unless the
+user separately asks.

package/assets/skills/coordinator-running-brainstorm-cycles/SKILL.md

@@ -43,9 +43,10 @@ at every stage:
 each time (`verify-against-source` + a prose-quality reviewer, sonnet sub-agents
 in parallel — see "Review-loop mechanics" below). Skipping any review gate is a
 documented anti-pattern. The brainstorm review catches design issues; the plan
-review catches contract-drift and quality issues `writing-plans`' internal
-reviewer misses; the prompt review catches plan→prompt translation errors before
-the implementer executes against them.
+review is the SOLE quality gate on the plan doc — the researcher authors the
+plan directly (no external tool with its own internal reviewer sits upstream of
+this gate); the prompt review catches plan→prompt translation errors before the
+implementer executes against them.
 
 ## Subagent model selection
 
@@ -81,7 +82,7 @@ forwarding.
 ### Footer → commit → stamp (per stage)
 
 1. After the artifact is written, append the gate footer:
-   `<!-- THRUM-GATE: stage=<brainstorm|plan|prompt> next=<dual-review|writing-plans|project-setup|dispatch> -->`
+   `<!-- THRUM-GATE: stage=<brainstorm|plan|prompt> next=<dual-review|plan|project-setup|dispatch> -->`
 2. **Commit the artifact (WIP) including the footer** — this gives the
    supplementary `requesting-code-review` pass a real `HEAD~1..HEAD` range.
 3. Run the dual review against that range; each fix cycle commits its changes
@@ -120,7 +121,7 @@ forwarding.
 
 ### Soft pre-flight greps (the SOFT enforcement tier)
 
-Before invoking `writing-plans` (Phase 6) and before `project-setup` (Phase 7),
+Before writing the plan (Phase 6) and before `project-setup` (Phase 7),
 grep the prior artifact for `THRUM-REVIEW: stage=<S> verdict=Ready:Yes` (or
 `verdict=OVERRIDE`); absent → STOP and run the review first. Anchor the match —
 `grep -E '...verdict=Ready:Yes([[:space:]]|-->|$)'`, never `grep -F` — or an
@@ -150,32 +151,22 @@ structurally-enforceable gate is `project-setup` Phase 0 (it hard-bails).
   `## Deviations from Source` block with attribution `owner decision`, never
   silently absorbed.
 
-### Superpowers dependency (D6)
+### No external plugin drives this pipeline (D6)
 
-The wrapper drives `superpowers:brainstorming` / `writing-plans`. Two distinct
-pre-flight behaviors:
+Neither the brainstorm stage (Phase 2) nor the plan stage (Phase 6) invokes an
+external skill — the researcher writes both artifacts directly, governed by
+this skill's own protocol block (Phase 2) and structure/stamp/deviations
+requirements (Phase 6). There is nothing to pre-flight-check or bail on for
+either stage, and no `/plugin install` path: no such plugin is declared
+anywhere in this repo's `.claude-plugin/marketplace.json` (thrum-tsaq4).
 
-- `requesting-code-review` not resolvable → SKIP the supplementary quality pass
-  gracefully (the loop still runs on the general-purpose primary).
-- `brainstorming` / `writing-plans` not present → **BAIL** with an install
-  instruction (`/plugin install superpowers@<marketplace>`).
+The one genuinely optional external supplement is `requesting-code-review`
+(Review-loop mechanics, "Quality" row) — not resolvable → SKIP the
+supplementary quality pass gracefully; the loop still runs on the
+general-purpose primary, which is authoritative regardless.
 
-`verify-against-source` carries no superpowers dependency and always works.
-
-### Countermand the superpowers chain (outcome-based)
-
-`brainstorming` auto-chains to `writing-plans`, and `writing-plans` defaults
-pull toward subagent-driven execution — both bypass thrum's `project-setup`. At
-each invocation, inject (keyed on the concept, so it survives upstream
-rewording):
-
-> Regardless of any execution-handoff, "recommended" sub-skill, or save-location
-> default these skills emit, the ONLY downstream path in thrum is the next thrum
-> stage. After the artifact is written, STOP — do not auto-chain. Save to the
-> thrum path, not the superpowers default. For `writing-plans`: remove/replace
-> the plan-header line matching the stable substring
-> `REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development` and ignore
-> the Execution-Handoff offer — the plan feeds `project-setup`.
+`verify-against-source` and the general-purpose prose-quality pass carry no
+external-plugin dependency and always work.
 
 ## Phase 1 — Set up the worktree, branch, and agent
 
@@ -353,12 +344,10 @@ distinction in the inbox display):
 8. **Go-deep-then-ready instruction** — one sentence telling them to confirm
    readiness, research aggressively, and have meaty material ready when the user
    joins (not to sit idle waiting).
-9. **Countermand callout** — `superpowers:brainstorming`'s terminal state is
-   "invoke writing-plans". Tell the researcher explicitly: when brainstorming
-   reaches that terminal state, STOP at the design doc — do NOT auto-chain to
-   `writing-plans`. The brainstorm goes through the Phase 3 review gate first,
-   then Phase 6 runs `writing-plans` deliberately (with its own countermand).
-   See "Review-loop mechanics → Countermand the superpowers chain."
+9. **Stop-at-the-artifact instruction** — tell the researcher explicitly: once
+   the brainstorm design doc is drafted, STOP there. It goes through the
+   Phase 3 review gate before anything else happens; the plan doc is a
+   separate, deliberate Phase 6 step after the brainstorm is LOCKED.
 
 Send the whole thing as one `thrum send` call. The recipient's runtime will
 display it as a single inbox message; structure beats brevity here.
@@ -475,23 +464,21 @@ expensive footguns hide.
 ## Phase 6 — Researcher writes the plan (with dual-review gate)
 
 Once the brainstorm is LOCKED (and any companion design spec is LOCKED), the
-researcher runs `superpowers:writing-plans` to convert brainstorm + spec into
-the implementation plan doc. (First, the soft pre-flight grep: `grep -F` the
-brainstorm for its `THRUM-REVIEW: stage=brainstorm verdict=Ready:Yes` (or
-`OVERRIDE`) stamp — absent → STOP and finish the brainstorm review.) **Inject
-the outcome-based countermand** (see Review-loop mechanics) at the
-`writing-plans` invocation: stop when the plan is written, save to the thrum
-path, and strip the `subagent-driven-development` plan-header line — the plan
-feeds `project-setup`, not superpowers execution.
+researcher writes the implementation plan doc directly, converting the
+brainstorm + spec into concrete steps. (First, the soft pre-flight grep:
+`grep -F` the brainstorm for its `THRUM-REVIEW: stage=brainstorm
+verdict=Ready:Yes` (or `OVERRIDE`) stamp — absent → STOP and finish the
+brainstorm review.) The plan feeds `project-setup` — there is no other
+downstream path.
 
 **The plan doc gets the SAME dual-review treatment as the brainstorm.** This
-review step is mandatory — `writing-plans` has an internal reviewer, but real-
-world experience shows that's not sufficient. Independent review catches
-contract-drift and quality issues the internal reviewer misses.
+review step is mandatory: there is no internal reviewer upstream of it, so
+this gate is the plan's only quality check. Independent review catches
+contract-drift and quality issues a single author would miss.
 
 **The researcher (not coord) dispatches the dual-review** in their own worktree:
 
-1. Researcher writes plan v1 via `writing-plans` skill (countermand applied).
+1. Researcher writes plan v1 directly.
 2. Researcher authors the `## Deviations from Source` block per
    `claude-plugin/commands/_deviations-protocol.md`, diffing plan v1 against
    the brainstorm + design spec — BEFORE dual-review, so
@@ -573,9 +560,8 @@ review catches translation errors (plan → prompt) plus prompt-specific quality
 4. Researcher signals "project-setup complete + post-setup dual-review applied"
    back to coord, citing both review passes + final artifact paths.
 
-Reaffirmation (countermand at the prompt stage): `project-setup` is the only
-downstream path — do not adopt `subagent-driven-development` execution even if a
-superpowers skill suggests it.
+Reaffirmation (at the prompt stage): `project-setup` is the only downstream
+path for the implementer prompt.
 
 If the researcher signals "project-setup complete" WITHOUT mentioning the
 post-setup reviews, ASK explicitly: "did the post-setup dual-review run on the
@@ -607,9 +593,9 @@ encodes this; include the verbatim protocol block in every briefing.
 ❌ **Half-batched findings.** Sending review findings before BOTH dual reviews
 complete. Researcher fixes batch 1 and never sees batch 2.
 
-❌ **Skipping the post-plan dual-review.** Treating `writing-plans` skill's
-internal reviewer as sufficient and proceeding directly to `project-setup`
-without an independent review of the plan doc. The plan and the impl
+❌ **Skipping the post-plan dual-review.** Proceeding directly to
+`project-setup` without an independent review of the plan doc — there is no
+internal reviewer upstream of it to lean on. The plan and the impl
 prompt MUST get the same dual-axis review treatment the brainstorm gets — Phase
 6 + Phase 7 explicit.
 

package/assets/skills/efficient-multi-agent-research/SKILL.md

@@ -15,10 +15,9 @@ single report.
 **Core principle:** The coordinator decides, sub-agents investigate. Keep
 investigation results out of the main context until consolidated.
 
-**REQUIRED BACKGROUND:** Read superpowers:dispatching-parallel-agents before
-using this skill. That skill
-covers general parallel dispatch. This skill extends it with a specific research
-workflow: partition, investigate to disk, consolidate, then decide.
+This skill is self-contained: partition, investigate to disk, consolidate,
+then decide — the full dispatch mechanics (Agent tool syntax, background mode,
+read-only scoping) are in "Core Pattern" below.
 
 ## When to Use
 

package/assets/skills/persistent-watcher-archetype/SKILL.md

@@ -227,18 +227,22 @@ stability check, writes one report file, and emits one matchable summary
 line. It is mechanical only — no auto-escalate, no auto-key — exactly the
 scope this section already describes; judgment stays in your own turn.
 
-**Setup (one-time per watcher instance):** `CLAUDE_PLUGIN_ROOT` is a
-Claude-Code-hook-only env var — it is NOT present in `thrum monitor`'s
-scheduled-process environment, so the script cannot locate itself inside
-the plugin tree at run time. Copy both scripts out of the skill's
-`resources/` into your own agent directory first:
-
-```bash
-cp "${CLAUDE_PLUGIN_ROOT}/skills/persistent-watcher-archetype/resources/thrum-watch-pane-capture.sh" \
-   "${CLAUDE_PLUGIN_ROOT}/skills/persistent-watcher-archetype/resources/thrum-capture-fallback.sh" \
-   .thrum/agents/<you>/
-chmod +x .thrum/agents/<you>/thrum-watch-pane-capture.sh .thrum/agents/<you>/thrum-capture-fallback.sh
-```
+**Setup (one-time per watcher instance):** the script cannot locate itself
+inside the plugin tree at run time — `thrum monitor`'s scheduled-process
+environment has none of the plugin-root env vars a hook invocation gets
+(`CLAUDE_PLUGIN_ROOT`, codex's `PLUGIN_ROOT`), and neither is reliably set
+in an ordinary interactive turn either, so a shell `cp` against either
+variable is not runtime-safe in any host. Copy both scripts out of the
+skill's `resources/` into your own agent directory using your Read/Write
+tools instead — the same skill-relative resolution every other `resources/`
+reference in this plugin already uses, with no env var and no
+runtime-versioned path involved:
+
+1. Read `resources/thrum-watch-pane-capture.sh` (relative to this skill) and
+   Write its exact content to `.thrum/agents/<you>/thrum-watch-pane-capture.sh`.
+2. Read `resources/thrum-capture-fallback.sh` and Write its exact content to
+   `.thrum/agents/<you>/thrum-capture-fallback.sh`.
+3. `chmod +x .thrum/agents/<you>/thrum-watch-pane-capture.sh .thrum/agents/<you>/thrum-capture-fallback.sh`
 
 Then register the monitor against that absolute copy path —
 **`--notify-on-success` is MANDATORY, not optional decoration**: a

package/assets/skills/state-migration/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: state-migration
-description: "Use when your agent-local thrum state is empty AND you have an existing State.md file in your agent directory - this is a ONE-TIME conditional onboarding that fires only on that exact combination. Do NOT use if thrum state already has entries (nothing to migrate) or if you have no State.md (brand-new agent, nothing to migrate). Triggers on: first session after the thrum state redesign lands, `thrum state list` returning empty while State.md exists on disk, being asked to migrate your personal state."
+description: "Use when your agent-local thrum state is empty AND you have an existing State.md file in your agent directory - this is a ONE-TIME conditional onboarding that fires only on that exact combination. Do NOT use if thrum state already has entries (nothing to migrate) or if you have no State.md (brand-new agent, nothing to migrate). Triggers on - first session after the thrum state redesign lands, `thrum state list` returning empty while State.md exists on disk, being asked to migrate your personal state."
 ---
 
 # Migrating personal State.md into `thrum state`

package/assets/skills/using-thrum-state/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: using-thrum-state
-description: "Use when reading or writing thrum state - checking your own agent-local current state at session start, updating your status/next-actions, reading a fleet fact like deploy state or topology before acting on it, citing a SHA or box fact in a decision, deciding whether a fleet row is fresh enough to trust, or responding to a freshness-sweep ping. Also use before writing any fleet row - deploy state, topology, worktree, agent pool, or a standing ruling - to confirm you are writing from a by-effect measurement, not a guess. Triggers on: citing a fleet fact, deploying, restarting a daemon, migrating schema, reconciling state at session start, receiving a stale-row ping."
+description: "Use when reading or writing thrum state - checking your own agent-local current state at session start, updating your status/next-actions, reading a fleet fact like deploy state or topology before acting on it, citing a SHA or box fact in a decision, deciding whether a fleet row is fresh enough to trust, or responding to a freshness-sweep ping. Also use before writing any fleet row - deploy state, topology, worktree, agent pool, or a standing ruling - to confirm you are writing from a by-effect measurement, not a guess. Triggers on - citing a fleet fact, deploying, restarting a daemon, migrating schema, reconciling state at session start, receiving a stale-row ping."
 ---
 
 # Using Thrum State

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-thrum-pro",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "description": "Thrum multi-agent coordination plugin for Open Code",
   "type": "module",
   "main": "./dist/index.js",