@mstar-harness/omp 3.6.0-alpha.4

package/skills/mstar-sdd/references/implementer-continuation-prompt.md

@@ -0,0 +1,44 @@
+# Implementer continuation prompt (sticky session)
+
+Use when PM continues **`SDD implementer session: sticky`** for Task N>1. Host: **resume** same agent when supported (`sticky-implementer-session.md`).
+
+```
+Dispatch:
+  Resume: [HOST_AGENT_ID from implementer-session.json]
+  Name: <CamelCaseId>                 # omp/Cursor name
+  Model: [same tier as session start unless PM upgrades]
+  Prompt body:
+    <SUBAGENT-STOP> Skip PM orchestration skills. You are a leaf implementer continuing a sticky SDD session.</SUBAGENT-STOP>
+
+    Continue as the same implementer on plan <plan-id>, Working branch: <branch>.
+
+    ## Completed (do not redo)
+
+    Read: [SDD_DIR]/progress.md and [SDD_DIR]/implementer-session.json
+
+    ## This task
+
+    Task N: <name>
+
+    Read first — your spec (verbatim): [BRIEF_FILE]
+
+    ## Context not in the brief
+
+    [Interfaces from earlier tasks only if not already in your session]
+
+    ## Report file
+
+    Write your full report to: [REPORT_FILE]
+
+    ## Your job
+
+    1. Implement exactly what this brief specifies (prior tasks are done)
+    2. Run tests; commit on Working branch
+    3. Write report file; return short summary only
+
+    ## When stuck
+
+    Report BLOCKED or NEEDS_CONTEXT — PM may reset session to fresh.
+```
+
+First task on a plan uses **`implementer-prompt.md`** (not this file).

package/skills/mstar-sdd/references/implementer-prompt.md

@@ -0,0 +1,56 @@
+# Implementer subagent prompt template
+
+Use when PM dispatches an SDD implementer (`mstar-sdd`) — **first task** or **`SDD implementer session: fresh`**.
+
+For **sticky** continuation (task 2+), use **`implementer-continuation-prompt.md`** instead.
+
+```
+Dispatch:
+  Role: <Execute as role-id>          # omp agent / Cursor subagent_type / OpenCode subagent → mstar-host C5
+  Name: <CamelCaseId>                 # omp/Cursor name
+  Model: [REQUIRED — per Model tier in Assignment and mstar-sdd SKILL]
+  Prompt body:
+    <SUBAGENT-STOP> Skip PM orchestration skills. You are a leaf implementer.</SUBAGENT-STOP>
+
+    You are implementing Task N: <name>
+
+    ## Scene
+
+    [One line: where this task fits in the plan]
+
+    ## Requirements
+
+    Read first — this is your spec (verbatim values): [BRIEF_FILE]
+
+    ## Context not in the brief
+
+    [Interfaces from earlier tasks, PM resolutions]
+
+    ## Report file
+
+    Write your full report to: [REPORT_FILE]
+
+    ## Before you begin
+
+    Ask questions now about requirements, approach, or dependencies.
+
+    ## Your job
+
+    1. Implement exactly what the brief specifies
+    2. Run tests (TDD if brief requires)
+    3. Commit on Working branch
+    4. Self-review
+    5. Write report file; return short summary only
+
+    ## When stuck
+
+    Report BLOCKED or NEEDS_CONTEXT — never guess.
+
+    ## Report format (in file)
+
+    - Status: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
+    - Implemented / attempted
+    - Tests: command, output, red/green evidence if TDD
+    - Files changed
+    - Self-review notes
+```

package/skills/mstar-sdd/references/sticky-implementer-session.md

