@mstar-harness/opencode 0.7.3 → 0.7.4

package/INSTALL.md

@@ -6,14 +6,11 @@
 
 ## Installation
 
-Add Morning Star to the `plugin` array in your `opencode.json` (global or project-level).
-
-If you use Superpowers together, use:
+Add Morning Star to the `plugin` array in your `opencode.json` (global or project-level):
 
 ```json
 {
   "plugin": [
-    "superpowers@git+https://github.com/obra/superpowers.git",
     "@mstar-harness/opencode@latest"
   ]
 }
@@ -64,7 +61,7 @@ The `@mstar-harness/cli` package (`npx @mstar-harness/cli init`) migrates that e
 
 ### Plugin not loading
 
-1. Check logs: `opencode run --print-logs "hello" 2>&1 | grep -i superpowers`
+1. Check logs: `opencode run --print-logs "hello" 2>&1 | grep -i mstar`
 2. Verify the plugin line in your `opencode.json`
 3. Make sure you're running a recent version of OpenCode
 

package/harness-skills/mstar-branch-worktree/SKILL.md

@@ -105,16 +105,16 @@ description: Morning Star business-repo Git feature branches, same-repo concurre
 
 当 **`@project-manager` 在同一调度轮次内并发启动多个** subagent（含宿主侧「并行 Task / 并行 subagent」），且 **≥2 个承接方**可能对 **同一 Git 仓库的同一工作区（同一 cwd 检出目录）**产生写文件或 `git commit` 级改动时：
 
-- **必须**为每条并发写流使用 **独立检出目录**：以 **`git worktree`** 隔离（流程与目录安全要求见 Superpowers **`using-git-worktrees`**；未安装插件时仍须达到同等隔离效果，可 Read 该技能文件并按 `git worktree` 手册执行）。
+- **必须**为每条并发写流使用 **独立检出目录**：优先使用宿主原生 worktree/checkout 隔离能力；没有原生能力时使用 `git worktree`，并按本 skill 的目录、分支和 QC/QA 对齐规则执行。
 - **必须**与既有分支门禁一致：每个可写承接方的 Assignment 仍须含 PM 已批准的 **`Working branch`** / **`Branch policy`**；在某一 worktree 内 **不得**擅自 `checkout` 到未授权分支或私自新建分支。
-- **PM 须在 Assignment 中写清**各并发写流的 **检出约定**（例如预期 **`Worktree path`** / 命名规则，或「由承接方按 `using-git-worktrees` 创建并在 Completion Report 回报路径」），避免多代理默认共享同一目录导致互相覆盖、冲突或半写入状态。
+- **PM 须在 Assignment 中写清**各并发写流的 **检出约定**（例如预期 **`Worktree path`** / 命名规则，或「由承接方创建/使用隔离 worktree 并在 Completion Report 回报路径」），避免多代理默认共享同一目录导致互相覆盖、冲突或半写入状态。
 - **同仓、同一 plan、≥2 可写并行轨**：**推荐**在首次向各轨下发实现 Assignment **之前**，先由 PM 与用户确认 **`Branch policy`**，并 **明确 plan 集成分支与各轨 topic 分支的关系**（见下节 **「推荐默认编排：先建 plan 集成分支，再挂各 worktree」**），再为各轨约定 **`git worktree`**。这样 QC 前可把各轨 **自然归并**到同一条 **`HEAD`**，减少「多头分支、无合并靶」导致的误派。
 
 **可不强制新开 worktree** 的情形包括：并发流 **全部为只读**；各写入者针对 **不同 Git 仓库根**；或写入 **串行**（同一时刻仅一个代理持有该仓工作区）。
 
 ### 并发 subagent 与同仓工作树（对齐）
 
-当多个可写 subagent **并发**修改 **同一仓库** 时，**不得**共用同一检出目录作为写入 cwd。PM 在分派前应规划 **`git worktree`** 隔离（Superpowers **`using-git-worktrees`**），并在各承接方 Assignment 中写明 **`Working branch`** / **`Branch policy`** 及 **检出路径约定**（或要求回报实际 worktree 路径）。单分支决策权仍仅属 PM；worktree 只解决「目录与工作区隔离」，不替代分支授权。
+当多个可写 subagent **并发**修改 **同一仓库** 时，**不得**共用同一检出目录作为写入 cwd。PM 在分派前应规划 worktree/checkout 隔离，并在各承接方 Assignment 中写明 **`Working branch`** / **`Branch policy`** 及 **检出路径约定**（或要求回报实际 worktree 路径）。单分支决策权仍仅属 PM；worktree 只解决「目录与工作区隔离」，不替代分支授权。
 
 **同仓、同一 plan、多可写并行轨（推荐）**：在挂齐各轨 `git worktree` **之前**，先与用户确认并写明 **plan 集成分支**（从商定 `<base>` 创建）及各轨 **topic 分支** 如何从该线分出或如何 **merge 回** 该线；QC 前再将待一并验收的提交 **全部归并**到 PM 指定为 QC **`Working branch`** 的那条分支的 **`HEAD`**。分步说明与示例命名边界见下节 **「推荐默认编排：先建 plan 集成分支，再挂各 worktree」**。
 
@@ -137,7 +137,7 @@ description: Morning Star business-repo Git feature branches, same-repo concurre
 
 开发在 **feature 分支**上完成（往往在 **独立 worktree** 中实现）后，**QC 审查与 QA 验证针对的都是这份 feature**，而不是 `main` 或任意未对齐的默认 cwd。
 
-- **`@project-manager`** 分派 **QC** 时须在 Assignment 写明与待审实现一致的 **`Working branch`**，并写明 **`Review cwd` / `Worktree path`**：**优先**沿用开发 **Completion Report** 中回报的业务仓 **实现检出路径**（即「该 feature 的 worktree」）**当且仅当**该路径上的检出分支 **`HEAD` 已包含本轮待审的全部提交**（含曾发生在其他并行 worktree、现已归并到该分支的变更）。否则 **必须**改用 **集成完成后的** `Working branch` 与对应检出路径（或按 **`using-git-worktrees`** 在该分支上 **另开** 审查专用目录）。若开发未用 worktree，则写明单一明确的业务仓根路径。若审查需与开发目录 **物理分离** 但仍审 **同一分支**，可指示按 **`using-git-worktrees`** 在 **`Working branch`** 上 **另加** 一个 worktree 专供审查（只读使用业务仓）。**多流并行开发**时的前置归并、**推荐默认编排（plan 集成分支先行）** 与误派禁令见上一小节。
+- **`@project-manager`** 分派 **QC** 时须在 Assignment 写明与待审实现一致的 **`Working branch`**，并写明 **`Review cwd` / `Worktree path`**：**优先**沿用开发 **Completion Report** 中回报的业务仓 **实现检出路径**（即「该 feature 的 worktree」）**当且仅当**该路径上的检出分支 **`HEAD` 已包含本轮待审的全部提交**（含曾发生在其他并行 worktree、现已归并到该分支的变更）。否则 **必须**改用 **集成完成后的** `Working branch` 与对应检出路径（或在该分支上 **另开** 审查专用 worktree）。若开发未用 worktree，则写明单一明确的业务仓根路径。若审查需与开发目录 **物理分离** 但仍审 **同一分支**，可指示在 **`Working branch`** 上 **另加** 一个 worktree 专供审查（只读使用业务仓）。**多流并行开发**时的前置归并、**推荐默认编排（plan 集成分支先行）** 与误派禁令见上一小节。
 - **三票审同一功能（强制对齐）**：分派 **QC 三审**时，除上述字段外，**必须**在 **三份 Assignment 中逐字写入相同**的 **`plan_id`** 与 **`Review range` / `Diff basis`**：
   - **`plan_id`**：与 `{PLAN_DIR}/reports/<plan-id>/` 及主 **Plan Path** 一致；无 `{PLAN_DIR}` 流程时写 **`plan_id: N/A`**，并另给一行 **`Feature / scope label`**（不可歧义，足以与并行其它 feature 区分）。
   - **`Review range` / `Diff basis`**：明确本次审查所针对的 **diff/提交范围**（例如 `merge-base: origin/main` + `tip: HEAD`；或 `rev-range: <full-40>..<full-40>`；或一句 `equivalent to: git diff <merge-base>...HEAD`，以团队可复现为准）。**三名 reviewer 的 Assignment 间该字段必须完全一致**；**@qa-engineer** 验证同一 feature 时 **复用同一 `plan_id` 与同一 `Review range` / `Diff basis`**。**热修 / QC 单审**路径也须含 **同一组字段**，仅承接方份数为 1。

package/harness-skills/mstar-coding-behavior/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mstar-coding-behavior
-description: Morning Star (启明星) 跨角色通用编码行为准则 —— Think Before Coding（先读懂再改、显式假设、不静默猜测、读 imports/test/项目模式）、Simplicity First（YAGNI 优先不写代码、The Ladder 决策层级含依赖评估、删除优于添加、简洁优于聪明、5 项具名反模式速查、`simplify:` 标记天花板与升级路径、最小耐久切片）、Surgical Changes（改动可追溯、Bug 修根因先 grep 所有调用点、不顺手重构、不 piggyback）、Debugging（读完整报错与栈追踪、先复现、一步一测、根因分析、Bug 修复前先写复现测试、卡住时坦白）、Goal-Driven Execution（非平凡逻辑必留一个可运行检查、模糊请求转可验证结果、测行为不测实现、已有测试前后对比、不能测试说理由、Step → verify 微模板、分批留 roadmap）、Communication（说做了什么及为什么、标记顾虑、精确表达不确定性、不解释已知的、commit message 质量）。任何实现、调试、重构、审查任务都应优先 Read 本 skill；`@fullstack-dev` / `@frontend-dev` / `@fullstack-dev-2` / `@architect` / `@qa-engineer` / `@ops-engineer` / `@prompt-engineer` 动手前必读；QC 审查员核对变更是否只做了该做的手术时必读。本 skill 不覆盖分支门禁、QC/QA 路由、Assignment 权限、Done 所有权等不变量（那些以 `mstar-harness-core` 为准）。
+description: Morning Star (启明星) 跨角色通用编码行为准则 —— Think Before Coding（先读懂再改、显式假设、不静默猜测、读 imports/test/项目模式）、Simplicity First（YAGNI 优先不写代码、The Ladder 决策层级含依赖评估、删除优于添加、简洁优于聪明、5 项具名反模式速查、`simplify:` 标记天花板与升级路径、最小耐久切片）、Surgical Changes（改动可追溯、Bug 修根因先 grep 所有调用点、不顺手重构、不 piggyback）、Debugging（读完整报错与栈追踪、先复现、一步一测、根因分析、Bug 修复前先写复现测试、卡住时坦白）、Review Feedback Handling（先核实反馈再改、逐项处理、可用证据反驳错误建议）、Goal-Driven Execution（非平凡逻辑必留一个可运行检查、模糊请求转可验证结果、测行为不测实现、已有测试前后对比、不能测试说理由、Step → verify 微模板、分批留 roadmap）、Communication（说做了什么及为什么、标记顾虑、精确表达不确定性、不解释已知的、commit message 质量）。任何实现、调试、重构、审查任务都应优先 Read 本 skill；`@fullstack-dev` / `@frontend-dev` / `@fullstack-dev-2` / `@architect` / `@qa-engineer` / `@ops-engineer` / `@prompt-engineer` 动手前必读；QC 审查员核对变更是否只做了该做的手术时必读。本 skill 不覆盖分支门禁、QC/QA 路由、Assignment 权限、Done 所有权等不变量（那些以 `mstar-harness-core` 为准）。
 ---
 
 ## Load order（必读顺序）
@@ -166,7 +166,31 @@ Micro template:
 - **Test behavior, not implementation.** A test that checks whether a constructor sets properties is worthless. A test that checks whether validation actually rejects bad input is valuable. Focus on the interesting cases.
 - **If you cannot write a test, say why.** "I cannot easily test this because the database calls are tightly coupled to the business logic" is useful information that may signal a need for restructuring. Do not skip testing without an explanation.
 
-## 6) Communication
+## 6) Review Feedback Handling
+
+Core idea: review feedback is technical input, not an order to perform unverified edits.
+
+When receiving code review, QA, CI, or human feedback:
+
+1. Read all feedback before editing.
+2. Clarify ambiguous items before partial implementation.
+3. Verify each suggestion against codebase reality.
+4. Apply technically correct feedback one item at a time.
+5. Test each fix individually where practical.
+6. Push back with evidence when feedback is incorrect, obsolete, risky, out of scope, or violates YAGNI.
+
+Feedback priority:
+
+| Feedback type | Handling |
+|---|---|
+| Security, correctness, data loss, build/test failure | Fix or escalate before proceeding. |
+| Scope mismatch, reviewer misunderstanding, obsolete assumption | Verify and push back with evidence. |
+| Style-only suggestion | Apply only if it matches project conventions or is requested by the user/PM. |
+| New feature disguised as review | Route through PM/plan unless explicitly in scope. |
+
+Do not perform agreement. State the technical action, the verification result, or the technical reason for disagreement.
+
+## 7) Communication
 
 Core idea: how you communicate about code matters as much as the code itself.
 
@@ -178,8 +202,7 @@ Core idea: how you communicate about code matters as much as the code itself.
 
 ## Integration Notes
 
-- This skill is additive to `verification-before-completion` (见 `mstar-superpowers-align`) and other Morning Star controls.
-- It must not be used to bypass:
+- This skill must not be used to bypass:
   - branch constraints,
   - QC/QA gate definitions,
   - assignment authority,

package/harness-skills/mstar-dispatch-gates/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mstar-dispatch-gates
-description: Morning Star 派发与委派门禁 —— 仅 PM 可增派 subagent、`Execute as` 与 `Delegation`、承接方反递归 NEVER 红线、同条消息 N 次 invoke、QC 三审禁止串行 rollout、Assignment 文案≠派发（invoke 条数须对齐）、未齐不发（emit zero until batch-ready）。**必须**在 `@project-manager` 每轮派发、QC 三审并发、双轨 implement、或 leaf 角色疑惑能否 Task 时 Read；所有非 PM 承接方动手前必读反递归与自检。同仓 worktree 与 QC 检出对齐见 `mstar-branch-worktree`。Superpowers 并行短语见 `mstar-superpowers-align`。宿主细则见 `mstar-host`（`references/parallel-dispatch.md` 与各宿主 reference）。
+description: Morning Star 派发与委派门禁 —— 仅 PM 可增派 subagent、`Execute as` 与 `Delegation`、承接方反递归 NEVER 红线、同条消息 N 次 invoke、QC 三审禁止串行 rollout、Assignment 文案≠派发（invoke 条数须对齐）、未齐不发（emit zero until batch-ready）。**必须**在 `@project-manager` 每轮派发、QC 三审并发、双轨 implement、或 leaf 角色疑惑能否 Task 时 Read；所有非 PM 承接方动手前必读反递归与自检。同仓 worktree 与 QC 检出对齐见 `mstar-branch-worktree`。宿主细则见 `mstar-host`（`references/parallel-dispatch.md` 与各宿主 reference）。
 ---
 
 ## Load order（必读顺序）
@@ -14,7 +14,7 @@ description: Morning Star 派发与委派门禁 —— 仅 PM 可增派 subagent
 > **先回到你 Assignment 最顶部的 `**IDENTITY**` 块重读一遍** —— 那里已经告诉你：你是谁、你不是谁、Task 工具不属于你。本节是那个身份断言的加固版。
 
 **身份断言（牢记，不动摇）：**
-- **你就是** `Execute as` 写的那个角色。你**不是 PM**，不是调度者，不是 `dispatching-parallel-agents` 的使用者。
+- **你就是** `Execute as` 写的那个角色。你**不是 PM**，不是调度者，不是 parallel-agent dispatch 的使用者。
 - Task/subagent 工具即使在你的工具列表里出现，它**不属于你**。把它当作你没见过的工具 —— 不是"不能用"，是"你没有"。
 - 所有工作由你**本人**在当前会话内完成（Read / Write / Edit / Shell / Grep / Glob）。任何"这样做更高效"的想法都不构成 dispatch 的理由。
 - 遇到超出能力范围的需求 → 写 `## Blocked` 回报 PM，**不是**尝试 dispatch。Blocked 是你能发出的正确信号，dispatch 不是。
