mstar-host-cursor

分类: 工具与效率 | 上传者: btspoony | 下载: 0 | 版本: v1.0（最新）
适用于晨星线束的光标主机适配器。每当在 Cursor 中使用“mstar-*”流程工作时，尤其是在处理“/pm”、基于任务的并行 QC 三重审核、特定于主机的澄清行为（无“问题”工具）或防止实施会话内递归任务误用时，请使用此技能。始终在“mstar-harness-core”之后加载此内容，以使光标行为与线束门和布线保持一致。
更新日志: Source: GitHub https://github.com/btspoony/mstar-harness
目录结构

当前层级: tree/main/.cursor/skills/mstar-host/
📄 SKILL.md 7.2 KB
SKILL.md

---
name: mstar-host-cursor
description: Cursor host adapter for Morning Star harness. Use this skill whenever working in Cursor with `mstar-*` flows, especially when handling `/pm`, Task-based parallel QC tri-review, host-specific clarify behavior (no `question` tool), or preventing recursive Task misuse inside implement sessions. Always load this after `mstar-harness-core` to align Cursor behavior with harness gates and routing.
---

# Morning Star × Cursor Host Adapter

This skill defines **entry points, load order, and host-specific behavior** for running Morning Star in **Cursor**.  
Process rules and gates remain authoritative in `mstar-*` skills; this file only explains Cursor-side adaptation.

## First Action: Load `mstar-harness-core`

At session start, the agent must **first** read `mstar-harness-core`, then load other `mstar-*` skills according to its index.

- Load timing for other skills (`mstar-plan-conventions`, `mstar-review-qc`, `mstar-coding-behavior`, `mstar-superpowers-align`) is governed by the `mstar-harness-core` skill index. Routing-eval lives under `.cursor/skills/` for **Cursor maint** only (see `repo-maintenance.mdc`).
- Role prompts are centralized in `mstar-roles`; in Cursor, `/pm` routes the main agent to the `project-manager` role in `mstar-roles`.

## Default path (recommended)

Use this default sequence unless a project rule explicitly overrides it:

1. Read `mstar-harness-core`
2. Read current host adapter (`mstar-host-cursor`)
3. Load role via `mstar-roles`
4. Execute with evidence-first completion checks

## Gotchas

- Cursor can parallelize QC via Task, but tri-review still requires identical `plan_id` and review scope fields across all three reviewers.
- Parallel QC does **not** imply different review cwd per reviewer.
- Task-based execution does **not** relax branch/worktree isolation requirements.
- Asking clarifying questions in Markdown is not equal to clarify completion; unresolved high-impact ambiguity is still `Blocked`.

## Cursor command simplification (`/pm`)

To reduce fragmented local command skills in Cursor, use this convention:

- **`/pm`**: Force the current session into Morning Star entry flow, load `mstar-harness-core` first, then load the `project-manager` role via `mstar-roles`.

Execution precedence:

1. User explicit instructions in this turn
2. Project-level `AGENTS.md` / `CLAUDE.md`
3. `mstar-harness-core` and related `mstar-*` skills
4. This `mstar-host` adapter

## Task Tool and Parallel Subagents (QC tri-review)

In Cursor, the main agent can use the **Task tool** to spawn subagents in parallel and implement the same **QC tri-review** structure used in OpenCode harness flows.

- **Prerequisite vs dispatch (same as OpenCode harness intent)**: one assistant message may run **`bash` / `read` / `glob`** only to pin `Review range`, merge-base, or cwd — **no** QC/dev Task dispatches for the batch in that message (unless `N = 1`). The **next** message that emits **any** Task for that batch must emit **all `N`** Tasks (**3** for tri-review) in **one** message. **Emit zero** Task dispatches until all `N` payloads are ready; **do not** send QC1 alone then QC2 after return.
- **Paste-only failure mode**: writing `## Assignment` in the main chat **without** issuing the matching **Task** calls means **dispatch did not happen**. **N** Assignments ⇒ **N** Task invocations in the dispatch turn (parallel QC ⇒ **3** Tasks in **one** assistant message when supported).
- Use `subagent_type`: `qc-specialist`, `qc-specialist-2`, `qc-specialist-3`, matching PM-issued **three independent Assignments**.
- Required alignment fields across all three QC Tasks: **`plan_id`**, **`Review cwd` / Worktree path**, **`Review range` / Diff basis`** must be text-identical to harness requirements (see `mstar-harness-core` `references/branch-and-worktree.md`, `mstar-plan-conventions`, `mstar-review-qc`).
- If prior implementation used multiple worktrees in one repo: parallel QC solves reviewer concurrency only; it does **not** mean each reviewer should inspect a different dev worktree. Keep review fields identical, and review against one branch/HEAD that contains the full review scope. If multi-track commits are not integrated yet, integrate or split scope first.
- Cursor/OpenCode differences are host capability differences (tooling, clarify interaction, artifact/report conventions), not process downgrades.

PM may explicitly note in Status Update that QC tri-review was executed via parallel Task subagents for traceability.

## When to use single-session or multi-window modes (supplemental)

These modes can supplement or replace Task parallelism when needed (state chosen mode in Status Update).

### Mode A — Single session, multiple roles

In one conversation, the main agent can execute sequentially: PM plans and writes Assignment first, then switch execution role explicitly, for example:

- `Acting as role: fullstack-dev — executing Assignment …`
- Before execution, read the corresponding role reference from `mstar-roles` and follow that role’s outputs and gates strictly.

If QC/QA runs without Task subagents, load corresponding `qc-specialist*` / `qa-engineer` roles in rounds within the same session; field alignment requirements remain unchanged.

### Mode B — Multi-window / multi-session role execution

Put one Assignment into a new chat, paste the Assignment in the first turn, and require that agent to load the corresponding role via `mstar-roles`. Useful for long implementations and reducing single-session context pressure; PM consolidates evidence/status in the main thread.

### Mode C — Worktree and concurrent writes

Even with Task parallelism, follow `mstar-harness-core` `references/branch-and-worktree.md`: if **two or more writers** modify the same repo concurrently, use `git worktree` (or equivalent isolation) and explicit branch/path conventions in Assignment. Do not confuse parallel QC capability with shared writable cwd safety, and do not assign different review cwd values for tri-review by default.

### No recursive Task inside implement subagents (aligned with `Execute as`)

A subagent that received Assignment via Task **is already** the `Execute as` executor. It must not spawn the same dev role recursively in the same session. Keep `Execute as` as plain role id. If outer messages conflict with Assignment (`complete personally`, `Delegation: forbidden`), Assignment wins.

## Clarify interaction

- When no `question` tool is available, ask via structured Markdown (headings/options) or equivalent Cursor interaction.
- Do not treat “question asked” as “clarify done”: unresolved high-impact ambiguity must still result in `Blocked` or escalation.

## Superpowers and skills

If no built-in Skill invocation tool exists, follow `mstar-superpowers-align` guidance for “plugin not installed” and use `Read` to load upstream `SKILL.md` content before execution.

## Relationship with project rules

Project-level `AGENTS.md` / `CLAUDE.md` found upward from cwd take precedence over global harness defaults. If conflicts exist with Cursor-side rules, project rules and current user instructions win.

## Shared protocol: library documentation retrieval (Context7)

Context7 retrieval is a shared process rule maintained by `mstar-harness-core`.  
Follow: `mstar-harness-core` skill `references/library-docs-protocol.md`.
登录后下载/点赞/收藏 ❤ 5 | ★ 0
mstar-host-cursor

目录结构

SKILL.md

举报内容

提示