@@ -0,0 +1,103 @@
+# Sticky implementer session (SDD token optimization)
+
+Reuse the **same implementer subagent** across multiple tasks in one plan when tasks are tightly coupled, same `Execute as` role, and same `Working branch`. **L2 task reviewers stay fresh per task** — do not sticky reviewers.
+
+SSOT for mode selection and host resume → this file. Per-task artifacts → **`file-handoffs.md`**.
+
+## When to use
+
+| `SDD implementer session` | Use |
+|---------------------------|-----|
+| **`fresh`** (default) | Independent tasks, module boundaries, different dev tracks, or first task on a plan |
+| **`sticky`** | Same `fullstack-dev` (or same role id), sequential tasks on one branch, strong file/context continuity (e.g. T3+T4 daemon stderr + DB reset) |
+
+**Prefer `sticky`** on iteration Phase 2 Autonomous Execute when PM will dispatch many tasks to the same dev on one plan feature branch.
+
+## Assignment fields (implement dispatch)
+
+```markdown
+**Execution mode**: sdd
+**SDD implementer session**: sticky | fresh
+**SDD dir**: `{HARNESS_DIR}/sdd/<plan-id>/`
+**Model tier**: standard
+**Execute as**: fullstack-dev
+**Working branch**: <branch>
+**Covers task**: N | N–M   # single task id for this dispatch turn
+```
+
+- **Task 1** (or first task after `fresh` reset): `SDD implementer session: fresh` or `sticky` (starts sticky ledger).
+- **Task 2+** with sticky: `SDD implementer session: sticky` + host **resume** (Cursor) or continuation prompt (fallback).
+
+## Session ledger: `implementer-session.json`
+
+PM writes/updates at `{SDD_DIR}/implementer-session.json` when starting or continuing sticky mode:
+
+```json
+{
+  "plan_id": "<plan-id>",
+  "execute_as": "fullstack-dev",
+  "session_mode": "sticky",
+  "host": "cursor",
+  "host_agent_id": "<agent-id from first Task return — required for resume>",
+  "working_branch": "feature/...",
+  "started_task": 1,
+  "last_task": 1,
+  "started_at": "2026-07-07T00:00:00Z"
+}
+```
+
+After each completed task review, PM sets `last_task` to N. **Do not** resume if `host_agent_id` is missing — fall back to `fresh` for that task.
+
+## Per-task loop (sticky implementer)
+
+Same as default SDD for artifacts and L2 review; only implementer dispatch differs:
+
+1. `mstar sdd task-brief` → `{SDD_DIR}/task-N-brief.md`
+2. Record `BASE_SHA`
+3. **Implementer dispatch**
+   - **First task** (`fresh` or sticky start): normal Task/subagent invoke → save `host_agent_id` to ledger
+   - **Next tasks** (`sticky`): host **resume** with same `host_agent_id` + continuation prompt (`implementer-prompt.md` § Continuation)
+4. On `DONE` → `mstar sdd review-package` → **fresh** task reviewer (never resume reviewer)
+5. Append `progress.md`; update ledger `last_task`
+6. Next task
+
+**Still required per task:** commit, `task-N-report.md`, task-level diff, task reviewer, `progress.md` line.
+
+## When to reset to `fresh`
+
+Start a **new** implementer session (`session_mode: fresh` or new ledger) when any:
+
+- `BLOCKED` / `NEEDS_CONTEXT` not resolved in one continuation turn
+- `Execute as` role changes (`fullstack-dev` → `fullstack-dev-2`)
+- `Working branch` changes
+- Host does not support resume (OpenCode without resume → use **micro-batch** or `fresh`)
+- Context clearly degraded (implementer confuses prior tasks) — PM judgment
+- Switching from another dev track mid-plan
+
+Delete or archive `implementer-session.json` when resetting.
+
+## Micro-batch fallback (no host resume)
+
+When resume is unavailable, PM may dispatch **one** implementer for **2–3** tightly coupled tasks:
+
+- Prompt lists `task-N-brief.md` … `task-M-brief.md` and matching report paths only
+- Implementer completes tasks **in order** in one session
+- PM still runs **per-task** `review-package` + **fresh** task reviewer after each task (or after batch if PM documents per-task SHAs in Assignment)
+
+Max **3** tasks per micro-batch without user override. See `project-manager.md` batch sizing.
+
+## Host mapping
+
+| Host | Sticky implementer |
+|------|-------------------|
+| **Cursor** | `Task` with `resume: <host_agent_id>` — **`mstar-host/references/cursor.md`** § SDD sticky |
+| **OpenCode** | Resume only if task tool supports it; else micro-batch or `fresh` per task |
+| **Codex** | Thread resume only when callable multi-agent tool documents agent id; else micro-batch or `fresh` |
+
+## PM NEVER (sticky)
+
+- Resume task **reviewer** sessions — reviewers stay fresh per task
+- Parallel sticky implementers on the same branch
+- Resume without updating `implementer-session.json` / `progress.md`
+- Skip per-task review because implementer "remembers" prior tasks
+- Paste full plan into continuation prompt — only new brief path + report path

