test: add package.json for opencode npm plugin test

Resumed sessions already have injected context in their conversation
history. Re-firing the hook was redundant and could cause issues.
The hook now fires only on startup, clear, and compact.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "superpowers",
       "description": "Core skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques",
-      "version": "5.0.1",
+      "version": "5.0.2",
       "source": "./",
       "author": {
         "name": "Jesse Vincent",

RELEASE-NOTES.md

@@ -1,5 +1,35 @@
 # Superpowers Release Notes
 
+## v5.0.3 (2026-03-15)
+
+### Bug Fixes
+
+- **Stop firing SessionStart hook on `--resume`** — the startup hook was re-injecting context on resumed sessions, which already have the context in their conversation history. The hook now fires only on `startup`, `clear`, and `compact`.
+
+## v5.0.2 (2026-03-11)
+
+### Zero-Dependency Brainstorm Server
+
+**Removed all vendored node_modules — server.js is now fully self-contained**
+
+- Replaced Express/Chokidar/WebSocket dependencies with zero-dependency Node.js server using built-in `http`, `fs`, and `crypto` modules
+- Removed ~1,200 lines of vendored `node_modules/`, `package.json`, and `package-lock.json`
+- Custom WebSocket protocol implementation (RFC 6455 framing, ping/pong, proper close handshake)
+- Native `fs.watch()` file watching replaces Chokidar
+- Full test suite: HTTP serving, WebSocket protocol, file watching, and integration tests
+
+### Brainstorm Server Reliability
+
+- **Auto-exit after 30 minutes idle** — server shuts down when no clients are connected, preventing orphaned processes
+- **Owner process tracking** — server monitors the parent harness PID and exits when the owning session dies
+- **Liveness check** — skill verifies server is responsive before reusing an existing instance
+- **Encoding fix** — proper `<meta charset="utf-8">` on served HTML pages
+
+### Subagent Context Isolation
+
+- All delegation skills (brainstorming, dispatching-parallel-agents, requesting-code-review, subagent-driven-development, writing-plans) now include context isolation principle
+- Subagents receive only the context they need, preventing context window pollution
+
 ## v5.0.1 (2026-03-10)
 
 ### Agentskills Compliance

hooks/hooks.json

@@ -2,7 +2,7 @@
   "hooks": {
     "SessionStart": [
       {
-        "matcher": "startup|resume|clear|compact",
+        "matcher": "startup|clear|compact",
         "hooks": [
           {
             "type": "command",

package.json

@@ -0,0 +1,6 @@
+{
+  "name": "superpowers",
+  "version": "5.0.3",
+  "type": "module",
+  "main": ".opencode/plugins/superpowers.js"
+}

skills/brainstorming/SKILL.md

@@ -119,12 +119,9 @@ digraph brainstorming {
 **Spec Review Loop:**
 After writing the spec document:
 
-1. Dispatch spec-document-reviewer subagent (see spec-document-reviewer-prompt.md) with precisely crafted review context — never your session history
+1. Dispatch spec-document-reviewer subagent (see spec-document-reviewer-prompt.md)
-2. Use a fresh reviewer with clean context. Never reuse or resume a prior reviewer.
+2. If Issues Found: fix, re-dispatch, repeat until Approved
-3. If the harness supports reviewer-specific model, profile, or effort controls, use the lightest reviewer configuration that can still do the review competently
+3. If loop exceeds 5 iterations, surface to human for guidance
-4. Use long waits for reviewer verdicts. If the harness distinguishes timeout from failure, timeout means `no verdict yet`, not review failure.
-5. If `ISSUES FOUND`: fix, re-dispatch, repeat until `APPROVED`
-6. If loop exceeds 5 iterations, surface to human for guidance
 
 **User Review Gate:**
 After the spec review loop passes, ask the user to review the written spec before proceeding:

skills/brainstorming/spec-document-reviewer-prompt.md

@@ -10,8 +10,6 @@ Use this template when dispatching a spec document reviewer subagent.
 Task tool (general-purpose):
   description: "Review spec document"
   prompt: |
-    REVIEW ONLY. DO NOT EDIT FILES. DO NOT COMMIT. DO NOT IMPLEMENT FIXES.
-
     You are a spec document reviewer. Verify this spec is complete and ready for planning.
 
     **Spec to review:** [SPEC_FILE_PATH]
@@ -38,15 +36,15 @@ Task tool (general-purpose):
 
     ## Output Format
 
-    First line must be exactly: `APPROVED` or `ISSUES FOUND`
+    ## Spec Review
 
-    ## Issues (if any)
+    **Status:** ✅ Approved | ❌ Issues Found
 
+    **Issues (if any):**
     - [Section X]: [specific issue] - [why it matters]
 
-    ## Recommendations (advisory)
+    **Recommendations (advisory):**
-
     - [suggestions that don't block approval]
 ```
 
-**Reviewer returns:** Verdict, Issues (if any), Recommendations
+**Reviewer returns:** Status, Issues (if any), Recommendations

skills/requesting-code-review/SKILL.md

@@ -33,21 +33,6 @@ HEAD_SHA=$(git rev-parse HEAD)
 
 Use Task tool with superpowers:code-reviewer type, fill template at `code-reviewer.md`
 
-**Reviewer dispatch rules:**
-- Always use a fresh reviewer with clean context.
-- Never reuse or resume a previous reviewer.
-- Provide only the work product and the minimum context needed to review it.
-- Never pass your session transcript or implementation chatter.
-- Make the prompt boundary explicit: review only, no edits, no implementation, no commits.
-- Require the reviewer to start with `APPROVED` or `ISSUES FOUND`.
-
-**Reviewer runtime rules:**
-- If the harness supports reviewer-specific model, profile, or effort controls, use the lightest reviewer configuration that can still do the job well.
-- If the harness does not expose reviewer controls, use the default reviewer configuration without inventing one.
-- Use long waits for reviewer verdicts.
-- If the harness distinguishes timeout from failure, treat timeout as `no verdict yet`, not as review failure.
-- Only declare review failure on actual error, cancellation, or unusable output.
-
 **Placeholders:**
 - `{WHAT_WAS_IMPLEMENTED}` - What you just built
 - `{PLAN_OR_REQUIREMENTS}` - What it should do
@@ -111,8 +96,6 @@ You: [Fix progress indicators]
 - Ignore Critical issues
 - Proceed with unfixed Important issues
 - Argue with valid technical feedback
-- Reuse a reviewer from an earlier pass
-- Treat a short reviewer timeout as proof the review failed
 
 **If reviewer wrong:**
 - Push back with technical reasoning

skills/requesting-code-review/code-reviewer.md

@@ -1,7 +1,5 @@
 # Code Review Agent
 
-REVIEW ONLY. DO NOT EDIT FILES. DO NOT COMMIT. DO NOT IMPLEMENT FIXES.
-
 You are reviewing code changes for production readiness.
 
 **Your task:**
@@ -64,8 +62,6 @@ git diff {BASE_SHA}..{HEAD_SHA}
 
 ## Output Format
 
-First line: `APPROVED` or `ISSUES FOUND`
-
 ### Strengths
 [What's well done? Be specific.]
 

skills/subagent-driven-development/SKILL.md

@@ -99,28 +99,6 @@ Use the least powerful model that can handle each role to conserve cost and incr
 - Touches multiple files with integration concerns → standard model
 - Requires design judgment or broad codebase understanding → most capable model
 
-If the harness exposes reviewer-specific model, profile, or effort controls, use the lightest reviewer configuration that can still perform the review competently. Narrow diff checks and spec-compliance checks usually fit a fast reviewer profile. Broad architectural or final-merge reviews may justify a stronger profile. If the harness does not expose reviewer controls, use the default reviewer configuration without inventing one.
-
-## Reviewer Dispatch Rules
-
-Reviewers are a special case. They must stay isolated from implementation context.
-
-- Always launch reviewers as fresh agents with clean context.
-- Never reuse, resume, or continue a reviewer. If you need re-review after changes, launch a new reviewer.
-- Give reviewers only the artifact to review plus the minimum context needed to evaluate it.
-- Never pass your session transcript, implementation chatter, or private working notes.
-- Review prompts must make the boundary explicit: review only, no edits, no implementation, no commits.
-- Require a rigid verdict header so drift is obvious immediately. Use `APPROVED` or `ISSUES FOUND` as the first line.
-
-### Reviewer Waiting
-
-Reviewer tasks often take longer than implementation tasks because they must derive context from the work product itself.
-
-- Use long waits for reviewer verdicts when the harness supports waiting.
-- If the harness distinguishes timeout from failure, treat timeout as `no verdict yet`, not as review failure.
-- Only declare a review failed when the harness reports an actual error, cancellation, or unusable result.
-- If reviewers can complete asynchronously, keep working and collect the verdict when it arrives.
-
 ## Handling Implementer Status
 
 Implementer subagents report one of four statuses. Handle each appropriately:
@@ -171,12 +149,10 @@ Implementer: "Got it. Implementing now..."
   - Committed
 
 [Dispatch spec compliance reviewer]
-Spec reviewer: APPROVED
+Spec reviewer: ✅ Spec compliant - all requirements met, nothing extra
-  All requirements met, nothing extra.
 
 [Get git SHAs, dispatch code quality reviewer]
-Code reviewer: APPROVED
+Code reviewer: Strengths: Good test coverage, clean. Issues: None. Approved.
-  Strengths: Good test coverage, clean. Issues: None.
 
 [Mark Task 1 complete]
 
@@ -193,7 +169,7 @@ Implementer:
   - Committed
 
 [Dispatch spec compliance reviewer]
-Spec reviewer: ISSUES FOUND
+Spec reviewer: ❌ Issues:
   - Missing: Progress reporting (spec says "report every 100 items")
   - Extra: Added --json flag (not requested)
 
@@ -201,8 +177,7 @@ Spec reviewer: ISSUES FOUND
 Implementer: Removed --json flag, added progress reporting
 
 [Spec reviewer reviews again]
-Spec reviewer: APPROVED
+Spec reviewer: ✅ Spec compliant now
-  Spec compliant now.
 
 [Dispatch code quality reviewer]
 Code reviewer: Strengths: Solid. Issues (Important): Magic number (100)
@@ -211,7 +186,7 @@ Code reviewer: Strengths: Solid. Issues (Important): Magic number (100)
 Implementer: Extracted PROGRESS_INTERVAL constant
 
 [Code reviewer reviews again]
-Code reviewer: APPROVED
+Code reviewer: ✅ Approved
 
 [Mark Task 2 complete]
 
@@ -219,8 +194,7 @@ Code reviewer: APPROVED
 
 [After all tasks]
 [Dispatch final code-reviewer]
-Final reviewer: APPROVED
+Final reviewer: All requirements met, ready to merge
-  All requirements met, ready to merge.
 
 Done!
 ```
@@ -270,10 +244,8 @@ Done!
 - Accept "close enough" on spec compliance (spec reviewer found issues = not done)
 - Skip review loops (reviewer found issues = implementer fixes = review again)
 - Let implementer self-review replace actual review (both are needed)
-- **Start code quality review before spec compliance is `APPROVED`** (wrong order)
+- **Start code quality review before spec compliance is ✅** (wrong order)
 - Move to next task while either review has open issues
-- Reuse a reviewer from an earlier review pass
-- Treat a short reviewer timeout as proof the reviewer failed
 
 **If subagent asks questions:**
 - Answer clearly and completely

skills/subagent-driven-development/code-quality-reviewer-prompt.md

@@ -8,9 +8,6 @@ Use this template when dispatching a code quality reviewer subagent.
 
 ```
 Task tool (superpowers:code-reviewer):
-  Review prompt must begin with:
-    REVIEW ONLY. DO NOT EDIT FILES. DO NOT COMMIT. DO NOT IMPLEMENT FIXES.
-
   Use template at requesting-code-review/code-reviewer.md
 
   WHAT_WAS_IMPLEMENTED: [from implementer's report]
@@ -26,4 +23,4 @@ Task tool (superpowers:code-reviewer):
 - Is the implementation following the file structure from the plan?
 - Did this implementation create new files that are already large, or significantly grow existing files? (Don't flag pre-existing file sizes — focus on what this change contributed.)
 
-**Code reviewer returns:** First line `APPROVED` or `ISSUES FOUND`, then Strengths, Issues (Critical/Important/Minor), Assessment
+**Code reviewer returns:** Strengths, Issues (Critical/Important/Minor), Assessment

skills/subagent-driven-development/spec-reviewer-prompt.md

@@ -8,8 +8,6 @@ Use this template when dispatching a spec compliance reviewer subagent.
 Task tool (general-purpose):
   description: "Review spec compliance for Task N"
   prompt: |
-    REVIEW ONLY. DO NOT EDIT FILES. DO NOT COMMIT. DO NOT IMPLEMENT FIXES.
-
     You are reviewing whether an implementation matches its specification.
 
     ## What Was Requested
@@ -58,7 +56,6 @@ Task tool (general-purpose):
     **Verify by reading code, not by trusting report.**
 
     Report:
-    - First line must be exactly: `APPROVED` or `ISSUES FOUND`
+    - ✅ Spec compliant (if everything matches after code inspection)
-    - If approved, briefly state why after `APPROVED`
+    - ❌ Issues found: [list specifically what's missing or extra, with file:line references]
-    - If issues found, list specifically what's missing or extra, with file:line references
 ```

skills/writing-plans/SKILL.md

@@ -116,11 +116,11 @@ After completing each chunk of the plan:
 
 1. Dispatch plan-document-reviewer subagent (see plan-document-reviewer-prompt.md) with precisely crafted review context — never your session history. This keeps the reviewer focused on the plan, not your thought process.
    - Provide: chunk content, path to spec document
-2. If `ISSUES FOUND`:
+2. If ❌ Issues Found:
    - Fix the issues in the chunk
    - Re-dispatch reviewer for that chunk
-   - Repeat until `APPROVED`
+   - Repeat until ✅ Approved
-3. If `APPROVED`: proceed to next chunk (or execution handoff if last chunk)
+3. If ✅ Approved: proceed to next chunk (or execution handoff if last chunk)
 
 **Chunk boundaries:** Use `## Chunk N: <name>` headings to delimit chunks. Each chunk should be ≤1000 lines and logically self-contained.
 
@@ -128,9 +128,6 @@ After completing each chunk of the plan:
 - Same agent that wrote the plan fixes it (preserves context)
 - If loop exceeds 5 iterations, surface to human for guidance
 - Reviewers are advisory - explain disagreements if you believe feedback is incorrect
-- Plan reviewers follow the same isolation rules as code reviewers: fresh reviewer, clean context, no transcript history, no reuse
-- If the harness supports reviewer-specific model, profile, or effort controls, use the lightest reviewer configuration that can still review the chunk competently
-- Use long waits for reviewer verdicts; if the harness distinguishes timeout from failure, timeout means `no verdict yet`, not review failure
 
 ## Execution Handoff
 

skills/writing-plans/plan-document-reviewer-prompt.md

@@ -10,8 +10,6 @@ Use this template when dispatching a plan document reviewer subagent.
 Task tool (general-purpose):
   description: "Review plan chunk N"
   prompt: |
-    REVIEW ONLY. DO NOT EDIT FILES. DO NOT COMMIT. DO NOT IMPLEMENT FIXES.
-
     You are a plan document reviewer. Verify this plan chunk is complete and ready for implementation.
 
     **Plan chunk to review:** [PLAN_FILE_PATH] - Chunk N only
@@ -40,15 +38,15 @@ Task tool (general-purpose):
 
     ## Output Format
 
-    First line: `APPROVED` or `ISSUES FOUND`
+    ## Plan Review - Chunk N
 
-    ## Issues (if any)
+    **Status:** Approved | Issues Found
 
+    **Issues (if any):**
     - [Task X, Step Y]: [specific issue] - [why it matters]
 
-    ## Recommendations (advisory)
+    **Recommendations (advisory):**
-
     - [suggestions that don't block approval]
 ```
 
-**Reviewer returns:** Verdict, Issues (if any), Recommendations
+**Reviewer returns:** Status, Issues (if any), Recommendations