superpowers-mcp 6.3.1 → 6.3.2

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/README.ja.md CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
  [English](README.md) | [繁體中文](README.zh-TW.md) | [日本語](README.ja.md) | [한국어](README.ko.md)
4
4
 
5
- [![バージョン](https://img.shields.io/badge/version-6.3.1-blue.svg)](https://github.com/Poseidoncode/superpowers-mcp)
5
+ [![バージョン](https://img.shields.io/badge/version-6.3.2-blue.svg)](https://github.com/Poseidoncode/superpowers-mcp)
6
6
  [![License](https://img.shields.io/badge/license-MIT-green.svg)](LICENSE)
7
7
 
8
8
  このドキュメントは、オリジナルの Superpowers スキルライブラリを独立した MCP Toolpack にパッケージ化するための情報と使用手順をまとめたものです。
@@ -128,7 +128,22 @@
128
128
 
129
129
  ## 🆕 最近の更新
130
130
 
131
- ### v6.3.1(最新)
131
+ ### v6.3.2(最新)
132
+
133
+ - **writing-plans — 2 つのプラン形状(Two Plan Shapes)と骨格優先(Skeleton-First)**:
134
+ - `skills/writing-plans/SKILL.md` に **Two Plan Shapes** ルーターを追加(`task-by-task` デフォルト vs `skeleton-first` 代替案)。
135
+ - 新規 [`skills/writing-plans/skeleton-first-plans.md`](skills/writing-plans/skeleton-first-plans.md) で Walking Skeleton(Task 1 で全サブシステムを貫通する最小稼働スライスを作成)、契約型タスク(Task Contracts、コードを直接書かずに厳密な Consumes/Produces インターフェースと観察可能な検証基準を定義)、`Tier: mechanical | judgment` タグを定義。
136
+ - **subagent-driven-development (SDD) — ウェーブディスパッチ(Wave Dispatch)と並列 Worktree プロトコル**:
137
+ - skeleton-first プランに対して **DISPATCH PLAN** を生成し、ファイルの競合がないタスクをウェーブとして並列ディスパッチ。
138
+ - **並列 Worktree プロトコル(Parallel Worktree Protocol)**:独立した `.worktrees/task-<N>` で並行タスクを実行し、プラン順序で順次統合。競合時は自動 rebase と implementer 再開で修正。
139
+ - Step 5 に完了後の `Plan holds` / `Amendment:` チェック行を追加し、進行中タスクの整合性を保ちながら後続タスクに更新された契約を伝播。
140
+ - **SDD — Tier 駆動モデルディスパッチ**:
141
+ - SDD ディスパッチャーと `implementer-prompt.md` が `Tier:` 指定(`mechanical` → 経済的な軽量モデル、`judgment` → 標準モデル)を直接適用し、トークンを節約。
142
+ - **writing-skills — バイナリ実行セキュリティ強化(`render-graphs.js`)**:
143
+ - `execSync` から `execFileSync('dot', ['-Tsvg'], ...)` に移行してシェルインジェクションを根絶。10MB バッファ上限、Windows CRLF 対応(`\r?\n`)、`winget` インストール案内を追加。
144
+ - **テストと検証**:MCP プロトコル、セキュリティ、SDD Bash(11 アサーション)、PowerShell(70 アサーション)、Graphviz レンダリングテストのすべてが 100% 合格。
145
+
146
+ ### v6.3.1
132
147
 
133
148
  - **SDD ワークスペース所有権マーカーと物理パス正規化**:`sdd-workspace`(Bash)と `sdd-workspace.ps1`(PowerShell)は `plan-path` マーカーと物理パス正規化(`pwd -P` および動的 `pwd` 検出)を使用。同名のプラン(`docs/alpha/plan.md` と `docs/beta/plan.md` など)が衝突せず個別の `.superpowers/sdd/` ワークスペースに分離されます。
134
149
  - **SDD レビューパッケージ範囲ガード**:`review-package` および `review-package.ps1` は `git merge-base --is-ancestor BASE HEAD` とコミット数を検証し、空や逆転した範囲による誤判定(false-pass)を防止。
package/README.ko.md CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
  [English](README.md) | [繁體中文](README.zh-TW.md) | [日本語](README.ja.md) | [한국어](README.ko.md)
4
4
 
5
- [![Version](https://img.shields.io/badge/version-6.3.1-blue.svg)](https://github.com/Poseidoncode/superpowers-mcp)
5
+ [![Version](https://img.shields.io/badge/version-6.3.2-blue.svg)](https://github.com/Poseidoncode/superpowers-mcp)
6
6
  [![License](https://img.shields.io/badge/license-MIT-green.svg)](LICENSE)
7
7
 
8
8
  이 문서는 원본 Superpowers 스킬 라이브러리를 독립적인 MCP Toolpack으로 패키징하기 위한 정보와 사용 지침을 요약한 것입니다.
@@ -128,7 +128,22 @@
128
128
 
129
129
  ## 🆕 최근 업데이트
130
130
 
131
- ### v6.3.1 (최신)
131
+ ### v6.3.2 (최신)
132
+
133
+ - **writing-plans — 2가지 계획 형태(Two Plan Shapes)와 스켈레톤 우선(Skeleton-First)**:
134
+ - `skills/writing-plans/SKILL.md`에 **Two Plan Shapes** 라우터를 추가(`task-by-task` 기본값 vs `skeleton-first` 대안).
135
+ - 새 [`skills/writing-plans/skeleton-first-plans.md`](skills/writing-plans/skeleton-first-plans.md)에서 Walking Skeleton(Task 1에서 전체 하위 시스템을 얇게 관통하는 실행 슬라이스 구축), 계약 기반 작업(Task Contracts, 코드 스크립트 대신 엄격한 Consumes/Produces 인터페이스 및 관찰 가능한 성공 기준 명시), `Tier: mechanical | judgment` 태그 정의.
136
+ - **subagent-driven-development (SDD) — 웨이브 디스패치(Wave Dispatch) 및 병렬 Worktree 프로토콜**:
137
+ - skeleton-first 계획에 대해 **DISPATCH PLAN**을 생성하여 파일 충돌이 없는 작업을 웨이브 단위로 병렬 디스패치.
138
+ - **병렬 Worktree 프로토콜(Parallel Worktree Protocol)**: 독립된 `.worktrees/task-<N>`에서 동시 작업을 실행하고 계획 순서대로 순차 병합. 충돌 시 자동 rebase 후 implementer를 재개하여 자체 해결.
139
+ - Step 5에 완료 후 `Plan holds` / `Amendment:` 점검 라인을 추가하여 진행 중인 작업의 무결성을 유지하면서 후속 작업에 변경된 계약 전파.
140
+ - **SDD — Tier 기반 모델 디스패치**:
141
+ - SDD 디스패처 및 `implementer-prompt.md`가 `Tier:` 지정(`mechanical` → 경제적인 경량 모델, `judgment` → 표준 모델)을 즉시 적용하여 토큰 낭비 방지.
142
+ - **writing-skills — 바이너리 실행 보안 강화(`render-graphs.js`)**:
143
+ - `execSync` 대신 `execFileSync('dot', ['-Tsvg'], ...)`로 전환하여 쉘 인젝션 위험 근절. 10MB 버퍼 제한, Windows CRLF(`\r?\n`) 호환 및 `winget` 설치 안내 추가.
144
+ - **테스트 및 검증**: MCP 프로토콜, 보안, SDD Bash(11개 어서션), PowerShell(70개 어서션), Graphviz 렌더링 테스트 100% 통과.
145
+
146
+ ### v6.3.1
132
147
 
133
148
  - **SDD 워크스페이스 소유권 마커 및 물리 경로 정규화**: `sdd-workspace`(Bash) 및 `sdd-workspace.ps1`(PowerShell)은 `plan-path` 마커와 물리 경로 정규화(`pwd -P` 및 동적 `pwd` 감지)를 사용. 동일한 이름의 계획 파일(`docs/alpha/plan.md` 및 `docs/beta/plan.md` 등)이 충돌 없이 별도의 `.superpowers/sdd/` 워크스페이스로 격리됩니다.
134
149
  - **SDD 리뷰 패키지 범위 가드**: `review-package` 및 `review-package.ps1`은 `git merge-base --is-ancestor BASE HEAD`와 커밋 수를 검증하여 비어 있거나 역전된 범위로 인한 오탐(false-pass)을 방지합니다.
package/README.md CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
  [English](README.md) | [繁體中文](README.zh-TW.md) | [日本語](README.ja.md) | [한국어](README.ko.md)
4
4
 
5
- [![Version](https://img.shields.io/badge/version-6.3.1-blue.svg)](https://github.com/Poseidoncode/superpowers-mcp)
5
+ [![Version](https://img.shields.io/badge/version-6.3.2-blue.svg)](https://github.com/Poseidoncode/superpowers-mcp)
6
6
  [![License](https://img.shields.io/badge/license-MIT-green.svg)](LICENSE)
7
7
 
8
8
  This document summarizes the information and usage instructions for packaging the original Superpowers skills library into an independent MCP Toolpack.
@@ -128,7 +128,22 @@ These skills are designed for orchestrating complex meta-execution patterns with
128
128
 
129
129
  ## 🆕 Recent Updates
130
130
 
131
- ### v6.3.1 (Latest)
131
+ ### v6.3.2 (Latest)
132
+
133
+ - **writing-plans — Two Plan Shapes Router & Skeleton-First Plans**:
134
+ - `skills/writing-plans/SKILL.md` introduces the **Two Plan Shapes** router (`task-by-task` default vs `skeleton-first` alternative) to determine architecture upfront.
135
+ - New [`skills/writing-plans/skeleton-first-plans.md`](skills/writing-plans/skeleton-first-plans.md) defines the Walking Skeleton pattern (Task 1 builds the thinnest running end-to-end slice across all subsystems), Task Contracts (strict interfaces and observable behaviors without code scripts), and deliberate `Tier: mechanical | judgment` tagging.
136
+ - **subagent-driven-development (SDD) — Wave Dispatch & Parallel Worktree Protocol**:
137
+ - SDD controller performs **Dispatch Plan** scanning on skeleton-first plans, grouping mutually file-disjoint tasks into waves for concurrent dispatch.
138
+ - **Parallel Worktree Protocol**: Runs concurrent tasks in dedicated `.worktrees/task-<N>` worktrees, with sequential plan-order merges and automatic rebase-to-fix loops on merge conflict or test regression.
139
+ - Step 5 adds the post-completion `Plan holds` / `Amendment:` check line, ensuring in-flight tasks complete cleanly while downstream tasks inherit updated plan contracts.
140
+ - **SDD — Tier-Driven Model Selection**:
141
+ - SDD dispatcher and `implementer-prompt.md` respect task `Tier:` markings (`mechanical` → fastest/cheapest tier; `judgment` → standard tier), saving tokens without redundant re-adjudication.
142
+ - **writing-skills — Binary Execution Hardening (`render-graphs.js`)**:
143
+ - Replaced `execSync` shell execution with direct `execFileSync('dot', ['-Tsvg'], ...)` to eliminate shell injection risks. Added 10MB buffer limits, Windows CRLF support (`\r?\n`), and Windows `winget` installation guidance.
144
+ - **Tests & Verification**: Full regression suites pass 100% across MCP protocol, Security Edge Cases, SDD Bash (11 assertions), PowerShell (70 assertions), and Graphviz rendering.
145
+
146
+ ### v6.3.1
132
147
 
133
148
  - **SDD Ownership Markers & Path Normalization**: `sdd-workspace` (Bash) and `sdd-workspace.ps1` (PowerShell) now manage plan-scoped workspaces using `plan-path` markers with canonical physical path normalization (`pwd -P` and dynamic `pwd` detection). Same-basename plans (e.g. `docs/alpha/plan.md` vs `docs/beta/plan.md`) safely disambiguate into distinct `.superpowers/sdd/` workspaces, preventing artifact and ledger overwrites.
134
149
  - **SDD Review Package Range Mechanical Guards**: `review-package` and `review-package.ps1` now enforce `git merge-base --is-ancestor BASE HEAD` and `git rev-list --count BASE..HEAD > 0` (exiting with code 3 on error) to reject invalid or empty commit ranges and prevent false-pass review approvals.
package/README.zh-TW.md CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
  [English](README.md) | [繁體中文](README.zh-TW.md) | [日本語](README.ja.md) | [한국어](README.ko.md)
4
4
 
5
- [![版本](https://img.shields.io/badge/version-6.3.1-blue.svg)](https://github.com/Poseidoncode/superpowers-mcp)
5
+ [![版本](https://img.shields.io/badge/version-6.3.2-blue.svg)](https://github.com/Poseidoncode/superpowers-mcp)
6
6
  [![授權](https://img.shields.io/badge/license-MIT-green.svg)](LICENSE)
7
7
 
8
8
  本文檔總結了將原始 Superpowers 技能庫打包成獨立 MCP Toolpack 的相關資訊與使用說明。
@@ -128,7 +128,22 @@
128
128
 
129
129
  ## 🆕 最近更新
130
130
 
131
- ### v6.3.1 (最新版)
131
+ ### v6.3.2 (最新版)
132
+
133
+ - **writing-plans — 雙計畫形態(Two Plan Shapes)與骨架優先(Skeleton-First)**:
134
+ - `skills/writing-plans/SKILL.md` 加入 **Two Plan Shapes** 路由機制(`task-by-task` 預設模式 vs `skeleton-first` 骨架優先),在撰寫計畫前提早決定架構模型。
135
+ - 新增 [`skills/writing-plans/skeleton-first-plans.md`](skills/writing-plans/skeleton-first-plans.md) 定義 Walking Skeleton(Task 1 先完成貫穿所有子系統的真實薄切片)、契約式任務(Task Contracts,嚴格定義 Consumes/Produces 接口與可觀測驗收標準,不預寫代碼腳本)與 `Tier: mechanical | judgment` 標記。
136
+ - **subagent-driven-development (SDD) — 波次派發(Wave Dispatch)與並行工作樹協議**:
137
+ - 控制器在衝突掃描階段針對 skeleton-first 計畫生成 **DISPATCH PLAN**,將檔案互斥且無未完成介面依賴的任務組成波次並行派發。
138
+ - **並行工作樹協議(Parallel Worktree Protocol)**:並行任務各於專屬 `.worktrees/task-<N>` 執行,按計畫順序依次合併;若遇衝突或驗證失敗,自動 rebase 並喚醒 implementer 自行修復。
139
+ - Step 5 增加完工後的 `Plan holds` / `Amendment:` 檢查行,確保並行在途任務順利收斂,並將介面變動直接傳遞給後續任務。
140
+ - **SDD — Tier 驅動模型分派**:
141
+ - SDD 控制器與 `implementer-prompt.md` 嚴格遵循計畫中的 `Tier:` 標記(`mechanical` → 快速經濟型模型;`judgment` → 標準中階模型),大幅節省 token 且不再重複審議。
142
+ - **writing-skills — 二進位安全加固(`render-graphs.js`)**:
143
+ - 改用 `execFileSync('dot', ['-Tsvg'], ...)` 徹底杜絕 shell 注入,設置 10MB 緩衝上限,支援 Windows CRLF(`\r?\n`)換行匹配與 `winget` 安裝提示。
144
+ - **測試與驗證**:MCP 協定、邊界安全、SDD Bash(11 項斷言)、PowerShell(70 項斷言)及 Graphviz 渲染測試全數 100% 通過。
145
+
146
+ ### v6.3.1
132
147
 
133
148
  - **SDD 工作區歸屬標記與實體路徑正規化**:`sdd-workspace`(Bash)與 `sdd-workspace.ps1`(PowerShell)改用 `plan-path` 歸屬標記與標準化實體路徑(`pwd -P` 與動態 `pwd` 偵測)。同名 plan(如 `docs/alpha/plan.md` 與 `docs/beta/plan.md`)會自動解析為獨立的 `.superpowers/sdd/` 工作區,杜絕產物與進度覆蓋。
134
149
  - **SDD 審查包範圍機械守衛**:`review-package` 與 `review-package.ps1` 強制校驗 `git merge-base --is-ancestor BASE HEAD` 與 commit 數量大於 0(錯誤時 exit 3),防止空範圍或倒置範圍造成審查假綠燈。
package/out/server.js CHANGED
@@ -49,7 +49,7 @@ Set the \`cycles\` parameter to \`"ref"\` to resolve cyclical schemas with defs.
49
49
  `}var vs=class{constructor(t=hf.default.stdin,r=hf.default.stdout){this._stdin=t,this._stdout=r,this._readBuffer=new gs,this._started=!1,this._ondata=n=>{this._readBuffer.append(n),this.processReadBuffer()},this._onerror=n=>{this.onerror?.(n)}}async start(){if(this._started)throw new Error("StdioServerTransport already started! If using Server class, note that connect() calls start() automatically.");this._started=!0,this._stdin.on("data",this._ondata),this._stdin.on("error",this._onerror)}processReadBuffer(){for(;;)try{let t=this._readBuffer.readMessage();if(t===null)break;this.onmessage?.(t)}catch(t){this.onerror?.(t)}}async close(){this._stdin.off("data",this._ondata),this._stdin.off("error",this._onerror),this._stdin.listenerCount("data")===0&&this._stdin.pause(),this._readBuffer.clear(),this.onclose?.()}send(t){return new Promise(r=>{let n=j_(t);this._stdout.write(n)?r():this._stdout.once("drain",r)})}};var ze=sr(require("fs/promises")),ye=sr(require("path")),$n=10*1024*1024,ys=class{skillsPath;cachedSkills=null;loadingPromise=null;skillMap=new Map;contentCache=new Map;constructor(t){this.skillsPath=t}stripQuotes(t){return t.replace(/^"(.*)"$|^'(.*)'$/,"$1$2").trim()}parseFrontmatter(t){let r=t;if(r.charCodeAt(0)===65279&&(r=r.slice(1)),!r.startsWith("---"))return{name:"",description:""};let n=r.split(/\r?\n/),o=[],i=!1;for(let u=1;u<n.length;u++){if(n[u].trim()==="---"){i=!0;break}o.push(n[u])}if(!i)return{name:"",description:""};let a="",s="",c=!1;for(let u of o){let l=u.match(/^name:\s*(.*?)\s*$/);if(l){a=this.stripQuotes(l[1]),c=!1;continue}let d=u.match(/^description:\s*(.*?)\s*$/);if(d){s=this.stripQuotes(d[1]),c=!0;continue}c&&/^\s+/.test(u)?s+=" "+u.trim():c=!1}return{name:a,description:s}}async exists(t){try{return await ze.access(t),!0}catch{return!1}}async listSkills(t=!1){if(this.cachedSkills&&!t)return this.cachedSkills;if(this.loadingPromise&&!t)return this.loadingPromise;t&&this.contentCache.clear();let r=this.internalListSkills();this.loadingPromise=r;try{return await r}finally{this.loadingPromise===r&&(this.loadingPromise=null)}}async internalListSkills(){if(!await this.exists(this.skillsPath))return this.cachedSkills??[];let t=[],r=new Map,n=!1;try{let o=await ze.readdir(this.skillsPath,{withFileTypes:!0});for(let i of o){if(!i.isDirectory()&&!i.isSymbolicLink())continue;let a=ye.join(this.skillsPath,i.name),s=ye.join(a,"SKILL.md");if(await this.exists(s))try{let c=await this.readFileNoFollow(s,this.skillsPath),{name:u,description:l}=this.parseFrontmatter(c),m={name:u||i.name,description:l,skillPath:s};t.push(m),r.set(m.name.toLowerCase(),m);let p=ye.basename(ye.dirname(m.skillPath)).toLowerCase();r.set(p,m)}catch{process.stderr.write(`Warning: Failed to read skill file in directory "${i.name}"
50
50
  `)}}n=!0}catch(o){process.stderr.write(`Error reading skills directory: ${String(o)}
51
51
  `)}return n&&(this.skillMap=r,this.cachedSkills=t.sort((o,i)=>o.name.localeCompare(i.name))),this.cachedSkills??[]}async findSkill(t){let r=typeof t=="string"?t.trim():"";if(!(!r||r==="."||r===".."||r.includes("/")||r.includes("\\")||r.includes("\0")))return this.cachedSkills||await this.listSkills(),this.skillMap.get(r.toLowerCase())}async readFileNoFollow(t,r){let n=ye.resolve(t),o=ye.resolve(r),i=async()=>{let l=await ze.realpath(n),d=await ze.realpath(o);if(!(await ze.stat(d)).isDirectory())throw new Error("Skills directory must be a directory");let p=ye.relative(d,l);if(p===".."||p.startsWith(`..${ye.sep}`)||ye.isAbsolute(p))throw new Error("File is outside skills directory");let h=await ze.stat(l);if(!h.isFile()||h.nlink!==1)throw new Error("Skill path is not a regular file");if(h.size>$n)throw new Error("Skill file exceeds size limit");return{realFilePath:l,stat:h}},a=await i(),s=await i();if(a.realFilePath!==s.realFilePath||a.stat.dev!==s.stat.dev||a.stat.ino!==s.stat.ino)throw new Error("File changed while validating its path");let c=process.platform==="win32"?0:ze.constants.O_NOFOLLOW,u=await ze.open(s.realFilePath,ze.constants.O_RDONLY|c);try{let l=await u.stat();if(!l.isFile()||l.nlink!==1||l.dev!==s.stat.dev||l.ino!==s.stat.ino||l.size>$n)throw new Error("File changed while opening");let d=[],m=64*1024,p=0;for(;p<=$n;){let v=Buffer.allocUnsafe(Math.min(m,$n+1-p)),{bytesRead:$}=await u.read(v,0,v.length,null);if($===0)break;if(p+=$,d.push(v.subarray(0,$)),p>$n)throw new Error("Skill file exceeds size limit")}let h=await u.stat();if(h.size>$n||h.dev!==s.stat.dev||h.ino!==s.stat.ino)throw new Error("File changed while reading");return Buffer.concat(d,p).toString("utf-8")}finally{await u.close()}}async readSkillContent(t,r=!1){let n=ye.resolve(t),o=ye.resolve(this.skillsPath),i=n,a=o;try{i=await ze.realpath(n),a=await ze.realpath(o)}catch{}let s=ye.relative(a,i);if(s.startsWith("..")||ye.isAbsolute(s))throw new Error(`Access denied: path "${t}" is outside skills directory`);if(this.contentCache.has(i)&&!r)return this.contentCache.get(i);try{let c=await this.readFileNoFollow(t,this.skillsPath);c.charCodeAt(0)===65279&&(c=c.slice(1));let u=c.replace(/^---\s*\r?\n[\s\S]*?\r?\n---\s*\r?\n?/,"").trim();return this.contentCache.set(i,u),u}catch(c){throw new Error(`Failed to read skill content: ${c instanceof Error?c.message:String(c)}`)}}clearCache(){this.cachedSkills=null,this.loadingPromise=null,this.skillMap.clear(),this.contentCache.clear()}};function jT(){let e=process.env.SKILLS_PATH;if(e){let r=ct.resolve(e),n=ct.normalize(r).toLowerCase(),o=ct.parse(r).root.toLowerCase();if(n===o||["/etc","/var","/bin","/sbin","/usr","/root","/sys","/proc","/dev","c:\\windows","c:\\program files","c:\\program files (x86)"].some(s=>n===s||n.startsWith(s+ct.sep)))process.stderr.write(`Warning: Potentially unsafe SKILLS_PATH: "${e}". Fallback to default.
52
- `);else return r}let t=ct.join(__dirname,"..","skills");return E_.existsSync(t)?t:ct.join(__dirname,"skills")}var O_=jT(),It=new ys(O_),Pr=new hs({name:"superpowers-mcp",version:"6.3.1"},{capabilities:{resources:{subscribe:!1},prompts:{},tools:{}}});Pr.setRequestHandler(od,async()=>({resources:(await It.listSkills()).map(t=>({uri:`skill://superpowers/${encodeURIComponent(t.name)}`,name:t.name,description:t.description,mimeType:"text/markdown"}))}));Pr.setRequestHandler(ad,async e=>{let t=e.params.uri,r=t.match(/^skill:\/\/superpowers\/(.+)$/);if(!r)throw new D(M.InvalidRequest,`Invalid skill URI: ${t}`);let n;try{n=decodeURIComponent(r[1])}catch{throw new D(M.InvalidRequest,`Invalid skill URI: ${t}`)}let o=await It.findSkill(n);if(!o)throw new D(M.InvalidRequest,`Skill not found: ${n}`);try{let i=await It.readSkillContent(o.skillPath);return{contents:[{uri:t,mimeType:"text/markdown",text:i}]}}catch{throw new D(M.InternalError,"Failed to read skill content safely.")}});Pr.setRequestHandler(sd,async()=>({prompts:[{name:"session-start",description:"Inject the Superpowers context into an AI agent session. Tells the agent it has superpowers and how to use the skill system."}]}));Pr.setRequestHandler(cd,async e=>{if(e.params.name!=="session-start")throw new D(M.InvalidRequest,`Unknown prompt: ${e.params.name}`);let t=await It.findSkill("using-superpowers"),r="";if(t)try{r=await It.readSkillContent(t.skillPath)}catch{r=`# Superpowers
52
+ `);else return r}let t=ct.join(__dirname,"..","skills");return E_.existsSync(t)?t:ct.join(__dirname,"skills")}var O_=jT(),It=new ys(O_),Pr=new hs({name:"superpowers-mcp",version:"6.3.2"},{capabilities:{resources:{subscribe:!1},prompts:{},tools:{}}});Pr.setRequestHandler(od,async()=>({resources:(await It.listSkills()).map(t=>({uri:`skill://superpowers/${encodeURIComponent(t.name)}`,name:t.name,description:t.description,mimeType:"text/markdown"}))}));Pr.setRequestHandler(ad,async e=>{let t=e.params.uri,r=t.match(/^skill:\/\/superpowers\/(.+)$/);if(!r)throw new D(M.InvalidRequest,`Invalid skill URI: ${t}`);let n;try{n=decodeURIComponent(r[1])}catch{throw new D(M.InvalidRequest,`Invalid skill URI: ${t}`)}let o=await It.findSkill(n);if(!o)throw new D(M.InvalidRequest,`Skill not found: ${n}`);try{let i=await It.readSkillContent(o.skillPath);return{contents:[{uri:t,mimeType:"text/markdown",text:i}]}}catch{throw new D(M.InternalError,"Failed to read skill content safely.")}});Pr.setRequestHandler(sd,async()=>({prompts:[{name:"session-start",description:"Inject the Superpowers context into an AI agent session. Tells the agent it has superpowers and how to use the skill system."}]}));Pr.setRequestHandler(cd,async e=>{if(e.params.name!=="session-start")throw new D(M.InvalidRequest,`Unknown prompt: ${e.params.name}`);let t=await It.findSkill("using-superpowers"),r="";if(t)try{r=await It.readSkillContent(t.skillPath)}catch{r=`# Superpowers
53
53
 
54
54
  You have superpowers. Use the read_skill and list_skills tools to discover and load skills.`}else{let o=ct.join(O_,"using-superpowers","SKILL.md");try{r=await It.readSkillContent(o)}catch{r=`# Superpowers
55
55
 
package/package.json CHANGED
@@ -2,7 +2,7 @@
2
2
  "name": "superpowers-mcp",
3
3
  "displayName": "Superpowers MCP",
4
4
  "description": "Superpowers skills library (TDD, debugging, collaboration workflows) as an MCP server for VSCode and Antigravity",
5
- "version": "6.3.1",
5
+ "version": "6.3.2",
6
6
  "publisher": "superpowers",
7
7
  "license": "MIT",
8
8
  "repository": {
@@ -173,6 +173,14 @@ its own text agrees with itself — the tests it specifies against the code it
173
173
  specifies, the files it creates against the files it later touches. "The scan
174
174
  is clean" without those rows is not a scan you ran.
175
175
 
176
+ **When the plan's header declares `Plan shape: skeleton-first`,** the
177
+ table gets a final section: the DISPATCH PLAN — group the pending tasks
178
+ into waves. Tasks in the same wave are mutually file-disjoint and consume
179
+ no interface still under construction — dispatch each wave's implementers
180
+ concurrently, one worktree per task, and integrate before the next wave;
181
+ tasks that fail those conditions serialize. On a skeleton-first plan, a
182
+ scan without a dispatch plan is not a scan you ran.
183
+
176
184
  Write the table to the ledger. Rule on everything you find before execution
177
185
  begins — each finding against the plan text that mandates it — and record
178
186
  each ruling in the ledger. If the scan is clean, proceed without comment.
@@ -187,6 +195,10 @@ Use the least powerful model that can handle each role to conserve cost and incr
187
195
 
188
196
  **Mechanical implementation tasks** (isolated functions, clear specs, 1-2 files): use a fast, cheap model. Most implementation tasks are mechanical when the plan is well-specified.
189
197
 
198
+ When a task carries a **Tier:** field, follow it — the planner already
199
+ ruled: mechanical → the cheapest available model; judgment → a standard
200
+ model. Do not re-litigate the tier at dispatch.
201
+
190
202
  **Integration and judgment tasks** (multi-file coordination, pattern matching, debugging): use a standard model.
191
203
 
192
204
  **Architecture and design tasks**: use the most capable available model.
@@ -208,7 +220,10 @@ most expensive — which silently defeats this section.
208
220
  **Turn count beats token price.** Wall-clock and context cost scale with how
209
221
  many turns a subagent takes, and the cheapest models routinely take 2-3× the
210
222
  turns on multi-step work — costing more overall. Use a mid-tier model as the
211
- floor for reviewers and for implementers working from prose descriptions.
223
+ floor for reviewers and for implementers working from task contracts or
224
+ prose descriptions — unless the task's Tier line says mechanical: the
225
+ planner has already ruled the deliverable fully specified, so treat a
226
+ mechanical-tier contract like spelled-out content.
212
227
  When the task's plan text contains the complete code to write, the
213
228
  implementation is transcription plus testing: use the cheapest tier for
214
229
  that implementer. Single-file mechanical fixes also take the cheapest tier.
@@ -260,7 +275,13 @@ and fix-round diffs need it.
260
275
  know; (4) your resolution of any ambiguity you noticed in the brief;
261
276
  (5) the report-file path and report contract. Exact values (numbers,
262
277
  magic strings, signatures, test cases) appear only in the brief. Never
263
- make a subagent read the whole plan file.
278
+ make a subagent read the whole plan file. When the brief is a contract
279
+ (goal, success criteria, interfaces) rather than written-out code, item
280
+ (3) also carries the elaboration the contract leaves to dispatch time:
281
+ the interfaces as actually built by completed tasks, environment facts
282
+ and discoveries from earlier reports, and any amendment rulings. There
283
+ the success criteria name the cases the tests must cover, and the
284
+ implementer designs its own code and tests within the contract.
264
285
  - **Report file:** name the implementer's report file after the brief
265
286
  (brief `…/task-N-brief.md` → report `…/task-N-report.md`) and put it in
266
287
  the dispatch prompt. The implementer writes the full report there and
@@ -281,6 +302,26 @@ and fix-round diffs need it.
281
302
  - Record the implementer's agent identity from the dispatch result —
282
303
  fix-loop rounds 1-3 resume this agent.
283
304
  - Never dispatch multiple implementation subagents in parallel (conflicts).
305
+ The one exception is a skeleton-first plan whose dispatch plan shows two
306
+ or more pending tasks mutually file-disjoint with none consuming an
307
+ interface still under construction. Dispatch those implementers
308
+ concurrently, each in its own worktree:
309
+ - Record the integration base commit in the ledger before the first
310
+ concurrent dispatch.
311
+ - Create one worktree per concurrent task off that base
312
+ (`git worktree add <repo-root>/.worktrees/task-<N> -b task-<N>
313
+ <base>`); each dispatch's `Work from:` is its own worktree, and its
314
+ BASE is that worktree's HEAD.
315
+ - Review each task's diff as usual when it reports. Integrate reviewed
316
+ branches in plan order: merge each into the integration branch
317
+ (`git merge --no-ff task-<N>`), and run that task's verification
318
+ commands after each merge.
319
+ - A merge conflict or post-merge verification failure is that task's
320
+ fix-loop round 1: rebase the task branch onto the current
321
+ integration head in its worktree, then resume its implementer
322
+ there. Never resolve conflicts yourself.
323
+ - Remove each worktree (`git worktree remove`) once its branch is
324
+ integrated, and record the integrated range in the ledger as usual.
284
325
 
285
326
  Template: [implementer-prompt.md](implementer-prompt.md)
286
327
 
@@ -442,6 +483,19 @@ message as your other bookkeeping:
442
483
  - `Task <N>: complete (commits <base7>..<head7>, <K> parked)` after a
443
484
  tripped breaker
444
485
 
486
+ **On a skeleton-first plan,** write one plan-check line with the
487
+ completion line. Re-read the remaining tasks against what this task
488
+ actually established — interfaces as built, environment facts,
489
+ discoveries in the report — and append either `Plan holds` or
490
+ `Amendment: Task <M>: <what changes and why>` to the ledger. An
491
+ amendment is plan authority applied at the plan layer: from then on the
492
+ amended text IS the plan's text, and it rides into every affected task's
493
+ dispatch under item (3). In-flight tasks in the same concurrent wave are
494
+ not aborted mid-flight; any interface divergences are surfaced and
495
+ resolved through the standard integration merge, rebase, and fix-loop
496
+ protocol. Never dispatch a task whose brief a completed task's report has
497
+ already invalidated.
498
+
445
499
  Then mark the todo complete and move on. Never move to the next task while
446
500
  the review has open Critical/Important issues that are neither fixed nor
447
501
  parked-with-ruling at the cap.
@@ -5,8 +5,11 @@ Use this template when dispatching an implementer subagent.
5
5
  ```
6
6
  Subagent (general-purpose):
7
7
  description: "Implement Task N: [task name]"
8
- model: [MODEL — REQUIRED: choose per SKILL.md Model Selection; an omitted
9
- model silently inherits the session's most expensive one]
8
+ model: [MODEL — REQUIRED: when the brief carries a Tier line, set from it:
9
+ mechanical → the cheapest model the subagent tool offers; judgment →
10
+ a standard mid-tier model. Otherwise choose per SKILL.md Model
11
+ Selection. An omitted model silently inherits the session's most
12
+ expensive one]
10
13
  prompt: |
11
14
  You are implementing Task N: [task name]
12
15
 
@@ -22,6 +22,30 @@ Assume they are a skilled developer, but know almost nothing about our toolset o
22
22
 
23
23
  If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.
24
24
 
25
+ ## Two Plan Shapes
26
+
27
+ Before mapping files, classify the plan's shape and say the
28
+ classification out loud — "this composes three subsystems, so I'll plan
29
+ it skeleton-first" — so your human partner can override it:
30
+
31
+ - **Task-by-task (default)** — tasks build the feature a component at a
32
+ time, each step carrying the actual content the engineer needs. Use it
33
+ for changes to code that already exists, for a spec that touches one
34
+ subsystem, and whenever the alternative's conditions do not clearly
35
+ hold. The rest of this skill describes this shape.
36
+ - **Skeleton-first (alternative)** — Task 1 is the thinnest end-to-end
37
+ slice through every subsystem the spec composes; later tasks widen it
38
+ one component at a time, each from a contract rather than written-out
39
+ code. Use it when the spec composes more than one subsystem AND a
40
+ running end-to-end slice early is worth a longer total build. Read
41
+ [skeleton-first-plans.md](skeleton-first-plans.md) before writing one
42
+ — it adds one line to the plan header and replaces this skill's task
43
+ granularity, task template, and plan-failure list.
44
+
45
+ When in doubt, plan task-by-task. Skeleton-first buys an earlier running
46
+ system and pays for it in total wall clock; it is a trade, not an
47
+ upgrade.
48
+
25
49
  ## File Structure
26
50
 
27
51
  Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.
@@ -0,0 +1,131 @@
1
+ # Skeleton-First Plans
2
+
3
+ The alternative plan shape from writing-plans' Two Plan Shapes router.
4
+ Each section below replaces the same-named section of
5
+ [SKILL.md](SKILL.md); everything SKILL.md says that is not named here
6
+ still binds — Scope Check, File Structure, Task Right-Sizing, the plan
7
+ header, Self-Review, and the Execution Handoff.
8
+
9
+ ## Overview
10
+
11
+ Write a plan that carries the decisions, not the keystrokes:
12
+ decomposition, file structure, interfaces, constraints, and a precise
13
+ contract per task. Assume the engineer is skilled and designs their own
14
+ code and tests from a precise contract, but knows nothing about our
15
+ codebase, toolset, or problem domain — every name, path, constraint, and
16
+ behavior they must match is stated explicitly. DRY. YAGNI. TDD.
17
+ Frequent commits.
18
+
19
+ ## When This Shape Fits
20
+
21
+ Use it when the spec composes more than one subsystem and a running
22
+ end-to-end slice early is worth a longer total build: the value arrives
23
+ as soon as real input reaches real output, and every later task widens
24
+ something that already runs.
25
+
26
+ Do not use it for a change to one subsystem, or when the whole point is
27
+ to land the finished thing as fast as possible. This shape spends its
28
+ first task on a slice that does almost nothing, and it spends planning
29
+ effort on contracts and interfaces the task-by-task shape gets for free
30
+ by writing the code out.
31
+
32
+ ## Plan Document Header
33
+
34
+ The header is SKILL.md's, plus one line directly under the **Goal:**
35
+ line, which is how executors know which shape they are running:
36
+
37
+ ```markdown
38
+ **Plan shape:** skeleton-first
39
+ ```
40
+
41
+ ## Walking Skeleton First
42
+
43
+ Task 1 builds the thinnest end-to-end slice through every subsystem the
44
+ spec composes — real input to real output — before any task deepens a
45
+ single layer; later tasks widen the skeleton.
46
+
47
+ The test of a skeleton is that it runs. A first task that builds the
48
+ data loader, the schema, or the config layer is a foundation, not a
49
+ skeleton: nothing runs until something above it exists. A skeleton
50
+ reaches the output — thinly, with one real case — through every
51
+ subsystem the spec names.
52
+
53
+ ## Task Contracts, Not Task Scripts
54
+
55
+ A task states WHAT must exist when it is done, precisely enough that a
56
+ skilled engineer can build it without asking you anything, without
57
+ prescribing HOW:
58
+
59
+ - **Goal:** one short paragraph naming the deliverable and its role in
60
+ the feature.
61
+ - **Success criteria:** concrete, checkable behaviors — exact commands
62
+ to run and what they must show, the cases tests must cover (including
63
+ failure cases), constraints that bind the implementation.
64
+ - **Notes:** what the engineer needs and cannot discover alone — spec
65
+ sections to read, files worth reading first, known pitfalls.
66
+
67
+ The Interfaces block carries the exact names, signatures, and types;
68
+ the success criteria carry the behaviors; the engineer supplies the
69
+ code and the test design. TDD and frequent commits remain required.
70
+
71
+ ## Task Structure
72
+
73
+ ````markdown
74
+ ### Task N: [Component Name]
75
+
76
+ **Files:**
77
+ - Create: `exact/path/to/file.py`
78
+ - Modify: `exact/path/to/existing.py:123-145`
79
+ - Test: `tests/exact/path/to/test.py`
80
+
81
+ **Interfaces:**
82
+ - Consumes: [what this task uses from earlier tasks — exact signatures]
83
+ - Produces: [what later tasks rely on — exact function names, parameter
84
+ and return types. A task's implementer sees only their own task; this
85
+ block is how they learn the names and types neighboring tasks use.]
86
+
87
+ **Goal:** [one paragraph — the deliverable and its role in the feature]
88
+
89
+ **Success criteria:**
90
+ - Run: `pytest tests/exact/path/to/test.py -v` — all tests pass; tests
91
+ cover [the specific behaviors and failure cases, named concretely]
92
+ - [observable behavior the deliverable must exhibit, with the exact
93
+ command or input/output that demonstrates it]
94
+ - [constraint that binds the implementation, copied from the spec]
95
+
96
+ **Notes:** [spec sections to read; files to read first; known pitfalls]
97
+
98
+ **Tier:** mechanical | judgment. Mechanical = the deliverable is fully
99
+ specified by Files + Interfaces + success criteria above (most tasks in
100
+ a well-specified plan are mechanical); judgment = multi-file
101
+ coordination, debugging, or real design latitude remains. The
102
+ implementer's model follows this field — mark it deliberately.
103
+
104
+ **Commit:** one commit ending the task; message named here.
105
+ ````
106
+
107
+ ## No Vague Contracts
108
+
109
+ Every contract must be checkable by someone who did not write it. These
110
+ are **plan failures** — never write them:
111
+ - "TBD", "TODO", "implement later", "fill in details"
112
+ - Goals naming activity instead of a deliverable ("improve error handling")
113
+ - Success criteria with no observable check ("works correctly", "handles edge cases")
114
+ - Interfaces blocks omitting a name, signature, or type another task consumes
115
+ - "Similar to Task N" (state this task's own contract in full — the engineer may be reading tasks out of order)
116
+ - References to types, functions, or methods not defined in any task's Interfaces block
117
+
118
+ ## Self-Review
119
+
120
+ Run SKILL.md's Self-Review checklist, reading step 2 against "No Vague
121
+ Contracts" above rather than "No Placeholders".
122
+
123
+ ## Red Flags
124
+
125
+ | Thought | Reality |
126
+ |---------|---------|
127
+ | "Task 1 is the data loader — that's the foundation" | A foundation is a layer. The skeleton runs real input to real output through every subsystem the spec names, thinly. |
128
+ | "The skeleton can return a hardcoded value for now" | It may be thin, but the path must be real: real input, real wiring, real output. A hardcoded response tests nothing end to end. |
129
+ | "A contract without the code is vague" | Vague is an uncheckable success criterion. Exact names, exact commands, exact expected output — no code. |
130
+ | "I'll write the test code into the task to be safe" | The success criteria name the cases; the implementer designs the tests. Written-out tests are the task-by-task shape. |
131
+ | "Skeleton-first is the better shape, so I'll use it here" | It costs total wall clock. Without more than one subsystem and a reason to want an early running slice, plan task-by-task. |
@@ -15,11 +15,11 @@
15
15
 
16
16
  const fs = require('fs');
17
17
  const path = require('path');
18
- const { execSync } = require('child_process');
18
+ const { execFileSync } = require('child_process');
19
19
 
20
20
  function extractDotBlocks(markdown) {
21
21
  const blocks = [];
22
- const regex = /```dot\n([\s\S]*?)```/g;
22
+ const regex = /```dot\r?\n([\s\S]*?)```/g;
23
23
  let match;
24
24
 
25
25
  while ((match = regex.exec(markdown)) !== null) {
@@ -69,7 +69,7 @@ ${bodies.join('\n\n')}
69
69
 
70
70
  function renderToSvg(dotContent) {
71
71
  try {
72
- return execSync('dot -Tsvg', {
72
+ return execFileSync('dot', ['-Tsvg'], {
73
73
  input: dotContent,
74
74
  encoding: 'utf-8',
75
75
  maxBuffer: 10 * 1024 * 1024
@@ -110,11 +110,12 @@ function main() {
110
110
  // Check if dot is available. Run the binary directly rather than probing
111
111
  // with `which`, which is not a command on Windows.
112
112
  try {
113
- execSync('dot -V', { stdio: 'ignore', encoding: 'utf-8' });
113
+ execFileSync('dot', ['-V'], { stdio: 'ignore' });
114
114
  } catch {
115
115
  console.error('Error: graphviz (dot) not found. Install with:');
116
- console.error(' brew install graphviz # macOS');
117
- console.error(' apt install graphviz # Linux');
116
+ console.error(' brew install graphviz # macOS');
117
+ console.error(' apt install graphviz # Linux');
118
+ console.error(' winget install Graphviz.Graphviz # Windows');
118
119
  process.exit(1);
119
120
  }
120
121