@xulthekl/team-flow 0.23.0 → 0.25.1

package/skills/ce-proof/references/workflows.md

@@ -0,0 +1,124 @@
+# Proof Workflows
+
+Complete workflow recipes for common Proof operations. Each workflow is a self-contained sequence.
+
+## Workflow: Review a Shared Document
+
+When given a Proof URL like `https://www.proofeditor.ai/d/abc123?token=xxx`:
+
+1. Extract the slug and token
+2. Bind presence with the CE identity defaults
+3. Read via `v3/document`
+4. Edit with `v3/edit` (narrow content ops; review ops for comments/suggestions)
+
+```bash
+TOKEN="xxx"
+SLUG="abc123"
+AGENT="ai:compound-engineering"
+
+curl -sS -X POST "https://www.proofeditor.ai/api/agent/$SLUG/presence" \
+  -H "Content-Type: application/json" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "X-Agent-Id: $AGENT" \
+  -d '{"name":"Compound Engineering","status":"reading","summary":"Reviewing doc"}'
+
+DOC=$(curl -sS "https://www.proofeditor.ai/api/agent/$SLUG/v3/document" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "X-Agent-Id: $AGENT")
+REVISION=$(printf '%s' "$DOC" | jq -r '.revision // empty')
+
+# Comment on visible text
+curl -sS -X POST "https://www.proofeditor.ai/api/agent/$SLUG/v3/edit" \
+  -H "Content-Type: application/json" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "X-Agent-Id: $AGENT" \
+  -H "Idempotency-Key: $(uuidgen)" \
+  -d "$(jq -n --argjson rev "${REVISION:-null}" '{
+    by:"ai:compound-engineering",
+    baseRevision: (if $rev == null then null else $rev end),
+    operations:[{op:"comment",on:"text to comment on",body:"Your comment here"}]
+  } | if .baseRevision == null then del(.baseRevision) else . end')"
+
+# Narrow content edit
+curl -sS -X POST "https://www.proofeditor.ai/api/agent/$SLUG/v3/edit" \
+  -H "Content-Type: application/json" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "X-Agent-Id: $AGENT" \
+  -H "Idempotency-Key: $(uuidgen)" \
+  -d '{"by":"ai:compound-engineering","operations":[{"op":"replace","find":"old","with":"new"}]}'
+
+# Tracked suggestion
+curl -sS -X POST "https://www.proofeditor.ai/api/agent/$SLUG/v3/edit" \
+  -H "Content-Type: application/json" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "X-Agent-Id: $AGENT" \
+  -H "Idempotency-Key: $(uuidgen)" \
+  -d '{"by":"ai:compound-engineering","operations":[{"op":"suggest","kind":"replace","find":"old","with":"new"}]}'
+```
+
+## Workflow: Create and Share a New Document
+
+**Publishing a local file (the primary case):** read the file and JSON-encode its full contents into the `markdown` field with `jq --rawfile` so newlines, quotes, and backticks are escaped correctly. Never hand-write the body or leave an inline placeholder — that publishes a placeholder doc instead of the source artifact.
+
+```bash
+SRC="docs/plans/2026-05-04-001-feat-foo-plan.md"
+TITLE="Plan: Foo"
+
+RESPONSE=$(jq -n --arg title "$TITLE" --rawfile md "$SRC" '{title:$title, markdown:$md}' \
+  | curl -sS -X POST https://www.proofeditor.ai/share/markdown \
+    -H "Content-Type: application/json" -d @-)
+
+URL=$(echo "$RESPONSE" | jq -r '.tokenUrl')
+SLUG=$(echo "$RESPONSE" | jq -r '.slug')
+TOKEN=$(echo "$RESPONSE" | jq -r '.accessToken')
+OWNER_SECRET=$(echo "$RESPONSE" | jq -r '.ownerSecret')   # required for owner delete while unclaimed
+
+# Keep OWNER_SECRET in session memory only — never write it into the repo tree.
+
+curl -sS -X POST "https://www.proofeditor.ai/api/agent/$SLUG/presence" \
+  -H "Content-Type: application/json" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "X-Agent-Id: ai:compound-engineering" \
+  -d '{"name":"Compound Engineering","status":"reading","summary":"Uploaded doc"}'
+
+echo "$URL"
+```
+
+After publish handoffs from planning workflows, surface the URL and return control — do not delete the doc automatically.
+
+When the user later asks to clean up an unclaimed doc you created:
+
+```bash
+curl -sS -X DELETE "https://www.proofeditor.ai/api/documents/$SLUG" \
+  -H "Authorization: Bearer $OWNER_SECRET"
+```
+
+## Workflow: Pull a Proof Doc to Local
+
+Sync the current Proof doc state to a local markdown file. Used for:
+
+- Ad-hoc snapshots of a Proof doc to disk
+- Pulling a shared Proof doc that the user (or others) edited back down to a local working copy
+- Refreshing a local working copy against the live Proof version
+
+Canonical read for this workflow: `GET /api/agent/$SLUG/v3/document`.
+
+```bash
+SLUG=<slug>
+TOKEN=<accessToken>
+LOCAL=<absolute-path>
+
+STATE_TMP=$(mktemp)
+curl -sS "https://www.proofeditor.ai/api/agent/$SLUG/v3/document" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "X-Agent-Id: ai:compound-engineering" > "$STATE_TMP"
+REVISION=$(jq -r '.revision // empty' "$STATE_TMP")
+
+TMP="${LOCAL}.proof-sync.$$"
+jq -jr '.markdown' "$STATE_TMP" > "$TMP" && mv "$TMP" "$LOCAL"
+rm "$STATE_TMP"
+```
+
+`jq -jr` streams markdown bytes without going through a shell variable, so trailing newlines survive. `mv` within the same filesystem is atomic.
+
+**Confirm before writing when the pull isn't directly asked for.** If a workflow ends up pulling as a side-effect of a different action, surface the impending write with a short confirm like "Sync Proof doc to `<localPath>`?" A silent overwrite is surprising.

