mstar-host

Files (17)

• SKILL.md
• host-role-binding-core.md · references/_shared/
• plan-mode-bridge-core.md · references/_shared/
• codex.md · references/
• cursor-plan-mode-bridge.md · references/
• cursor.md · references/
• dsh-agent-teams.md · references/
• dsh-workflow-scripts.md · references/
• dsh.md · references/
• kimi-plan-mode-bridge.md · references/
• kimi.md · references/
• omp-plan-mode-bridge.md · references/
• omp.md · references/
• opencode.md · references/
• parallel-dispatch.md · references/
• zcode-plan-mode-bridge.md · references/
• zcode.md · references/

SKILL.md (first lines)

# Morning Star Host Adapter

Host-specific **capabilities and entry behavior** for Morning Star. Process gates and invariants stay in `mstar-harness-core` and topic `mstar-*` skills.

## Load order

**本 skill 总是在 `mstar-harness-core` 之后加载**（先 Read `mstar-harness-core` SKILL.md；宿主注入项目 `AGENTS.md` 也不跳过，见下 `## First action`）。本 skill 只适配宿主入口 / 检测 / 计划 UX；状态机与门禁以 `mstar-harness-core` 为准。

## First action

Read **`mstar-harness-core`** before this skill (even when the host injects project `AGENTS.md`).

## Default path

1. Read `mstar-harness-core`
2. Read **`mstar-host`** (this skill) and detect host below
3. Read **`references/<host>.md`** for the active host
4. Load role via `mstar-roles`
5. Execute with evidence-first completion checks

Load topic skills **on demand** per `mstar-roles` (do not read every `mstar-*` skill by default). Cursor routing-eval (`.cursor/skills/mstar-routing-eval/`) is regression tooling only — not part of runtime load order.

## Detect active host

Detect from **session tool shapes and available commands** — not from plugin markers on disk. The `*-plugin/plugin.json` files **cannot** identify the host: they all coexist in this harness source repo and in any multi-host install.