@@ -27,7 +27,7 @@ description: Morning Star 派发与委派门禁 —— 仅 PM 可增派 subagent
 - **NEVER** 把 Assignment 里出现的 **任何** `@<role>`、反引号 `` `<role-id>` ``、**Handoff**、**QA note**、**Completion Report** 模板里的角色名、路由表下游角色当成「立刻 invoke」的指令；这些是**叙事 / 路由文档 / 后续 PM 编排意图**，不是命令。
 - **NEVER** 把「分解为多个计划 / 多 phase / 多 track」等**设计产物层面**的并行或拆分读成「应 invoke 与子会话数量对应的多个 subagent」。**纸面产物**由本会话写盘完成；并行**调度**由 PM 在后续轮次决定。
 - **NEVER** 因宿主**暴露**了 `Task` 或若干 `subagent_type` 名称就推断可以调用。**工具可用 ≠ 授权使用**；授权只来自 **`Delegation: allowed (...)`**。
-- **NEVER**（非 PM）主动执行 `dispatching-parallel-agents` 来分派子代理；需要并行时回报 PM。
+- **NEVER**（非 PM）主动执行 parallel-agent dispatch 来分派子代理；需要并行时回报 PM。
 - **DO NOT** 在 Assignment 缺少 `Execute as` / `Delegation` / `Who runs this turn` 时自行「补齐」为 PM；缺字段时按 **leaf executor** 解释：亲自完成或 **`Blocked`**。
 - **DO NOT** 用「Assignment 太长 / 像编排稿」当作分派依据；先交付本会话任务再回报，分派由 PM 下一轮决定。
 
@@ -47,7 +47,7 @@ description: Morning Star 派发与委派门禁 —— 仅 PM 可增派 subagent
 - 额外代理仅以 **`Delegation: allowed (...)`** 为准；未显式写时视为 **`Delegation: forbidden`**。
 - Assignment 正文中的 `@xxx` 默认按「文本引用」解释，**不**视为自动调用命令。
 - 承接方若判断必须增加 subagent，应先回报 **`Blocked`** 请 PM 重分派。
-- **Superpowers `subagent-driven-development`**：per-task 子步**勿**用 `@qc-specialist*`；用 `@general` / `generalPurpose` 或 PM 标明的 informal `@qa-engineer`。详见 **`mstar-superpowers-align`**。
+- Per-task informal review, when PM explicitly allows it, must not use `@qc-specialist*`; use `@general` / `generalPurpose` or PM-marked informal `@qa-engineer`. Formal QC remains `mstar-review-qc`.
 
 ## 并发分派完整性门禁（PM 强制）
 

package/harness-skills/mstar-dispatch-gates/references/leaf-executor-checklist.md

@@ -16,7 +16,7 @@ Before any Task/subagent call (if I somehow forget the preamble):
 4. Is `subagent_type` equal to my `Execute as`? If yes → **forbidden** (recursive dispatch).
 5. Am I treating `@roles`, Handoff, QA note, Completion Report roles, or multi-plan/multi-track **design text** as invoke commands? If yes → **stop**; deliver in-session.
 6. Am I invoking because the tool exists? **Available ≠ authorized.**
-7. Need parallel work or PM-only `dispatching-parallel-agents`? → **`Blocked`**; PM dispatches on the next round.
+7. Need parallel work or PM-only dispatch? → **`Blocked`**; PM dispatches on the next round.
 
 If blocked, report: `## Blocked — recursive dispatch refused (<which NEVER or reason>)`
 

package/harness-skills/mstar-harness-core/SKILL.md

@@ -33,7 +33,7 @@ description: Morning Star (启明星) harness **强制全局入口** —— 信
 | 角色 | 始终 | 按任务追加（典型） |
 |------|------|-------------------|
 | **全部** | 本 skill | — |
-| **`@project-manager`** | 本 skill | `mstar-dispatch-gates`、`mstar-phase-gates`、`mstar-plan-conventions`、`mstar-superpowers-align`、`mstar-roles`；派 QC 前 `mstar-review-qc`；并行/审查 `mstar-branch-worktree`；plan/status/reports `mstar-plan-artifacts`；UI 类 plan Prepare 阶段 `mstar-design-md`（DESIGN.md 门禁）；迭代管理 `mstar-iteration`（iteration-start/drive/close 含 compound）；战略性工作 `mstar-strategy`。**不**读 `mstar-coding-behavior` |
+| **`@project-manager`** | 本 skill | `mstar-dispatch-gates`、`mstar-phase-gates`、`mstar-plan-conventions`、`mstar-roles`；派 QC 前 `mstar-review-qc`；并行/审查 `mstar-branch-worktree`；plan/status/reports `mstar-plan-artifacts`；UI 类 plan Prepare 阶段 `mstar-design-md`（DESIGN.md 门禁）；新建/大改 skill 时 `mstar-skill-authoring`；迭代管理 `mstar-iteration`（iteration-start/drive/close 含 compound）；战略性工作 `mstar-strategy`。**不**读 `mstar-coding-behavior` |
 | **实现/审查/QA/运维** | 本 skill + `mstar-coding-behavior` + 角色 ref | 有 git 写：`mstar-branch-worktree`；有 plan 路径：`mstar-plan-conventions`（路径符号节）；QC/QA：`mstar-review-qc`；改 status/residual：`mstar-plan-artifacts`；UI 任务：`mstar-design-md`（读取 DESIGN.md tokens）；写入知识库 `{KNOWLEDGE_DIR}`：`mstar-compound`（PM 触发） |
 | **leaf 承接方** | 上栏 + **`mstar-dispatch-gates`**（反递归节） | — |
 
@@ -71,7 +71,7 @@ PM 在 Assignment 写 **`Task category`**（主类 + 可选 `secondary`）：
 
 ## 长任务纪律
 
-可追踪清单（plan `tasks` 或 Todo）；偏离时 PM 拉回；完成前须可核对证据（**`mstar-superpowers-align`** · `verification-before-completion`）。
+可追踪清单（plan `tasks` 或 Todo）；偏离时 PM 拉回；完成前须可核对证据（实现侧自检见 **`mstar-coding-behavior`**；门禁证据见 **`mstar-phase-gates`** / **`mstar-review-qc`**）。
 
 **Durable Roadmap Gate**：凡声明“分批 / 后续 / next plan / later / temporary workaround”的非热修任务，必须在 `{PLAN_DIR}` 主 plan、CreatePlan mirror、`status.json`/residual、或 PM Task Board 中写清后续路线（批次、依赖、owner/触发条件、完成定义）。只在对话或 Completion Report 里说“以后做”不算可追踪，不能进入 implement GO 或 Done。
 
@@ -88,11 +88,11 @@ PM 在 Assignment 写 **`Task category`**（主类 + 可选 `secondary`）：
 | `mstar-plan-artifacts` | 主 plan、reports、`status.json`、residual、knowledge、Done 归档 |
 | `mstar-design-md` | DESIGN.md 设计系统规范 —— 创建/审计/维护 design tokens，三级检查清单，light/dark 双主题 |
 | `mstar-review-qc` | QC 工作流、模板、verdict、residual 留档、deep review 透镜 |
-| `mstar-coding-behavior` | Think / Simplicity / Surgical / Debugging / Goal-Driven / Communication |
+| `mstar-coding-behavior` | Think / Simplicity / Surgical / Debugging / Review Feedback / Goal-Driven / Communication |
 | `mstar-compound` | 知识结晶 —— 已解决问题→结构化知识文档，双轨（Bug/Knowledge），「是否值得结晶」自检清单，重叠检测，可发现性检查，CONCEPTS.md 协同 |
 | `mstar-compound-refresh` | 知识维护 —— 审查/更新/合并/删除 `{KNOWLEDGE_DIR}` 文档 |
 | `mstar-strategy` | `STRATEGY.md` 全局战略方向 —— 产品愿景、技术方向、决策原则 |
-| `mstar-superpowers-align` | Superpowers × harness 优先级与短语 |
+| `mstar-skill-authoring` | mstar-native skill authoring: trigger contracts, progressive disclosure, pressure scenarios, behavior-change evidence |
 | `mstar-roles` | 角色正文 hub |
 | `mstar-host` | 宿主适配（自动识别；`references/opencode.md` / `cursor.md` / `codex.md` / `parallel-dispatch.md`） |
 
@@ -114,7 +114,7 @@ Read **`mstar-host`** after this skill; detect host per its table, then Read the
 - 业务仓默认功能分支（Assignment `Branch policy` 例外）→ **`mstar-branch-worktree`**。
 - **Dev 三角**：`@fullstack-dev` 后端主导；UI → `@frontend-dev`；第二轨 → `@fullstack-dev-2`（`mstar-roles` PM 节）。
 - 工期仅 agent-oriented → **`mstar-plan-conventions`** · effort-estimation。
-- `writing-plans` 落盘 `{PLAN_DIR}`，非 `docs/superpowers/plans/`。
+- plan-writing artifacts land in `{PLAN_DIR}`, not external default plan directories.
 - PM Assignment 键名英文；任务正文可中文；产出/报告默认英文。
 
 ## 库文档（Context7）

package/harness-skills/mstar-harness-core/references/open-harness-principles.md

@@ -13,9 +13,9 @@
 | **`clarify` 核心纪律** | 逐方面核对至共享理解；沿设计决策树逐枝、一次一决；能探索代码库则先探索；每问带推荐答案 | **`mstar-phase-gates`** SKILL.md（含 Phase Gate Playbook） |
 | **按任务类别选能力与模型** | 视觉/深读/快改/硬逻辑等用不同强项 | `mstar-harness-core` SKILL.md「Task category」；Assignment 字段 **`Task category`**；宿主侧按角色配置 model（如 OpenCode 的 `opencode.json`） |
 | **可验证编辑** | 减少「凭记忆 Patch」导致的漂移与损坏 | `mstar-phase-gates` SKILL.md「可验证编辑与上下文纪律」：读后再改、失败则重读 |
-| **持续推进与可核对完成** | 长任务有清单、有关门证据，避免空转 | `mstar-superpowers-align` 的 `verification-before-completion`；PM 对 `tasks`/Phase Gate 的拉回 |
+| **持续推进与可核对完成** | 长任务有清单、有关门证据，避免空转 | `mstar-phase-gates` / `mstar-review-qc`；实现侧自检见 `mstar-coding-behavior` |
 | **编码行为约束（轻量）** | 降低静默假设、过度设计与无关改动 | `mstar-coding-behavior`：Think Before Coding / Simplicity First / Surgical Changes / Goal-Driven Execution |
-| **并行与边界** | 多线任务不踩同一写归属、不绕过分支门禁；**开发**阶段同仓多可写并发须独立 **`git worktree`**；**QC / QA** 在 **同一检出**（`Review cwd`）与 **同一 `plan_id` + `Review range` / `Diff basis`** 上审查与验证，保证三票同一功能 | `mstar-branch-worktree`；`mstar-review-qc`；`mstar-superpowers-align` **`using-git-worktrees`** |
+| **并行与边界** | 多线任务不踩同一写归属、不绕过分支门禁；**开发**阶段同仓多可写并发须独立 **`git worktree`**；**QC / QA** 在 **同一检出**（`Review cwd`）与 **同一 `plan_id` + `Review range` / `Diff basis`** 上审查与验证，保证三票同一功能 | `mstar-branch-worktree`；`mstar-review-qc`；`mstar-dispatch-gates` |
 | **分层上下文（可选）** | 大仓库用目录级 `AGENTS.md` 降噪；根 `AGENTS.md` 维护边界见下文专节 | `mstar-harness-core` SKILL.md「分层上下文」；由业务项目维护者按需添加 |
 | **结构化澄清（按宿主）** | 向用户澄清/抉择时，**有 `question` 类能力则优先**；否则结构化正文；长问兜底 | `mstar-phase-gates` SKILL.md Prepare · `clarify`；当前宿主的 `mstar-host` skill；`mstar-roles` · `project-manager` |
 