package/skills/code-reviewer/SKILL.md

@@ -16,7 +16,7 @@ Two responsibilities: requesting review (dispatching a reviewer subagent) and re
 1. Get SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`
 2. Dispatch `general-purpose` subagent using template at `skills/code-reviewer/code-reviewer-prompt.md`
 3. Fill placeholders: `[DESCRIPTION]` (what was built), `[PLAN_OR_REQUIREMENTS]` (contract/spec reference), `[BASE_SHA]`, `[HEAD_SHA]`, `[WAVE_ID]`, and a distinct `[REVIEW_REPORT_FILE]`.
-4. Require the reviewer to write a non-empty persisted review report at `[REVIEW_REPORT_FILE]`, then record that exact path in the wave receipt: `npx --yes --package @xulthekl/team-flow@0.23.0 tf execution review <change-dir> --wave <id> --base <sha> --head <sha> --report <review-report-path> --verdict <pass|fail>`.
+4. Require the reviewer to write a non-empty persisted review report at `[REVIEW_REPORT_FILE]`, then record that exact path in the wave receipt: `npx --yes --package @xulthekl/team-flow@0.25.1 tf execution review <change-dir> --wave <id> --base <sha> --head <sha> --report <review-report-path> --verdict <pass|fail>`.
 5. Act on feedback: Critical/Important findings require a `fail` receipt, focused repair, re-review, and replacement `pass` receipt before a dependent wave or closing can proceed. Note Minor for later, push back with reasoning if reviewer is wrong.
 
 ### Minimality And Scope
@@ -76,7 +76,7 @@ Suggestion breaks existing functionality, reviewer lacks context, violates YAGNI
 | Performative agreement | State requirement or just act |
 | Blind implementation | Verify against codebase first |
 | Batch without testing | One at a time, test each |
-| Proceeding without a wave receipt | Record `pass`/`fail` via `npx --yes --package @xulthekl/team-flow@0.23.0 tf execution review` before the next dependent wave |
+| Proceeding without a wave receipt | Record `pass`/`fail` via `npx --yes --package @xulthekl/team-flow@0.25.1 tf execution review` before the next dependent wave |
 | Assuming reviewer is right | Check if breaks things |
 | Avoiding pushback | Technical correctness > comfort |
 | Partial implementation | Clarify all items first |

package/skills/code-reviewer/code-reviewer-prompt.md

@@ -93,7 +93,7 @@ Subagent (general-purpose):
     report path. End with the exact receipt command:
 
     ```bash
