@xulthekl/team-flow 0.32.2 → 0.34.0

package/agents/prd-completeness-reviewer.md

@@ -1,52 +1,6 @@
 ---
 name: prd-completeness-reviewer
-description: >-
-  PRD 完整性自动评审。在 PRD 写入后、冻结前，独立检查"需求描述是否完整到能支撑
-  后续 plan/spec 实施"（5 维度），输出分级完整性报告。只读审查，不修改任何文件。
-  与 claim verifier 分工：claim verifier 管"说得对不对"（核查事实声明），
-  本 agent 管"说得全不全、能否落地"。
-  Examples:
-
-<example>
-Context: PRD 刚写完，orchestrator 需要在冻结前做完整性门禁检查。
-user: "PRD 写好了，帮我看看完整不完整，能不能往下做 plan"
-assistant: "我来启动 prd-completeness-reviewer agent，独立审查 PRD 的 5 维度完整性。"
-<commentary>
-PRD 完整性评审是 orchestrator S2 阶段冻结前的关键门禁。本 agent 在独立上下文中运行，
-未参与 PRD 产出，规避锚定效应。审查报告写在 response 中，由编排层落盘到
-prd/vN/prd-completeness-review.md。FAIL（仅 Critical 触发）→ 回 ce-brainstorm Phase 1.3 补充。
-</commentary>
-</example>
-
-<example>
-Context: 用户担心 PRD 缺验收标准，导致后面 plan/spec 无法落地。
-user: "这份 PRD 的每个功能都有可验证的验收标准吗？"
-assistant: "让 prd-completeness-reviewer agent 做一次 D2 验收标准维度的结构化检查。"
-<commentary>
-D2 验收标准是 Critical 级维度——缺失即触发 FAIL。没有可验证的 AC，下游 plan/spec/build
-将失去判定基准。本 agent 逐功能核查 AC/成功信号是否存在且可验证。
-</commentary>
-</example>
-
-<example>
-Context: PRD 补充修订后需要重新评审（FAIL 后第 2 轮）。
-user: "PRD 按上一轮意见补充了边界场景，重新跑一下完整性检查"
-assistant: "我启动 prd-completeness-reviewer agent 进行第 2 轮完整性评审，对比上轮 Critical 项是否已补齐。"
-<commentary>
-FAIL→回 Phase 1.3 补充→重新评审，直到无 Critical。Important 不阻断，
-以 PASS_WITH_WARNINGS 交人工裁定。
-</commentary>
-</example>
-
-<example>
-Context: 人工冻结前想先确认 PRD 范围闭环、没有悬空功能。
-user: "帮我看看 PRD 的 in/out scope 是不是清楚，有没有写了但没人接的功能"
-assistant: "我启动 prd-completeness-reviewer agent 做 D5 范围闭环维度的检查。"
-<commentary>
-D5 范围闭环是 Important 级——悬空功能（in scope 写了但无对应实现路径）或 out scope
-未声明，会在 plan 阶段才暴露。提前在 PRD 层闭环可降低下游返工。
-</commentary>
-</example>
+description: PRD 完整性自动评审。在 PRD 写入后、冻结前，独立检查"需求描述是否完整到能支撑后续 plan/spec 实施"（5 维度），输出分级完整性报告。只读审查，不修改任何文件。与 claim verifier 分工——claim verifier 管"说得对不对"（核查事实声明），本 agent 管"说得全不全、能否落地"。
 
 model: inherit
 color: yellow

package/agents/prototype-builder.md

@@ -1,46 +1,6 @@
 ---
 name: prototype-builder
