@loneexile/omp-superpowers 6.4.2-omp.1

package/skills/diagnosing-superpowers/templates/bundle-README.md

@@ -0,0 +1,77 @@
+# Superpowers session diagnosis bundle
+
+Session: <session-id>
+Harness: <name> <version> (<provenance label>)    Superpowers: <version> (<sha or "not a checkout">; <provenance label>)
+Redaction level: skeleton | evidence | full
+Built: <ISO timestamp>
+
+Qualify header version fields as historical evidence, unverified snapshot,
+current observation, or unknown. `environment.json` carries the same
+provenance distinctions for every environment field and its supporting
+location.
+
+## What this is
+
+A scrubbed record of a coding-agent session that had superpowers installed
+and went wrong. It lets an agent or person who was not present decide
+whether superpowers contributed and, if so, what to change. The report
+inside states what happened with `path:line` evidence. By design it
+contains no diagnosis of superpowers and no proposed fix; that is the
+reader's job.
+
+## Files
+
+- `report.md` — the diagnosis report (problem statement, verdict,
+  environment, sessions, timeline, findings, involvement, coverage notes).
+- `case.md` — the case file the analysts worked from.
+- `environment.json` — machine-readable copy of the environment section.
+- `timeline.md` — the per-turn timeline.
+- `findings/<dimension>.md` — raw analyst findings per dimension.
+- `transcripts/<session-id>.md` — condensed per-turn rendering of each
+  examined session (never the raw JSONL). Tool-result bodies by level:
+
+  | Level | Tool-result bodies |
+  |---|---|
+  | skeleton | intentionally limited; replaced by `[tool result: <tool>, <bytes> bytes, exit <code>]` |
+  | evidence | kept for cited events, including the commands and results needed to support findings |
+  | full | all kept |
+- `scrub-log.md` — every placeholder used and its category (never the
+  original value).
+
+## How to read it
+
+Start with `report.md` §1–2, then §7 (involvement) and the evidence lines
+it cites, then the matching turns in `transcripts/`. `path:line` references
+point at the original files on the reporter's machine; the same line
+numbers are preserved in the condensed transcripts as `[L<n>]` markers.
+
+## Redaction
+
+Placeholders look like `<EMAIL-1>`, `<PERSON-2>`, `<SECRET-3>`, `<HOST-4>`,
+`<REPO-5>`, `<ORG-6>`, `<PROPRIETARY-7>`; home paths are rewritten to `~/…`. The same placeholder
+always refers to the same original value within this bundle.
+
+## Producer instructions
+
+Completed bundles replace these instructions with actual results.
+
+After scrubbing, check every material exported finding using only this bundle:
+resolve its citation to an included transcript/source marker, read the cited
+command/result or quotation, and verify that it supports the claim. Path and
+line existence alone are insufficient. Record specific limitations when the
+redaction level or necessary withholding removes support.
+
+Reconcile report, case, environment, findings, README and any local issue
+draft. Refresh scrub-log counts against final files excluding the log itself.
+Remove stale export statements; distinguish bundle preparation from archive
+delivery. Retain a mapping from historical anchors to included evidence.
+
+Record the independent privacy audit separately from evidence usefulness:
+- Privacy audit: CLEAN or unresolved misses.
+- Evidence support: supported or limited, with affected findings and reasons.
+
+If content changes after checking, repeat the affected checks. Present the
+final log, file list and both outcomes for the existing archive approval.
+Archive the reviewed files and verify the delivered archive matches them.
+Record archive delivery outside the reviewed bundle rather than changing its
+contents after approval. Scrubbing is not exhaustive privacy certification.

package/skills/diagnosing-superpowers/templates/case.md

