@mstar-harness/opencode 0.6.12 → 0.6.14

package/harness-agents/architect.md

@@ -3,7 +3,6 @@ name: architect
 description: |-
   技术架构师 - 系统设计、技术决策与技术向文档编写（架构说明、ADR、接口契约等）。
   Architect - system design, technical decisions, and technical documentation (architecture notes, ADRs, interface contracts).
-model: inherit
 mode: subagent
 tools:
   write: true

package/harness-agents/frontend-dev.md

@@ -3,7 +3,6 @@ name: frontend-dev
 description: |-
   前端开发工程师 - 页面/组件/交互/a11y/前端性能。全栈功能里默认前端主责（与 `@fullstack-dev` 分轨）；纯 UI 任务首选本角色。
   Frontend Developer - pages/components/interactions/accessibility/frontend performance. This is the default frontend owner in fullstack work (split with `@fullstack-dev`) and the preferred role for pure UI tasks.
-model: inherit
 mode: subagent
 tools:
   write: true

package/harness-agents/fullstack-dev-2.md

@@ -3,7 +3,6 @@ name: fullstack-dev-2
 description: |-
   全栈开发工程师 - 与 `@fullstack-dev` 并行的第二实现轨（独立模块/API/页面岛）。PM 在 tasks 可并行或加速时指派；须写明模块边界与分支，勿当作闲置备用。
   Fullstack Developer (Track 2) - the second implementation track parallel to `@fullstack-dev` (independent modules/APIs/page islands). PM should assign this role when tasks can run in parallel or when acceleration is needed, with explicit module boundaries and branch ownership.
-model: inherit
 mode: subagent
 tools:
   write: true

package/harness-agents/fullstack-dev.md

@@ -3,7 +3,6 @@ name: fullstack-dev
 description: |-
   全栈开发工程师 - 后端主导的全栈实现（API/业务/数据层）。UI 重或新页面多时由 PM 拆给 `@frontend-dev`；第二并行实现轨用 `@fullstack-dev-2`。Hotfix/单流小改可一人完成。
   Fullstack Developer - backend-led fullstack implementation (API/business/data). PM should split UI-heavy or new-page work to `@frontend-dev`, and use `@fullstack-dev-2` for the second parallel track. One developer can handle hotfixes or small single-stream updates.
-model: inherit
 mode: subagent
 tools:
   write: true

package/harness-agents/ops-engineer.md

@@ -3,7 +3,6 @@ name: ops-engineer
 description: |-
   运维工程师 - 部署、监控和基础设施。
   Ops Engineer - deployment, monitoring, and infrastructure operations, including CI/CD and observability.
-model: inherit
 mode: subagent
 tools:
   write: true

package/harness-agents/product-manager.md

@@ -3,7 +3,6 @@ name: product-manager
 description: |-
   产品经理 - 需求分析、产品规划、市场/用户研究与产品向文档编写。
   Product Manager - requirements analysis, product planning, market/user research, and product-facing documentation.
-model: inherit
 mode: subagent
 tools:
   write: true

package/harness-agents/project-manager.md

@@ -3,7 +3,6 @@ name: project-manager
 description: |-
   项目经理 - 协调开发团队，管理项目进度。
   Project Manager - coordinate the team, track progress, and orchestrate execution across roles.
-model: inherit
 mode: primary
 tools:
   write: true

package/harness-agents/prompt-engineer.md

@@ -3,7 +3,6 @@ name: prompt-engineer
 description: |-
   提示词工程师 - 设计与优化 Agent 提示词与技能。
   Prompt Engineer - design and optimize prompts and skills for agents, including refactoring and debugging prompt systems.
-model: inherit
 mode: subagent
 tools:
   write: true

package/harness-agents/qa-engineer.md

@@ -3,7 +3,6 @@ name: qa-engineer
 description: |-
   测试工程师 - 编写测试用例和自动化测试。
   QA Engineer - test planning, automated tests, coverage improvements, and regression protection.
-model: inherit
 mode: subagent
 tools:
   write: true

package/harness-agents/qc-specialist-2.md