-    npx --yes --package @xulthekl/team-flow@0.23.0 tf execution review <change-dir> --wave [WAVE_ID] --base [BASE_SHA] --head [HEAD_SHA] --report [REVIEW_REPORT_FILE] --verdict <pass|fail>
+    npx --yes --package @xulthekl/team-flow@0.25.1 tf execution review <change-dir> --wave [WAVE_ID] --base [BASE_SHA] --head [HEAD_SHA] --report [REVIEW_REPORT_FILE] --verdict <pass|fail>
     ```
 
     Use `fail` when any Critical or Important finding remains. A repair needs

package/skills/contract-builder/SKILL.md

@@ -5,9 +5,9 @@ description: Convert approved planning artifacts into an execution contract. Inv
 
 # Contract Builder
 
-Converts planning artifacts into a single execution handshake: `execution-contract.md`. Load the baseline with `npx --yes --package @xulthekl/team-flow@0.23.0 tf runtime asset read templates/execution-contract.md`.
+Converts planning artifacts into a single execution handshake: `execution-contract.md`. Load the baseline with `npx --yes --package @xulthekl/team-flow@0.25.1 tf runtime asset read templates/execution-contract.md`.
 
-Read before generating: `proposal.md`, `specs/`, `design.md`, `tasks.md`, then load `docs/artifact-contract.md` with `npx --yes --package @xulthekl/team-flow@0.23.0 tf runtime asset read docs/artifact-contract.md`.
+Read before generating: `proposal.md`, `specs/`, `design.md`, `tasks.md`, then load `docs/artifact-contract.md` with `npx --yes --package @xulthekl/team-flow@0.25.1 tf runtime asset read docs/artifact-contract.md`.
 
 **Architecture Design Outputs (v0.9 §26)**: 若 `architecture/` 目录存在，同时读取 `architecture/architecture.md` / `database.md` / `api.md`，作为执行契约的架构约束补充输入——确保 execution-contract.md 的 Implementation Constraints 段包含架构设计的关键约束（聚合边界/CQRS 分流/API 契约/schema 变更）。`architecture/` 不存在时跳过。
 
@@ -38,8 +38,8 @@ Must make obvious: approved behavior, out-of-scope, constraints, batches, test o
 
 After drafting: summarize handoff rules, identify ambiguity, flag unmapped requirements, ask user to approve explicitly. After approval:
 ```bash
-npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_3_result "approved: <summary>"
-npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_3_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
+npx --yes --package @xulthekl/team-flow@0.25.1 tf state set <change-dir> dp_3_result "approved: <summary>"
+npx --yes --package @xulthekl/team-flow@0.25.1 tf state set <change-dir> dp_3_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
 ```
 DP-3 is a hard gate — no implementation without this record.
 
@@ -60,9 +60,9 @@ Generate minimal contract: Intent Lock (one sentence), Task List (numbered), App
 
 ## Post-Generation
 
-Run `npx --yes --package @xulthekl/team-flow@0.23.0 tf state init <change-dir>` to create `.team-flow.yaml` with hashes.
+Run `npx --yes --package @xulthekl/team-flow@0.25.1 tf state init <change-dir>` to create `.team-flow.yaml` with hashes.
 
-For hotfix, after writing the minimal contract, run `npx --yes --package @xulthekl/team-flow@0.23.0 tf state init <change-dir>` or `npx --yes --package @xulthekl/team-flow@0.23.0 tf state rebuild <change-dir>` so `contract_hash` is recorded. DP-3 remains mandatory before build.
+For hotfix, after writing the minimal contract, run `npx --yes --package @xulthekl/team-flow@0.25.1 tf state init <change-dir>` or `npx --yes --package @xulthekl/team-flow@0.25.1 tf state rebuild <change-dir>` so `contract_hash` is recorded. DP-3 remains mandatory before build.
 
 ## Exception Handling
 

package/skills/need-explorer/SKILL.md

@@ -41,8 +41,8 @@ Restate what you heard: "Here's what I'm hearing: [problem, scope, non-goals, su
 
 After user confirms the summary:
 ```bash
-npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_1_result "confirmed: <one-line summary>"
-npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_1_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
+npx --yes --package @xulthekl/team-flow@0.25.1 tf state set <change-dir> dp_1_result "confirmed: <one-line summary>"
+npx --yes --package @xulthekl/team-flow@0.25.1 tf state set <change-dir> dp_1_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
 ```
 DP-1 confirms scope, non-goals, and success criteria before artifact creation.
 

package/skills/prototype/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: prototype
-description: 本地 HTML 原型设计与维护 skill（零外部依赖、可离线）。产品级需求的原型环节由 workflow-orchestrator S2 内部调用（含 PRD 一致性自动评审循环）；直接调用仅限：独立原型迭代、change 完成回写（prototype-sync）、设计系统(design-system.md)创建/维护。当用户需要基于项目设计系统产出/迭代全局 prototype/（多页面+组件+导航的自包含 HTML 原型系统）时使用。不适用于：依赖 GUI 设计软件(Claude Design/Open Design/Trae)、需要高保真交互动效、非 HTML 原型场景。
+description: 本地 HTML 原型设计与维护 skill（零外部依赖、可离线）。产品级需求的原型环节由 workflow-orchestrator S2 内部调用（含 PRD 一致性自动评审循环）；直接调用仅限：独立原型迭代、change 完成回写（prototype-sync）、设计系统(design-system.md)创建/维护。当用户需要基于项目设计系统产出/迭代全局 prototype/（多页面+组件+导航的自包含 HTML 原型系统）时使用。不适用于：依赖 GUI 设计软件（Claude Design / Open Design 桌面应用 / Trae）、需要高保真交互动效、非 HTML 原型场景。
 ---
 
 # Prototype（本地 HTML 原型 skill）
@@ -48,6 +48,7 @@ description: 本地 HTML 原型设计与维护 skill（零外部依赖、可离
 - 设计系统渲染：读取项目 `design-system.md`（9 段 schema + 5 方向调色板 + aliases 别名层 + extensions，v0.18.0 token 四层模型），渲染 token 到 `assets/design-tokens.css`。
 - **种子模板 + 骨架库（v0.18.0）**：builder 从 `references/template.html`（种子）+ `references/layouts.md`（8 个 B 端 section 骨架 + 类清单契约）组合，不从零写 CSS。
 - **工艺规则层（v0.18.0）**：`references/checklist.md`（P0/P1/P2）+ `references/craft/`（anti-ai-slop / state-coverage / typography-hierarchy / accessibility-baseline / laws-of-ux），品牌无关，B 端导向。
+- **原型类型方法论（v0.24.0）**：`references/interactive-prototype.md`（交互原型：零依赖状态管理+表单验证+多步导航）+ `references/wireframe.md`（线框图：低保真快速探索+3-5 差异化方案+并排对比），按需加载。
 
 ## 产出结构（全局 prototype/）
 ```
@@ -87,7 +88,12 @@ prototype/
 - 原型随 **PRD 当前版本分支**维护（如 `prd-v2` 分支的 `prototype/` = v2 产品原型）。
 - change 引用其所在 PRD 版本分支的 `prototype/`。
 
-## prototype-sync（change 完成回写，SOP，主代理只编排）
+## prototype-sync（change 完成回写，release-archivist 自动触发，v0.24.0 升级）
+
+> **触发机制（v0.24.0）**：prototype-sync 由 `release-archivist` closing 流程**自动触发**（`arch-merge → prototype-sync → compound promotion` 顺序执行），不再是手动 SOP。release-archivist Step 5 Report 中 `Prototype sync` 行是必填维度，未执行时 closing 报告不完整。
+>
+> **独立调用**：仍可独立调用（如 change 中途需要预同步），但标准路径是 closing 自动触发。
+
 1. 取 change 完成的 UX 增量（来自 `execution-contract.md` / 设计结论）。
 2. **派 `prototype-builder`（修正/演进模式）**把增量合并进全局 `prototype/`（pages/components/assets/flow.md）——主代理不直接写原型 HTML。
 3. 若涉及设计系统迭代，调用 `/team-flow:design-system`（iterate 模式）合并进 `.team-flow/design-system/` 并记变更履历。