package/skills/mstar-sdd/references/task-reviewer-prompt.md

@@ -0,0 +1,53 @@
+# Task reviewer subagent prompt template
+
+One reviewer per task: spec compliance + code quality (`mstar-sdd`).
+
+```
+Dispatch:
+  Role: code-reviewer                 # L2 SDD task reviewer; NOT qc-specialist*
+                                      # omp: agent = "code-reviewer" (when listed) or "reviewer"/"task" + C5b; Cursor: subagent_type = "generalPurpose" fallback → mstar-host C5
+  Name: <CamelCaseId>                 # omp/Cursor name
+  Model: [REQUIRED — standard tier default; capable if diff is large/subtle]
+  Prompt body:
+    <SUBAGENT-STOP> Skip PM orchestration. Read-only review.</SUBAGENT-STOP>
+
+    Review one task implementation: spec compliance first, then quality.
+    Task-scoped gate — plan-level QC comes later on the whole branch.
+
+    ## What was requested
+
+    Brief: [BRIEF_FILE]
+
+    Global constraints (verbatim):
+    [GLOBAL_CONSTRAINTS]
+
+    ## Implementer report
+
+    [REPORT_FILE] — treat claims as unverified until checked against diff.
+
+    ## Diff
+
+    Base: [BASE_SHA]
+    Head: [HEAD_SHA]
+    Diff file: [DIFF_FILE]
+
+    Read the diff file once. Do not re-run git. Do not mutate checkout.
+    Do not re-run full test suite — trust implementer evidence unless a
+    specific doubt needs one focused test.
+
+    ## Output
+
+    ### Spec Compliance
+    - ✅ Spec compliant | ❌ Issues found (file:line)
+    - ⚠️ Cannot verify from diff: [items for PM to check]
+
+    ### Strengths
+
+    ### Issues
+    #### Critical | Important | Minor
+
+    ### Assessment
+    **Task quality:** Approved | Needs fixes
+```
+
+Re-review after fixes covers both verdicts. PM resolves all ⚠️ items before marking task complete.

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