@@ -3,7 +3,6 @@ name: qc-specialist-2
 description: |-
   质量控制专家（Reviewer #2）- 代码审查和质量保证。
   Quality Control Specialist (Reviewer #2) - code review and quality assurance after significant changes.
-model: inherit
 mode: subagent
 tools:
   write: true

package/harness-agents/qc-specialist-3.md

@@ -3,7 +3,6 @@ name: qc-specialist-3
 description: |-
   质量控制专家（Reviewer #3）- 代码审查和质量保证。
   Quality Control Specialist (Reviewer #3) - code review and quality assurance after significant changes.
-model: inherit
 mode: subagent
 tools:
   write: true

package/harness-agents/qc-specialist.md

@@ -3,7 +3,6 @@ name: qc-specialist
 description: |-
   质量控制专家（Reviewer #1）- 代码审查和质量保证。
   Quality Control Specialist (Reviewer #1) - code review and quality assurance after significant changes.
-model: inherit
 mode: subagent
 tools:
   write: true

package/harness-agents/writing-specialist.md

@@ -3,7 +3,6 @@ name: writing-specialist
 description: |-
   写作专家 - 文档写作、小说写作、文案写作与脚本写作。
   Writing Specialist - documentation, fiction, copywriting, and script writing.
-model: inherit
 mode: subagent
 tools:
   write: true

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

@@ -0,0 +1,143 @@
+---
+name: mstar-design-md
+description: DESIGN.md design system specification for Morning Star projects. Create, audit, and maintain project-level design tokens (Colors, Typography, Spacing, Elevation, Motion, Shapes, Components, Voice & Content) using Vercel Geist as reference template. Three-level completeness checklist (MVP/Standard/Production) with built-in upgrade placeholders. Supports light/dark dual-theme via DESIGN.md + DESIGN.dark.md sharing same token names with different values. Prepare 阶段由 @architect 主责创建，@product-manager 提供设计需求；@frontend-dev / @fullstack-dev 实现 UI 时消费；@qc-specialist / @qa-engineer 审查 UI 对齐 DESIGN.md。Read when PM assigns DESIGN.md creation in Prepare, initiating a new UI project, @architect defining a design system, implementing styled components, auditing UI against design spec, adding dark theme, or user mentions "DESIGN.md" / "design tokens" / "design system". Phase gate → **mstar-phase-gates**; paths → **mstar-plan-conventions**.
+---
+
+## Load order
+
+**Before first Read of this skill: Read `mstar-harness-core` (SKILL.md).** For Prepare phase integration and gate rules, read `mstar-phase-gates`. For plan directory paths (`{HARNESS_DIR}`, `{SPECS_DIR}`), read `mstar-plan-conventions`. On conflict, **`mstar-harness-core` wins**.
+
+| 你还可能要 Read | 何时 |
+|-----------------|------|
+| `mstar-phase-gates` | Prepare 阶段判定 gate、何时 DESIGN.md 必须就绪 |
+| `mstar-plan-conventions` | `{HARNESS_DIR}` / `{SPECS_DIR}` 路径解析 |
+| `mstar-roles` | `@architect` / `@product-manager` / `@frontend-dev` / `@qc-specialist` / `@qa-engineer` 角色职责边界 |
+| `mstar-coding-behavior` | 实现角色消费 DESIGN.md 前的通用编码约束 |
+
+## Scope (DESIGN.md lifecycle)
+
+| Topic | See |
+|-------|-----|
+| Normative spec: section definitions, token naming, light/dark rules | `references/design-md-spec.md` |
+| Three-level completeness checklist (MVP / Standard / Production) | `references/completeness-checklist.md` |
+| Vercel Geist DESIGN.md as annotated reference | `references/vercel-example.md` |
+| Full template with Level 2/3 placeholders | `templates/DESIGN.md.template` |
+| Dark theme template (same token names, different values) | `templates/DESIGN.dark.md.template` |
+
+**Out of scope:** rendered UI artifacts (use Open Design MCP `user-open-design`); frontend implementation that consumes DESIGN.md tokens (use `@frontend-dev` / `@fullstack-dev`); QC review verdict rules (→ **`mstar-review-qc`**).
+
+## Location
+
+- **Primary**: project root `DESIGN.md` (human + agent visible, aligns with `AGENTS.md`)
+- **Dark theme**: project root `DESIGN.dark.md` (same token names, different values)
+- `DESIGN.md` is a **project-level design contract**, not a harness internal artifact. It lives beside `README.md` and `AGENTS.md`.
+
+## Role lifecycle
+
+### Creator: `@architect` (primary) + `@product-manager` (requirements)
+
+`@architect` owns DESIGN.md content — token selection, naming, completeness level decisions. `@product-manager` provides design intent: brand identity, target audience, must-have UI patterns, accessibility requirements.
+
+### Orchestrator: `@project-manager`
+
+In Prepare phase, PM decides whether the project needs a DESIGN.md. If yes, dispatches to `@architect` with product requirements from `@product-manager`. PM checks DESIGN.md exists and meets the assigned completeness level before `plan(locked)`.
+
+### Consumers
+
+- `@frontend-dev` / `@fullstack-dev` — read DESIGN.md before implementing styled components; map tokens to CSS/theme variables
+- `@qc-specialist` — verify UI implementation aligns with DESIGN.md tokens
+- `@qa-engineer` — verify visual output matches design spec
+
+## Phase gate integration
+
+DESIGN.md is a **Prepare-stage artifact** (like spec). It must be created and reviewed before `plan(locked)` for any plan that includes UI work.
+
+1. PM includes "DESIGN.md creation/audit" in Prepare tracking checklist when the plan involves UI
+2. `@architect` creates or updates DESIGN.md; `@product-manager` reviews design intent alignment
+3. PM gates on: DESIGN.md exists, meets completeness level declared in plan, `@product-manager` signed off
+
+For **hotfix** or plans with no UI changes, DESIGN.md check may be skipped.
+
+## Completeness levels
+
+DESIGN.md supports three levels, each with built-in upgrade path:
+
+1. **Level 1 — MVP** (minimal, prevents guesswork): palette, base typography, spacing scale
+2. **Level 2 — Standard** (consistent components): full token scales, breakpoints, component tokens (Button, Input)
+3. **Level 3 — Production** (complete design system): dual theme, elevation, motion, shapes, component library, voice
+
+The template includes all levels; Level 2 and 3 sections are commented out with `<!-- LEVEL2_PLACEHOLDER: ... -->` markers that explain when to activate them. The audit workflow detects these placeholders and can recommend upgrade.
+
+Full checklist → `references/completeness-checklist.md`.
+
+## Workflows
+
+### Workflow 1: Create DESIGN.md (Prepare phase)
+
+1. Read `references/design-md-spec.md` for section definitions
+2. Copy `templates/DESIGN.md.template` to `{PROJECT_ROOT}/DESIGN.md`
+3. Interview `@product-manager` for brand colors, typography preferences, must-have patterns
+4. Fill Level 1 sections; leave Level 2/3 as-is (commented placeholders)
+5. If plan requires Level 2+ out of the gate, fill those sections too
+6. Run the completeness audit workflow below to confirm level
+7. Report to PM: path created, level achieved, what's needed for next level
+
+### Workflow 2: Audit DESIGN.md completeness
+
+1. Read `DESIGN.md` and `DESIGN.dark.md` (if exists)
+2. Load `references/completeness-checklist.md`
+3. Check each checklist item; note gaps
+4. Report:
+   - Current completeness level
+   - Gaps preventing next level
+   - Presence of upgrade placeholders (`LEVEL2_PLACEHOLDER`, `LEVEL3_PLACEHOLDER`)
+   - Recommendation: whether to upgrade now or defer
+5. Update DESIGN.md level tag (e.g., `<!-- COMPLETENESS_LEVEL: 1 -->`) if changed
+
+### Workflow 3: Add dark theme
+
+1. Read existing `DESIGN.md` to extract token names
+2. Copy `templates/DESIGN.dark.md.template` to `{PROJECT_ROOT}/DESIGN.dark.md`
+3. For each token in DESIGN.md, define the dark-theme equivalent value
+4. Preserve same token names; only values change (see `references/design-md-spec.md` § Light/Dark rules)
+5. Audit with Workflow 2 to confirm Level 3 completeness
+
+### Workflow 4: Consume DESIGN.md (implementation roles)
+
+Before writing styled UI code:
+1. Read `DESIGN.md` (and `DESIGN.dark.md` if exists)
+2. Extract tokens into implementation layer (CSS custom properties, Tailwind config, theme object, etc.)
+3. Follow DESIGN.md Voice & Content rules for copy text
+4. If DESIGN.md is missing or incomplete, report to PM — do not guess tokens
+
+## Light/Dark dual-theme rules
+
+Dual theme uses **same token names, different values** across two files:
+
+```
+DESIGN.md         DESIGN.dark.md
+-----------       --------------
+gray-100: #fff    gray-100: #111
+gray-1000: #000   gray-1000: #eee
+```
+
+- Token names are the **SSOT interface** — consumers reference tokens by name, not raw values
+- `references/design-md-spec.md` § Light/Dark rules defines the contract
+
+## Open Design integration
+
+If `user-open-design` MCP is available:
+- DESIGN.md is the **design intent** (tokens + rules)
+- Open Design manages **rendered artifacts** (HTML/CSS/JSX previews)
+- When DESIGN.md is updated, recommend syncing the Open Design project to reflect new tokens
+- DESIGN.md does not replace Open Design; they are complementary
+
+## References
+
+- `references/design-md-spec.md` — normative spec: section definitions, token naming conventions, light/dark contract
+- `references/completeness-checklist.md` — three-level audit checklist with detailed criteria per level
+- `references/vercel-example.md` — Vercel Geist DESIGN.md as annotated reference (read when creating from scratch or needing design inspiration)
+
+**Templates (this skill):**
+- `templates/DESIGN.md.template` — full template including all Level 1-3 sections with placeholder comments
+- `templates/DESIGN.dark.md.template` — dark theme template with same token names, different values

package/harness-skills/mstar-design-md/references/completeness-checklist.md

@@ -0,0 +1,175 @@
+# DESIGN.md Completeness Checklist
+
+Three-level progressive checklist for evaluating whether a `DESIGN.md` is sufficient to drive agent UI generation. Each level builds on the previous level's requirements.
+
+## How to use
+
+1. Read `DESIGN.md` (and `DESIGN.dark.md` if exists)
+2. Check each item in the target level (and all lower levels)
+3. An item is **complete** only when concrete values exist — placeholder comments do not count
+4. A `DESIGN.md` is at **Level N** when all items in Level N and below are complete
+5. Record the result in a comment at the top of DESIGN.md:
+
+```
+<!-- COMPLETENESS_LEVEL: N — last audited YYYY-MM-DD -->
+```
+
+## Level 1 — MVP (prevents guesswork)
+
+The minimum bar for an agent to produce UI without hallucinating colors and typography. Sufficient for early-stage projects, prototypes, and CLI tools with minimal UI.
+
+### Checklist
+
+- [ ] **Overview** — design system name and aesthetic principles stated
+- [ ] **Colors — Background** — at least one surface color (`background-100`)
+- [ ] **Colors — Text** — at least one text color (`gray-1000` or equivalent)
+- [ ] **Colors — Accent** — at least one accent color for links/actions (`blue*` or brand equivalent)
+- [ ] **Colors — Semantic** — at least one error color (`red*`) and warning color (`amber*`)
+- [ ] **Typography — Body** — at least one body text token with font family, size, weight, line height
+- [ ] **Typography — Heading** — at least one heading token
+- [ ] **Spacing** — base unit declared (4px or 8px) and at least 5 scale steps
+- [ ] **Breakpoints** — at least 2 responsive breakpoints defined
+
+### What an agent CAN do at Level 1
+
+- Style a basic page with correct brand colors
+- Choose readable typography
+- Apply consistent spacing
+- Make a responsive layout that works on mobile and desktop
+- Signal errors with the correct color
+
+### What an agent CANNOT do at Level 1
+
+- Build a consistent component library (no component tokens)
+- Apply elevation/shadow correctly (will guess)
+- Use motion responsibly (will guess)
+- Generate dark mode (no DESIGN.dark.md)
+- Apply voice rules to copy text
+
+### Verdict
+
+- **All 9 items checked → Level 1 complete**
+- **Missing items → below Level 1 (insufficient for agent UI generation)**
+
+## Level 2 — Standard (consistent components)
+
+Sufficient for building a consistent, polished UI with reusable components. The expected level for production codebases with a frontend.
+
+Prerequisite: Level 1 complete.
+
+### Checklist
+
+- All Level 1 items complete
+- [ ] **Colors — Full background scale** — `background-100` through at least `background-300`
+- [ ] **Colors — Full gray solid scale** — `gray-100` through `gray-1000` (10 steps)
+- [ ] **Colors — Gray alpha scale** — at least `gray-alpha-100` through `gray-alpha-600`
+- [ ] **Colors — All accent scales** — `blue`, `red`, `amber`, `green`, `teal`, `purple`, `pink` with at least `700`/`800`/`900`/`1000` steps each
+- [ ] **Typography — Headings** — at least 3 heading levels (e.g., `heading-32`, `heading-24`, `heading-20`)
+- [ ] **Typography — Labels** — at least one label token
+- [ ] **Typography — Buttons** — at least one button typography token
+- [ ] **Spacing** — full 9-step scale (4, 8, 12, 16, 24, 32, 40, 64, 96px) and three-step rhythm documented
+- [ ] **Breakpoints** — at least 4 breakpoints
+- [ ] **Components — Button** — at least primary and secondary variants with size variants (default 40px, small 32px), plus hover/active/disabled/focus states
+- [ ] **Components — Input** — at least default variant with size variants, plus hover/active/disabled/focus/error states
+
+### What an agent CAN do at Level 2
+
+- Everything from Level 1
+- Build a consistent Button component with all states
+- Build a consistent Input component with all states
+- Use the full color scale for nuanced visual hierarchy
+- Apply correct typography to every text role
+- Use translucent overlays and borders (alpha scale)
+- Pick the right accent color for each semantic purpose
+
+### What an agent CANNOT do at Level 2
+
+- Generate dark mode (no DESIGN.dark.md)
+- Apply elevation/shadows with confidence (may guess)
+- Use motion consistently (may guess)
+- Enforce voice rules on copy text
+- Know the correct border radius for each component type
+
+### Verdict
+
+- **All 11 items checked (on top of Level 1) → Level 2 complete**
+- **1–3 items missing → Level 2 partial; useable but expect component inconsistencies**
+- **4+ items missing → below Level 2; recommend completing Level 1 only deploy**
+
+## Level 3 — Production (complete design system)
+
+Full design system ready for production at scale. Includes dual theme, motion, and voice.
+
+Prerequisite: Level 2 complete.
+
+### Checklist
+
+- All Level 1 and Level 2 items complete
+- [ ] **DESIGN.dark.md exists** — dark theme file with same token names, dark-appropriate values
+- [ ] **Dark theme covers all tokens** — every token in DESIGN.md has a corresponding entry in DESIGN.dark.md
+- [ ] **Elevation — Shadows** — at least 3 elevation levels (card, popover, modal) with explicit `box-shadow` values
+- [ ] **Motion — Easing** — easing curve declared
+- [ ] **Motion — Durations** — at least state change, popover, modal durations
+- [ ] **Motion — Reduced motion** — `prefers-reduced-motion` rule declared
+- [ ] **Shapes — Border radius** — at least 4 radius tokens (surface/input, menu/modal, fullscreen, pill)
+- [ ] **Components — Full library** — at least Card, Modal, Tooltip, Menu/Dropdown tokens
+- [ ] **Voice & Content** — writing rules documented: casing conventions, action naming, error format, toast format, empty state format
+
+### What an agent CAN do at Level 3
+
+- Everything from Levels 1 and 2
+- Generate dark-mode-compatible UI
+- Apply elevation correctly for every UI layer
+- Animate state changes consistently
+- Apply correct border radius per element type
+- Write correct microcopy (button labels, errors, toasts, empty states)
+- Build a full component library (Card, Modal, Tooltip, Menu)
+
+### Verdict
+
+- **All 9 items checked → Level 3 complete (production-ready)**
+- **DESIGN.dark.md missing but rest complete → Level 2+ (partial Level 3, no dark mode)**
+
+## Audit workflow
+
+### When auditing existing DESIGN.md
+
+1. Load the DESIGN.md file
+2. Start at Level 1 checklist — check each item against actual content
+3. If Level 1 complete, proceed to Level 2
+4. If Level 2 complete, proceed to Level 3
+5. Record the level as `<!-- COMPLETENESS_LEVEL: N -->` at top of DESIGN.md
+6. For each incomplete item, note what's missing and which level it belongs to
+7. Check for `LEVEL2_PLACEHOLDER` / `LEVEL3_PLACEHOLDER` markers — if present and the project is ready for upgrade, recommend activation
+
+### When creating new DESIGN.md
+
+1. Decide target level with PM/architect:
+   - Prototype / early project → Level 1
+   - Production frontend → Level 2
+   - Full design system → Level 3
+2. Copy the template from `templates/DESIGN.md.template`
+3. Fill all items in the target level
+4. Run this checklist to confirm
+5. Leave higher-level placeholders as-is
+
+### When upgrading DESIGN.md
+
+1. Read current DESIGN.md and note the level tag
+2. Identify which items in the next level are missing
+3. For each missing item, either:
+   - Fill with concrete values if known
+   - Leave the `LEVEL*_PLACEHOLDER` marker if deferred
+4. Re-audit and update the level tag
+
+## Upgrade trigger conditions
+
+Agents encountering a DESIGN.md with placeholders should evaluate these conditions:
+
+| Condition | Action |
+|-----------|--------|
+| `LEVEL2_PLACEHOLDER` found AND plan includes component work | Recommend completing the Level 2 sections |
+| `LEVEL3_PLACEHOLDER` found AND plan includes dark mode | Recommend creating DESIGN.dark.md |
+| `LEVEL3_PLACEHOLDER` found AND plan targets production release | Recommend completing Level 3 |
+| `COMPLETENESS_LEVEL: 1` AND project has >3 UI views | Recommend upgrading to Level 2 |
+| `COMPLETENESS_LEVEL: 2` AND project has dark mode requirement | Recommend upgrading to Level 3 |