-description: >-
-  原型构建 agent——将设计稿（HTML/CSS/JS）转化为可运行的原型系统。在 prototype skill
-  编排中作为子代理调用，负责原型代码生成、设计系统集成、质量保证。只写不读 specs。
-  Examples:
-
-<example>
-Context: prototype skill 完成设计稿生成后，需要构建可运行的原型。
-user: "设计稿生成完了，帮我构建原型"
-assistant: "我来启动 prototype-builder agent，将设计稿转化为可运行的原型系统。"
-<commentary>
-原型构建是 prototype skill 的核心执行步骤。本 agent 读取设计稿（HTML/CSS/JS），
-集成设计系统，生成可运行的原型，执行质量保证检查。
-</commentary>
-</example>
-
-<example>
-Context: 需要修复原型中的问题。
-user: "原型跑起来了，但样式有点问题，帮我修一下"
-assistant: "让 prototype-builder agent 修复原型的样式问题。"
-<commentary>
-原型修复需要读取现有原型代码，定位问题，应用修复，重新验证。
-</commentary>
-</example>
-
-<example>
-Context: 需要为原型添加新功能。
-user: "原型需要加一个搜索功能，帮我实现"
-assistant: "我启动 prototype-builder agent，为原型添加搜索功能。"
-<commentary>
-原型扩展需要读取现有原型，理解结构，添加新功能，确保与设计系统一致。
-</commentary>
-</example>
-
-<example>
-Context: 需要将原型集成到真实系统。
-user: "原型验证通过了，帮我集成到真实系统"
-assistant: "我启动 prototype-builder agent，将原型代码集成到真实项目。"
-<commentary>
-原型集成需要提取原型中的有效代码，适配真实系统的技术栈，确保功能一致。
-</commentary>
-</example>
+description: 原型构建 agent——将设计稿（HTML/CSS/JS）转化为可运行的原型系统。在 prototype skill 编排中作为子代理调用，负责原型代码生成、设计系统集成、质量保证。只写不读 specs。
 
 model: inherit
 color: green

package/agents/prototype-env-scout.md

@@ -1,31 +1,6 @@
 ---
 name: prototype-env-scout
-description: >-
-  原型环境探查（prototype skill 内部编排步骤①）。只读探查设计系统现状（9 段 schema
-  完整度）、原型仓库分支、PRD 版本、已有页面，产出环境简报 + 推荐原型方案设计 +
-  readiness verdict。只读，不写 prototype/，不改 design-system.md。
-  Examples:
-
-<example>
-Context: prototype skill 进入步骤①，需要先摸清环境再设计原型方案。
-user: "要做驾驶舱原型，先帮我看看设计系统、分支、PRD 这些环境情况"
-assistant: "我启动 prototype-env-scout agent，只读探查设计系统/分支/PRD/已有页面，产出环境简报和原型方案建议。"
-<commentary>
-环境探查是 prototype 内部编排的第一步，为后续方案评审和 prototype-builder 绘制提供
-决策依据。本 agent 只读，发现设计系统缺失时把 verdict 标为 needs_design_system 交主代理
-决定是否先派 design-system-architect，而非自己阻断或写文件。
-</commentary>
-</example>
-
-<example>
-Context: 迭代已有原型，需要确认当前分支与 PRD 版本是否对齐。
-user: "PRD 升到 v2 了，原型分支对不对得上？已有哪些页面？"
-assistant: "让 prototype-env-scout agent 探查到原型分支与 PRD 版本的对齐情况和现有原型清单。"
-<commentary>
-原型随 PRD 当前版本分支维护（prd-vN 分支）。本 agent 检测当前分支是否匹配目标 PRD 版本，
-并清点现有 pages/components/flow.md，供迭代方案参考。
-</commentary>
-</example>
+description: 原型环境探查（prototype skill 内部编排步骤①）。只读探查设计系统现状（9 段 schema 完整度）、原型仓库分支、PRD 版本、已有页面，产出环境简报 + 推荐原型方案设计 + readiness verdict。只读，不写 prototype/，不改 design-system.md。
 
 model: inherit
 color: cyan

package/agents/prototype-reviewer.md

@@ -1,46 +1,6 @@
 ---
 name: prototype-reviewer