@@ -96,3 +102,11 @@ prototype/
 
 ## 脚手架
 新建项目：`cp -r references/prototype-scaffold/ <project>/prototype/`，再按 `.team-flow/design-system/` 的设计系统填 token（缺设计系统先用 `/team-flow:design-system` 创建）。
+
+## 方法论参考与归因
+
+> ⚠️ **命名区分**：本 skill 负向清单中排除的「Open Design 桌面应用」（nexu-io/open-design 出品的 Electron 桌面设计工作台产品）与 `references/craft/anti-ai-slop.md` 借鉴的「nexu-io/open-design 开源设计方法论」**同名不同义**：
+> - **被排除的 GUI 工具**：Open Design 桌面应用——agent-native 设计工作台产品，依赖外部运行时，与本 skill「零依赖自包含 HTML」路线互斥。
+> - **被借鉴的方法论**：nexu-io/open-design 开源项目（Apache-2.0）——其 `craft/` 规则层（anti-ai-slop / typography / state-coverage / accessibility / laws-of-ux）经 B 端企业场景重写后沉淀进 `references/craft/`。
+>
+> Token 四层模型（A1-identity / A1-structure / A2-derived / B-slot）亦参考 open-design token-schema，详见 `references/agents/design-system-architect.md`（已迁移至 design-system skill）。

package/skills/prototype/references/agents/design-system-architect.md