@@ -0,0 +1,182 @@
+---
+name: mstar-skill-authoring
+description: Agent skill 撰写 / 重写 / 优化规范（SkillsBench 实验门控）。在新建任意 skill、大改 SKILL.md、改写 description 触发契约、压缩过长 body、评审 skill 结构、或判断某段行为塑形文案是否值得保留时读取。适用于任何领域的 skill，不限于本仓库专题；不用于普通应用实现。
+---
+
+# Skill Authoring
+
+本 skill 约束如何编写、审查与验证 **任意** agent skill（`SKILL.md`）。面向 **skill 工作**，不是普通应用实现。
+
+## Load Order
+
+在本 harness 仓库内工作时：先 Read **`mstar-harness-core`**（加载 / 冲突裁决）；仓库维护另遵根目录 `AGENTS.md`。
+
+在其它仓库 / 宿主上使用本 skill 时：按当地入口文档加载；本文件的原则与门控仍然适用。
+
+改现有 skill 时：读完被改 skill 及其 SSOT 引用；禁止仅为文风重写相邻 skill。
+
+详细 writer 流程与输出模板 → `references/skillsbench-authoring.md`（需要完整循环时再读）。
+
+## Workflow
+
+主链：按「Frontmatter Contract」先定触发契约（原则 3）→ 按「Body 必须回答的 5 问」写默认紧凑 body（原则 2）→ 变体细节按「Progressive Disclosure」进 `references/` / `templates/` / `scripts/` → 行为塑形改动按「验证门控（Evidence，原则 4 + 6）」留 paired 证据 → 按「Review Template」自审并完成「完成时主动说明」三问。
+
+## 6 条作者原则（Decision Rules，必须遵守）
+
+来源：SkillsBench 大规模实验。违反任一都会降低 agent 性能。
+
+| # | 原则 | 强制动作 |
+|---|------|----------|
+| 1 | **专家流程优先** | 先提取真实操作步骤、决策标准、约束、API 坑与失败恢复；模型只做编辑器。禁止把一键生成稿当最终版。 |
+| 2 | **紧凑程序性** | body 只答 5 问（见下）；详例 / 长文档进 `references/`，按需加载。过长 body 几乎无提升甚至负提升。 |
+| 3 | **路由最小化** | 任务真正需要时才加载；目标 **1–3** 个 skill。description 必须具体到可精准匹配，避免无关激活。 |
+| 4 | **按 model+harness 实测** | 文件可移植 ≠ 行为可移植。在实际使用的模型与宿主（omp / Cursor / Codex / Claude Code 等）分别验证触发、执行、token、回归。 |
+| 5 | **只补模型缺口** | 编码内部约定、受监管流程、脆弱 API、专业判断、反复失败模式。不写模型已会的通用知识。 |
+| 6 | **每次改动=受控实验** | 必须有 paired 证据（with vs without，或 before/after + 可观察标准）。held-out / 压力场景未提升则拒绝合入。禁止“感觉更好”。 |
+
+## Body 必须回答的 5 问
+
+合格 `SKILL.md` **只**清晰回答：
+
+1. **何时加载？**（触发 / 排除）
+2. **按什么顺序与关键决策点执行？**
+3. **哪些约束 / 不变量绝不可违反？**
+4. **正确结果长什么样？**（成功标准 / 证据）
+5. **主路径不够时打开哪些额外资源？**
+
+答不进这 5 问的内容 → 删或移到 `references/`。
+
+### 运行时别名（runtime alias map）
+
+已发布的 `mstar-*` 专题 skill 允许**运行时模式**（`lintFiveQuestion(body, "runtime")`）用**锁定别名表**回答同一问题（引擎常量 `RUNTIME_HEADING_ALIASES`）：
+
+| 问题 | 运行时别名（标题子串，大小写不敏感） |
+|------|------|
+| Workflow | `process`、`playbook` |
+| Decision Rules | `hard rules`、`core rules`、`rule`、`gate`、`not to do`、`red flags`、`反模式`、`红线`、`规则`、`门禁` |
+| Evidence | `output format`、`证据` |
+| References | `dependencies`、`关系` |
+
+- 别名表是**锁定表**：改表必须同步引擎回归测试与 corpus。
+- **新写 / greenfield skill（authoring / strict）仍要求 canonical 标题**；运行时别名只豁免已发布专题 skill 的机械 lint，**不豁免语义**——别名标题必须真实回答对应问题，正文不得因别名而缩水。
+
+## Skill Purpose Test
+
+仅当全部成立才新建 / 扩写 skill：
+
+1. 行为应跨多项目、角色或任务复用。
+2. 需要判断或排序，且不宜用代码强制。
+3. 现有 skill 树尚未拥有同一规则（避免副本）。
+4. 触发条件可写清，agent 知道何时读取。
+
+不要为这些建 skill：一次性项目约定（放项目 `AGENTS.md` / 等价处）、可 lint/脚本化的机械规则、无复用手法的事故叙述、已有 skill 规则的副本。
+
+## Frontmatter Contract
+
+```yaml
+---
+name: example-skill
+description: Use when...
+---
+```
+
+- `name`：稳定、小写、连字符。
+- `description`：**触发契约**，不是流程摘要。写清症状、上下文、角色、产物与排除条件。
+- 第三人称；足够具体以避免无关加载（原则 3）。
+- 禁止在 description 里总结整条 workflow（否则 agent 可能只跟摘要、跳过 body）。
+
+Bad：`Explains how to write plans with steps, tests, commits, and review gates.`  
+Better：`Use when a non-trivial task has a spec or requirements and needs a written implementation plan before code changes.`
+
+> **Engine check (when available):** run `mstar skill lint <skill-dir>` (or `import { lintFrontmatter, lintFiveQuestion } from "@mstar-harness/engine"` in a host hook) to lint the frontmatter contract and the five-question body contract above. On `fail` -> do not proceed; fix and re-run. Skill text below remains authoritative when the runtime is absent.
+
+## 默认 Body 结构
+
+```markdown
+# Skill Title
+
+## Load Order
+## Scope
+## Workflow
+## Decision Rules
+## Evidence
+## References
+```
+
+Keep `SKILL.md` focused on the main execution path. Move long examples, templates, schemas, and detailed variants into `references/`, `templates/`, or `scripts/`.
+
+## Skill-relative script and asset paths
+
+When a skill ships executables or assets under `scripts/` / `templates/` / `references/`, name them as **skill → relative path**：
+
+- Good: skill **`my-skill`** → `scripts/do-thing`
+- Good: `<my-skill>/scripts/do-thing`（已加载 skill 根的占位写法）
+- Bad：把 `skills/my-skill/scripts/do-thing` 写成消费仓库 cwd 下的字面路径
+
+Agents 按 **skill 名** 发现 skill；文档若给出完整仓内相对路径，agent 常在应用仓库 cwd 下按字面搜索而找不到。先解析已加载 skill 根目录，再拼 `scripts/…` / `references/…`。
+
+在本 harness：解析方式见 **`mstar-host`** § Resolve loaded skill root（omp `skill://`、各宿主插件挂载等）。其它环境按当地 skill 安装约定解析。
+
+> **Engine check (when available):** import `resolveAssetPath` from `@mstar-harness/engine` in a host hook to resolve a skill-relative asset per the convention above (no CLI form yet). On `fail` -> do not proceed; fix and re-run. Skill text below remains authoritative when the runtime is absent.
+
+## Progressive Disclosure
+
+1. Frontmatter：仅触发  
+2. `SKILL.md`：主执行路径  
+3. `references/` / `templates/` / `scripts/`：变体细节，按需加载  
+
+多宿主 / 多域细节按文件拆分，并在 body 写明「何时打开哪份」。
+
+## 验证门控（Evidence，原则 4 + 6）
+
+行为塑形改动必须留下证据，任选可观测形式：
+
+- 2–3 个压力 prompt（无 skill 易失败；有 skill 应通过）
+- before/after 期望 + 触发短语 + 一次具体校验（检索、链接、dry-run）
+- 记录失败原因、token / 延迟回归；未提升则回滚文案
+
+压力场景骨架：
+
+```json
+{
+  "skill_name": "example-skill",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "会诱使 agent 违反目标规则的真实任务",
+      "expected_output": "合规行为长什么样",
+      "files": []
+    }
+  ]
+}
+```
+
+## 完成时主动说明
+
+写完 / 大改 skill 后必须交代：
+
+1. **删了 / 压了什么**，以及如何满足原则 2 与 5  
+2. **如何验证原则 6**（paired 证据或压力场景）  
+3. **触发契约**是否仍足够窄（原则 3）
+
+## Review Template
+
+```markdown
+## Skill Review
+- Trigger contract:
+- 5 questions covered:
+- Principles 2/5 compactness:
+- SSOT alignment:
+- Progressive disclosure:
+- Evidence for behavior change (P6):
+- Stale references checked:
+- Verdict: Approve | Request Changes | Needs Discussion | Unconfirmed
+- Unconfirmed: paired evidence (P6) cannot be established or verified
+```
+
+## References
+
+| 何时 | 打开 |
+|------|------|
+| 需要完整 skill-writer 流程、原则细则、输出模板 | `references/skillsbench-authoring.md` |
+| 需要把「真实产物」固化为可重跑断言（P6 重武器选项） | `references/regression-fixation.md` |