-description: >-
-  原型 vs PRD 一致性自动评审。在原型产出后、人工评审前，独立检查原型与 PRD
-  的结构化一致性（6 维度），输出分级一致性报告。只读审查，不修改任何文件。
-  Examples:
-
-<example>
-Context: 原型刚产出，orchestrator 需要在人工评审前做自动一致性检查。
-user: "原型做好了，帮我检查一下和 PRD 是否一致"
-assistant: "我来启动 prototype-reviewer agent，独立审查原型与 PRD 的 6 维度一致性。"
-<commentary>
-原型自动评审是 orchestrator S2 阶段的关键门禁。prototype-reviewer 在独立上下文中运行，
-未参与 PRD/原型产出，规避锚定效应。审查报告写在 response 中，由编排层落盘。
-</commentary>
-</example>
-
-<example>
-Context: 原型经过修正后需要重新评审（第 2 轮）。
-user: "原型修正完了，重新跑一下一致性检查"
-assistant: "我启动 prototype-reviewer agent 进行第 2 轮自动评审，对比修正前后不一致项是否收敛。"
-<commentary>
-FAIL 后修正→重新评审，最多 3 轮。连续两轮不一致项集合无缩小则转人工，避免死循环。
-</commentary>
-</example>
-
-<example>
-Context: 用户想确认原型是否覆盖了 PRD 中定义的所有页面和功能。
-user: "PRD 里定义了 8 个页面，原型是不是都有了？"
-assistant: "让 prototype-reviewer agent 做一次 D1 页面完整性 + D2 功能覆盖的结构化检查。"
-<commentary>
-D1/D4 走 Pre-check（Bash 结构化预检），机械化验证页面文件存在性和导航链接完整性。
-</commentary>
-</example>
-
-<example>
-Context: 人工评审前想先过一遍术语和字段是否对齐。
-user: "帮我看看原型里的字段名称和 PRD 定义的是否一致"
-assistant: "我启动 prototype-reviewer agent 做 D3 字段一致性 + D5 术语一致性的语义对比。"
-<commentary>
-D3/D5 走 Deep-check（LLM 语义对比），标注为建议级，误报可被人工推翻。
-</commentary>
-</example>
+description: 原型 vs PRD 一致性自动评审。在原型产出后、人工评审前，独立检查原型与 PRD 的结构化一致性（6 维度），输出分级一致性报告。只读审查，不修改任何文件。
 
 model: inherit
 color: green

package/agents/release-archivist.md

@@ -1,27 +1,6 @@
 ---
 name: release-archivist
-description: >-
-  发布归档 agent——在 build-executor 完成实施之后、change 关闭之前,执行验证、产出
-  closing 总结并完成归档就绪(arch-merge / prototype-sync / 复利晋升)。可写型,负责归档制品。
-  Examples:
-
-<example>
-Context: 实施完成,需要验证并收尾归档。
-user: "实施做完了,帮我验证并归档这个 change"
-assistant: "I'll launch the release-archivist agent to verify, summarize, and ready the archive."
-<commentary>
-release-archivist 是 closing 阶段的收尾 agent,守"验证先于完成"铁律,产出验证报告与归档。
-</commentary>
-</example>
-
-<example>
-Context: 验证发现实施偏离契约,需回退而非强行关闭。
-user: "验证发现 design 决策和代码对不上"
-assistant: "I'll have release-archivist route back to bridging instead of forcing closure."
-<commentary>
-若实施偏离契约,回退 bridging 再关闭;FAIL 不进 DP-7。
-</commentary>
-</example>
+description: 发布归档 agent——在 build-executor 完成实施之后、change 关闭之前，执行验证、产出 closing 总结并完成归档就绪（arch-merge / prototype-sync / 复利晋升）。可写型，负责归档制品。
 
 model: inherit
 color: yellow

package/agents/spec-writer.md

@@ -1,27 +1,6 @@
 ---
 name: spec-writer
-description: >-
-  规格编写 agent——在 need-explorer 完成 DP-1 之后、contract-builder 之前，产出并打磨
-  proposal.md / specs/ / design.md / tasks.md 四件规划制品。可写型,负责规划制品目录。
-  Examples:
-
-<example>
-Context: need-explorer 已记录 DP-1,change 意图稳定,可以落盘规划制品。
-user: "需求已经澄清清楚了,帮我把 proposal/specs/design/tasks 写出来"
-assistant: "I'll launch the spec-writer agent to produce the four planning artifacts in order."
-<commentary>
-spec-writer 是 exploring→bridging 之间的产出 agent。逐件生成、逐件确认,防止 scope 漂移。
-</commentary>
-</example>
-
-<example>
-Context: 本 change 经 architecture-design 判定为 required,architecture/ 三件套已产出。
-user: "架构设计做完了,写 design.md 时要对齐架构决策"
-assistant: "I'll have spec-writer read architecture/ and align design.md Decisions with it."
-<commentary>
-design.md 的 Decisions 必须引用 architecture/ 决策,tasks.md 须对齐 api.md 路由表与 sql/ 脚本。
-</commentary>
-</example>
+description: 规格编写 agent——在 need-explorer 完成 DP-1 之后、contract-builder 之前，产出并打磨 proposal.md / specs/ / design.md / tasks.md 四件规划制品。可写型，负责规划制品目录。
 
 model: inherit
 color: cyan

package/docs/README_en.md

@@ -126,7 +126,7 @@ npm install -g team-flow
 
 ### Version
 