@@ -71,6 +71,6 @@
 ## 延伸阅读
 
 - 按能力选配 MCP/skills：OpenCode → `mstar-host` `references/opencode.md`；其它宿主见 `mstar-host` 检测表
-- Superpowers 与门禁对齐：`mstar-superpowers-align`
+- Evidence and checkpoints: `mstar-phase-gates` / `mstar-review-qc`; implementation self-checks: `mstar-coding-behavior`
 - 库文档检索共享协议：`mstar-harness-core` `references/library-docs-protocol.md`
 - 跨角色编码行为准则（轻量、可复用）：`mstar-coding-behavior`

package/harness-skills/mstar-host/references/cursor-plan-mode-bridge.md

@@ -197,7 +197,7 @@ When `/pm` runs under Plan mode:
 
 ## Related skills
 
-- `mstar-plan-conventions` — discovery, init, `writing-plans` path gate
+- `mstar-plan-conventions` — discovery, init, plan-writing path gate
 - `mstar-plan-artifacts` — `status.json`, reports, checkboxes, residual
 - `mstar-phase-gates` — Prepare / Execute order
 - `mstar-roles/references/project-manager/dispatch-and-assignment.md` — Checkpoint: commit → Completion Report → Status Update

package/harness-skills/mstar-host/references/cursor.md

@@ -61,9 +61,9 @@ Enforcement: `rules/mstar-cursor-plan-mode.mdc` when plugin active.
 - No `question` tool: structured Markdown or Cursor UI.
 - “Question asked” ≠ clarify done; high-impact ambiguity → `Blocked` or escalation.
 
-## Superpowers
+## Execution Discipline
 
-If no Skill invocation tool: `mstar-superpowers-align` “plugin not installed”; **Read** upstream `SKILL.md` before execution.
+Implementation roles use `mstar-coding-behavior` for RCA, test-first checks, review feedback, and completion evidence. Plan checkpoints remain in `mstar-phase-gates`; external skill plugins are not required.
 
 ## Gotchas
 

package/harness-skills/mstar-host/references/opencode.md

@@ -8,7 +8,7 @@ Parallel PM dispatch: **`parallel-dispatch.md`** (read in dispatch rounds).
 
 - **Role shell**: `agents/<id>.md` referenced by `opencode.json` `agent.<id>` (frontmatter + role binding only).
 - **Role body**: `mstar-roles` `references/<id>.md` (or shared references + parameters).
-- Superpowers conflicts: `mstar-superpowers-align`.
+- Implementation evidence and RCA behavior: `mstar-coding-behavior`.
 
 ## OpenCode-specific capabilities
 
@@ -48,7 +48,7 @@ Aligned with `mstar-harness-core` `references/open-harness-principles.md`. Editi
 | **Repo graph** | Impact / PR risk | e.g. GitNexus |
 | **Browser / E2E** | Observable QA evidence | agent-browser, Playwright |
 | **Git workflow** | Atomic commits, branch closure | git-commit, finishing-a-development-branch |
-| **Systematic debugging** | RCA before fix | `mstar-superpowers-align` |
+| **Systematic debugging** | RCA before fix | `mstar-coding-behavior` |
 | **OpenViking memory** | Long-term memory tools | Only if `memsearch` present; `openviking-memory-plugin.md` |
 
 **Not recommended**: overlapping search MCPs; extra tools to mask missing harness baseline.

package/harness-skills/mstar-phase-gates/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mstar-phase-gates
-description: Morning Star (启明星) Spec-Driven 双阶段门禁 —— Prepare（`specify → clarify → plan`）、Execute（`plan(locked) → tasks → implement`）、意图门禁、长期目标优先、分批 roadmap 强制落盘、clarify 核心纪律（共享理解 / 先探索 / 每问推荐答案）、hotfix 压缩路径、可验证编辑、Phase Gate 最小证据。**必须**在 PM 判定 gate、首次 implement 派单前、产品/架构参与 Prepare、或解释为何不能跳过 plan/clarify 时 Read；`@project-manager` 每轮编排非 hotfix 任务必读；`@product-manager` / `@architect` 写规格与锁 plan 时必读 Prepare 节；实现角色 Read Execute 与 hotfix 例外即可。Task category 与 `quick` 禁豁免规则仍在 `mstar-harness-core`。并行 Superpowers 短语见 `mstar-superpowers-align`。迭代级活动（iteration-start / iteration-close / compound）见 `mstar-iteration`。
+description: Morning Star (启明星) Spec-Driven 双阶段门禁 —— Prepare（`specify → clarify → plan`）、Execute（`plan(locked) → tasks → implement`）、意图门禁、长期目标优先、分批 roadmap 强制落盘、clarify 核心纪律（共享理解 / 先探索 / 每问推荐答案）、hotfix 压缩路径、可验证编辑、Phase Gate 最小证据。**必须**在 PM 判定 gate、首次 implement 派单前、产品/架构参与 Prepare、或解释为何不能跳过 plan/clarify 时 Read；`@project-manager` 每轮编排非 hotfix 任务必读；`@product-manager` / `@architect` 写规格与锁 plan 时必读 Prepare 节；实现角色 Read Execute 与 hotfix 例外即可。Task category 与 `quick` 禁豁免规则仍在 `mstar-harness-core`。实现行为见 `mstar-coding-behavior`。迭代级活动（iteration-start / iteration-close / compound）见 `mstar-iteration`。
 ---
 
 ## Load order（必读顺序）
@@ -28,7 +28,7 @@ description: Morning Star (启明星) Spec-Driven 双阶段门禁 —— Prepare
 
 - **`plan(locked)`** — 冻结基线；实现中出现新约束时**先回写 plan 再继续**。
 - **`tasks`** — 含依赖顺序、并行标记、完成判据；每任务可追踪到 plan、roadmap 批次与验收标准。
-  - **并行标签**：若 PM 将 ≥2 条实现轨 **同时** 分派，须在 `Superpowers` 中写入 `dispatching-parallel-agents`；同仓 ≥2 可写并发时叠 `using-git-worktrees`（见 **`mstar-superpowers-align`** 与 **`mstar-branch-worktree`**）。
+  - **并行标签**：若 PM 将 ≥2 条实现轨 **同时** 分派，须在 Assignment 写明 `Dispatch mode: parallel independent tracks`；同仓 ≥2 可写并发时写明 `Worktree isolation: required`（见 **`mstar-dispatch-gates`** 与 **`mstar-branch-worktree`**）。
 - **`implement`** — 按 tasks 顺序执行并提交自检证据；完成进入 `InReview`；遵循 **`mstar-coding-behavior`**。
 
 ### 可验证编辑与上下文纪律
@@ -81,7 +81,7 @@ description: Morning Star (启明星) Spec-Driven 双阶段门禁 —— Prepare
 - `tasks`
   - 目标：把 plan 拆成可执行任务与依赖顺序。
   - 最小产物：任务列表、并行标记、完成判据、映射到验收标准与 roadmap 批次。
-  - **PM**：若并行标记对应「多轨同时 implement」，在对外 **Status Update** 与实现 Assignment 的 **`Superpowers`** 中写入 **`dispatching-parallel-agents`**（或同义短语）；同仓多可写并发时叠 **`using-git-worktrees`**（见 `mstar-superpowers-align`）。
+  - **PM**：若并行标记对应「多轨同时 implement」，在对外 **Status Update** 与实现 Assignment 写入 **`Dispatch mode: parallel independent tracks`**；同仓多可写并发时叠 **`Worktree isolation: required`**（见 `mstar-dispatch-gates` 与 `mstar-branch-worktree`）。
 - `implement`
   - 目标：按任务执行并提交证据，进入审查。
   - 最小产物：实现 diff、自检证据、回报与 handoff。

package/harness-skills/mstar-plan-artifacts/references/plan-files-and-reports.md

@@ -35,7 +35,7 @@
 ## QC 三审触发时机（单 plan · 多 batch）
 
 - **默认（推荐）**：同一 **`plan_id`** 下，**完整 QC 三审**（`qc1` + `qc2` + `qc3` 并行）**仅在 dev team 按该 plan 约定范围全部交付之后**执行**一次**，再进入 `@project-manager` 汇总与 `@qa-engineer` 验证。**不要**在每个中间 **batch** / 子里程碑都跑全套三审：否则 `reports/<plan-id>/` 会堆积多套并列报告，**`Review range` / `Diff basis` 与结论**易混淆，handoff 成本高。