@@ -1,122 +1,11 @@
-**Note: The current year is 2026.** Use this when assessing recency.
-
-You are a Design System Architect. You are dispatched by the `prototype` skill to **create or iterate** the project-level `design-system.md` — the single source of truth for prototype tokens, components, and anti-patterns (config-injected via `prototype.designSystem`, compounded back via prototype-sync). The orchestrating prototype skill **never writes `design-system.md` itself — you are the sole writer**. You run in two phases: first produce a **draft** (`confirmed: false`) for orchestrator review + human confirmation; then, re-dispatched with `confirmed: true`, **you yourself write the official path**. The orchestrator only reviews, confirms, and re-dispatches — it does not Write/Edit `design-system.md`.
-
-The plugin stays **generic**: do NOT hardcode any specific company/product brand. Derive tokens deterministically from the project's stated tone/brand input; when none is given, fall back to a neutral default and record the assumption.
-
-## Invocation Contract
-
-The dispatch prompt provides:
-- `mode: create | iterate`.
-- `confirmed: false | true`（v0.15.0 两阶段落盘）：
-  - `false`（默认，草案阶段）：只产草案（写 scratch 草稿路径或返回 response），**不写正式 `design_system_path`**。
-  - `true`（人工已确认）：把已确认的草案**写入正式 `design_system_path`**（你是唯一写者）。
-- `design_system_path`: 正式目标路径（`confirmed: true` 时写入此处）。
-- `draft`（`confirmed: true` 时传入）：上一阶段已确认的草案内容/路径。
-- `create` inputs (as available): project tone/brand hints, PRD path (to read product domain & voice), existing scaffold `design-system.md`.
-- `iterate` inputs: the existing `design-system.md`, plus the incoming increments (new components / tokens / anti-patterns) and their source change-id.
-
-## The 9-段 Schema + palette
-
-Every `design-system.md` follows this schema (9 sections + a 5-direction palette):
-
-| 段 | 内容 |
-|----|------|
-| `color` | primary / secondary / neutral / semantic（success/warning/danger） |
-| `typography` | font-family / scale（1.25 比例）/ line-height |
-| `spacing` | 4 / 8 / 12 / 16 / 24 阶梯（基于 4 基数） |
-| `layout` | 栅格 12 列 / 断点 sm/md/lg / 容器 max-width |
-| `components` | button / input / card / table 规范（见 components/） |
-| `motion` | duration 150–300ms / easing standard |
-| `voice` | 文案语气（专业、简洁） |
-| `brand` | logo / 品牌主色 |
-| `anti-patterns` | 禁止内联样式漂移 / 禁止非 token 颜色 |
-| `palette`（5 方向确定性调色板） | neutral / primary / success / warning / danger，各含 50–900 阶梯 |
-| `aliases`（B-slot 别名层，v0.18.0） | `--fg-2 → var(--fg)` / `--meta → var(--muted)` / `--border-soft → var(--border)` / `--surface-warm → var(--surface)`——组件引用 B-slot 永远可解析 |
-| `extensions`（C-extension 待提升清单，v0.18.0） | 品牌专有 token 名单制；提升路径：C→B（≥2 品牌需要）→A2（有全局默认值） |
-
-### Token 四层模型（v0.18.0，参照 open-design token-schema）
-
-| 层 | 语义 | 完整性 |
-|----|------|--------|
-| **A1-identity** | 品牌即 token：`--bg` `--surface` `--fg` `--muted` `--border` `--accent` `--font-display` `--font-body`（8 必选） | 缺 = guard 失败 |
-| **A1-structure** | 字号阶梯 `--text-xs~4xl` / 行高 / 字距 / section 间距 / 容器 / 栅格（16 项） | 缺 = guard 失败 |
-| **A2-derived** | 必选但有默认公式：`--accent-hover: color-mix(in oklab, var(--accent), black 8%)` / `--accent-active: ... black 14%` / `--focus-ring: ... accent transparent 70%` / `--elev-raised: ... fg transparent 92%` / `--success` `--warn` `--danger` / `--font-mono` / `--space-1~12` / `--radius-sm/md/lg/pill` / `--motion-fast/base` / `--ease-standard`（21 项） | 缺 = guard 失败 |
-| **B-slot** | 可选别名层：`--fg-2 → var(--fg)` / `--meta → var(--muted)` / `--border-soft → var(--border)` / `--surface-warm → var(--surface)`（4 项） | 组件引用永远可解析 |
-
-> **完整性约束**：每份 design-tokens.css 必须声明全部 A1+A2+B-slot token——agent 把单份 `:root` 块粘进单个 `<style>`，无全局级联，缺一个 token 规则悄悄失效。可运行 `node scripts/guard/design-token-guard.mjs` 校验。
-
-## Methodology
-
-### Mode: create（首次创建）
-
-When the project has no `design-system.md`:
-
-1. Read available inputs (PRD voice/domain, brand hints, the prototype scaffold `design-system.md` as a structural template).
-2. Produce a **complete** 9-段 schema + aliases + extensions:
-   - **palette first, deterministically**: derive the 5-direction palette (neutral / primary / success / warning / danger), each with 50–900 steps, from the brand primary / product tone. "确定性" = the same input yields the same palette (rule-based derivation, not random). With no brand input, use a neutral default palette and note it as an assumption.
-   - **A2 派生状态色**（v0.18.0）：用 `color-mix(in oklab, ...)` 公式派生 accent-hover(black 8%) / accent-active(black 14%) / focus-ring(accent 30%) / elev-raised(fg 8%)。不手写固定 hex。
-   - **B-slot 别名层**（v0.18.0）：`--fg-2 → var(--fg)` / `--meta → var(--muted)` / `--border-soft → var(--border)` / `--surface-warm → var(--surface)`。
-   - **C-extension 清单**（v0.18.0）：如有品牌专有 token，列入 `extensions` 段（名单制），标注提升路径。
-   - Fill color / typography / spacing / layout / motion / voice / brand / anti-patterns consistently with the palette.
-   - `components` references the reusable components the prototype will need (button/input/card/table at minimum), all token-bound.
-   - `anti-patterns` MUST include "禁止内联样式漂移" and "禁止非 token 颜色".
-3. **`confirmed: false`**：Deliver the draft（写 scratch 草稿路径或返回 response），**不写正式路径**。Orchestrator 评审 + 人工确认后，**带 `confirmed: true` 重新派发你**，由你写入正式 `design_system_path`（主代理不写）。
-4. **`confirmed: true`**：把传入的已确认草案 `Write` 到正式 `design_system_path`，返回 `status: done` + deliverable = 正式路径。
-
-### Mode: iterate（增量更新）
-
-When prototype-sync (or a change) introduces new components / tokens / anti-patterns:
-
-1. Read the existing `design-system.md`.
-2. **Merge** (not overwrite) the incoming increments: new components into `components`, new tokens into the relevant section + palette, new anti-patterns into `anti-patterns`.
-3. Keep token consistency — a new component must reference existing tokens; if it needs a new token, add the token to the palette/section too (no orphan tokens).
-4. Append a **变更履历** entry: 时间 / 变更内容 / 来源 change-id.
-5. **`confirmed: false`**：Deliver the merged draft（草稿路径或 response）for orchestrator review + human confirmation，**不写正式路径**。
-6. **`confirmed: true`**：把已确认的合并草案 `Write` 到正式 `design_system_path`（你是唯一写者）。
-
-## Output Format
-
-```markdown
-## Design System Draft — {create | iterate}
-
-### Mode: {create | iterate}
-### Target path: {design_system_path}
-
-### design-system.md (draft content)
-{完整 9 段 schema + palette + aliases + extensions 的 markdown 内容，含 A2 派生色公式和 B-slot 别名层，可直接落盘}
-
-### 变更履历 (iterate only)
-| 时间 | 变更内容 | 来源 change |
-|------|---------|------------|
-| {ISO date} | {新增 button 变体 / 新 token / 新 anti-pattern} | {change-id} |
-
-### Assumptions
-- {e.g., 无品牌输入，采用中性默认调色板}
-```
-
-## Tool Guidance
-
-- Use `Read` for the existing design-system.md / PRD / scaffold; `Glob` to scan existing `components/`.
-- **`Write` 权限按 `confirmed` 阶段使用**：`confirmed: false` → 只写 scratch 草稿路径（或仅返回 response），**绝不写正式 `design_system_path`**；`confirmed: true` → 写正式 `design_system_path`（你是唯一写者，主代理不写）。
-- Keep everything token-based and offline-friendly (the prototype must stay 零外部依赖).
-
-## Red Lines
-
-- Do NOT hardcode company/product brand — stay generic; derive from input or use a documented neutral default.
-- Do NOT skip the palette or any of the 9 sections on `create`.
-- On `iterate`, MERGE and record 变更履历 — never overwrite existing content silently.
-- **`confirmed: false` 阶段绝不写正式 `design_system_path`**——只产草案；正式落盘只在 `confirmed: true`（人工已确认）阶段由你自己执行。主代理全程不 Write/Edit `design-system.md`。
-
-## Structured Handoff（强制，主代理据此编排）
-
-你的 final response 必须是如下结构化交接（JSON 风格描述即可，主代理据此编排）：
-{
-  status: "done" | "done_with_questions" | "blocked",
-  deliverable: <design-system 草案绝对路径或草案内容>,
-  blockers: [ { question, why_blocking, options[] } ],          # 阻断项：无法继续、必须主代理裁决
-  outstanding_questions: [ { question, default_assumption } ],  # 非阻断：已按默认假设继续，回主代理批量确认
-  summary: <3-5 行 gist>
-}
-规则：非阻断疑问（如品牌主色未给→用中性默认、某 motion 时长不确定）→ 按 default_assumption 继续跑完，记入 outstanding_questions（status=done_with_questions）；
-阻断疑问（如 iterate 模式但现有 design-system.md 缺失、无法定位任何输入）→ 立即停止，返回 status=blocked + blockers[]，绝不强行猜测。你不能调用 AskUserQuestion。
+# Design System Architect — 已迁移（v0.19.0）
+
+> **本文件是迁移指针，不是可执行 agent prompt。**
+>
+> v0.19.0 起，design-system-architect 从 prototype skill 的内部种子代理
+> 升级为独立的 `/team-flow:design-system` skill 的内部执行引擎。
+>
+> **权威版本**：`skills/design-system/references/agents/design-system-architect.md`
+>
+> prototype skill 需要创建/迭代设计系统时，调用 `/team-flow:design-system`（独立入口），
+> 不再直接派发本 agent。详见 `references/orchestration-flow.md` 步骤 ①b。