@@ -0,0 +1,64 @@
+# Case: <session-id>
+
+Workspace: ~/.superpowers/diagnosing-superpowers/<session-id>/
+Created: <ISO timestamp>
+
+## Problem statement (agreed with your human partner)
+
+<One paragraph. Names the session(s), the turn range if known, what was
+expected, what happened, and the observable that matters: wall-clock,
+tokens, repeated actions, a specific unexpected action.>
+
+Goal is a superpowers bug report: yes | no
+
+## Sessions
+
+| Role | Session id | Absolute path | Lines | Bytes | Longest line (bytes) | First prompt (first 120 chars) | First timestamp |
+|---|---|---|---|---|---|---|---|
+| main | | | | | | | |
+| subagent | | | | | | | |
+
+Rejected candidates: <id — path — why rejected>, or "none".
+
+Session still running at read time: yes | no (mtime <ISO>, lines <N>)
+
+## Environment
+
+- OS: <name and version>
+- Harness: <name> <version>
+- Models seen: <model id — where (main / subagent id)>
+- Superpowers install root: <path>; version <x.y.z>; git sha <sha or "not a checkout">
+- Skill files read or injected during the session:
+
+| Skill / source path | sha1 or unavailable | Provenance | Supporting location |
+|---|---|---|---|
+
+Label environment and skill observations as historical evidence, unverified
+snapshot, current observation, or unknown. Check supplied provenance notes,
+archives and captured skill bodies before declaring historical information
+unavailable. Missing original paths do not erase retained copies. Current
+versions/mtimes do not establish historical versions; one captured skill body
+does not authenticate an entire installation.
+
+- Other plugins / extensions / MCP servers configured: <list, or "none found">
+- Instruction files present (paths only): <list>
+
+## Context-safety rules for every reader of these files
+
+- Follow `references/context-safety.md` before reading any file listed here.
+- In a subagent transcript, "user" is the parent agent.
+
+## Discovered sources and record meanings
+
+- Sources consulted: <absolute path, tool, help, or documentation source>
+- Extraction commands or queries: <bounded commands or tool queries used for each source>
+- Target identity evidence: <session id, working directory, timestamps, matching content, and supporting record locations>
+- Associated sessions: <session id, relationship, and supporting record locations, or "none found">
+- Human messages: <record shape and evidence for its meaning>
+- Injected messages and parent dispatches: <record shape and evidence for its meaning>
+- Assistant messages: <record shape and evidence for its meaning>
+- Tool calls and results: <record shapes, how they match, and evidence for those meanings>
+- Usage counters: <fields, incremental or cumulative semantics, units, and evidence, or "unavailable">
+- Timing: <fields, units, event boundaries, and evidence, or "unavailable">
+- Other relevant records: <models, versions, compactions, or other meanings and evidence>
+- Unresolved information: <missing, inaccessible, ambiguous, or absent information, or "none">

package/skills/diagnosing-superpowers/templates/issue.md

