晨星工作流引擎 btspoony/mstar-harness

Morning Star

Harness 工作流引擎 · 智能体插件

English /

GitHub · Issues

dshfind
Greptile: The War on Bugs

Morning Star 把一套交付流程带进你已经在用的 AI 编程工具 —— dsh、omp、OpenCode、Cursor、Kimi Code、ZCode 和 Codex。你只需说清想要什么，project-manager 智能体会澄清需求、维护计划，再把工作从需求一路推进到实现、评审、验收，直到开出 pull request。需求、架构、实现、评审、验收和审计，各自交给负责该环节的角色。

为什么用它

- 从需求到 pull request —— 需求说一次就够；PM 维护计划，拉来合适的专家，把一切推进到 pull request。如果工作中途停下，计划会记下停在哪里，之后可以接着做。
- 用专家分工，不写一条长提示词 —— PM 负责编排；需求、架构、实现、QC、验收、审计、运维各由独立角色负责，每个角色的职责范围都很窄。
- 过程可审计 —— 计划、发现、评审报告和决策都记录在仓库的 harness 目录下，不只在聊天里。
- 边界明确 —— 迭代启动时，工作流会开 pull request 并记录合并策略。reviewed-auto 下，只有当前 PR head 上已定稿并发布的 ship it 评审报告才授权合并；owner-gated 下，流程停在 merge-ready，等你书面批准。策略从未记录时，运行会退回 Phase 1，不会默认采用任何一种。审计只读取和报告；任何触及真实环境的操作都需要你明确授权。

安装

每个宿主都有两种安装方式：本 CLI 的 init 流程，或宿主自带的插件管理器 —— 原生命令只安装插件。选项、路径布局和各宿主说明见 INSTALL.md。

- dsh（DeepSeek Harness） —— 需要 dsh CLI 在 PATH 上
- CLI：npx @mstar-harness/cli init --target dsh
- 原生：dsh plugin --profile web add @mstar-harness/dsh
- omp —— 需要安装 omp CLI
- CLI：npx @mstar-harness/cli init --target omp
- 原生：omp plugin install @mstar-harness/omp
- OpenCode
- CLI：npx @mstar-harness/cli init --target opencode
- 原生：OpenCode 1.x 用 @mstar-harness/opencode，OpenCode 2.x 用 @mstar-harness/opencode-v2 —— 加到 opencode.json 的插件列表里，然后重启 OpenCode
- Cursor —— 需要 git
- CLI：npx @mstar-harness/cli init --target cursor
- 原生：git clone https://github.com/btspoony/mstar-harness.git ~/.cursor/plugins/local/morning-star-harness，然后 Developer: Reload Window
- Kimi Code —— 没有 CLI 目标
- 原生：/plugins install https://github.com/btspoony/mstar-harness，然后 /plugins reload
- ZCode
- CLI：npx @mstar-harness/cli init --target zcode
- 原生：把 https://github.com/btspoony/mstar-harness 添加为 ZCode 插件市场，然后安装 morning-star-harness
- Codex —— 需要 codex CLI
- CLI：npx @mstar-harness/cli init --target codex
- 原生：codex plugin marketplace add btspoony/mstar-harness --ref main，然后 codex plugin add morning-star-harness@mstar-repo

使用

每个会话进入一次 PM，然后用自己的话描述工作；PM 在该会话里跑流程。

| 宿主 | 进入 PM |
| dsh | pm 技能 |
| omp | /skill:pm |
| OpenCode | Project Manager 智能体，或 /pm |
| Cursor | /pm |
| Kimi Code | 会话中自动加载，或 /skill:pm |
| ZCode | /morning-star-harness:pm |
| Codex | /pm |

单任务（不走迭代）

给 PM 一个具体需求——比如：「给公开 API 加上限流，并用测试覆盖。」 PM 会澄清缺口、写出计划、在功能分支上执行，并推动它走完 实现 → 独立 QC 评审 → 验收 → 完成。本轮确认但未修复的问题会记录为 issue，不会丢弃。你评审结果并合并。

迭代

| 命令 | 何时使用 |
| /iteration-start [direction] [pause] | 阶段 1：交互式方向锁定（grill-me），产出本次迭代的指南针与计划，然后自动继续执行、收尾、发起 pull request，直至可合并。pause 会在阶段 1 后停下；用 /iteration-drive 继续。 |
| /iteration-drive | 恢复或推进已锁定的迭代。不接受参数。 |
| /iteration-loop [direction] [scale] | 同样的生命周期端到端跑完，跳过交互阶段。scale（S / M / L / XL）限制本次迭代承接的计划数量。 |