-- Current: `v0.32.2`
+- Current: `v0.34.0`
 - v0.9.1 highlights: DP-4 execution-mode recommendations, a portable runtime across 17 platforms, and a raw-package smoke with no plugin-root variable.
 - Self-contained — no OpenSpec or Superpowers runtime required
 - Upstream: [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec), [obra/superpowers](https://github.com/obra/superpowers)

package/docs/solutions/INDEX.md

@@ -2,6 +2,7 @@
 <!-- 每条一行，按 severity 降序，≤150 行硬上限 -->
 | date | phase | domain | type | severity | summary | file |
 |------|-------|--------|------|----------|---------|------|
+| 2026-08-04 | cross-phase | general | insight | medium | (no summary) | cross-phase/2026-08-04-no-summary.md |
 | 2026-08-03 | cross-phase | general | insight | medium | (no summary) | cross-phase/2026-08-03-no-summary.md |
 | 2026-08-01 | cross-phase | general | insight | medium | (no summary) | cross-phase/2026-08-01-no-summary.md |
 | 2026-07-31 | cross-phase | general | insight | medium | (no summary) | cross-phase/2026-07-31-no-summary.md |

package/docs/solutions/cross-phase/2026-08-04-no-summary.md

@@ -0,0 +1,17 @@
+---
+phase: cross-phase
+domain: general
+type: insight
+severity: medium
+date: 2026-08-04
+source: 
+---
+
+## 问题描述
+(no summary)
+
+## 根因/模式
+（待补充）
+
+## 预防措施/应用方式
+（待补充）

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
   "description": "Unified workflow plugin: team-flow (spec-driven dev) + compound-engineering core subset + architecture-design (4A/DDD) + prototype (local HTML). 24 skills, one install.",
-  "version": "0.32.2",
+  "version": "0.34.0",
   "contextFileName": "GEMINI.md"
 }

package/hooks/session-start

@@ -1,11 +1,11 @@
 #!/usr/bin/env bash
-# v0.32.2: auto-sync CLI version with plugin version
+# v0.34.0: auto-sync CLI version with plugin version
 set -e
 
 # ═══════════════════════════════════════════════════════════════
 # Plugin version (update this when releasing new versions)
 # ═══════════════════════════════════════════════════════════════
-PLUGIN_VERSION="0.32.2"
+PLUGIN_VERSION="0.34.0"
 
 # ═══════════════════════════════════════════════════════════════
 # Step 1: Auto-sync CLI version with plugin version

package/llms.txt

@@ -3,7 +3,7 @@
 ## Overview
 spec-superflow is a self-contained workflow integration plugin for Claude Code, Cursor, OpenAI Codex CLI/App, GitHub Copilot CLI, Gemini CLI, OpenCode, WorkBuddy, and Trae. It merges spec-driven planning artifacts (proposal, specs, design, tasks) with disciplined execution guardrails (TDD, review gates, controlled handoff) into one unified workflow.
 
-Current version: v0.32.2.
+Current version: v0.34.0.
 
 ## Key Documents
 - README.md: Chinese homepage with full usage guide and FAQ

package/package.json

@@ -1,12 +1,12 @@
 {
   "name": "@xulthekl/team-flow",
-  "version": "0.32.2",
+  "version": "0.34.0",
   "description": "Unified plugin (24 skills + 15 agents) integrating team-flow, compound-engineering, architecture-design, prototype, design-system, workflow-orchestrator, workflow-bootstrap, e2e, session-handoff, workflow-feedback for multi-agent coding tools.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
   "bin": {
-    "tf": "./scripts/team-flow.mjs",
-    "team-flow": "./scripts/team-flow.mjs"
+    "tf": "scripts/team-flow.mjs",
+    "team-flow": "scripts/team-flow.mjs"
   },
   "type": "module",
   "scripts": {
@@ -41,12 +41,13 @@
   "license": "MIT",
   "repository": {
     "type": "git",
-    "url": "https://github.com/MageByte-Zero/team-flow"
+    "url": "git+https://github.com/MageByte-Zero/team-flow.git"
   },
   "engines": {
     "node": ">=20"
   },
   "devDependencies": {
+    "js-yaml": "^5.2.3",
     "typescript": "^6.0.3"
   }
 }

package/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.32.2",
+  "version": "0.34.0",
   "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking). 24 skills + 15 agents, one install.",
   "author": {
     "name": "LT"