@@ -0,0 +1,51 @@
+Title: <skill or symptom>: <one-line observable> (<harness>)
+
+- [x] I searched existing issues and this is not a duplicate (searched: <query terms>; closest: <#n title, or "none">)
+
+## Environment (required)
+
+| Field | Value | Provenance / supporting evidence |
+|-------|-------|-------------------------------|
+| Superpowers version | <version> (<sha or "not a checkout">) | <historical evidence / unverified snapshot / current observation / unknown>; <location> |
+| Harness (Claude Code, Cursor, etc.) | <harness> | <label>; <location> |
+| Harness version | <version> | <label>; <location> |
+| Your model + version | <model ids seen> | <label>; <location> |
+| All plugins installed | <list> | <label>; <location> |
+| OS + shell | <os version>, <shell> | <label>; <location> |
+
+## Is this a Superpowers issue or a platform issue?
+
+- [ ] I confirmed this issue does not occur without Superpowers installed
+
+The reporter has not tried reproducing without superpowers. Evidence for
+involvement is below; it does not establish cause.
+
+## What happened?
+
+<Problem statement, then the triage verdict, with `path:line` citations
+rewritten as `transcript line <n>`.>
+
+## Steps to reproduce
+
+1. <first human prompt, scrubbed>
+2. <the turns leading to the problem, one line each>
+3. <the observable>
+
+## Expected behavior
+
+<from the problem statement>
+
+## Actual behavior
+
+<from the triage verdict>
+
+## Debug log or conversation transcript
+
+Session id(s): <ids>. Delivered local archive: <path, redaction level <level>
+| none built>. Attached bundle: <no claim; attach only after approval>.
+Superpowers involvement per the diagnosis report: <possible | likely>, with
+evidence at <transcript lines>. This report does not propose a fix.
+
+---
+Filed with the `diagnosing-superpowers` skill. Model, harness, harness
+version, and installed plugins are listed above.

package/skills/diagnosing-superpowers/templates/report.md

@@ -0,0 +1,82 @@
+# Session diagnosis: <session-id>
+
+Report path: ~/.superpowers/diagnosing-superpowers/<session-id>/report.md
+Written: <ISO timestamp>
+
+## 1. Problem statement (REQUIRED)
+
+<Copied from the case file.>
+
+## 2. Triage verdict (REQUIRED)
+
+<What the evidence shows happened around the reported problem. Prose, with
+`path:line` after every claim. State confidence: high / medium / low, and
+what would raise it. No statement about what superpowers should do.>
+
+## 3. Environment (REQUIRED)
+
+- OS:
+- Harness and version:
+- Models seen:
+- Superpowers install root / version / git sha:
+- Skill files read or injected (sha1 table from the case file):
+- Other plugins, extensions, MCP servers:
+- Instruction files present (paths only):
+
+Label every environment field and skill observation as historical evidence,
+unverified snapshot, current observation, or unknown, and record its
+supporting evidence location.
+
+## 4. Sessions examined (REQUIRED)
+
+| Role | Session id | Absolute path | Lines | Bytes |
+|---|---|---|---|---|
+
+Rejected candidates: <id — path — why>, or "none".
+
+## 5. Timeline (REQUIRED)
+
+One row per human-typed prompt. Events column lists skills invoked,
+subagents dispatched, compaction, errors, resumes, aborts.
+
+| Turn | Line | Time | Request (one line) | Events |
+|---|---|---|---|---|
+
+## 6. Findings (REQUIRED, one subsection per dimension)
+
+Each finding:
+```
+- finding: <one sentence>
+  evidence: <path:line> — "<short quote>"
+  turns: <first>–<last>
+  confidence: high | medium | low
+```
+A dimension with nothing to report says `none found — checked: <what was checked>`.
+
+### 6.1 Skill timeline
+### 6.2 Plan adherence
+### 6.3 Repeated work
+### 6.4 Stumbles
+### 6.5 Quality evidence
+### 6.6 Request conflicts
+### 6.7 Cost and time
+### 6.8 Other plugins and skills used
+
+## 7. Superpowers involvement (REQUIRED)
+
+not indicated | possible | likely
+
+Evidence lines: <path:line list>. This section states involvement only. It
+does not name a defect and does not propose a change.
+
+## 8. Coverage notes (REQUIRED)
+
+- Not read: <ranges, files, and why>
+- Harness features unavailable: <list or none>
+- Session was in progress at read time: yes/no
+- For your human partner to double-check: <list or none>
+
+## 9. Similar sessions (only when requested)
+
+| Session id | Path | Date | Harness | Matched | Did not match |
+|---|---|---|---|---|---|

package/skills/dispatching-parallel-agents/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: dispatching-parallel-agents
+description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
+---
+
+# Dispatching Parallel Agents
+
+## Overview
+
+You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.
+
+When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.
+
+**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.
+
+## When to Use
+
+```dot
+digraph when_to_use {
+    "Multiple failures?" [shape=diamond];
+    "Are they independent?" [shape=diamond];
+    "Single agent investigates all" [shape=box];
+    "One agent per problem domain" [shape=box];
+    "Can they work in parallel?" [shape=diamond];
+    "Sequential agents" [shape=box];
+    "Parallel dispatch" [shape=box];
+
+    "Multiple failures?" -> "Are they independent?" [label="yes"];
+    "Are they independent?" -> "Single agent investigates all" [label="no - related"];
+    "Are they independent?" -> "Can they work in parallel?" [label="yes"];
+    "Can they work in parallel?" -> "Parallel dispatch" [label="yes"];
+    "Can they work in parallel?" -> "Sequential agents" [label="no - shared state"];
+}
+```
+
+**Use when:**
+- 3+ test files failing with different root causes
+- Multiple subsystems broken independently
+- Each problem can be understood without context from others
+- No shared state between investigations
+
+**Don't use when:**
+- Failures are related (fix one might fix others)
+- Need to understand full system state
+- Agents would interfere with each other
+
+## The Pattern
+
+### 1. Identify Independent Domains
+
+Group failures by what's broken:
+- File A tests: Tool approval flow
+- File B tests: Batch completion behavior
+- File C tests: Abort functionality
+
+Each domain is independent - fixing tool approval doesn't affect abort tests.
+
+### 2. Create Focused Agent Tasks
+
+Each agent gets:
+- **Specific scope:** One test file or subsystem
+- **Clear goal:** Make these tests pass
+- **Constraints:** Don't change other code
+- **Expected output:** Summary of what you found and fixed
+
+### 3. Dispatch in Parallel
+
+Issue all three subagent dispatches in the same response — they run in parallel:
+
+```text
+Subagent (general-purpose): "Fix agent-tool-abort.test.ts failures"
+Subagent (general-purpose): "Fix batch-completion-behavior.test.ts failures"
+Subagent (general-purpose): "Fix tool-approval-race-conditions.test.ts failures"
+# All three run concurrently.
+```
+
+Multiple dispatch calls in one response = parallel execution. One per response = sequential.
+
+### 4. Review and Integrate
+
+When agents return:
+- Read each summary
+- Verify fixes don't conflict
+- Run full test suite
+- Integrate all changes
+
+## Agent Prompt Structure
+
+Good agent prompts are:
+1. **Focused** - One clear problem domain
+2. **Self-contained** - All context needed to understand the problem
+3. **Specific about output** - What should the agent return?
+
+```markdown
+Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
+
+1. "should abort tool with partial output capture" - expects 'interrupted at' in message
+2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed
+3. "should properly track pendingToolCount" - expects 3 results but gets 0
+
+These are timing/race condition issues. Your task:
+
+1. Read the test file and understand what each test verifies
+2. Identify root cause - timing issues or actual bugs?
+3. Fix by:
+   - Replacing arbitrary timeouts with event-based waiting
+   - Fixing bugs in abort implementation if found
+   - Adjusting test expectations if testing changed behavior
+
+Do NOT just increase timeouts - find the real issue.
+
+Return: Summary of what you found and what you fixed.
+```
+
+## Common Mistakes
+
+**❌ Too broad:** "Fix all the tests" - agent gets lost
+**✅ Specific:** "Fix agent-tool-abort.test.ts" - focused scope
+
+**❌ No context:** "Fix the race condition" - agent doesn't know where
+**✅ Context:** Paste the error messages and test names
+
+**❌ No constraints:** Agent might refactor everything
+**✅ Constraints:** "Do NOT change production code" or "Fix tests only"
+
+**❌ Vague output:** "Fix it" - you don't know what changed
+**✅ Specific:** "Return summary of root cause and changes"
+
+## When NOT to Use
+
+**Related failures:** Fixing one might fix others - investigate together first
+**Need full context:** Understanding requires seeing entire system
+**Exploratory debugging:** You don't know what's broken yet
+**Shared state:** Agents would interfere (editing same files, using same resources)
+
+## Real Example from Session
+
+**Scenario:** 6 test failures across 3 files after major refactoring
+
+**Failures:**
+- agent-tool-abort.test.ts: 3 failures (timing issues)
+- batch-completion-behavior.test.ts: 2 failures (tools not executing)
+- tool-approval-race-conditions.test.ts: 1 failure (execution count = 0)
+
+**Decision:** Independent domains - abort logic separate from batch completion separate from race conditions
+
+**Dispatch:**
+```
+Agent 1 → Fix agent-tool-abort.test.ts
+Agent 2 → Fix batch-completion-behavior.test.ts
+Agent 3 → Fix tool-approval-race-conditions.test.ts
+```
+
+**Results:**
+- Agent 1: Replaced timeouts with event-based waiting
+- Agent 2: Fixed event structure bug (threadId in wrong place)
+- Agent 3: Added wait for async tool execution to complete
+
+**Integration:** All fixes independent, no conflicts, full suite green
+
+## Verification
+
+After agents return:
+1. **Review each summary** - Understand what changed
+2. **Check for conflicts** - Did agents edit same code?
+3. **Run full suite** - Verify all fixes work together
+4. **Spot check** - Agents can make systematic errors