迭代只有走完合并后的收尾才算结束：阶段关闭、pull request 打开、或 pull request 已合并，本身都不算完成。命令拼写因宿主而异——有些宿主需要插件前缀，Codex 只在项目作用域安装命令技能；参数形式与各宿主细节见 docs/commands.md。

审计、评审与验证

| 命令 | 何时使用 |
| /codebase-audit [keywords] | 只读调查，产出按优先级排序、可直接执行的改进计划；用类别焦点（bug、security、perf、tech-debt 等）缩小范围。 |
| /amazing-pr-review [pr\|branch] [quick\|default\|deep] | 合并前评审 PR 或分支，三档强度，最终给出一个结论——ship it、needs fixes 或 blocked，来自一次稳定运行（未中断完成、每个必需领域都已开启、解析出的 diff 基线可读且完整）的发现统计；或仅在三种情况下给出唯一推导出的 incomplete——运行在综合前停止、某个必需领域席位从未开启、或解析出的 diff 基线无法读取。墙钟超时不算其中一种：完整覆盖的运行超出预算时，仍发布由统计推导的结论，并把超时声明为备注。 |
| /amazing-test-audit [scope] [quick\|deep] [campaign] | 只读审计测试面 → 产出删除、修复、合并或迁移测试的计划。 |
| /amazing-e2e-check [environment] [scenarios] | 在独立工作流中运行你明确要求的浏览器、设备或已安装部署场景。 |

审计命令只读取和报告，不改你的代码。有两条边界要知道：给 /amazing-pr-review 一个 pull request 编号时，它会把发现作为评论评审发到 GitHub——它从不批准、请求修改或合并；/amazing-e2e-check 只在你要求时运行，涉及真实环境的步骤需要明确授权。

工作流

flowchart TD
A["You describe the work"] --> B["PM clarifies it and writes the plan"]
B --> C["Implement on a feature branch"]
C --> D["Independent review"]
D -->|changes requested| C
D --> E["Acceptance by QA or the PM, with its own evidence"]
E -->|not accepted| C
E --> F{"Iteration with plans still to run?"}
F -->|yes: next plan| C
F -->|no| G["Wrap up: record results and issues, keep reusable lessons"]
G --> H["Open the pull request"]
H --> I["CI checks and review feedback"]
I --> J{"All green and reviews resolved?"}
J -->|no: fix, verify, push| I
J -->|yes| K["Merge-ready"]
K -->|per its merge policy §5.3, or your approval| L["Merge"]
L --> M["Verify the merge, then close the delivery"]

主路径展示的是一次开发交付。每个计划都要过一遍计划级 QC 评审——默认三个独立席位——多任务计划在实施期间还要加一轮逐任务评审。热修复——或明确设为内联执行的计划——走更轻的路线，评审席位更少。验收是单独的一轮，自带证据——由 QA 或 PM 负责——不是把实施者的总结再读一遍；本轮不修的已确认问题会转成跟踪 issue，而不是被丢掉。

范围说明。 迭代先和你锁定方向，然后对它接下的每个计划跑一遍逐计划循环，并在开 pull request 之前统一收尾一次；没有迭代时，循环只跑单个计划。验证型或纯报告型交付物——比如审计——在约定的完成点结束，不开 pull request，也不合并。在开发路径上，计划只有拿到证据才算完成：计划完成、merge-ready、已合并是三件不同的事，只有经过验证的合并，再加上合并后收尾，才算结束交付。合并是另一项授权，来源只能记录一个：在 owner-gated 下由你批准或自己合并；在 reviewed-auto 下，记录在案的策略只有在当前 PR head 上有一份已定稿、已发布的 ship it 报告时才提供授权——光有评审不算。从未记录过策略的迭代回到 Phase 1，不会退回到上述任何一种。分支清理始终是单独的显式步骤。

引擎会检查这套流程里可机械检查的部分——工作流状态流转、分支与 worktree 对齐、派发前置条件、计划与 issue 的记账。这些检查默认只做提示：报告问题；项目或迭代可以用 enforcement: hard 选择开启阻断式执行；违规能否真正阻断取决于宿主。流程状态（计划、工作流记录、发现、评审报告）存放在 harness 目录，默认是 .mstar/，脚手架的标准 .gitignore 片段会忽略它——安装器不会改动 .gitignore。