| Signal | Host | Next read |
|--------|------|-----------|
| **`subagent_type`** param on the Task tool (plus **CreatePlan**/**SwitchMode** when Plan mode is active) | `cursor` | `references/cursor.md`; Plan mode also `references/cursor-plan-mode-bridge.md` |
| **`question`** tool, or **`task`** tool with **`subagent`** (singular) — no `tasks[]` batch | `opencode` | `references/opencode.md` |
| **`task`** tool with **`agent`** / **`tasks[]`** batch, **`ask`**, **`hub`** (omp also exposes `/goal`; goal rule is host-agnostic per below) | `omp` | `references/omp.md`; Plan mode also `references/omp-plan-mode-bridge.md` |
| **`subagent`** tool (dsh's model-facing delegation tool — `@deepseek-ai/dsh-tool-subagent` default `toolName`), **`spawn_teammate`** / **`team_task_create`** (dsh Agent Teams tools — `@deepseek-ai/dsh-experimental-tool-agent-team`) | `dsh` | `references/dsh.md` |
| **`Agent`** / **`AskUserQuestion`** / **`EnterPlanMode`** + **`AgentSwarm`** (Kimi-only) | `kimi` | `references/kimi.md`; Plan mode also `references/kimi-plan-mode-bridge.md` |
| **`Agent`** / **`AskUserQuestion`** / **`EnterPlanMode`** / **`TodoWrite`**, **no `AgentSwarm`** | `zcode` | `references/zcode.md`; Plan mode also `references/zcode-plan-mode-bridge.md` |
| `/plan`, `/goal` slash commands; **Goal tools**; `functions.*` / `codex_app.*` tool namespaces; `tool_search`; Browser plugin tools | `codex` | `references/codex.md`; Plan mode also `references/_shared/plan-mode-bridge-core.md` |
| Still ambiguous | - | Read sections in **`cursor.md`**, **`opencode.md`**, **`codex.md`**, **`kimi.md`**, **`zcode.md`**, **`omp.md`**, and **`dsh.md`** that match tools you have; **`mstar-harness-core` wins** on conflict |

Order matters: check `cursor` → `opencode` → `omp` → `dsh` → `kimi` → `zcode` → `codex`. The four Task-shaped tokens are distinct: `subagent_type` (Cursor), `task_subagent` (OpenCode's `subagent` parameter on the `task` tool), `agent`/`tasks[]` (omp), and `subagent` (dsh's own delegation tool). No row shares another's token, so the dsh row collides with none and sits with the agent-tool hosts.

> **Engine check (when available):** run `mstar host detect --signals <comma-list>` (or `import { detectHost } from "@mstar-harness/engine"` in a host hook) to resolve the detection table above from session tool shapes (prints the host id, or `ambiguous` to fall back on the table + judgment). On `fail` -> do not proceed; fix and re-run. Skill text below remains authoritative when the runtime is absent.

## Parallel dispatch (invoke-capable hosts)

When PM dispatches **N >= 2** concurrent assignees (QC tri-review, dual-track implement, etc.) and the host exposes actual invoke / Task / subagent tools, read **`references/parallel-dispatch.md`** in the dispatch round (shared with `mstar-dispatch-gates`). Without a callable invoke tool when dispatch is required → **`Blocked`**; Assignment Markdown alone is not dispatch.

On **dsh** only, read-only fan-out runs through the native **`workflow`** tool instead of N `subagent` invokes. **N ≥ 3** is the width it is designed for; **1–2 seats** are carried by `subagent` — read-only fan-out never takes a teammate at any N. Where the Team layer disables `subagent`, the script follows the work, not the seat count: a 2-seat PR review runs § 3 `mstar-pr-seats` with the tier's two domain lenses, and a 2-category codebase audit runs § 2 `mstar-audit-fanout` with two `categories` (§ 3 requires `target` + `diffBase`, so it never carries an audit). **Separately**, a one-seat SDD task review must not consume a roster slot, so routing it through a one-seat § 4 `workflow` run is a **supported** route on a Team profile, not an improvisation. Writable fan-out never uses `workflow` — it has no per-child pre-start veto seam. Scripts + operator path: `references/dsh.md` § Read-only fan-out via the `workflow` tool.

## `/goal` directive (host-agnostic)

**Applicability is by capability, not host identity**: any host that exposes a `/goal` command (currently Codex Goal Mode and omp; other code agents may add it later) attaches a persistent objective to the thread. **Exception — dsh:** mstar **stops arming** a goal there and never uses a `/goal` objective or a goal round loop as the progression driver — dsh runs on the native workflow (workflow snapshot phases + dispatch gates + **subagent settle notifications**; each settle notification is a **`result-settled` Rescheduling checkpoint** — run that checkpoint and dispatch the ready independent work before any wait, never "one settle → one dispatch", per `mstar-iteration` `references/phase-2-worktree-lease.md` §2.4; a manually armed `/goal` stays outside mstar's flow). Full rule → `references/dsh.md`. Rule — **always set the goal to running the complete flow to the end**, never a sub-stage:

- **Advancing an iteration**: set the goal to **complete the entire iteration flow** (`iteration-start → per-plan cycles → iteration-close → PR delivery → PR merge-ready loop`). Do not set a sub-stage goal (e.g. "finish Phase 1 only").
- **Advancing non-iteration work** (single plan / hotfix / one-off task): set the goal to **complete the entire per-plan flow** (`specify → clarify → plan → tasks → implement → plan QC tri + QA gate → Done`; standalone development plans continue through the delivery tail to verified merge + terminal close — `mstar-harness-core`「最小交付循环」/ `mstar-artifacts/references/plan-workflow-lifecycle-contract.md`). Do not set a sub-stage goal (e.g. "write the plan" or "implement one task").

Goal text is a session-level objective only: store.db execution authority under `{HARNESS_DIR}` and authored `{PLAN_DIR}` plans remain authoritative, and goal completion is **not** harness Done. Mirror goal success criteria into the SSOT plan; when the goal changes, update goal text and the SSOT in the same round.

## Phase-transition todo refresh (host-agnostic)

At each phase transition the primary PM refreshes session todos before the next action/dispatch: close completed entries only, retain pending gates and append next-phase obligations. Project the selected workflow's complete lifecycle, not another per-row primary scope. Todos remain a projection, not state authority.

`todo` entries are a projection, not SSOT: they reflect the ACTIVE workflow phase / plan states and named plan/gate evidence, and cannot authorize or invent a state transition. Store.db workflow/plan rows remain the execution authority, with authored plan artifacts kept aligned; this is freshness discipline, not a new host hook anchor, tool, or deterministic enforcement mechanism.

## Host hooks (anchor contract)

Shared lifecycle skills name **host-agnostic anchors** — named moments at which the active host obliges the PM to run a host-defined coordinator action. The anchor vocabulary is frozen and carries no host identity: tool names, exact parameters, prerequisites, refusal codes, native settings and auto-trigger scope live **only** in `references/<host>.md`.

| Anchor | Moment |
|--------|--------|
| `direction-lock` | direction locked, formal compass/plans ready, and workflow registered with coordinator seat acquired — before the Review & Edit chain |
| `phase-1-lock` | Phase 1 completion — once the integration worktree exists and the newly created integration branch is pushed; Phase 1 commits nothing (the PM lock alone is not the moment) |
| `phase-2-entry` | the Phase 2 execute/resume entry — after the §2.0 gates, before the per-plan loop; **not** the Phase-1-reused integration-worktree step |
| `rescheduling-checkpoint` | each `Rescheduling checkpoint` re-evaluation |

**Execution rule.** At each anchor the PM executes whatever the **active host reference** declares under its own `## Host hooks` section for that anchor. A host reference that declares nothing for an anchor means **no-op**: never invent an action, never substitute another host's declaration, and never treat an absent declaration as permission to skip the anchor's shared step.

**Marker form.** A shared file that owns an anchor carries a comment marker plus a one-line pointer — neither names a host or a tool:

```markdown
<!-- host-hook: <anchor> -->
> Execute the active host reference's `## Host hooks` declaration for `<anchor>`; this file defines no host action.
```

Carrier locations — the four markers in the shared corpus (all four live under `skills/`, never in `commands/`):

| File | Location | Anchor |
|------|----------|--------|
| `mstar-iteration/references/phase-1-prepare.md` | §1.5, after formal compass/plans are ready, workflow registration creates its running ACTIVE lifecycle, and this session acquires the coordinator seat; before Review & Edit | `direction-lock` |
| `mstar-iteration/references/phase-2-worktree-lease.md` | §2.3 「Integration worktree (Phase 2 entry) + control root」 checklist tail, after step 7 (integration-branch push — Phase 1 commits nothing) — the Phase 1 route reaches it through `iteration-start`'s integration-branch step, which carries a pointer only | `phase-1-lock` |
| `mstar-iteration/references/phase-2-worktree-lease.md` | immediately before the `## 2.4 Per-plan loop` heading (the Phase 2 execute/resume entry; §2.3 is the Phase-1-reused step and triggers nothing) | `phase-2-entry` |
| `mstar-iteration/references/phase-2-worktree-lease.md` | `### Rescheduling checkpoint` | `rescheduling-checkpoint` (the five frozen reason names are handed off verbatim) |

**Shared-text boundary:** new/modified skills outside mstar-host and canonical commands use capability wording, not host names/tools/fields/native settings/extension filenames. Concrete adapters remain exclusively in this skill's per-host references.

**Enforcement surface.** The check applies to **the files a change touches**, never to the whole corpus: shared text that already violates the rule and is not part of the current change is **out of scope of the rule's enforcement** and is cleared in batches under the `host-seam-corpus-cleanup` goal of the store-authoritative `_default` project roadmap (read rule → `mstar-project-governance`; legacy `{PROJECT_DIR}/_default/roadmap.md` is transport/history only). Until that cleanup completes, a whole-tree grep over shared text is **not** a valid assertion for this rule — judge a change on the shared-layer text it adds or edits.

## Resolve loaded skill root

Docs name assets as skill **`<name>`** → `scripts/…` / `references/…`. **Resolve the loaded skill directory first** — do **not** open `skills/<name>/…` from a consumer app cwd (that layout exists in the harness source / plugin package only).

| Host | Prefer | Filesystem fallback (only if the host cannot load by name) |
|------|--------|--------------------------------------------------------------|
| **omp** | `skill://<name>` / `skill://<name>/<rel>` / `/skill:<name>` | Plugin package root `skills/<name>/` after install/link — not app cwd |
| **Cursor** | Skill **name** via plugin skills | Global `~/.cursor/plugins/local/morning-star-harness/skills/<name>/`; project `.cursor/plugins/morning-star-harness/skills/<name>/` |
| **Codex** | Skill **name** via plugin | Plugin-mounted `skills/<name>/`; project command skills under `.agents/skills/<name>/` |
| **OpenCode** | Skill **name** via `@mstar-harness/opencode` | Package-internal `harness-skills/<name>/` — never `process.cwd()/skills/` |
| **dsh** | Skill **name** via the mstar skill-local provider (`providerName: mstar`) | `$DSH_BUNDLED_SKILL_DIR/<name>[/<rel>]` — the packaged `harness-skills/` mirror mounted package-relative by `@mstar-harness/dsh`; never app cwd |
| **Kimi / ZCode** | Skill **name** / `/skill:<name>` | Plugin mount `./skills/<name>/` from the installed plugin root |

Authoring convention: **`mstar-skill-authoring`** § Skill-relative script and asset paths. Per-host URI / mount detail: `references/<host>.md`.

> **Engine check (when available):** run `mstar host skill-root --host <id> --skill <name>` (or import `resolveSkillRoot` from `@mstar-harness/engine` in a host hook) to resolve the loaded skill root per the table above. On `fail` -> do not proceed; fix and re-run. Skill text below remains authoritative when the runtime is absent.

## Conflict order（Decision Rules）

1. User explicit instructions (this turn)
2. Project `AGENTS.md` / `CLAUDE.md`
3. `mstar-harness-core` and related `mstar-*` skills
4. This `mstar-host` skill and `references/*`

From btspoony/mstar-harness, MIT.

More from btspoony/mstar-harness