@mstar-harness/dsh 2.1.1

package/harness-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/harness-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/harness-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/harness-skills/mstar-skill-authoring/SKILL.md

@@ -0,0 +1,162 @@
+---
+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`（需要完整循环时再读）。
+
+## 6 条作者原则（必须遵守）
+
+来源：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/`。
+
+## 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 写明「何时打开哪份」。
+
+## 验证门控（原则 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
+```
+
+## References
+
+| 何时 | 打开 |
+|------|------|
+| 需要完整 skill-writer 流程、原则细则、输出模板 | `references/skillsbench-authoring.md` |

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

@@ -0,0 +1,117 @@
+# 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.
+
+## 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

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

@@ -0,0 +1,130 @@
+---
+name: mstar-strategy
+description: Morning Star 全局战略方向 —— 创建并维护 `STRATEGY.md`（项目级战略文档），作为 brainstorm/plan 的上游锚点。定义产品愿景、技术方向、不做事项、决策原则。触发：项目初始化、方向性决策变更、或 PM 要求战略对齐时。
+---
+
+# mstar-strategy（全局战略方向）
+
+## Load order
+
+**Read `mstar-harness-core` first.** Path symbols → **`mstar-plan-conventions`**. On conflict, **`mstar-harness-core` wins**.
+
+## Purpose
+
+`STRATEGY.md` is the project's **upstream anchor** — a concise declaration of what the project is, where it's going, and what principles guide decisions. It is read as grounding by brainstorm, plan, and ideation phases so strategic choices flow into every feature.
+
+Without a strategy document, decisions are made in isolation — each plan misses the larger context.
+
+## 产物存储位置
+
+**SSOT**: `mstar-plan-conventions/references/artifact-storage-paths.md`。STRATEGY.md → `<repo-root>/STRATEGY.md`（与 `.git/`、`AGENTS.md` 同级）。**禁止**放入 `{HARNESS_DIR}`、`docs/` 或任何子目录。
+
+## When to use
+
+| Trigger | Example |
+|---------|---------|
+| Project initialization | "Create STRATEGY.md for this new project" |
+| Directional change | "We're pivoting from monolith to microservices" |
+| PM requests alignment | "Check if this plan aligns with our strategy" |
+| Periodic review | "Review and update STRATEGY.md" |
+
+## STRATEGY.md structure
+
+A good strategy document is opinionated and concise. It should fit in one screen of reading.
+
+### Required sections
+
+```markdown
+# Strategy
+
+## Vision
+<1-2 sentences: what the project aims to become>
+
+## What we build
+<Core product/users/use cases>
+
+## What we don't build
+<Explicit non-goals — as important as goals>
+
+## Guiding Principles
+- <Principle 1>
+- <Principle 2>
+- <Principle 3>
+
+## Technology Direction
+<Key tech choices and rationale>
+
+## Decision Log
+<Major past decisions with context — why, not just what>
+```
+
+> **Engine check (when available):** run `mstar lint <STRATEGY.md>` (or `import { lintStrategySections } from "@mstar-harness/engine"` in a host hook) to check the six required sections above (Vision, What we build, What we don't build, Guiding Principles, Technology Direction, Decision Log). On `fail` -> do not proceed; fix and re-run. Skill text below remains authoritative when the runtime is absent.
+
+### Optional sections
+
+- **Current Focus** — what the team is working on now
+- **Risks & Mitigations** — known strategic risks
+- **Competitive Context** — what alternatives exist and how we differ
+
+## Creating STRATEGY.md
+
+### Phase 1: Gather context
+
+1. Read existing project documentation (README, AGENTS.md, existing specs).
+2. If `{KNOWLEDGE_DIR}` or `{ITERATION_DIR}` exist, scan for architectural decisions and patterns.
+3. If `CONCEPTS.md` exists, use it to understand domain vocabulary.
+
+### Phase 2: Interview
+
+Ask PM these questions (one at a time):
+
+1. "What is the one-sentence vision for this project?"
+2. "Who are the primary users and what do they need most?"
+3. "What are you explicitly NOT building? What's out of scope permanently?"
+4. "What 2-3 principles should guide every technical decision?"
+5. "What technology bets have you made, and why?"
+
+### Phase 3: Draft
+
+Write STRATEGY.md at the repo root. Keep it concise — each section should be 1-3 sentences or a short bullet list.
+
+### Phase 4: Discoverability
+
+Check if AGENTS.md references STRATEGY.md. If not, propose adding:
+
+```markdown
+- `STRATEGY.md` — project vision and guiding principles
+```
+
+Ask for consent before applying.
+
+## Maintaining STRATEGY.md
+
+### Review triggers
+
+- After a major architectural decision
+- When a plan introduces a new technology stack
+- Quarterly review (scheduled by PM)
+
+### Update rules
+
+1. **Be decisive about direction changes.** Don't keep old strategy alongside new — replace it.
+2. **Log decisions with context.** The Decision Log captures *why* a choice was made, not just what.
+3. **Keep it current.** Stale strategy is worse than no strategy — it misdirects plans.
+
+## STRATEGY.md vs other docs
+
+| Document | Purpose | Audience |
+|----------|---------|----------|
+| `STRATEGY.md` | Product/technical direction, principles, decisions | PM, architect, all implementers |
+| `AGENTS.md` | Repo maintenance policy, conventions | Contributors and agents |
+| `CONCEPTS.md` | Domain vocabulary | Anyone reading/writing project docs |
+| Plans in `{PLAN_DIR}/` | Feature-level implementation plan | Implementers, reviewers |
+
+## NOT to do
+
+- Do not write STRATEGY.md as a novel — it should be scannable
+- Do not include implementation details or file paths
+- Do not create without PM/architect input (ask the questions)
+- Do not keep outdated strategy as "historical reference" — git preserves it
+- Do not conflate strategy (direction) with conventions (how-to)

package/harness-skills/pm/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: pm
+description: "PM entry shim — force project-manager orchestration when user invokes /pm or this skill (Codex, Cursor, OpenCode, Kimi, ZCode, and omp). General per-plan PM work: this skill + project-manager.md. Formal iteration lifecycle: mstar-iteration (host commands/ may orchestrate Phase 1–5). Boot, routing, dispatch SSOT → mstar-roles/references/project-manager.md and topic mstar-* skills — not here."
+---
+
+# PM (entry shim)
+
+**Thin launcher only.** Boot lists, iteration phases, Assignment templates, and SDD loops are **not** maintained in this file.
+
+## Host entry
+
+| Host | Use |
+|------|-----|
+| **Codex** | **`/pm`** or this skill → **`project-manager`** for the session |
+| **Cursor** | **`/pm`** or this skill → general PM orchestration (single-plan, hotfix, QC waves, dispatch) **without** starting an iteration. Formal iteration → host **`commands/`** + **`mstar-iteration`** |
+| **OpenCode** | Same as Cursor when no command: **`project-manager`** via `mstar-roles` → `references/project-manager.md` |
+| **Kimi** | **`/skill:pm`** or this skill → **`project-manager`**; iteration → plugin **`commands/`** (`/morning-star-harness:iteration-*`) |
+| **ZCode** | **`/morning-star-harness:pm`** or **`/skill:pm`** → **`project-manager`** (no session auto-load) |
+| **omp** | **`/skill:pm`** or this skill → **`project-manager`**; iteration → **`/iteration-start`** · **`/iteration-drive`** · **`/iteration-loop`** (filename commands) |
+
+**Iteration lifecycle** (optional): host `commands/` may sequence Phase 1–5; semantics SSOT → **`mstar-iteration`**. Not required for ordinary PM work.
+
+**Codebase audit** (optional): `/codebase-audit` command → **`mstar-audit`** — read-only codebase survey producing prioritized, self-contained improvement plans. Output feeds iteration-start §1 Research or normal Prepare → Execute. Dispatched by PM under `Task category: audit`.
+
+Detect host → **`mstar-host`** → `references/codex.md` | `cursor.md` | `opencode.md` | `kimi.md` | `zcode.md` | `omp.md`.
+
+## Read next (in order)
+
+1. `mstar-harness-core`
+2. `mstar-roles` → **`references/project-manager.md`** — required reading list, routing, dispatch-first, iteration branch policy
+3. Topic skills **on demand** per that file and the active workflow (`mstar-dispatch-gates`, `mstar-iteration`, `mstar-sdd`, `mstar-review-qc`, …)
+
+## Four rules (everything else is a pointer)
+
+1. **Delegate** — PM does not implement, QC, or QA in-thread (`project-manager.md` Execution Boundary; hotfix → `mstar-phase-gates`).
+2. **Dispatch** — when host has invoke/Task tools: **1 Assignment ⇒ 1 invoke** (`mstar-dispatch-gates`). Markdown alone is not dispatch.
+3. **SSOT** — iteration lifecycle → **`mstar-iteration`**; Cursor Plan mode → **`mstar-host/references/cursor-plan-mode-bridge.md`**.
+4. **Autonomous Execute push** — multi-plan iteration Phase 2–5: continuously dispatch implement → QC → QA → Done through merge-ready exit without routine yes/no prompts; **Blocked** only on true conflicts or metadata gaps → **`mstar-iteration` §2.6**.
+
+Conflict: user instructions → project `AGENTS.md` / `CLAUDE.md` → `mstar-harness-core` → this file.