package/skills/mstar-skill-authoring/references/regression-fixation.md

@@ -0,0 +1,46 @@
+# 回归固化参考（Regression Fixation Reference）
+
+行为塑形改动（skill 正文流程、命令序列、CLI 行为面）的 paired evidence 武器库之一（P6 **重武器选项**）。默认证据仍是 SKILL.md「验证门控」的 P6 before/after + 应用案例；仅当行为可脚本化、且该行为面值得长期固化时，用本手法。
+
+## 何时用（When）
+
+- 行为面有**可执行产物**：skill 正文里的流程脚本 / 命令序列 / CLI 调用链。
+- 该面曾出过行为 bug，或改动触碰宿主边界（解析、打包、路径解析、子进程执行）。
+- 例外：纯文案 / 无可观测行为的规则微调 → 走默认 P6，不加载本参考。
+
+## 手法（Technique）
+
+1. **真实产物当被测对象（real artifact as test subject）**
+   不 import 源码、不 mock 掉被测面本身——直接运行用户/agent 实际触达的产物（built bundle、命令序列、宿主钩子驱动的完整流程）。产物侧跑通，才能覆盖「源码 import 跑不到」的缺陷面（bundle 解码、产物路径解析、子进程环境）。
+   → 本仓实例：`packages/cli/test/bundle-smoke.test.ts`（2026-08-16 落地）对 **built bundle** `dist/mstar-harness.js` 子进程执行 `dispatch validate` 并断言 exit code，而非 import `src/index.ts`。
+
+2. **Mock 宿主钩子（mock host hooks）**
+   把宿主边界替换为受控桩：mstar 面对应 dispatch / file IO / CLI 调用。固定输入（fixture 文件、argv、环境变量），断言行为输出（exit code、stdout/stderr、副作用文件）。钩子命名沿用宿主自身词汇，不引入外部系统 hook 名。
+
+3. **双路径断言一致（dual-path assertion）**
+   同一断言集对两条路径各跑一遍并断言一致：**真实模块路径**（import 产物 / 源码）与**被测路径**（vm 求值真实脚本 / 子进程 bundle）。任一路径偏离 → 立即暴露「实现与产物行为漂移」。
+
+4. **修复固化（fix solidification）**
+   行为 bug 修复流程：先写复现用例见 FAIL → 修 → 用例见 PASS → 进回归集。此后每次改动重跑回归集，同类 bug 不再复发（回归集随修复轮增长）。
+
+## 最小骨架（Skeleton，零外部依赖）
+
+```js
+// node:test + vm：求值「真实脚本文本」，不复制逻辑到测试
+import test from "node:test";
+import vm from "node:vm";
+
+const script = readFileSync("flow.js", "utf8"); // 真实产物
+const sandbox = { dispatch: mockDispatch, fileIO: mockFileIO }; // mock 宿主钩子
+vm.runInNewContext(script, sandbox);             // 被测路径
+assert.deepEqual(sandbox.events, expected);      // 断言行为输出
+// 双路径：同一断言集对真实模块路径再跑一遍，assert 一致
+```
+
+bun test 同理：`Bun.spawnSync` 子进程跑 bundle + `expect` 断言（见本仓 bundle-smoke 实例）。
+
+## 边界（Boundaries）
+
+- **零外部依赖**：Node 内置 `vm` / `node:test`（或 bun test）即可，不引入第三方测试框架。
+- **不强制**：默认仍是 P6 before/after + 应用案例；本参考是重武器选项。
+- **只固化可观测行为**：模型判断、触发精确性等不可脚本化断言的面，仍走压力场景（SKILL.md「验证门控」）。