仪表盘

127.0.0.1 上的只读页面，仅限本机访问。从哪个仓库启动，就把该仓库的项目进度、未关闭 issue 和路线图汇到一屏。页面有 Issues、Workflows、Iterations、Roadmap 四块；在 Issues 里可以搜索、筛选，打开某个 issue 的记录历史，还能看 issue flow——issue 新增与关闭的累计趋势。页面上不做任何写入，改动都走命令行。

mstar-harness dashboard

命令会打印一行 JSON 结果。打开 data.url（http://127.0.0.1: 加上实际绑定的端口），按 Ctrl-C 停止。--port 和 --project <projectId> 可选；不传 --port 就由系统挑。页面不推送实时更新。

细节见 docs/runtime-reference.md。

MCP

在支持 MCP 的编码工具里，查 issue、路线图和工作流，跑对应的命令行操作和检查，不用敲 shell 命令。mstar-harness mcp 是本包里的 stdio 服务器。它遵循和命令行相同的规则——不是新增权限——也没有单独的 MCP 包。

安装后，宿主通常已经有自己的启动配置；见 INSTALL.md。静态 JSON 配置用下面的形状（npx 用 PATH 上的 Node 跑 bin，见前置条件）。不要把它覆盖到宿主已经写好的文件上。OpenCode 不读静态文件——它的插件从 config 钩子注入服务器。dsh 是例外：随附的那一行在配置档包含 @deepseek-ai/dsh-mcp-client 之前一直不生效（dsh plugin --profile web add @deepseek-ai/dsh-mcp-client）。

{
"mcpServers": {
"morning-star": {
"command": "npx",
"args": ["@mstar-harness/cli", "mcp"]
}
}
}

更多细节见 docs/runtime-reference.md。

角色与技能

| Agent ID | 职责 |
| project-manager | 路由、分配、阶段推进 |
| product-manager | 需求、产品规划、调研 |
| architect | 架构与技术契约 |
| fullstack-dev / fullstack-dev-2 | 后端主导实现 / 第二条并行线 |
| frontend-dev | UI、交互、前端性能 |
| qa-engineer | QA gate: mandatory 时的验收 |
| code-reviewer | SDD 逐任务评审；代码库审计（audit 类别） |
| qc-specialist / -2 / -3 | QC 三人组 |
| ops-engineer | 部署、监控、基础设施 |
| writing-specialist | 文档、小说、文案、脚本 |
| prompt-engineer | 提示词 / 技能 / 规则相关工作 |

project-manager 跑你的会话并派活：需求与架构、后端与前端实现、QC 评审、验收、代码库与 PR 审计、运维、写作，各交给专门角色。每个角色都遵循 mstar-* 技能。

命令行

mstar-harness 命令行覆盖会话之外你要做的事：issue、roadmap、工作流状态、检查、仪表盘和 MCP。

- 直接问命令本身。 --help 会显示命令需要哪些输入；对于 issue 的写入动词，它会逐个列出 payload 字段，并标明类型，以及该字段是必填，还是只在某种处置方式下才必填。用法被拒绝时，会告诉你它发现了什么问题、该去读哪条帮助路径，以及怎么恢复。

mstar-harness --help # command families
mstar-harness issue close --help # options and payload fields for one verb
mstar-harness schema --command issue.close # the same contract as machine-readable JSON

- mstar-harness report 会起草一份离线、脱敏的 GitHub issue 报告，供你发布前审阅。

宿主接入、issue 与 roadmap 命令族，以及这些界面的细节，都在 docs/runtime-reference.md 里。

文档

- docs/runtime-reference.md — 组件、存储布局、角色与技能、命令行与 MCP 参考。
- INSTALL.md — 各宿主的安装与验证，以及 report 命令的详细说明。
- docs/commands.md — 七个斜杠命令：参数、何时使用、归属技能。
- CONCEPTS.md — harness 在技能和文档中通用的词汇。
- 发布说明：CHANGELOG.md / CHANGELOG_CN.md。命令行参数：见 mstar-use-cli 技能。
- 维护者：AGENTS.md。

许可证

MIT。见 LICENSE。