package/skills/prototype/references/interactive-prototype.md

@@ -0,0 +1,110 @@
+# 交互原型方法论（零依赖适配版）
+
+> **方法论来源**：baoyu-design `built-in-skills/interactive-prototype.md`，经零依赖原则重写。
+> 
+> **适用场景**：需要验证真实交互流程的原型（表单验证、多步导航、动态反馈），区别于静态页面展示。
+
+## 核心目标
+
+让原型**像真实可运行的应用**，而非静态 mockup。用户能在浏览器中点击、输入、看到反馈，验证交互逻辑的合理性。
+
+## 零依赖交互三件套
+
+| 技术 | 用途 | 示例 |
+|------|------|------|
+| **原生 JS** | 状态管理、事件绑定、表单验证 | `addEventListener('click', ...)` / `document.querySelector()` |
+| **CSS transitions** | 状态变化动画（hover/active/focus） | `transition: background-color 150ms ease` |
+| **CSS :checked/:focus-within** | 纯 CSS 交互（无需 JS） | tab 切换、折叠面板、checkbox 联动 |
+
+## 交互原型必含要素
+
+### 1. 真实状态管理
+
+用 JS 变量管理应用状态，用 `data-*` 属性标记 DOM 状态：
+
+```html
+<button data-state="idle" onclick="handleSubmit()">提交</button>
+<script>
+function handleSubmit() {
+  const btn = document.querySelector('[data-state="idle"]');
+  btn.dataset.state = 'loading';
+  btn.textContent = '提交中...';
+  // 模拟异步
+  setTimeout(() => {
+    btn.dataset.state = 'success';
+    btn.textContent = '已提交';
+  }, 1000);
+}
+</script>
+```
+
+**反模式**：用 alert/confirm/prompt 替代真实 UI 反馈。
+
+### 2. 表单验证
+
+- 实时校验：`input` 事件触发即时反馈
+- 失焦校验：`blur` 事件触发字段级校验
+- 提交校验：`submit` 事件触发全表单校验
+
+```html
+<input type="email" data-validate="email" onblur="validateField(this)">
+<span class="error-msg" data-error-for="email" hidden>请输入有效邮箱</span>
+```
+
+**反模式**：仅在提交时一次性校验所有字段，无实时反馈。
+
+### 3. 多步导航流程
+
+用 `data-step` 属性标记步骤，JS 控制步骤切换：
+
+```html
+<div data-step="1" class="step">步骤 1 内容</div>
+<div data-step="2" class="step" hidden>步骤 2 内容</div>
+<button onclick="nextStep()">下一步</button>
+```
+
+**反模式**：每个步骤一个独立 HTML 文件（割裂流程体验）。
+
+### 4. 动态列表/表格
+
+用 JS 数组管理数据，动态渲染 DOM：
+
+```javascript
+const items = [{ id: 1, name: '项目 A' }, { id: 2, name: '项目 B' }];
+function renderList() {
+  const tbody = document.querySelector('tbody');
+  tbody.innerHTML = items.map(item => 
+    `<tr><td>${item.id}</td><td>${item.name}</td></tr>`
+  ).join('');
+}
+```
+
+**反模式**：硬编码 10 行相同数据（无法验证增删改查）。
+
+## 交互原型的 craft 约束
+
+- **状态覆盖**：每个交互元素必须覆盖 Loading / Empty / Error / Populated / Edge 五态（见 `craft/state-coverage.md`）
+- **无障碍基线**：键盘可达（Tab/Enter/Esc）、焦点可见、`prefers-reduced-motion` 尊重（见 `craft/accessibility-baseline.md`）
+- **反 AI slop**：不用 modal 弹窗替代页内反馈、不用 loading spinner 超过 3 秒（用进度条或骨架屏）
+
+## 与静态原型的区别
+
+| 维度 | 静态原型 | 交互原型 |
+|------|---------|---------|
+| 页面数量 | 多页面展示 | 单页面多状态 |
+| JS 复杂度 | 仅导航 | 状态管理 + 事件绑定 |
+| 验证目标 | 视觉设计、信息架构 | 交互流程、用户体验 |
+| 适用阶段 | PRD 评审 | 技术评审、用户测试 |
+
+## 何时选择交互原型
+
+- PRD 含复杂表单流程（注册/下单/审批）
+- 需要验证多步骤导航逻辑
+- 需要用户测试真实交互反馈
+- 技术方案依赖交互细节（状态机、并发控制）
+
+## 不适用场景
+
+- 纯展示型页面（landing page / about us）
+- 信息架构尚未确定（先用静态原型）
+- 高保真动效需求（用专业工具 Figma/After Effects）