package/skills/mstar-skill-authoring/references/skillsbench-authoring.md

@@ -0,0 +1,154 @@
+# SkillsBench Skill-Writer Reference
+
+Load this only when creating, rewriting, or optimizing a `SKILL.md` and you need the full writer loop. Runtime agents following an already-good skill should not need this file.
+
+## Role
+
+You are a strict AI Agent Skill engineer. When drafting, rewriting, or optimizing **any** `SKILL.md` (any domain, any repo), obey all six principles below. Any violation lowers agent performance.
+
+## Six Principles (refined)
+
+### 1. Start from real expert process, not model improvisation
+
+- Extract the domain expert’s real steps, decision criteria, constraints, API pitfalls, and failure-recovery paths first.
+- Treat the model as editor / implementer only.
+- Accept candidate edits only after an evaluation gate (held-out prompts, pressure scenarios, or concrete before/after checks).
+- Never ship a one-shot model-generated skill as the final version.
+
+### 2. Keep the skill compact and procedural
+
+`SKILL.md` body must stay short. Prefer compact / standard length; long docs rarely help and often hurt.
+
+The body must answer **only** these five questions:
+
+| # | Question | Typical section |
+|---|----------|-----------------|
+| a | When should this skill load? | description + Scope |
+| b | In what order, with which decision points? | Workflow / Decision Rules |
+| c | Which constraints / invariants must never be violated? | Scope / hard rules |
+| d | What does correct look like? | Evidence / success criteria |
+| e | Which extra resources to open when the main path is not enough? | References |
+
+Use progressive disclosure: core path in body; examples, long tables, host variants, schemas → `references/` and load on demand.
+
+Delete or relocate anything that does not serve a–e.
+
+### 3. Load only the 1–3 skills the task truly needs
+
+- Minimize routing. More than ~3 skills dilutes context and lowers pass rate.
+- Write descriptions specific enough for precise matching; include exclusions when over-trigger risk is high.
+- Do not activate unrelated skills “just in case”.
+
+### 4. Test each model + harness combination independently
+
+- File portability ≠ behavior portability.
+- Validate on the actual model and host in use (direct chat / omp / Cursor / Codex / Claude Code / …):
+  - trigger accuracy
+  - execution correctness
+  - token cost
+  - regressions against prior wording
+
+### 5. Encode only gaps the base model cannot reliably fill
+
+Prefer encoding:
+
+- internal conventions and SSOT ownership
+- regulated or safety-critical procedures
+- fragile APIs and host-specific resolution rules
+- professional judgment and recurring failure modes
+
+Do **not** restate generic knowledge the model already has — that wastes tokens and adds noise.
+
+### 6. Treat every skill edit as a controlled experiment
+
+- Require paired evaluation: with-skill vs without-skill, or before vs after with observable criteria.
+- Accept only when success rate and trajectory quality improve on held-out / pressure cases.
+- Record failure reasons, token cost, latency, and regressions.
+- Reject “feels better” judgments.
+
+## Writer workflow
+
+1. **Collect expert path** — steps, branches, invariants, pitfalls, recovery (P1).
+2. **Gap filter** — keep only what the base model misses or mis-orders (P5).
+3. **Draft description** — third person; explicit trigger + exclusion; no workflow summary (P3).
+4. **Draft compact body** — answer the five questions; move bulk to `references/` (P2).
+5. **Wire progressive disclosure** — body names exactly which reference to open when.
+6. **Pressure / paired check** — 2–3 prompts that fail without the skill; confirm improvement (P4, P6).
+7. **Ship note** — list deletions/compressions (P2/P5) and how P6 was verified.
+
+## Authoring devices
+
+Small, composable techniques for specific authoring problems; each maps onto one or two
+principles above. Pull one in when it fits — do not encode all six into every skill.
+
+1. **Calibrated examples file** (serves P2/P5) — keep one small reference of real cases
+   distilled into annotated judgments; readers identify the governing principle, not text
+   templates, and it is written back when a new rule settles. In this harness: the Q1–Q8
+   worked judgments in `mstar-compound` `references/compound-workflow.md`; this iteration's
+   fold-B overcorrection checklist (device 3) is a softer second instance.
+
+2. **Recall batteries** (serves P5) — for audit/hunt skills: over-matching probes that
+   force a semantic judgment, plus a documented list of known false-positive families; a
+   zero-hit pattern proves nothing until you have seen it match. In this harness: the recon
+   hints `mstar-audit` fans out to scout subagents — scoping facts, domain risk hints, and
+   decided-tradeoff "don't report" pointers.
+
+3. **Overcorrection traps** (adjacent to P6) — a short section per skill naming the failure
+   modes of over-applying its own rules, so the skill guards its own bias. In this harness:
+   the overcorrection-traps row in `mstar-compound` `references/compound-workflow.md`
+   (obligation↛endorsement flips, hypotheticals stay marked, delete clauses, not sentences).
+
+4. **Required-explicit-input** (adjacent to P3) — when the required scope or answers are
+   missing, report and stop; never infer a repo-wide default. In this harness: `mstar-audit`
+   asks which findings to turn into plans — "do not write 30 plans nobody asked for" —
+   instead of inferring the scope itself.
+
+5. **Questions ≠ write authority** (serves P6) — interaction and calibration gates never
+   change edit authority; only the evaluation does. In this harness: `grill-me` interviews
+   without editing, and `mstar-sdd` keeps the per-task reviewer's report separate from the
+   implementer's application.
+
+6. **Invocation boundary** (adjacent to P3) — declare expensive workflows user-invocable
+   only; never put them in a skill load order. In this harness: the `/iteration-*` lifecycle
+   lives in `commands/`; `mstar-harness-core` keeps command-layer references out of the
+   `mstar-*` load matrix.
+
+## Output template
+
+```markdown
+### Description
+<third-person trigger + exclusions>
+
+### Body
+<compact SKILL.md answering the five questions>
+
+### Changelog vs prior / draft
+- Removed / compressed: ...
+- Why this serves P2 and P5: ...
+- How P6 was verified: ...
+- Trigger narrowness (P3): ...
+```
+
+## Layout mapping (optional, this harness)
+
+When authoring inside the Morning Star harness repo, map concerns as follows. Outside this repo, ignore this table and use the local project’s entry docs.
+
+| Writer concern | Home in this harness |
+|----------------|----------------------|
+| Global load / conflict | `mstar-harness-core` |
+| Skill authoring rules | this skill (`mstar-skill-authoring`) |
+| Host path resolution | `mstar-host` |
+| Repo maintenance (rename/index) | root `AGENTS.md` |
+| Runtime vs maintenance split | runtime rules in skills; maintenance in `AGENTS.md` |
+
+Default body skeleton and review checklist live in the parent `SKILL.md`; do not duplicate them here unless this reference is read in isolation.
+
+## Anti-patterns
+
+- Pasting a long tutorial into `SKILL.md` “for completeness”
+- Description that narrates the whole procedure
+- Encoding style preferences with no failure mode
+- Copying another skill’s rule into a new skill instead of extending SSOT
+- Accepting edits after a single cherry-picked happy-path demo
+- Bundling multiple domains into one body instead of splitting references
+- Framing a general authoring skill as if it only applied to one product’s skill tree