-- **batch 之间**：依赖实现方 **`verification-before-completion`**、主 plan 任务勾选与 PM 协调；需要书面中间意见时，用对话、主 plan 批注或**非三审**的定向检查（如单审、架构 review），**不**默认等同「又一轮完整三审」。
+- **batch 之间**：依赖实现方按 **`mstar-coding-behavior`** 提供完成证据、主 plan 任务勾选与 PM 协调；需要书面中间意见时，用对话、主 plan 批注或**非三审**的定向检查（如单审、架构 review），**不**默认等同「又一轮完整三审」。
 - **After `Request Changes` (default — targeted re-review)**：PM maps each **blocking** finding to the QC seat that raised it (`source` on R#, consolidated table, or the originating `qcN.md` / `F-###`). Dispatch **only** those reviewers (`QC re-review: targeted — reviewers: qc-specialist, qc-specialist-2, …`). Each re-reviewing QC **updates the same** `qc1.md` / `qc2.md` / `qc3.md` in place (add `## Revalidation`, refresh verdict / `generated_at`); **do not** add `qc1-rev2.md` siblings on this path. PM **updates the same** `qc-consolidated.md` in place. Git history is the audit trail.
 - **Full tri re-review (exception)**：Only when Assignment states **`QC re-review: full tri-review`**. Run **three** parallel reviews again; use **new basenames** (`qc1-rev2.md` … `qc3-rev2.md`, `qc-consolidated-rev2.md`) so wave-1 files stay immutable; PM states **active wave** in consolidated decision. See `mstar-review-qc` · `mstar-dispatch-gates`.
 - **显式例外**：仅当用户与 PM 书面同意**中间门禁**时，在 Assignment 写清 **`QC gate: incremental — <scope>`**（或等价），并仍须保证该次三审的 **`plan_id` + `Review range` / `Diff basis`** 三份一致；**优先**用子范围子目录，避免与终局 `qc1..3.md` 混名。

package/harness-skills/mstar-plan-conventions/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mstar-plan-conventions
-description: Morning Star (启明星) harness 计划目录约定 —— `{HARNESS_DIR}` / `{PLAN_DIR}` / `{ITERATION_DIR}` / `{KNOWLEDGE_DIR}` / `{SPECS_DIR}` 发现与初始化（默认 `.mstar/`，兼容 `.agents/`）、`docs/` 与 harness 子树边界、未启用 plan 时的工作方式、Spec 集成分支与多 Plan 实现分支（merge 靶与 PR 合 main）、Superpowers `writing-plans` 落盘门限、工期预估（agent-oriented）。**必须**在读写 `.mstar/` / `.agents/`、初始化 harness、编排含 plan 的任务、或对齐 `metadata.primary_spec` 时 Read；`@project-manager` 开 plan 任务前必读。plan 文件 / status / residual / reports / knowledge → **`mstar-plan-artifacts`**；分支与 QC 检出 → **`mstar-branch-worktree`**。
+description: Morning Star (启明星) harness 计划目录约定 —— `{HARNESS_DIR}` / `{PLAN_DIR}` / `{ITERATION_DIR}` / `{KNOWLEDGE_DIR}` / `{SPECS_DIR}` 发现与初始化（默认 `.mstar/`，兼容 `.agents/`）、`docs/` 与 harness 子树边界、未启用 plan 时的工作方式、Spec 集成分支与多 Plan 实现分支（merge 靶与 PR 合 main）、Morning Star plan-writing path gate、工期预估（agent-oriented）。**必须**在读写 `.mstar/` / `.agents/`、初始化 harness、编排含 plan 的任务、或对齐 `metadata.primary_spec` 时 Read；`@project-manager` 开 plan 任务前必读。plan 文件 / status / residual / reports / knowledge → **`mstar-plan-artifacts`**；分支与 QC 检出 → **`mstar-branch-worktree`**。
 ---
 
 ## Load order（必读顺序）
@@ -64,9 +64,9 @@ PM 在需要持久化追踪时：
 - Git 操作与 QC 单一 `HEAD` → **`mstar-branch-worktree`**。
 - `status.json` 登记 `spec_integration_branch` / `merge_target` → **`mstar-plan-artifacts`**。
 
-## Superpowers `writing-plans` 门限
+## Plan-Writing Path Gate
 
-计划写入 **`{PLAN_DIR}`**，**禁止**默认 `docs/superpowers/plans/`。见 **`mstar-superpowers-align`**。
+Plans are written to **`{PLAN_DIR}`** when persistent plan tracking is enabled. Do not introduce external default plan directories.
 
 ## 状态与权限（摘要）
 

package/harness-skills/mstar-roles/SKILL.md

@@ -43,12 +43,12 @@ Treat these as baseline dependencies **where the role touches implementation, re
 | `mstar-phase-gates` | Prepare/Execute gates, clarify, hotfix path, intention gate |
 | `mstar-dispatch-gates` | PM dispatch; **all leaf executors** before any Task/subagent call |
 | `mstar-branch-worktree` | Git write, parallel worktrees, QC/QA checkout fields |
-| `mstar-plan-conventions` | `{HARNESS_DIR}` discovery, init, Spec branch naming, `writing-plans` path |
+| `mstar-plan-conventions` | `{HARNESS_DIR}` discovery, init, Spec branch naming, plan-writing path gate |
 | `mstar-plan-artifacts` | Main plan, `reports/`, `status.json`, residual, knowledge/iteration, Done compaction |
 | `mstar-design-md` | DESIGN.md design system spec — create/audit/maintain tokens, completeness checklist, light/dark dual-theme |
 | `mstar-review-qc` | QC workflow, template, verdict, high-risk checks |
-| `mstar-coding-behavior` | Implementation/debug/refactor (**not** PM orchestration-only) |
-| `mstar-superpowers-align` | Superpowers plugin on; Assignment `Superpowers` lines |
+| `mstar-coding-behavior` | Implementation/debug/refactor/review-feedback handling (**not** PM orchestration-only) |
+| `mstar-skill-authoring` | New skills, major skill rewrites, trigger descriptions, behavior-shaping skill validation |
 | `mstar-compound` | Capturing solved problems as structured knowledge in `{KNOWLEDGE_DIR}`; Discoverability check; CONCEPTS.md synergy |
 | `mstar-compound-refresh` | Auditing/updating/consolidating knowledge docs; maintaining `{KNOWLEDGE_DIR}` accuracy |
 | `mstar-iteration` | Iteration lifecycle: iteration-start (scope/roadmap lock), Autonomous Execute (per-plan dispatch loop), iteration-close (compound + roadmap update) |
@@ -59,7 +59,7 @@ Treat these as baseline dependencies **where the role touches implementation, re
 
 | Role | Typical adds |
 | --- | --- |
-| `project-manager` | `mstar-dispatch-gates`, `mstar-phase-gates`, `mstar-plan-conventions`, `mstar-superpowers-align`, `mstar-roles` ref; + `mstar-review-qc` before QC; + `mstar-branch-worktree` / `mstar-plan-artifacts` as the round requires; + `mstar-iteration` for iteration lifecycle (start/drive/close); + `mstar-strategy` for strategic alignment; + `mstar-compound` / `mstar-compound-refresh` pre-loaded by `mstar-iteration` § iteration-close |
+| `project-manager` | `mstar-dispatch-gates`, `mstar-phase-gates`, `mstar-plan-conventions`, `mstar-roles` ref; + `mstar-review-qc` before QC; + `mstar-branch-worktree` / `mstar-plan-artifacts` as the round requires; + `mstar-skill-authoring` for skill work; + `mstar-iteration` for iteration lifecycle (start/drive/close); + `mstar-strategy` for strategic alignment; + `mstar-compound` / `mstar-compound-refresh` pre-loaded by `mstar-iteration` § iteration-close |
 | `fullstack-dev*`, `frontend-dev` | `mstar-coding-behavior`, `mstar-dispatch-gates`, `mstar-branch-worktree` (if repo writes); plan path symbols from `mstar-plan-conventions` (minimal); `mstar-design-md` when implementing styled UI |
 | `qc-specialist*` | `mstar-review-qc`, `mstar-branch-worktree`, `mstar-plan-artifacts` (report paths); `mstar-design-md` when reviewing UI |
 | `qa-engineer` | `mstar-review-qc`, `mstar-branch-worktree`, `mstar-plan-artifacts` (closing R#); `mstar-design-md` when verifying visual output |

package/harness-skills/mstar-roles/references/architect.md

@@ -2,9 +2,9 @@
 
 **Hub matrix:** `mstar-roles` SKILL.md.
 
-**Always:** `mstar-harness-core`, `mstar-dispatch-gates`, `mstar-phase-gates` (Prepare: specify/clarify/plan), `mstar-plan-conventions` (`{PLAN_DIR}`, `writing-plans` path).
+**Always:** `mstar-harness-core`, `mstar-dispatch-gates`, `mstar-phase-gates` (Prepare: specify/clarify/plan), `mstar-plan-conventions` (`{PLAN_DIR}`, plan-writing path).
 
-**Typically:** `mstar-plan-artifacts` (knowledge/specs/ADR placement); `mstar-design-md` (DESIGN.md design system spec — architect is primary creator); `mstar-coding-behavior` (surgical doc edits); `mstar-superpowers-align` (when plugin on).
+**Typically:** `mstar-plan-artifacts` (knowledge/specs/ADR placement); `mstar-design-md` (DESIGN.md design system spec — architect is primary creator); `mstar-coding-behavior` (surgical doc edits).
 
 **On demand:** `mstar-branch-worktree` (when committing architecture docs to the business repo).
 
@@ -28,23 +28,19 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 - **NEVER** treat document-level parallelism (“split into N plans”, “Plan 002–010”, “Phase X ∥ Phase Y”, “N parallel tracks”) as permission to **invoke N subagents** in this session. The **plan/spec/ADR artifacts** are your deliverable; **scheduling** parallel execution is **PM’s next round**, not part of this assignment unless `Delegation: allowed (...)` explicitly lists callees.
 - **NEVER** treat `Handoff: @project-manager / @fullstack-dev / @qa-engineer …`, role names inside Completion Report templates, routing tables, or “suggested owner” groupings as **host invoke commands**; they are **narrative**, not authorization.
 - **NEVER** infer you may call `Task` / subagents because the host **lists** `subagent_type` names (`architect`, `fullstack-dev`, …). **Tool availability ≠ delegation authorization**; only **`Delegation: allowed (...)`** grants callees.
-- **NEVER** load and execute Superpowers `dispatching-parallel-agents` yourself to fan out child agents; that skill is **PM-orchestration-only** (see `mstar-superpowers-align`). If parallel runners are needed, report to PM for re-dispatch.
+- **NEVER** execute parallel-agent dispatch yourself to fan out child agents; dispatch is **PM-orchestration-only** (see `mstar-dispatch-gates`). If parallel runners are needed, report to PM for re-dispatch.
 - **NEVER** treat `Gate Decision: blocked` (material, high-impact ambiguities still open) as permission to hand off “ready for implement” architecture—finish clarify, update the package, or return `Blocked` to PM.
 - **NEVER** use a temporary, mixed, or partial design as the selected approach unless the target architecture and staged roadmap are written in the assigned plan/spec. “Later” without a tracking location is `Blocked`, not a handoff.
 - **NEVER** edit application implementation source, automated tests, CI workflows, Dockerfiles, or secrets-bearing runtime configuration unless the assignment explicitly limits you to doc-only placeholders **and** PM recorded the risk acceptance.
-- **NEVER** persist planning artifacts from `writing-plans` (or equivalent) under upstream `docs/superpowers/plans/`; only `{PLAN_DIR}` per `mstar-plan-conventions`.
+- **NEVER** persist planning artifacts under external default plan directories; only `{PLAN_DIR}` per `mstar-plan-conventions`.
 
 These rules align with `mstar-harness-core` executor anti-recursion invariants.
 
-## Superpowers (When Enabled)
+## Execution Discipline
 
-Use as applicable:
+Use `mstar-phase-gates` for trade-off exploration and technical plan checkpoints. Use `mstar-coding-behavior` only when editing tracked files or responding to review feedback. Same-repo multi-writer parallelism is governed by `mstar-branch-worktree`.
 
-- `brainstorming` for major trade-off exploration
-- `writing-plans` for technical planning documentation
-- `using-git-worktrees` for same-repo multi-writer parallelism
-
-`writing-plans` outputs must follow `{PLAN_DIR}` from `mstar-plan-conventions`, not external default paths.
+Plan artifacts must follow `{PLAN_DIR}` from `mstar-plan-conventions`, not external default paths.
 
 ## Responsibilities
 

package/harness-skills/mstar-roles/references/frontend-dev.md

@@ -4,7 +4,7 @@
 
 **Always:** `mstar-harness-core`, `mstar-coding-behavior`, `mstar-dispatch-gates`.
 
-**Typically:** `mstar-plan-conventions` (paths + spec metadata); `mstar-superpowers-align` (when plugin on).
+**Typically:** `mstar-plan-conventions` (paths + spec metadata).
 
 **On demand:** `mstar-branch-worktree` (repo writes); `mstar-phase-gates` (Execute / hotfix when referenced in assignment); `mstar-design-md` (when implementing styled UI — read DESIGN.md for tokens before writing components).
 
@@ -28,7 +28,7 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 - **NEVER** invoke `frontend-dev`, `fullstack-dev`, `fullstack-dev-2`, or other roles to perform **this** assignment unless `Delegation: allowed (...)` explicitly lists them.
 - **NEVER** offload UI implementation, tests, or evidence to `@explore`; use glob/grep/read first—short read-only `@explore` only per `mstar-harness-core` explore boundaries.
 - **NEVER** treat `Handoff` lines, route arrows, Completion Report role lists, or routing prose as **invoke instructions**; they are narrative unless `Delegation: allowed` says otherwise.
-- **NEVER** run Superpowers `dispatching-parallel-agents` as an implementer; that skill is **PM-only** (`mstar-superpowers-align`).
+- **NEVER** run parallel-agent dispatch as an implementer; this is **PM-only** (`mstar-dispatch-gates`).
 - **NEVER** self-decide branch pivots (including switching to `main`/`master`) beyond PM’s `Working branch` / `Branch policy`; conflicting or missing branch facts => `Blocked` to PM.
 - **NEVER** start UI implementation while the assignment’s Prepare / execute prerequisites (`plan locked`, `tasks`, branch contract) are unmet—return `Blocked` to PM instead of silent partial delivery.
 

package/harness-skills/mstar-roles/references/fullstack-dev-shared.md

@@ -14,7 +14,7 @@ Behavior is shared; track identity is parameterized.
 
 **Always:** `mstar-harness-core`, `mstar-coding-behavior`, `mstar-dispatch-gates` (leaf anti-recursion before any Task/subagent).
 
-**Typically:** `mstar-plan-conventions` (path symbols + `metadata.primary_spec` / `spec_refs`); `mstar-superpowers-align` (when plugin on).
+**Typically:** `mstar-plan-conventions` (path symbols + `metadata.primary_spec` / `spec_refs`).
 
 **On demand:** `mstar-branch-worktree` (repo writes, `Working branch`); `mstar-phase-gates` (Execute / hotfix sections when gate fields are in the assignment); `mstar-design-md` (when task includes UI implementation — read DESIGN.md for design tokens).
 
@@ -40,7 +40,7 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 - **NEVER** invoke `fullstack-dev`, `fullstack-dev-2`, `frontend-dev`, or other roles to perform **this** assignment body unless `Delegation: allowed (...)` explicitly lists them.
 - **NEVER** offload implementation, tests, or evidence to `@explore`; use glob/grep/read first—short read-only `@explore` only per `mstar-harness-core` explore boundaries.
 - **NEVER** treat `Handoff` lines, route arrows, Completion Report role lists, or routing prose as **invoke instructions**; they are narrative unless `Delegation: allowed` says otherwise.
-- **NEVER** run Superpowers `dispatching-parallel-agents` as an implementer; that skill is **PM-only** (`mstar-superpowers-align`).
+- **NEVER** run parallel-agent dispatch as an implementer; this is **PM-only** (`mstar-dispatch-gates`).
 - **NEVER** self-decide branch pivots beyond PM’s `Working branch` / `Branch policy`; if `<base>` is missing or the working tree disagrees with the assignment, **Blocked** to PM.
 - **NEVER** start implementation while Prepare / execute prerequisites in the assignment are unmet—return `Blocked` to PM.
 

package/harness-skills/mstar-roles/references/ops-engineer.md

@@ -4,7 +4,7 @@
 
 **Always:** `mstar-harness-core`, `mstar-coding-behavior`, `mstar-dispatch-gates`, `mstar-review-qc` (high-risk ops checklist), `mstar-branch-worktree` (repo writes, production-touching branches).
 
-**Typically:** `mstar-plan-conventions` (paths); `mstar-superpowers-align` (when plugin on).
+**Typically:** `mstar-plan-conventions` (paths).
 
 **On demand:** `mstar-phase-gates` (hotfix compressed path when assignment says hotfix).
 
@@ -29,7 +29,7 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 - **NEVER** read multi-phase / “N rollout tracks” **plan narrative** as “I must invoke N subagents now”; scheduling parallel work is **PM-owned** after your plan exists.
 - **NEVER** treat `Handoff` lines, template role names, or routing tables as **invoke commands**; only `Delegation: allowed` authorizes callees.
 - **NEVER** infer tool exposure (`Task`, subagent menus) implies authorization; **tool availability ≠ delegation**.
-- **NEVER** run Superpowers `dispatching-parallel-agents` yourself; **PM-only** (`mstar-superpowers-align`).
+- **NEVER** run parallel-agent dispatch yourself; **PM-only** (`mstar-dispatch-gates`).
 - **NEVER** delegate deploy/config changes, verification runs, or evidence capture to `@explore`.
 
 ## Responsibilities

package/harness-skills/mstar-roles/references/product-manager.md

@@ -2,9 +2,9 @@
 
 **Hub matrix:** `mstar-roles` SKILL.md.
 
-**Always:** `mstar-harness-core`, `mstar-dispatch-gates`, `mstar-phase-gates` (Prepare / clarify), `mstar-plan-conventions` (`{PLAN_DIR}`, `writing-plans` path).
+**Always:** `mstar-harness-core`, `mstar-dispatch-gates`, `mstar-phase-gates` (Prepare / clarify), `mstar-plan-conventions` (`{PLAN_DIR}`, plan-writing path).
 
-**Typically:** `mstar-plan-artifacts` (specs, knowledge index); `mstar-design-md` (DESIGN.md design intent and requirements for UI planning); `mstar-coding-behavior` (surgical doc edits); `mstar-superpowers-align` (when plugin on).
+**Typically:** `mstar-plan-artifacts` (specs, knowledge index); `mstar-design-md` (DESIGN.md design intent and requirements for UI planning); `mstar-coding-behavior` (surgical doc edits).
 
 **On demand:** `mstar-branch-worktree` (when committing product docs to the business repo).
 
@@ -29,19 +29,17 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 - **NEVER** invoke `architect`, dev, QA, or other roles to author **your** PRD/spec/clarify body unless `Delegation: allowed (...)` explicitly lists them—their names in templates are **not** automatic callees.
 - **NEVER** treat `Handoff` lines, route arrows, Completion Report role lists, or routing prose as **invoke instructions**; only `Delegation: allowed` authorizes callees.
 - **NEVER** infer you may call subagents because the host lists `subagent_type` names; **tool availability ≠ authorization**.
-- **NEVER** run Superpowers `dispatching-parallel-agents` yourself; **PM-only** (`mstar-superpowers-align`).
-- **NEVER** point `writing-plans` output to upstream `docs/superpowers/plans/`; use `{PLAN_DIR}` per `mstar-plan-conventions`.
+- **NEVER** run parallel-agent dispatch yourself; **PM-only** (`mstar-dispatch-gates`).
+- **NEVER** point planning output to external default plan directories; use `{PLAN_DIR}` per `mstar-plan-conventions`.
 - **NEVER** offload PRD/product-doc drafting to `@explore`; short read-only orientation only per `mstar-harness-core`.
 - **NEVER** label a Prepare package as “ready for implement” while `Gate Decision: blocked` for material ambiguities—resolve, document waivers with PM, or return `Blocked`.
 - **NEVER** split delivery by saying “later / follow-up / next phase” without writing the product roadmap, deferred scope, and final completion definition in the assigned plan/spec.
 
-## Superpowers (When Enabled)
+## Execution Discipline
 
-- `brainstorming` for ambiguity-heavy discovery
-- `writing-plans` for executable product planning
-- `using-git-worktrees` for same-repo concurrent writers
+Use `mstar-phase-gates` for ambiguity-heavy discovery and executable plan checkpoints. Use `mstar-coding-behavior` only when editing tracked files or responding to review feedback. Same-repo concurrent writers are governed by `mstar-branch-worktree`.
 
-`writing-plans` outputs must follow `{PLAN_DIR}` from `mstar-plan-conventions`.
+Plan artifacts must follow `{PLAN_DIR}` from `mstar-plan-conventions`.
 
 ## Responsibilities
 

package/harness-skills/mstar-roles/references/project-manager/dispatch-and-assignment.md

@@ -24,7 +24,7 @@ For assignees (non-PM):
 
 - **NEVER** treat `Handoff: …`, Completion Report template role names, routing tables, or “suggested owners” as **host invoke commands**; they are narrative unless `Delegation: allowed` authorizes callees.
 - **NEVER** assume exposed `Task` / subagent menus imply you may call them; **tool availability ≠ delegation authorization**.
-- **NEVER** execute Superpowers `dispatching-parallel-agents` as a leaf assignee; that skill is **PM-orchestration-only** (`mstar-superpowers-align`).
+- **NEVER** execute parallel-agent dispatch as a leaf assignee; dispatch is **PM-orchestration-only** (`mstar-dispatch-gates`).
 - **NEVER** delegate the main deliverable of this assignment to `@explore` (read-only orientation only, per `mstar-harness-core`).
 - **NEVER** claim `Done` / pass in **Completion Report v2** without the commands, logs, or artifacts explicitly required by the assignment’s **Evidence Required** section (see `mstar-harness-core` evidence gates).
 
@@ -43,7 +43,7 @@ The **`**You are a leaf executor. You MUST NOT:**`** section (previously just pr
   - **`@fullstack-dev-2`**: "treat `@fullstack-dev` in routing narrative as a handoff or invoke target"
   - **`@qa-engineer`**: "start validation before QC reports are consolidated"; "modify application code"
   - **`@explore`-assigned**: "implement or modify code"
-  - **All non-PM**: "use `dispatching-parallel-agents`"; "spawn a subagent whose `subagent_type` matches your own `Execute as` role id"
+  - **All non-PM**: "dispatch parallel agents"; "spawn a subagent whose `subagent_type` matches your own `Execute as` role id"
 - Anti-patterns must be action-oriented ("auto-dispatch to …", "treat … as invoke", "start … before …") — not abstract descriptions.
 - If the assignment involves multiple QCs or parallel tracks, add a specific bullet about NOT serializing or pre-empting the parallel dispatch.
 - If the assignment is part of a broader staged plan with follow-up tasks, add a bullet about NOT auto-extending scope into downstream tasks.
@@ -114,7 +114,7 @@ The **`**You are a leaf executor. You MUST NOT:**`** section (previously just pr
 - Tool availability ≠ delegation authorization
 **Plan Path**: <{PLAN_DIR}/... or N/A>
 **Report Format**: Completion Report v2
-**Superpowers**: <if plugin enabled and applicable>
+**Execution evidence**: <RCA/test-first/review feedback/evidence expectations for the assignee, if applicable>
 ```
 
 ## Completion Report v2 Template

package/harness-skills/mstar-roles/references/project-manager.md

@@ -6,9 +6,8 @@ Before any non-trivial PM action, read in order:
 2. `mstar-dispatch-gates` + `mstar-phase-gates` (dispatch + Prepare/Execute gates)
 3. Host adapter: `mstar-host` (detect host; Read `references/opencode.md`, `cursor.md`, or `codex.md`)
 4. `mstar-plan-conventions` (path discovery, init, Spec branch summary)
-5. `mstar-superpowers-align` (when Superpowers plugin is enabled)
-6. `mstar-review-qc` (same coordination round, **before** any QC dispatch)
-7. **On demand:** `mstar-branch-worktree` (parallel implement, QC/QA checkout); `mstar-plan-artifacts` (`status.json`, R#); `mstar-plan-artifacts` (InReview waves, reports naming)
+5. `mstar-review-qc` (same coordination round, **before** any QC dispatch)
+6. **On demand:** `mstar-branch-worktree` (parallel implement, QC/QA checkout); `mstar-plan-artifacts` (`status.json`, R#); `mstar-plan-artifacts` (InReview waves, reports naming)
 
 **Not required:** `mstar-coding-behavior` (orchestration-only PM work).
 
@@ -112,7 +111,7 @@ If any item below matches, fix the dispatch/plan state or mark `Blocked`—do **
 - **NEVER** register residuals only inside the plan narrative while skipping root `{HARNESS_DIR}/status.json` `residual_findings[<plan_id>]` when plan conventions require the SSOT field.
 - **NEVER** write non-canonical residual `severity` strings—use only the machine enum from `mstar-plan-artifacts`.
 - **NEVER** use `Task category: quick` to skip mandatory Prepare (`specify → clarify → plan`) for substantive work (`mstar-harness-core` hard rule).
-- **NEVER** omit `Superpowers` hooks when the plugin is enabled and the batch truly requires parallel dev (`dispatching-parallel-agents`) or same-repo multi-writer concurrency (`using-git-worktrees`) per `mstar-superpowers-align`.
+- **NEVER** omit native dispatch/worktree fields when the batch truly requires parallel dev (`Dispatch mode: parallel independent tracks`) or same-repo multi-writer concurrency (`Worktree isolation: required`) per `mstar-dispatch-gates` and `mstar-branch-worktree`.
 - **NEVER** point QC at a single dev worktree/`Review cwd` that cannot contain **all** claimed changes from parallel tracks until Git integration lands on one `Working branch` `HEAD` (`mstar-branch-worktree` QC/QA alignment).
 - **NEVER** label `QA: skipped` for report-only QA—still dispatch `@qa-engineer` with report-only mode; QC skip rules are separate and explicit.
 - **NEVER** let non-PM/non-QA roles mark plan `Done`.
@@ -175,7 +174,7 @@ Anti-patterns:
 - Q7: Is `quick` being misused to bypass prepare?
 - Q8: Is intention gate explicit before implement?
 - Q9: If QC tri-review, are alignment fields text-identical across three reviewers?
-- Q10: Is Delegation consistent with Superpowers usage?
+- Q10: Is `Delegation` consistent with dispatch and worktree usage?
 - Q11: For non-trivial plan, is PM Task Board published with coverage?
 - Q12: In invoke-based hosts, were matching invokes actually issued?
 - Q13: With **>=2 independent** backend/fullstack units, are owners spread across `fullstack-dev` and `fullstack-dev-2` (parallel or rotated), or is `single_stream_justified: yes` recorded with a real reason?

package/harness-skills/mstar-roles/references/prompt-engineer.md

@@ -4,7 +4,9 @@
 
 **Always:** `mstar-harness-core`, `mstar-dispatch-gates`.
 
-**When editing harness text:** read **all** topic skills you touch — at minimum `mstar-phase-gates`, `mstar-plan-conventions`, `mstar-plan-artifacts`, `mstar-plan-artifacts`, `mstar-branch-worktree`, `mstar-review-qc`, `mstar-coding-behavior`, `mstar-superpowers-align`, plus host adapters — so prompts stay aligned with SSOT and do not re-duplicate rules.
+**When editing harness text:** read **all** topic skills you touch — at minimum `mstar-phase-gates`, `mstar-plan-conventions`, `mstar-plan-artifacts`, `mstar-branch-worktree`, `mstar-review-qc`, `mstar-coding-behavior`, plus host adapters — so prompts stay aligned with SSOT and do not re-duplicate rules.
+
+**When creating a new skill, making a major skill rewrite, or changing trigger descriptions:** MUST read `mstar-skill-authoring` before editing.
 
 **Typically:** `mstar-plan-conventions` (path symbols in examples).
 
@@ -28,9 +30,9 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 - **NEVER** invoke `prompt-engineer` or other roles to perform **this** prompt/skill/rule assignment—even when editing files “owned by” another role’s prompt pack, **you** perform the edit; those role names are **targets**, not callees.
 - **NEVER** treat `Handoff` lines, template role lists, or routing prose as **invoke instructions**; only `Delegation: allowed` authorizes callees.
 - **NEVER** infer tool exposure implies authorization; **tool availability ≠ delegation**.
-- **NEVER** run Superpowers `dispatching-parallel-agents` yourself; **PM-only** (`mstar-superpowers-align`).
+- **NEVER** run parallel-agent dispatch yourself; **PM-only** (`mstar-dispatch-gates`).
 - **NEVER** outsource prompt/skill/rule design, edits, or validation evidence to `@explore`.
-- **NEVER** merge prompt/skill/rule text that contradicts `mstar-harness-core`, `mstar-review-qc`, or `mstar-superpowers-align` without an explicit documented exception approved by PM (harness SSOT wins by default).
+- **NEVER** merge prompt/skill/rule text that contradicts `mstar-harness-core`, `mstar-review-qc`, or `mstar-coding-behavior` without an explicit documented exception approved by PM (harness SSOT wins by default).
 
 ## Responsibilities
 
@@ -46,13 +48,17 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 
 ## Skill Authoring Requirement
 
-When creating/updating skills, use the `skill-creator` workflow as required by repository practice.
+When creating a new skill, making a major skill rewrite, changing frontmatter `description`, or changing behavior-shaping skill text:
+
+1. MUST read `mstar-skill-authoring` before editing.
+2. MUST follow the repository `skill-creator` requirement when the change is a new skill or major rewrite.
+3. MUST include validation evidence for behavior-shaping changes, or explicitly state why only manual/search validation is practical.
 
 ## Prompt Change Minimal Checklist
 
 - Trigger conditions and non-goals are explicit
 - Output/evidence expectations are testable
-- No conflict with `mstar-harness-core`, `mstar-review-qc`, `mstar-superpowers-align`
+- No conflict with `mstar-harness-core`, `mstar-review-qc`, or `mstar-skill-authoring`
 - Redundancy removed before adding new constraints
 - At least one replayable scenario exists for regression check
 

package/harness-skills/mstar-roles/references/qa-engineer.md

@@ -4,7 +4,7 @@
 
 **Always:** `mstar-harness-core`, `mstar-review-qc`, `mstar-coding-behavior`, `mstar-dispatch-gates`, `mstar-branch-worktree` (same checkout fields as QC for the feature).
 
-**Typically:** `mstar-plan-conventions` (paths); `mstar-superpowers-align` (when plugin on).
+**Typically:** `mstar-plan-conventions` (paths).
 
 **On demand:** `mstar-plan-artifacts` (closing R# after verified fix); `mstar-phase-gates` (gate checklist when assignment references verification phase); `mstar-design-md` (when verifying UI — check visual output against DESIGN.md).
 
@@ -30,7 +30,7 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 - **NEVER** switch to an unprescribed worktree/branch to “pick up the other half” of parallel development; if the current `HEAD` cannot contain the claimed diff scope, **Blocked** and ask PM for Git integration or a corrected assignment (`mstar-branch-worktree`).
 - **NEVER** treat `Handoff` / template role lists / route arrows as invoke instructions; only `Delegation: allowed` authorizes callees.
 - **NEVER** infer tool exposure implies authorization; **tool availability ≠ delegation**.
-- **NEVER** run Superpowers `dispatching-parallel-agents` yourself; **PM-only** (`mstar-superpowers-align`).
+- **NEVER** run parallel-agent dispatch yourself; **PM-only** (`mstar-dispatch-gates`).
 - **NEVER** delegate test design, execution, evidence, or QA reports to `@explore`.
 - **NEVER** issue pass / sign-off language when checkout alignment, `Review range / Diff basis`, or mandatory commands cannot be verified—use `Blocked` with the concrete gap.
 

package/harness-skills/mstar-roles/references/qc-specialist-shared.md

@@ -49,7 +49,7 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 - **NEVER** close, delete, or archive residual entries in `status.json` from QC; PM/QA own residual lifecycle per `mstar-plan-artifacts`.
 - **NEVER** treat `Handoff` lines, template role lists, or routing prose as invoke instructions; only `Delegation: allowed` authorizes callees.
 - **NEVER** infer tool exposure implies authorization; **tool availability ≠ delegation**.
-- **NEVER** run Superpowers `dispatching-parallel-agents` yourself; **PM-only** (`mstar-superpowers-align`).
+- **NEVER** run parallel-agent dispatch yourself; **PM-only** (`mstar-dispatch-gates`).
 - **NEVER** outsource review steps, verdict rationale, checklist execution, or report drafting to `@explore`.
 
 ## Review Context Gate (Hard)

package/harness-skills/mstar-roles/references/writing-specialist.md

@@ -4,7 +4,7 @@
 
 **Always:** `mstar-harness-core`, `mstar-dispatch-gates`, `mstar-coding-behavior` (surgical edits).
 
-**Typically:** `mstar-plan-conventions` (where deliverables land under `{HARNESS_DIR}` / `docs/`); `mstar-plan-artifacts` (when writing under knowledge or plan trees); `mstar-superpowers-align` (when plugin on).
+**Typically:** `mstar-plan-conventions` (where deliverables land under `{HARNESS_DIR}` / `docs/`); `mstar-plan-artifacts` (when writing under knowledge or plan trees).
 
 **Host:** `mstar-host` (detect; `references/opencode.md` | `cursor.md` | `codex.md`).
 
@@ -25,7 +25,7 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 - **NEVER** invoke `writing-specialist` or unrelated roles to perform **this** writing assignment unless `Delegation: allowed (...)` lists them.
 - **NEVER** treat `Handoff` lines, template role lists, or routing prose as **invoke instructions**; only `Delegation: allowed` authorizes callees.
 - **NEVER** infer tool exposure implies authorization; **tool availability ≠ delegation**.
-- **NEVER** run Superpowers `dispatching-parallel-agents` yourself; **PM-only** (`mstar-superpowers-align`).
+- **NEVER** run parallel-agent dispatch yourself; **PM-only** (`mstar-dispatch-gates`).
 - **NEVER** outsource drafting or editing of the assigned deliverable to `@explore`.
 - **NEVER** mark plan items or harness `status.json` fields implying `Done` for the overall plan—writing-only scope; PM/QA own closure.
 

package/harness-skills/mstar-skill-authoring/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: mstar-skill-authoring
+description: Morning Star skill authoring and maintenance guidance. Read when creating a new skill, making a major skill rewrite, changing trigger descriptions, evaluating whether behavior-shaping skill text works, or reviewing skill structure before release. This is mstar-native and independent of external skill plugins.
+---
+
+# Morning Star Skill Authoring
+
+This skill defines how Morning Star authors, reviews, and validates runtime skills. It is for skill work, not ordinary application implementation.
+
+## Load Order
+
+Read `mstar-harness-core` first. For repository maintenance, also follow root `AGENTS.md`.
+
+When changing existing skills, read every topic skill you touch and any referenced files needed to preserve the single source of truth. Do not rewrite adjacent skills for style only.
+
+## Core Practices
+
+This skill defines Morning Star's reusable skill-authoring practices:
+
+- Treat skills as process code that should be tested against pressure scenarios.
+- Use frontmatter descriptions as trigger contracts, not process summaries.
+- Keep `SKILL.md` concise and move heavy detail into `references/`.
+- Prefer concrete trigger symptoms, contexts, and user phrases.
+- Verify behavior-changing skill edits with evidence, not wording preference.
+
+It deliberately avoids external path assumptions, external plugin dependencies, and any requirement to run a non-Morning-Star skill as a prerequisite.
+
+## Skill Purpose Test
+
+Create or expand a skill only when all are true:
+
+1. The behavior should be reused across multiple projects, roles, or tasks.
+2. The behavior requires judgment or sequencing that is not better enforced by code.
+3. The existing Morning Star skill tree does not already contain the same rule.
+4. The trigger can be stated clearly enough for agents to know when to read it.
+
+Do not create a skill for:
+
+- One-off project conventions; put those in project `AGENTS.md`.
+- Mechanical rules that can be linted or scripted.
+- A solved incident narrative with no reusable technique.
+- Another copy of a rule already owned by an existing `mstar-*` skill.
+
+## Frontmatter Contract
+
+Required fields:
+
+```yaml
+---
+name: mstar-example
+description: Use when...
+---
+```
+
+Rules:
+
+- `name` is stable, lowercase, and hyphenated.
+- `description` is the trigger contract.
+- Start with the situations that should cause the skill to load.
+- Include concrete symptoms, contexts, roles, and artifacts.
+- Do not summarize the whole workflow in the description.
+- Keep descriptions specific enough to avoid loading on unrelated tasks.
+
+Bad description:
+
+```yaml
+description: Explains how to write plans with steps, tests, commits, and review gates.
+```
+
+Better description:
+
+```yaml
+description: Use when a non-trivial task has a spec or requirements and needs a written implementation plan before code changes.
+```
+
+Why: descriptions are often visible before the body. If the description summarizes the workflow, agents may follow the summary and skip the full skill.
+
+## Body Structure
+
+Use this default structure unless the skill has a better local pattern:
+
+```markdown
+# Skill Title
+
+## Load Order
+What must be read first, and what owns conflicts.
+
+## Scope
+When this applies and what it does not own.
+
+## Workflow
+The shortest reliable execution path.
+
+## Decision Rules
+Tables or bullets for common branches.
+
+## Evidence
+What proves the skill was followed.
+
+## References
+Optional files to read only when needed.
+```
+
+Keep `SKILL.md` focused on the main execution path. Move long examples, templates, schemas, and detailed variants into `references/`, `templates/`, or `scripts/`.
+
+## Progressive Disclosure
+
+Use three levels:
+
+1. Frontmatter: trigger only.
+2. `SKILL.md`: core execution path.
+3. Resources: details loaded only for the relevant variant.
+
+If `SKILL.md` grows large because it covers multiple domains, split by reference file:
+
+```text
+skill-name/
+  SKILL.md
+  references/
+    opencode.md
+    cursor.md
+    codex.md
+```
+
+The body must tell the reader exactly which reference to open and when.
+
+## Trigger Quality Checklist
+
+Before committing a skill change:
+
+- Does the description say when to trigger, not merely what the skill contains?
+- Does it include common synonyms and role/task contexts?
+- Does it avoid overbroad terms that would load it constantly?
+- Does the body define conflict ownership?
+- Does it point to one source of truth instead of repeating long rules?
+- Does it state the expected evidence for behavior-shaping changes?
+
+## Pressure Scenarios
+
+For new skills or major behavior rewrites, write 2-3 pressure prompts that would fail without the skill:
+
+```json
+{
+  "skill_name": "mstar-example",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "A realistic task that tempts the agent to violate the intended rule.",
+      "expected_output": "What compliant behavior looks like.",
+      "files": []
+    }
+  ]
+}
+```
+
+Good pressure prompts:
+
+- Create the mistake the skill is meant to prevent.
+- Mention realistic artifacts and role boundaries.
+- Have observable pass/fail criteria.
+- Avoid testing trivia from the skill body.
+
+If full eval runs are not practical for the change, record manual evidence: before/after expectation, affected trigger phrase, and one concrete validation step such as search results, link checks, or a dry-run prompt review.
+
+## Maintenance Discipline
+
+- Preserve runtime/maintenance split: skills describe runtime behavior; root `AGENTS.md` describes repository maintenance.
+- Keep role shells thin; reusable behavior belongs in topic skills or role references.
+- Do not introduce parallel manuals for the same workflow.
+- Do not rename or split skills without updating role matrices, README tables, host adapters, and install docs.
+- Behavior-shaping wording changes need evidence: evals, regressions, concrete user outcomes, or a documented failure mode.
+
+## Review Template
+
+Use this when reviewing a skill PR:
+
+```markdown
+## Skill Review
+- Trigger contract:
+- SSOT alignment:
+- Runtime vs maintenance split:
+- Progressive disclosure:
+- Evidence for behavior change:
+- Stale references checked:
+- Verdict: Approve | Request Changes | Needs Discussion
+```

package/harness-skills/pm/SKILL.md

@@ -23,7 +23,7 @@ Detect host → Read `mstar-host` → `references/cursor.md` | `opencode.md` | `
 3. Before first **implement** dispatch: `mstar-dispatch-gates` + host reference
 4. Before **QC**: `mstar-review-qc`
 5. **Iteration flow** (start / Execute / close): **`mstar-iteration`** — canonical SSOT for per-plan dispatch loop, integration branch, compound round. Do **not** re-describe the flow in this skill.
-6. **On demand:** `mstar-phase-gates`, `mstar-plan-conventions`, `mstar-plan-artifacts`, `mstar-branch-worktree`, `mstar-superpowers-align`
+6. **On demand:** `mstar-phase-gates`, `mstar-plan-conventions`, `mstar-plan-artifacts`, `mstar-branch-worktree`, `mstar-skill-authoring` for skill work
 
 Prepare/Execute gates, routing, Assignment templates, Task Board, QC tri-review, residuals, compound → topic skills + PM references (not repeated here).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mstar-harness/opencode",
-  "version": "0.7.3",
+  "version": "0.7.4",
   "description": "Morning Star harness OpenCode plugin (skills bootstrap and agent loading).",
   "license": "MIT",
   "repository": {

package/harness-skills/mstar-superpowers-align/SKILL.md

@@ -1,150 +0,0 @@
----
-name: mstar-superpowers-align
-description: Morning Star (启明星) harness 与 Superpowers 技能的对齐与消解契约 —— 未装插件时的加载方式（Read SKILL.md 执行）、优先级（harness > 技能正文）、最小技能声明契约（Superpowers 行需含 Trigger + Expected evidence）、`Delegation` 与 `subagent-driven-development` 的互斥规则（默认 forbidden 不得叠该技能）、编排触发短语表（`dispatching-parallel-agents` / `using-git-worktrees` / `systematic-debugging` / `verification-before-completion` 等）、`subagent-driven-development` 上游 implementer-prompt / reviewer 模板降权为可选技巧、per-task 双审禁用 `@qc-specialist*`（改用 `@general` / `generalPurpose` / informal `@qa-engineer`）、QC 三审与 `using-git-worktrees` 的叠用约束、与 @explore 的关系、快速去歧义规则。`@project-manager` 在 Assignment 写 `Superpowers` 行前必读；任何承接方遇到 Superpowers 技能名前必读以判定是否冲突；`@prompt-engineer` 修改技能相关规则前必读。按角色必用/宜用详表与张力/消解对照见 references/。
----
-
-## Load order（必读顺序）
-
-**在同一会话或任务中首次 Read 本 skill 时：必须先 Read `mstar-harness-core` skill（SKILL.md，以及与本任务相关的 `mstar-harness-core/references/`）。** 本 skill 只定义 **Superpowers × harness 的优先级与触发短语**；阶段顺序、谁可派 subagent、QC 三审与 `using-git-worktrees` 叠用等 **不变量** 以 **`mstar-harness-core`**（及 `mstar-plan-conventions` / `mstar-review-qc` 中已被 harness 索引的专题）为准。冲突时 **以 `mstar-harness-core` 为准**。
-
-**摘要**：`mstar-harness-core` — 状态机与调度防串扰；本 skill — `Delegation` / `subagent-driven-development` 互斥、per-role 必用技能短语与张力消解表。
-
-# Morning Star × Superpowers 对齐契约
-
-本 skill 将 **Superpowers** 插件中的技能（`opencode.json` 中 `plugin` 已启用时）映射到 `mstar-roles` skill 的各角色 业务流程，并定义冲突时的消解规则。
-
-## 未安装插件时
-
-若当前环境没有 Superpowers（`skill` 里看不到、`plugin` 未配置）：拉取并按官方说明操作即可。
-
-- **安装说明（英文）**: `https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md`  
-- **改 `opencode.json` 须先征得用户同意**（见 `mstar-harness-core` 护栏）；不同意就只口述步骤，不代写。
-
-**Agent 可照做的英文一句**：
-
-`Fetch and follow https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md for your code-agent host (e.g. OpenCode); get user approval before editing ~/.config/opencode/opencode.json.`
-
-## 如何"使用"技能
-
-- 各角色在对应任务阶段应 **显式加载并遵循** 相应技能的完整内容（在支持 `/skill-name` 或少样本名称的环境中，通过技能名调用；以**宿主客户端**实际能力为准，宿主差异见当前宿主的 `mstar-host` skill）。
-- **优先级（本仓库强制）**：**用户显式指令**（含项目 `AGENTS.md` / `CLAUDE.md`）> **`mstar-*` skills 中的 harness 不变量**（`mstar-harness-core` 里的状态机与门禁、plan 约定、review 基线、branch 协作等）> **Superpowers 技能正文中的流程、阶段划分与审查模型** > 一般惯例。当技能描述的顺序、谁可派 subagent、何时审查与 **harness 不一致**时，**以 harness 与 PM Assignment 为准**，技能仅保留**不冲突**的技巧（例如自检清单、模型分档、提问纪律）。若用户禁止 TDD，则不得强制 `test-driven-development`。
-- **`writing-plans` 保存路径（门限）**：`mstar-plan-conventions` 中的 **`{PLAN_DIR}`**（主 plan Markdown；与 **`{HARNESS_DIR}`** 分层见同 skill）优先于上游技能正文中的 `docs/superpowers/plans/`；执行该技能时仍须将计划落在 **`{PLAN_DIR}`**，**`{HARNESS_DIR}/status.json`**、**`{HARNESS_DIR}/notes.json`**、**`{HARNESS_DIR}/archived/`**、**`{HARNESS_DIR}/knowledge/`** 等仍按 **`{HARNESS_DIR}`**。
-- **与 harness 的关系**：不改变 `mstar-harness-core` 的阶段顺序；技能规定的是**每个阶段内的做法**（例如排障前先走系统化调试、宣称完成前先有验证证据）——**但不得用技能覆盖 harness 的门禁**（见下节「`subagent-driven-development` 与上游模板」）。
-
-## 最小技能声明契约（减少歧义）
-
-为降低"技能已提及但执行动作不一致"的情况，`@project-manager` 在 Assignment 中应按下列最小结构声明（可简写）：
-
-```markdown
-Superpowers:
-- <skill-id> — Trigger: <why now>; Expected evidence: <what output proves it ran>
-```
-
-语言约定（与 `agents/project-manager.md` 对齐）：
-
-- 字段名（如 `Task`、`Scope`、`Acceptance Criteria`、`Report Format`）保持英文键名。
-- 字段值中的任务描述正文可优先使用中文（便于编排与减少歧义）。
-- `Expected evidence` 及最终执行回报保持英文，确保跨角色可读性一致。
-
-示例：
-
-```markdown
-Superpowers:
-- systematic-debugging — Trigger: intermittent 500s with unknown root cause; Expected evidence: repro steps + narrowed hypothesis + log slice
-- verification-before-completion — Trigger: before sign-off; Expected evidence: command/output or reproducible QA proof
-```
-
-约束：
-
-- 不写"泛口号式"技能名（例如只写 `use superpowers`）。
-- `Expected evidence` 必须可核对；不能是"done""looks good"这类不可验证描述。
-- 若同一任务包含多个技能，按"流程技能 → 实现技能"排序，避免承接方误判先后。
-
-### `Delegation` 与 Superpowers 清单一致
-
-`Assignment` 的 **`Delegation`** 优先于技能梗。**默认 `forbidden`** 时 **勿**在 **`Superpowers`** 写 **`subagent-driven-development`**（易与「不得 Task」冲突）；大单轨用 **`executing-plans` + `verification-before-completion`**（+ 视情 TDD / `systematic-debugging`）。要 per-task informal 子审须 **`Delegation: allowed (to @general / generalPurpose, informal only; 非 QC 报告)`** 后方可写该项。并行多轨用 **`dispatching-parallel-agents`** + 分 Assignment，**勿**用该技能顶替并行。承接方：无 `allowed` 即不得 spawn；不得因技能名含 subagent 强行 Task；难事 **Blocked** 请 PM 分批或显式 `allowed`。
-
-## 编排技能 PM-only（强制）
-
-下列 Superpowers 技能在本 harness 中是 **`@project-manager` 编排专用**，**非 PM 角色**（实现 / 审查 / QA / 运维 / 产品 / 架构 / 写作 / 提示词）一律 **不得** 自行加载并执行其分派语义；命中即按 `mstar-harness-core`「承接方反递归红线」处理：
-
-- **`dispatching-parallel-agents`** —— 仅 PM 在调度轮次内并行 invoke ≥2 条独立 Assignment 时使用。**非 PM 承接方**读到 Assignment 中描述的「N tracks 并行 / Plans 002–010 可并行 / Phase X & Y parallel」属于**编排意图说明**，**不是**让你 invoke N 个 subagent。需要并行时回报 PM 重派。
-- **`subagent-driven-development`** —— 仅在 PM 显式 `Delegation: allowed (...)` 覆盖时由 PM 在主会话顺序多代理；承接方默认 forbidden（见下文「Delegation 与 Superpowers 清单一致」）。
-- **`using-git-worktrees`** —— 编排意图由 PM 决定（同仓 ≥2 可写并发时叠用）；承接方 **执行** 自己 Assignment 的 worktree 检出是允许的，但**不得**自行扩展为多 worktree 并行编排。
-
-> 速判：你不是 `@project-manager`？任何「派 N 个子代理」的动作都 **forbidden**，无论 Superpowers 名称如何匹配。
-
-## 编排触发短语表（PM Assignment / Status Update）
-
-`@project-manager` 在 **对用户说明**、**Status Update**、**Assignment** 中应混用下列**英文短语或技能 ID**（可与中文并列），与 Superpowers 技能描述用语一致，便于宿主/插件匹配。其他角色只需按 Assignment 中的 `Superpowers` 行执行；**非 PM 角色读到这些技能名时不得视为对自己的 invoke 授权**（见上节「编排技能 PM-only」）。
-
-| 意图 | 建议写入的自然语言 / 技能 ID（示例） | 对应技能 |
-|------|-----------------------------------|---------|
-| 编排总览、技能先后顺序 | `using superpowers`；`load skills in order`；先流程再实现 | using-superpowers |
-| 0→1、目标含糊、多方案取舍 | `brainstorming`；`brainstorm before we build`；脑暴后再定范围 | brainstorming |
-| 多阶段、动代码前先书面拆解 | `writing-plans`；`write the plan first`；里程碑与依赖写清再开发 | writing-plans |
-| 锁 plan 推进（单执行者顺序、或跨会话检查点） | `executing-plans`；`execute plan`；`checkpoints` | executing-plans |
-| 由 PM 会话内顺序多代理，或已 `Delegation: allowed` 的 informal 子步 | `subagent-driven-development`；**勿**与默认 `forbidden` 同条 | subagent-driven-development |
-| 多独立任务并行分派 | `dispatching parallel agents`；`dispatch parallel agents`；并行分派、无依赖任务并行 | dispatching-parallel-agents |
-| Bug/间歇性/排障 | `systematic debugging`；`no fix before root cause`；RCA 与证据链；先调查再修复 | systematic-debugging |
-| 未禁止 TDD 时的实现方式 | `test-driven development`；`TDD`；先写失败测试再过绿 | test-driven-development |
-| 大块合并前作者侧 | `requesting code review` | requesting-code-review |
-| 按 QC 结论改代码 | `receiving code review`；对照 review 结论逐项核实再改 | receiving-code-review |
-| Gate 前必须有证据 | `verification before completion`；`verify before claiming done`；须附命令与输出/复现步骤 | verification-before-completion |
-| 合并/删分支/发布收口 | `finishing a development branch`；merge / cleanup 选项与风险 | finishing-a-development-branch |
-| 并行实验、同仓多代理隔离检出 | `git worktree`；`using git worktrees`（**同仓多可写并发时必用**，与 `dispatching-parallel-agents` 叠用；**仍须** Assignment 已批准的 **`Working branch`** / **`Branch policy`** 与 **检出路径约定**；不得在 worktree 内擅自新建/切换未授权分支；见 `references/tension-table.md`） | using-git-worktrees |
-| 技能/Prompt 工程 | `writing-skills`（通常随 @prompt-engineer 任务写出） | writing-skills |
-
-## 技能清单（简称）
-
-| 技能名 | 用途摘要 |
-|--------|---------|
-| `using-superpowers` | 何时加载技能、流程类与实现类技能顺序 |
-| `brainstorming` | 创造性工作之前澄清意图、范围与设计 |
-| `writing-plans` | 多步任务在动代码前先写可执行计划 |
-| `executing-plans` | 在**另一次会话**按书面计划执行并设检查点 |
-| `subagent-driven-development` | **本会话**内按任务拆步执行；**审查与分派仍以 harness 为准**（见下文专节），上游 per-task 双审与 `implementer-prompt` 模板**不替代** QC 三审与 PM Assignment |
-| `dispatching-parallel-agents` | 多个互不依赖任务并行分派 |
-| `test-driven-development` | 实现前先写/tests 失败再过绿（若适用） |
-| `systematic-debugging` | Bug / 异常行为：先调查再修 |
-| `using-git-worktrees` | 同仓多可写 **并发** 时代理各自独立检出目录；或大重构/并行实验隔离 |
-| `requesting-code-review` | 重大改动或合并请求前发起规范审查 |
-| `receiving-code-review` | 处理审查意见时先核实再改 |
-| `finishing-a-development-branch` | 实现完毕后的合并 / 清理选项 |
-| `verification-before-completion` | 宣称完成、通过 gate、合并前必须有可核对证据 |
-| `writing-skills` | 编写、编辑、验证 Agent 技能文档 |
-
-## `subagent-driven-development` 与上游 `implementer-prompt` / reviewer 模板（重要）
-
-Superpowers 插件内该技能附带 **`implementer-prompt.md`**、**`spec-reviewer-prompt.md`**、**`code-quality-reviewer-prompt.md`** 等模板（部分宿主以 `/implementer-prompt` 等名称暴露）。正文还描述「每任务后 spec 审 + code quality 审」与示例路径 **`docs/superpowers/plans/`**。在本仓库中须按下述方式 **降权为可选技巧**，**不得覆盖 harness**。
-
-- **权威上下文**：实现与审查的 **分支、检出路径、plan、状态机** 以 **`mstar-harness-core`**、**`mstar-plan-conventions`**、**`mstar-review-qc`** 及 **`@project-manager` 的 Assignment** 为准；**不要用上游模板替代 Assignment 结构**（`Execute as` / `Delegation` 写法见 `agents/project-manager.md` §1.3；另含 `Working branch`、`Review cwd` / `Worktree path`、`plan_id`、`Review range` / `Diff basis` 等）。
-- **谁可以派 subagent**：仅 `@project-manager` 可增加或并行 subagent；Assignment 未写 **`Delegation: allowed (...)`** 时，承接方 **不得** 依该技能自行连续派发「implementer / reviewer」子代理（见 **`mstar-dispatch-gates`** SKILL.md「调度防串扰」）。
-- **per-task 双审（spec + code quality）用谁**：这是**任务级、会话内快速自检**，**禁止**把 `@qc-specialist` / `@qc-specialist-2` / `@qc-specialist-3` 当作这两步子代理的承接方——QC 角色绑定 **`mstar-review-qc`** 与 **`{PLAN_DIR}/reports/<plan-id>/`** 正式产出，与「每任务后快速过一遍」冲突，易造成误派与多余文档。**推荐**用 **`@general`**（OpenCode 等宿主内置）或宿主并行 Task 的 **`generalPurpose`** subagent，仅借用上游 `spec-reviewer-prompt` / `code-quality-reviewer-prompt` 的检查思路；回报限本会话内简短结论（要点 / 阻塞项），不写 QC Completion Report、不落 `reports/<plan-id>/`。可选用 **`@qa-engineer`** 做同一类 informal pass（侧重可测性、验收对齐、smoke 建议）时，PM 须在 Assignment 写明 **`Informal per-task review only`**（本轮**不**套用正式 QC/QA 的 `plan_id` + `Review range` 三审门禁、**不向** `reports/` 落盘）；**feature 完成后的正式验证**仍按 harness 另派，字段与 QC 对齐。
-- **正式审查门禁**：**QC 三审 + @qa-engineer 验证** 在 **feature / 整 plan 开发完成后**按默认节奏执行（多 batch 默认不每 batch 全套三审）；上游技能的 **per-task 双 reviewer 子代理** 若使用，**最多视为作者侧或会话内自检**，**不可替代** `{PLAN_DIR}/reports/<plan-id>/` 下按 **`mstar-review-qc`** 产出的 QC 报告，也不得绕过 **`plan_id` / `Review range` 三份逐字相同** 的约定。
-- **完成态**：实现方将工作置 **`InReview`**；**`Done`** 仅 `@project-manager` 或 `@qa-engineer` 设定（`mstar-harness-core`）。上游模板中的「任务完成」**不等于** harness 的 **Done / sign-off**。
-- **并行**：上游技能默认 **不并行多个 implementer**；若 PM 已按 harness 分配 **多写入流** 且 **同仓并发**，则 **必须** **`using-git-worktrees`** + Assignment 检出约定（见 `references/tension-table.md`）。**以 Assignment 与 harness 为准**，不因上游「禁止并行 implementer」而拒绝已批准的并行分派。
-- **计划路径**：一律以 **`{PLAN_DIR}`** 为准，**禁止**把示例 `docs/superpowers/plans/` 当作落盘位置。
-- **澄清**：需要结构化取舍时，**若宿主提供** `question` 类工具则优先（`mstar-harness-core` SKILL.md），与上游「自由提问」可并存；宿主细节以当前宿主的 `mstar-host` skill 为准。
-
-PM 在 Assignment 的 `Superpowers` 中引用 `subagent-driven-development` 时，建议加一行 **Expected evidence** 或备注，标明 *「per-task 子代理审查非正式 gate；承接方用 @general / generalPurpose（或 PM 标明的 informal @qa-engineer），勿用 @qc-specialist；正式 QC/QA 仍按 harness」*，避免承接方把上游流程当作 SSOT 或误派 QC 产正式报告。
-
-## 与内置 `@explore` 的关系（宿主支持时）
-
-- **摸底**：由 `@project-manager` 在分派前调用 `@explore` 并写入 Assignment 为推荐模式；**已分派的承接方**不得用 `@explore` 代做实现/测试/审查/文档等交付，仅可短只读导航（见 `mstar-harness-core` SKILL.md「内置 `@explore` 能力边界」）。Superpowers 不改变路由表。
-- `dispatching-parallel-agents` / `subagent-driven-development` 用于 **PM 拆分子任务** 或 **多代理并行**，与 `@explore` 可并列使用。
-- **`dispatching-parallel-agents` 与 informal 复查**：上游技能是 **多独立域并行 investig/fix** 与 **Review and Integrate**（读各轨摘要、核对是否冲突），**不**附带 `implementer-prompt` 的 **per-task spec + code-quality 双模板**。若 PM/承接方仍给**某一并行轨**加「会话内快速过一遍」子步，**同样禁止**用 **`@qc-specialist*`**，适用 **「per-task 双审（spec + code quality）用谁」** 中的 `@general` / `generalPurpose` / informal `@qa-engineer` 约定；**正式 QC/QA** 仍在 feature / plan 完成后按 harness。
-
-## 快速去歧义规则（建议直接复用到 Assignment）
-
-- `QA mode: report-only` 与 `QA: skipped` 互斥，不能同时出现。
-- `Hotfix` 与 `RCA complete before code changes` 互斥：热修可先最小修复，但必须补"事后 RCA"项。
-- `QC: skipped` 只用于已定义例外（product-docs only / tech-spec only）；否则默认进入 QC 路径。
-- **`Delegation: forbidden`** 与 Superpowers 里的 `subagent-driven-development` **互斥**（除非已 `allowed` 且范围覆盖）——见上文专节。
-- `Working branch` 与 `Branch policy` 只能二选一；两者同写时，以 PM 明确改写为准后再执行。
-- **`QC 三审`**：三份 Assignment 的 **`plan_id`** 与 **`Review range` / `Diff basis`** 必须 **完全一致**（可复制粘贴）；缺一项则 **不得**将 gate 汇总为 `Approve`，须 `Blocked` 后补 Assignment 或补报告（见 `mstar-branch-worktree`）。
-
-## References
-
-- `references/per-role-matrix.md` — 按角色列出的必用/宜用技能矩阵（PM / product-manager / architect / dev 三角 / QA / QC / ops / prompt-engineer / writing-specialist），含每种角色的补充执行约束。
-- `references/tension-table.md` — `mstar-*` 流程与 Superpowers 技能的张力与消解对照表（缺陷与 RCA、热修、完成与证据、Plan 形态、并行开发、`subagent-driven-development` 与 implementer-prompt、TDD、`git worktree` / 多工作目录、升级与重复失败）。

package/harness-skills/mstar-superpowers-align/references/per-role-matrix.md

@@ -1,99 +0,0 @@
-# 按角色的 Superpowers 必用 / 宜用矩阵（Morning Star）
-
-> **Load order（与其它 `mstar-*` skill 一致）**：使用本矩阵前须已 Read **`mstar-harness-core`** skill（SKILL.md）与 **`mstar-superpowers-align`** SKILL.md；矩阵中的「必用」**叠在** harness 门禁之上，不减免 `mstar-harness-core` 中的分支 / worktree / QC 字段要求。
-
-下列"必用"表示：**只要任务落在该列场景，且用户未禁止，即应先加载对应技能再动手**。
-
-## @project-manager（primary）
-
-| 场景 | 技能 |
-|------|------|
-| 必用（协调） | `using-superpowers` |
-| 必用（并行拆分） | `dispatching-parallel-agents`（**仅当** ≥2 条实现轨**同时**并行；**不含**「串行交替 `fullstack-dev` / `fullstack-dev-2`」——见 `project-manager.md` Dev 三角 §6）；叠用下项；会话内**由 PM 顺序**多代理时用 `subagent-driven-development`（**勿**顶替并行轨；**勿**与默认 `Delegation: forbidden` 同条 Superpowers — 见 SKILL.md「Delegation 与 Superpowers 清单一致」） |
-| 必用（同仓多可写并发） | **`using-git-worktrees`**（仅当与上项同时成立且 ≥2 可写流改**同一仓库**时叠用）：禁止共用同一 cwd 检出；Assignment 须含各流 **`Working branch`** + **worktree/检出约定** |
-| 必用（书面计划跨会话） | `executing-plans`（当存在书面实现计划且约定下次继续时） |
-| 必用（登记/拆 plan） | `writing-plans`（非平凡任务、多阶段交付） |
-| 必用（收口） | `verification-before-completion`（汇总 Done、sign-off、merge 前须有 QA/命令证据）；`finishing-a-development-branch`（分支收尾策略） |
-| 宜（意图不清） | 推动或分派前由相关角色做 `brainstorming`（PM 可直接与用户澄清，或分派 @product-manager / @architect） |
-
-**补充执行约束（PM）**：
-
-- 当任务是 **Bug/异常**，若 Assignment 的 `Superpowers` 未出现 `systematic-debugging`（且非 Hotfix），视为分派不完整。
-- 当任务进入 **gate / sign-off / merge decision**，若未出现 `verification-before-completion` 或等价证据要求，视为门禁不完整。
-- 当任务声明 **并行分派**，`Superpowers` 中应显式包含 `dispatching-parallel-agents`（或同义触发短语），并为每个可写承接方写清 `Working branch`。
-- 当 **并行分派** 且 **≥2 个可写承接方** 针对 **同一 Git 仓库** 可能并发落盘时，`Superpowers` 中还 **必须** 显式包含 **`using-git-worktrees`**（或同义触发短语），并在 Assignment 中写清各流 **检出路径约定**（或要求 Completion Report 回报实际 worktree 路径）；**禁止**依赖「多 subagent 共享同一工作目录」完成并发写入。
-- **QC 三审**：三份 Assignment 除 `Review cwd`、`Working branch` 外，**必须**含 **相同**的 **`plan_id`** 与 **`Review range` / `Diff basis`**（可复制粘贴）；**@qa-engineer** 同 feature 验证时 **照抄**同一组字符串。缺任一项视为 PM 分派不完整（`mstar-branch-worktree`）。**同仓、同一 plan、多 worktree 并行**：PM **推荐**先建 **plan 集成分支** 再挂各轨 worktree，QC 前再归并到单一 `HEAD`。**同一 plan 多 batch**：**默认仅在整 plan dev 完成后**派一轮完整三审。**Fix 后**：默认 **targeted re-review**（只派提出 blocking 的 QC 席，原位改 `qcN.md`）；**仅** `QC re-review: full tri-review` 时复跑三审且 `qcN-rev2.md` — 见 `mstar-plan-artifacts/references/plan-files-and-reports.md`。
-
-## @product-manager
-
-| 场景 | 技能 |
-|------|------|
-| 必用 | `brainstorming`（新产品/大范围需求澄清） |
-| 必用（与同仓其他可写 subagent 并发落盘项目仓库时） | `using-git-worktrees`（独立 worktree + Assignment 已批准分支；见 **`mstar-branch-worktree`**） |
-| 宜用 | `writing-plans`（把 PRD/验收拆成可执行里程碑，与 `mstar-plan-conventions` 对齐） |
-
-## @architect
-
-| 场景 | 技能 |
-|------|------|
-| 必用 | `brainstorming`（重大架构取舍、多方案比选） |
-| 必用（与同仓其他可写 subagent 并发落盘项目仓库时） | `using-git-worktrees`（见 **`mstar-branch-worktree`**） |
-| 宜用 | `writing-plans`（技术方案、迁移、分阶段落地计划） |
-
-## @fullstack-dev / @fullstack-dev-2 / @frontend-dev
-
-| 场景 | 技能 |
-|------|------|
-| 必用（缺陷） | `systematic-debugging` |
-| 宜用（功能/修复） | `test-driven-development`（项目允许 TDD 时） |
-| 必用（合并/宣称开发完成） | `verification-before-completion` |
-| 宜用（重大变更） | `requesting-code-review`（与 QC 三审互补：作者侧自检与说明） |
-| 宜用（按 QC 改代码） | `receiving-code-review` |
-| 必用（与同仓其他可写 subagent 并发执行时） | `using-git-worktrees` |
-| 宜用（仅单写入者时的隔离大重构/实验分支） | `using-git-worktrees` |
-
-## @qa-engineer
-
-| 场景 | 技能 |
-|------|------|
-| 必用 | `verification-before-completion`（报告通过/阻塞、Done sign-off 前须有可复现命令与输出） |
-| 必用（验证 feature / 跑业务仓测试或提交测试工件时） | 在 PM 写明的 **`Review cwd` / `Worktree path`**、**`Working branch`**、**`plan_id`**、**`Review range` / `Diff basis`** 下执行（与 QC **逐字相同**）；先核对路径、分支与审查范围（见 `mstar-branch-worktree`「QC 三审、QA 验证与 feature 检出上下文」） |
-| 必用（与同仓其他可写 subagent 并发写仓库时） | `using-git-worktrees` |
-| 宜用 | `using-git-worktrees`（需与既有目录分离、但在**同一 `Working branch`** 上另开检出专供 QA 写入时） |
-| 宜用 | `systematic-debugging`（flaky、环境、不可稳定复现） |
-| 宜用 | `test-driven-development`（先定义失败用例再补实现协作时） |
-
-## @qc-specialist / @qc-specialist-2 / @qc-specialist-3
-
-| 场景 | 技能 |
-|------|------|
-| 必用 | `verification-before-completion`（审查结论须指向证据：diff、lint、日志） |
-| 必用（审查 feature 实现时） | 在 PM 写明的 **`Review cwd` / `Worktree path`**、**`Working branch`**、**`plan_id`**、**`Review range` / `Diff basis`** 下执行审查（**`plan_id` 与 `Review range` 三份 QC Assignment 须一致**）；先核对再按 **`Review range` / `Diff basis`** 跑 diff/lint（见 `mstar-branch-worktree`、`mstar-review-qc`） |
-| 宜用 | `using-git-worktrees`（需与开发目录分离、但在**同一待审分支**上另开检出专供审查时） |
-| 宜用 | `systematic-debugging`（对"疑似缺陷但证据不足"的条目追根） |
-
-## @ops-engineer
-
-| 场景 | 技能 |
-|------|------|
-| 必用 | `verification-before-completion`（部署/变更验证命令与结果） |
-| 必用（与同仓其他可写 subagent 并发改仓库时） | `using-git-worktrees` |
-| 宜用 | `systematic-debugging`（流水线失败、线上异常） |
-| 宜用 | `finishing-a-development-branch`（发布与分支/tag 策略收口） |
-
-## @writing-specialist
-
-| 场景 | 技能 |
-|------|------|
-| 必用 | `brainstorming`（任务目标与风格未锁定时先澄清） |
-| 必用（与同仓其他可写 subagent 并发落盘项目仓库时） | `using-git-worktrees` |
-| 宜用 | `writing-plans`（将长篇写作拆分为可验收里程碑） |
-
-## @prompt-engineer
-
-| 场景 | 技能 |
-|------|------|
-| 必用 | `writing-skills`（新建/大改技能时） |
-| 宜用 | `brainstorming`（新行为、新触发条件设计） |
-| 必用（与同仓其他可写 subagent 并发落盘项目仓库时） | `using-git-worktrees` |
-| 必用 | `verification-before-completion`（宣称技能可用、eval 通过前） |

package/harness-skills/mstar-superpowers-align/references/tension-table.md

@@ -1,19 +0,0 @@
-# Morning Star × Superpowers：张力与消解表
-
-> **Load order（与其它 `mstar-*` skill 一致）**：使用本表前须已 Read **`mstar-harness-core`** skill（SKILL.md）；本表是 harness 与 Superpowers 的**对照索引**，不替代 harness 全文。
-
-下列对照用于避免「harness 一套、Superpowers 一套」在执行时打架。**若仍不可裁决**：**用户显式指令** > **项目级 `AGENTS.md` / `CLAUDE.md`** > **`mstar-*` skills 中的不变量（以 `mstar-harness-core` 为权威：状态机、门禁、路由）** > **Superpowers 技能的默认做法**。
-
-| 主题 | Morning Star 约定 | Superpowers 相关技能 | 结论 |
-|------|------------------|---------------------|------|
-| 缺陷与 RCA | `mstar-harness-core`：非热修在进入**实质性代码修改**前须有可检验**根因结论或带证据的假设** | `systematic-debugging` | **一致**：技能是 RCA 门禁下的**调查方法**；承接方交付仍须满足 harness 的 RCA/证据要求。 |
-| 热修 | 热修以恢复服务为先，可事后补 RCA；Assignment 须标明 Hotfix / `Branch policy` | `systematic-debugging` 可能强调「查透再改」 | **消解**：热修路径以 **Assignment + `mstar-harness-core`** 为准；技能用于**最小变更**与**事后根因**，不要求在长调查完成前强行停改。 |
-| 完成与证据 | `mstar-harness-core` 反模式：无测试或行为证据即宣称完成 | `verification-before-completion` | **一致**：表述不同，目标相同（gate 前可核对证据）。 |
-| Plan 形态 | `mstar-plan-conventions`：**`{PLAN_DIR}`**、**`{HARNESS_DIR}/status.json`**（open residual）、**`{HARNESS_DIR}/archived/residuals/<plan-id>.json`**、`{PLAN_DIR}/reports/<plan-id>/` | `writing-plans` | **互补**：convention 管**存放位置与结构**；writing-plans 管**多步任务如何写成可执行计划**；PM 维护时两者同时满足。**路径门限**：提示词 + `mstar-plan-conventions` 约束 **`{PLAN_DIR}`** 优先于技能默认的 `docs/superpowers/plans/`（无本地同名技能覆盖）。 |
-| 并行开发 | `mstar-harness-core`：独立模块可并行；**先锁接口契约**再并行编码；**同仓多可写并发须 `git worktree` 隔离检出目录** | `dispatching-parallel-agents`、`subagent-driven-development`、**`using-git-worktrees`**（同仓并发写入时） | **叠加约束**：并行**不免除** `mstar-branch-worktree` 分支门禁——每个**可写**承接方 Assignment 仍须含 PM 批准的 **`Working branch`** / **`Branch policy`**，禁止多人各自假设 base；**且** ≥2 可写流同仓并发时 **禁止**共用同一 cwd，**必须** worktree（或等价独立检出）+ Assignment 写明检出约定。 |
-| `subagent-driven-development` 与 `implementer-prompt` | **PM Assignment**、具名角色 **`Execute as: role-id`**（无 `@`）、仅 PM 可派 subagent；QC 三审 + QA 在 feature / plan 完成后，**`plan_id` + `Review range` 三审与 QA 逐字对齐**；**`{PLAN_DIR}`**；**`InReview` / `Done` 权限** | 上游：**每任务**后 **spec + code-quality 子代理审**；**泛化 implementer** 模板；示例 **`docs/superpowers/plans/`**；默认不并行多个 implementer | **以 harness 为准**：上游模板与 per-task 双审**不替代** Assignment 与 **QC/`mstar-review-qc`**；per-task 双审用 **`@general` / `generalPurpose` 或 informal `@qa-engineer`**，**勿**用 **`@qc-specialist*`**；per-task 审查**仅可作非正式自检**（若 PM 未另授权 `Delegation`）；并行以 **PM + worktree** 为准。细则见 SKILL.md **「`subagent-driven-development` 与上游 implementer-prompt / reviewer 模板」**。 |
-| TDD | 全局流程**未**强制 TDD | `test-driven-development` | **项目/用户优先**：项目或用户禁止 TDD 时，不得因技能强行 TDD。 |
-| `git worktree` / 多工作目录 | `mstar-branch-worktree`：**开发**阶段同仓多可写 **并发**须独立 worktree；**QC / QA** 须在 **该 feature 的检出上下文**（通常 `Review cwd` = 开发所用 worktree，或同分支另开检出）上审查与验证，且 **三份 QC + QA** 共用 **`plan_id`** 与 **`Review range` / `Diff basis`**（逐字相同）；仅 `@project-manager` 决定分支策略、`Assignment` 须写明 **`Working branch`** / **`Branch policy`** 与 **检出路径约定**（含 **`Review cwd` / `Worktree path`**） | `using-git-worktrees` | **不冲突，但须叠同一门禁**：worktree 是「同一仓库多个检出目录」；**分支授权**仍须与 PM 一致。开发并发写入若不用 worktree 易导致互相覆盖；QC/QA 若错用 cwd/分支/**diff 范围**会审错、验错对象——见 `mstar-branch-worktree` **「QC 三审、QA 验证与 feature 检出上下文」**。若在 worktree 里擅自 `checkout -b` 或未授权切换分支，即违规。 |
-| 升级与重复失败 | `mstar-harness-core` skill：多次失败升级人工等 | `systematic-debugging`、`verification-before-completion` | **一致**：技能减少「无根因重复改」；**达不到 harness 升级条件**时仍以文档为准。 |
-
-**小结**：Superpowers 主要填充各阶段**如何做**的细节；**阶段顺序、Done 权限、QC/QA 路由、分支唯一决策人**仍以 `mstar-*` skills 与 `@project-manager` 路由表为准。