Compare commits
5
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
8fc1cd05b7 | ||
|
|
b859a84455 | ||
|
|
9a1400758e | ||
|
|
a58dd1aff3 | ||
|
|
bb5e6be73e |
@@ -482,8 +482,8 @@
|
||||
{
|
||||
"name": "req-prd-plugin",
|
||||
"source": "./skills-req/req-prd-plugin",
|
||||
"description": "产品需求设计技能。PRD 文档编写、需求分析、用户故事、对比式分析。纯产品视角,不含技术实现。",
|
||||
"version": "2.0.0",
|
||||
"description": "产品需求设计技能。覆盖问答访谈、PRD、缺陷收敛及 HTML 原型验证闭环。纯产品视角,不含技术实现。",
|
||||
"version": "2.1.0",
|
||||
"category": "productivity",
|
||||
"keywords": [
|
||||
"project-management",
|
||||
@@ -495,8 +495,8 @@
|
||||
{
|
||||
"name": "req-prototype-plugin",
|
||||
"source": "./skills-req/req-prototype-plugin",
|
||||
"description": "原型生成与关联。支持 HTML 上传(/req prototype upload,iframe 嵌入详情页)和 Stitch AI 生成两种模式。",
|
||||
"version": "2.0.0",
|
||||
"description": "原型生成与关联。支持 HTML 正式交付、Requirement 关联、iframe 验证闭环及 Stitch AI 视觉探索。",
|
||||
"version": "2.1.0",
|
||||
"category": "productivity",
|
||||
"keywords": [
|
||||
"project-management",
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# ai-proj-helper
|
||||
|
||||
Claude Code 技能市场 + MCP 配置管理工具。
|
||||
Codex 优先、兼容 Claude Code 的 Agent Skills 市场与 MCP 配置管理工具。
|
||||
|
||||
## 快速开始
|
||||
|
||||
```bash
|
||||
./init.sh
|
||||
./install-skills.sh
|
||||
```
|
||||
|
||||
交互式配置 MCP 连接(默认 SSE 模式)+ 自动注册技能市场到 `~/.claude/plugins/known_marketplaces.json`。支持命令行参数:
|
||||
默认安装到 Codex 标准目录 `~/.agents/skills`。Claude Code 的 MCP 与 marketplace 初始化使用:
|
||||
|
||||
```bash
|
||||
./init.sh --mode sse --token aiproj_pk_xxx
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# ai-proj-helper — 让 Claude Code 变成你的项目经理
|
||||
# ai-proj-helper — 让 Codex / Claude Code 变成你的项目经理
|
||||
|
||||
> 一套开箱即用的 Claude Code 技能包 + MCP 服务,帮你用自然语言管理需求、写代码、做评审、同步飞书,把 AI 助手变成真正的项目经理。
|
||||
> 一套遵循 Agent Skills 标准的技能包 + MCP 服务,支持 Codex,并兼容 Claude Code。
|
||||
|
||||
## 它能帮你做什么
|
||||
|
||||
@@ -66,7 +66,7 @@ PRD 文档存储在思源笔记中,可以导出发送到飞书群,通过飞
|
||||
|
||||
### 前置条件
|
||||
|
||||
- **Claude Code** 已安装([安装指南](https://docs.anthropic.com/en/docs/claude-code/overview))
|
||||
- **Codex**([Skills 文档](https://developers.openai.com/codex/skills))或 **Claude Code** 已安装
|
||||
- **ai-proj 账号 + MCP API Key**:联系管理员获取(Key 格式: `aiproj_pk_xxx`)
|
||||
|
||||
### 一键部署(2 步搞定)
|
||||
@@ -76,18 +76,16 @@ PRD 文档存储在思源笔记中,可以导出发送到飞书群,通过飞
|
||||
git clone https://gitea.pipexerp.com/pipexerp/ai-proj-helper.git
|
||||
cd ai-proj-helper
|
||||
|
||||
# 2. 运行初始化(按提示输入 API Key 即可)
|
||||
./init.sh
|
||||
# 2. 默认安装到 Codex 的用户级标准目录 ~/.agents/skills
|
||||
./install-skills.sh
|
||||
```
|
||||
|
||||
脚本会自动完成:
|
||||
- 配置 MCP 服务器连接(`~/.claude/.mcp.json`)
|
||||
- 注册技能市场到 Claude Code(`~/.claude/plugins/known_marketplaces.json`)
|
||||
- 安装完整技能目录到 `~/.claude/skills/`(包括 references、scripts 和 assets)
|
||||
安装器会复制完整技能目录,包括 `SKILL.md`、references、scripts 和 assets。Codex 会自动发现 `~/.agents/skills` 中的技能;若没有出现,重启 Codex。
|
||||
|
||||
也支持命令行参数跳过交互:
|
||||
Claude Code 用户显式选择 Claude 目标;需要同时配置 MCP 和 marketplace 时运行 `init.sh`:
|
||||
|
||||
```bash
|
||||
./install-skills.sh --agent claude
|
||||
./init.sh --mode sse --token aiproj_pk_xxx
|
||||
```
|
||||
|
||||
@@ -172,13 +170,17 @@ skills:
|
||||
|
||||
A: 需要先联系管理员获取 MCP API Key(格式 `aiproj_pk_xxx`),然后在提示处输入。
|
||||
|
||||
**Q: 安装后 Codex 没有识别到技能?**
|
||||
|
||||
A: 确认技能位于 `~/.agents/skills/<name>/SKILL.md`,然后重启 Codex。Codex CLI 也可用 `/skills` 查看。
|
||||
|
||||
**Q: 安装后 Claude Code 没有识别到技能?**
|
||||
|
||||
A: 重启 Claude Code 后生效。如果仍不生效,检查 `~/.claude/plugins/known_marketplaces.json` 中是否包含 `ai-proj-helper` 条目。
|
||||
|
||||
**Q: 如何更新到最新版本?**
|
||||
|
||||
A: 进入项目目录执行 `git pull`,然后重新运行 `./init.sh`。
|
||||
A: 进入项目目录执行 `git pull`,然后运行 `./install-skills.sh`;Claude Code 用户增加 `--agent claude`。
|
||||
|
||||
**Q: 如何禁用不需要的技能?**
|
||||
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
# Setup Guide
|
||||
# Claude Code Marketplace Setup
|
||||
|
||||
本页只描述 Claude Code marketplace。Codex 用户直接运行 `./install-skills.sh`,技能默认安装到 `~/.agents/skills`。
|
||||
|
||||
## 1. Clone the Gitea Repository
|
||||
|
||||
@@ -114,7 +116,7 @@ ai-proj-helper/
|
||||
- Check plugin name is correct
|
||||
- Ensure marketplace.json is valid: `cat .claude-plugin/marketplace.json | jq`
|
||||
|
||||
**"Skills not working"**
|
||||
**"Skills not working in Claude Code"**
|
||||
- Skills are Agent Skills (auto-invoked by Claude when relevant)
|
||||
- They don't create slash commands
|
||||
- Check plugin installation: `/plugin list`
|
||||
|
||||
+10
-3
@@ -1,6 +1,6 @@
|
||||
# Skill Sync Guide
|
||||
|
||||
仓库中的插件是团队技能的发布源,本机 `~/.claude/skills/` 是安装目标。个人技能保留在
|
||||
仓库中的插件是团队技能的发布源。默认安装目标是 Codex 的用户级标准目录 `~/.agents/skills/`。个人技能保留在
|
||||
`skills-personal/` 或其他本机目录,不会进入公开 marketplace。
|
||||
|
||||
## 从仓库更新本机
|
||||
@@ -11,6 +11,12 @@ git pull
|
||||
./install-skills.sh
|
||||
```
|
||||
|
||||
Claude Code 需要显式选择目标:
|
||||
|
||||
```bash
|
||||
./install-skills.sh --agent claude
|
||||
```
|
||||
|
||||
安装器会复制完整技能目录,包括 `SKILL.md`、`references/`、`scripts/` 和 `assets/`。它用内容摘要区分仓库升级和本地修改:
|
||||
|
||||
- 目标未修改时,版本升级会自动安装。
|
||||
@@ -23,11 +29,12 @@ git pull
|
||||
```bash
|
||||
./install-skills.sh --list
|
||||
./install-skills.sh --category dev
|
||||
./install-skills.sh --exclude ai-proj-cicd-release
|
||||
```
|
||||
|
||||
## 将本机技能发布到仓库
|
||||
|
||||
不要批量复制整个 `~/.claude/skills/`。系统技能、第三方托管技能、包含机器路径或凭据的技能不应发布。
|
||||
不要批量复制整个 `~/.agents/skills/` 或其他 Agent 的安装目录。系统技能、第三方托管技能、包含机器路径或凭据的技能不应发布。
|
||||
|
||||
1. 选择确实属于本仓库、可供团队复用的技能。
|
||||
2. 在对应 `skills-*/<name>-plugin/` 下放置 `.claude-plugin/plugin.json` 和完整 `skills/` 目录。
|
||||
@@ -51,7 +58,7 @@ git pull
|
||||
|
||||
**本地修改被跳过怎么办?**
|
||||
|
||||
先比较仓库源和 `~/.claude/skills/<name>/`。保留本地修改时将其整理成插件变更;确认丢弃时再对该次安装使用 `--force`。
|
||||
先比较仓库源和 `~/.agents/skills/<name>/`。保留本地修改时将其整理成插件变更;确认丢弃时再对该次安装使用 `--force`。Claude 目标改查 `~/.claude/skills/`。
|
||||
|
||||
**marketplace 没更新?**
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/bin/bash
|
||||
# ai-proj-helper 初始化脚本
|
||||
# 配置 MCP 连接 + 安装技能到 ~/.claude/skills/
|
||||
# 配置 Claude MCP 连接 + 安装 Claude 技能
|
||||
|
||||
set -e
|
||||
|
||||
@@ -187,7 +187,8 @@ fi
|
||||
# Use the versioned installer as the single installation path so references,
|
||||
# scripts and assets stay beside SKILL.md and local edits are not overwritten.
|
||||
echo "📦 安装技能到 ~/.claude/skills/ ..."
|
||||
"$SCRIPT_DIR/install-skills.sh"
|
||||
"$SCRIPT_DIR/install-skills.sh" --agent claude
|
||||
SKILL_COUNT=$(python3 -c 'import json, os; p=os.path.expanduser("~/.claude/.installed-skills.json"); print(len(json.load(open(p))) if os.path.exists(p) else 0)' 2>/dev/null || echo 0)
|
||||
echo "✅ 技能安装完成"
|
||||
|
||||
# ── Verify MCP connection ────────────────────────────────────────────
|
||||
@@ -250,7 +251,7 @@ if $HAS_CLAUDE; then
|
||||
else
|
||||
echo " ✅ MCP 服务器 → $MCP_CONFIG"
|
||||
fi
|
||||
echo " ✅ 技能 ($SKILL_COUNT 个) → $SKILLS_DIR"
|
||||
echo " ✅ 技能 ($SKILL_COUNT 个) → ~/.claude/skills"
|
||||
echo ""
|
||||
echo "重启 Claude Code 即可使用。"
|
||||
echo "如需更改配置,编辑 claude-config.yaml 后重新运行 ./init.sh"
|
||||
|
||||
+58
-16
@@ -1,13 +1,15 @@
|
||||
#!/usr/bin/env bash
|
||||
# install-skills.sh — Cross-machine Claude skill sync from ai-proj-helper
|
||||
# install-skills.sh — Cross-agent skill sync from ai-proj-helper
|
||||
#
|
||||
# Usage:
|
||||
# ./install-skills.sh [options]
|
||||
#
|
||||
# Options:
|
||||
# --agent <agent> Install target: codex (default) or claude
|
||||
# --dry-run Preview changes without writing anything
|
||||
# --category <cat> Only install plugins in dir_category=<cat>
|
||||
# Valid values: biz, core, dev, integration, personal, req
|
||||
# --exclude <name> Skip one install_name (repeatable)
|
||||
# --force Overwrite even if local files were modified
|
||||
# --cleanup Remove locally installed skills that are no longer in repo
|
||||
# --list List all available plugins without installing
|
||||
@@ -16,12 +18,14 @@
|
||||
set -euo pipefail
|
||||
|
||||
REPO_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
SKILLS_DIR="${HOME}/.claude/skills"
|
||||
COMMANDS_DIR="${HOME}/.claude/commands"
|
||||
STATE_FILE="${HOME}/.claude/.installed-skills.json"
|
||||
SKILLS_DIR=""
|
||||
COMMANDS_DIR=""
|
||||
STATE_FILE=""
|
||||
|
||||
AGENT_TARGET="codex"
|
||||
DRY_RUN=false
|
||||
CATEGORY_FILTER=""
|
||||
EXCLUDED_NAMES=()
|
||||
FORCE=false
|
||||
CLEANUP=false
|
||||
LIST_ONLY=false
|
||||
@@ -43,11 +47,19 @@ dry() { echo -e "${YELLOW}[dry]${RESET} $*"; }
|
||||
# ── Argument parsing ───────────────────────────────────────────────────────────
|
||||
while [[ $# -gt 0 ]]; do
|
||||
case "$1" in
|
||||
--agent)
|
||||
[[ $# -ge 2 ]] || { error "--agent requires codex or claude"; exit 1; }
|
||||
AGENT_TARGET="$2"; shift ;;
|
||||
--dry-run) DRY_RUN=true ;;
|
||||
--force) FORCE=true ;;
|
||||
--cleanup) CLEANUP=true ;;
|
||||
--list) LIST_ONLY=true ;;
|
||||
--category) CATEGORY_FILTER="$2"; shift ;;
|
||||
--category)
|
||||
[[ $# -ge 2 ]] || { error "--category requires a value"; exit 1; }
|
||||
CATEGORY_FILTER="$2"; shift ;;
|
||||
--exclude)
|
||||
[[ $# -ge 2 ]] || { error "--exclude requires an install_name"; exit 1; }
|
||||
EXCLUDED_NAMES+=("$2"); shift ;;
|
||||
--help|-h)
|
||||
grep '^#' "$0" | grep -v '!/usr' | sed 's/^# \?//'
|
||||
exit 0 ;;
|
||||
@@ -58,6 +70,24 @@ while [[ $# -gt 0 ]]; do
|
||||
shift
|
||||
done
|
||||
|
||||
case "$AGENT_TARGET" in
|
||||
codex)
|
||||
# ~/.agents/skills is the current user-level Codex discovery location and
|
||||
# is intentionally agent-neutral. Commands are installed as normal skills.
|
||||
SKILLS_DIR="${AI_PROJ_HELPER_SKILLS_DIR:-${HOME}/.agents/skills}"
|
||||
STATE_FILE="${AI_PROJ_HELPER_STATE_FILE:-${HOME}/.agents/.ai-proj-helper-installed-skills.json}"
|
||||
;;
|
||||
claude)
|
||||
SKILLS_DIR="${AI_PROJ_HELPER_SKILLS_DIR:-${HOME}/.claude/skills}"
|
||||
COMMANDS_DIR="${AI_PROJ_HELPER_COMMANDS_DIR:-${HOME}/.claude/commands}"
|
||||
STATE_FILE="${AI_PROJ_HELPER_STATE_FILE:-${HOME}/.claude/.installed-skills.json}"
|
||||
;;
|
||||
*)
|
||||
error "Unsupported agent: $AGENT_TARGET (expected codex or claude)"
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
# ── State helpers (plain JSON via python3) ─────────────────────────────────────
|
||||
state_get() {
|
||||
# state_get <install_name> -> prints version or empty string
|
||||
@@ -94,7 +124,7 @@ state_set() {
|
||||
import json,os
|
||||
f='$STATE_FILE'
|
||||
d=json.load(open(f)) if os.path.exists(f) else {}
|
||||
d['$name']={'version':'$ver','install_type':'$itype','content_digest':'$digest'}
|
||||
d['$name']={'version':'$ver','install_type':'$itype','content_digest':'$digest','agent':'$AGENT_TARGET'}
|
||||
json.dump(d,open(f,'w'),indent=2)
|
||||
" 2>/dev/null
|
||||
}
|
||||
@@ -149,7 +179,9 @@ files = [target] if target.is_file() else sorted(
|
||||
path for path in target.rglob("*") if path.is_file() or path.is_symlink()
|
||||
)
|
||||
for path in files:
|
||||
relative = path.name if target.is_file() else path.relative_to(target).as_posix()
|
||||
# A single-file command is renamed when installed for Claude. Hash its
|
||||
# content under a stable logical name so source and target compare equally.
|
||||
relative = "." if target.is_file() else path.relative_to(target).as_posix()
|
||||
digest.update(relative.encode("utf-8"))
|
||||
digest.update(b"\0")
|
||||
if path.is_symlink():
|
||||
@@ -222,6 +254,11 @@ install_plugin() {
|
||||
dir_category="$(read_field "$json_path" dir_category)"
|
||||
version="$(read_field "$json_path" version)"
|
||||
|
||||
local excluded
|
||||
for excluded in ${EXCLUDED_NAMES[@]+"${EXCLUDED_NAMES[@]}"}; do
|
||||
[[ "$install_name" == "$excluded" ]] && return
|
||||
done
|
||||
|
||||
# Skip if no install metadata (legacy plugin without our new fields)
|
||||
if [[ -z "$install_name" || -z "$install_type" ]]; then
|
||||
warn "$(basename "$plugin_dir"): missing install_name/install_type, skipping"
|
||||
@@ -239,8 +276,13 @@ install_plugin() {
|
||||
return
|
||||
fi
|
||||
|
||||
local effective_install_type="$install_type"
|
||||
if [[ "$AGENT_TARGET" == "codex" ]]; then
|
||||
effective_install_type="skill"
|
||||
fi
|
||||
|
||||
if [[ "$LIST_ONLY" == true ]]; then
|
||||
echo " [$dir_category] $install_type:$install_name v$version"
|
||||
echo " [$dir_category] $effective_install_type:$install_name v$version"
|
||||
return
|
||||
fi
|
||||
|
||||
@@ -250,7 +292,7 @@ install_plugin() {
|
||||
src_dir="$(resolve_skills_src "$skills_dir")"
|
||||
|
||||
local source_path target_path
|
||||
if [[ "$install_type" == "command" ]]; then
|
||||
if [[ "$effective_install_type" == "command" ]]; then
|
||||
source_path="$src_dir/SKILL.md"
|
||||
target_path="$COMMANDS_DIR/${install_name}.md"
|
||||
else
|
||||
@@ -274,13 +316,13 @@ install_plugin() {
|
||||
|
||||
if [[ "$FORCE" == false && -n "$target_digest" && "$target_digest" == "$source_digest" ]]; then
|
||||
if [[ "$DRY_RUN" == false && ( "$current_version" != "$version" || "$recorded_digest" != "$source_digest" ) ]]; then
|
||||
state_set "$install_name" "$version" "$install_type" "$source_digest"
|
||||
state_set "$install_name" "$version" "$effective_install_type" "$source_digest"
|
||||
fi
|
||||
return
|
||||
fi
|
||||
|
||||
local legacy_subset=false
|
||||
if [[ "$install_type" == "skill" && -z "$recorded_digest" && -n "$target_digest" ]]; then
|
||||
if [[ "$effective_install_type" == "skill" && -z "$recorded_digest" && -n "$target_digest" ]]; then
|
||||
if is_compatible_subset "$source_path" "$target_path"; then
|
||||
legacy_subset=true
|
||||
fi
|
||||
@@ -294,7 +336,7 @@ install_plugin() {
|
||||
fi
|
||||
|
||||
# Perform install
|
||||
if [[ "$install_type" == "command" ]]; then
|
||||
if [[ "$effective_install_type" == "command" ]]; then
|
||||
# Single-file command → ~/.claude/commands/<name>.md
|
||||
local src_md="$src_dir/SKILL.md"
|
||||
if [[ ! -f "$src_md" ]]; then
|
||||
@@ -308,13 +350,13 @@ install_plugin() {
|
||||
else
|
||||
mkdir -p "$COMMANDS_DIR"
|
||||
cp "$src_md" "$COMMANDS_DIR/${install_name}.md"
|
||||
state_set "$install_name" "$version" "$install_type" "$source_digest"
|
||||
state_set "$install_name" "$version" "$effective_install_type" "$source_digest"
|
||||
ok "$install_name → command (v$version)"
|
||||
INSTALL_ACTION=true
|
||||
fi
|
||||
|
||||
else
|
||||
# Skill directory → ~/.claude/skills/<name>/
|
||||
# Standard skill directory → the selected agent's discovery root.
|
||||
local dst_dir="$SKILLS_DIR/$install_name"
|
||||
|
||||
if [[ "$DRY_RUN" == true ]]; then
|
||||
@@ -324,7 +366,7 @@ install_plugin() {
|
||||
mkdir -p "$dst_dir"
|
||||
# rsync resolved source (handles nested skills/ structures)
|
||||
rsync -a --delete "$src_dir/" "$dst_dir/"
|
||||
state_set "$install_name" "$version" "$install_type" "$source_digest"
|
||||
state_set "$install_name" "$version" "$effective_install_type" "$source_digest"
|
||||
ok "$install_name → skill (v$version)"
|
||||
INSTALL_ACTION=true
|
||||
fi
|
||||
@@ -387,7 +429,7 @@ main() {
|
||||
return
|
||||
fi
|
||||
|
||||
info "Installing Claude skills from: $REPO_DIR"
|
||||
info "Installing skills for $AGENT_TARGET from: $REPO_DIR"
|
||||
[[ "$DRY_RUN" == true ]] && warn "DRY RUN — no files will be written"
|
||||
[[ -n "$CATEGORY_FILTER" ]] && info "Category filter: $CATEGORY_FILTER"
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "req-prd-plugin",
|
||||
"description": "产品需求设计技能。PRD 文档编写、需求分析、用户故事、对比式分析。纯产品视角,不含技术实现。",
|
||||
"version": "2.0.0",
|
||||
"description": "产品需求设计技能。覆盖问答访谈、PRD、缺陷收敛及 HTML 原型验证闭环。纯产品视角,不含技术实现。",
|
||||
"version": "2.1.0",
|
||||
"author": {
|
||||
"name": "qiudl"
|
||||
},
|
||||
|
||||
@@ -16,7 +16,36 @@ description: 产品设计与需求管理。用于 PRD 文档编写、需求分
|
||||
|
||||
**插件扩展**:
|
||||
- `req-compare` — 对比式 PRD 编写(系统平移/竞品借鉴时激活)
|
||||
- `req-prototype` — UI 原型生成
|
||||
- `req-prototype` — UI 模块在 PRD/缺陷收敛后生成、上传并关联 HTML 原型
|
||||
- `defect-analysis` — 设计访谈确认后,对最新版 PRD 反复审计和修订直至收敛
|
||||
|
||||
## 模块设计访谈模式
|
||||
|
||||
设计模块、系统、跨域流程,或目标/边界/业务规则尚未确定时,必须先执行问答式设计访谈,不得直接补全假设后生成 PRD。用户明确要求“你问我答”时也进入此模式。范围小、规则已完整确认的需求可以直接编写 PRD。
|
||||
|
||||
进入此模式后,**完整读取并执行** [references/design-interview-and-defect-loop.md](references/design-interview-and-defect-loop.md)。该协议定义:
|
||||
|
||||
- 每轮只问一个会改变方案的关键问题;
|
||||
- 将问题、AI 建议、用户原话、决策和未决项逐轮写入 ai-proj 需求的讨论文档;
|
||||
- 讨论结论经用户确认后,才能创建或更新 PRD;
|
||||
- 使用 `defect-analysis` 对最新版 PRD 执行“审计 → 修订 → 全量重审”循环;
|
||||
- UI 模块在 PRD 收敛后使用 `req-prototype` 生成独立 HTML 原型、上传关联 Requirement、回填 PRD 并完成可访问性与关键状态校验;
|
||||
- 原型评审改变产品行为时,回到问答、PRD 修订和 `defect-analysis` 全量重审,再生成新原型版本;
|
||||
- 讨论文档缺失、写入失败、用户未确认、原型未验证,或仍有未处置的致命/高严重度缺陷时,不得宣称设计完成或提交评审。
|
||||
|
||||
## HTML 原型完成闸门
|
||||
|
||||
模块包含用户界面、用户操作流程或可视状态时,HTML 原型是产品设计交付物,不是评审后的可选补充。默认执行 `/req prototype upload [REQ-ID]`,具体生成、上传、iframe 回填和验证规则由 `req-prototype` 定义。
|
||||
|
||||
必须满足:
|
||||
|
||||
1. 原型基于最新版、已完成缺陷收敛的 PRD,并记录 PRD 文档标识、版本或内容摘要;
|
||||
2. 覆盖核心入口、主流程以及 PRD 明确要求的空态、失败态、无权限态和确认/撤销反馈;
|
||||
3. 上传后重新读取 Requirement,确认原型 URL/版本已关联,并验证 URL 可访问、iframe 可展示、核心交互可操作;
|
||||
4. 将 iframe、原型版本、版本说明和验证结果回填 PRD `4.2 界面原型`,并把生成、反馈、修订和确认写入同一讨论文档;
|
||||
5. 用户明确确认最终 PRD 与原型表达的是同一方案。
|
||||
|
||||
纯后端、批处理、基础设施等确实没有用户界面的模块可以跳过,但必须在讨论文档和 PRD `4.2` 中记录“无 UI,原型不适用”的理由及用户确认,不得静默省略。
|
||||
|
||||
## 客户原话原则(REQ-20260416-0017 P1-8)
|
||||
|
||||
@@ -108,10 +137,21 @@ description: 产品设计与需求管理。用于 PRD 文档编写、需求分
|
||||
|
||||
### 4.2 界面原型
|
||||
|
||||
> 使用 `/req prototype [REQ-ID]` 基于 PRD 自动生成 Stitch 原型。
|
||||
> 生成后截图将自动回填到此章节。
|
||||
> UI 模块使用 `/req prototype upload [REQ-ID]` 基于最新版 PRD 生成并上传 HTML 原型。
|
||||
> 原型必须用 iframe 展示;Stitch 可作为视觉探索的可选输入,不能代替最终 HTML 原型闭环。
|
||||
|
||||
[执行 `/req prototype` 后自动填充]
|
||||
**原型基线**:
|
||||
- PRD 文档/版本:...
|
||||
- 原型版本与说明:...
|
||||
- Requirement 关联状态:已验证 | 未验证
|
||||
- 可访问性/关键交互验证:...
|
||||
|
||||
<iframe src="[prototype_url]"
|
||||
width="100%" height="600" frameborder="0"
|
||||
style="border-radius:8px;border:1px solid #e5e7eb;">
|
||||
</iframe>
|
||||
|
||||
[无 UI 模块填写:原型不适用的理由、讨论记录位置和用户确认原话]
|
||||
|
||||
## 5. 技术要求
|
||||
### 5.1 性能要求
|
||||
@@ -395,6 +435,8 @@ mcp__ai-proj__export_task_document_to_file
|
||||
- 需求池(ai-proj 需求列表)
|
||||
```
|
||||
|
||||
若命中“模块设计访谈模式”,本阶段改为执行访谈协议并持续写入 ai-proj 讨论文档;访谈未确认前不进入 PRD 定稿。
|
||||
|
||||
### 2. 需求分析
|
||||
|
||||
```
|
||||
@@ -419,10 +461,44 @@ mcp__ai-proj__export_task_document_to_file
|
||||
|
||||
输出:
|
||||
- PRD 文档
|
||||
- 原型设计
|
||||
- 可生成原型的界面状态与交互规格
|
||||
```
|
||||
|
||||
### 4. 评审验证
|
||||
### 4. 缺陷收敛
|
||||
|
||||
```
|
||||
输入:
|
||||
- 已确认讨论结论
|
||||
- 最新版完整 PRD
|
||||
|
||||
执行:
|
||||
- defect-analysis 全维度审计
|
||||
- 接受项修订 PRD
|
||||
- 对修订后的完整 PRD 重新审计,直至一轮 0 个新缺陷
|
||||
|
||||
输出:
|
||||
- 已收敛 PRD
|
||||
- 缺陷处置记录
|
||||
```
|
||||
|
||||
### 5. HTML 原型与反馈闭环
|
||||
|
||||
```
|
||||
适用:
|
||||
- 所有包含界面、用户操作或可视状态的模块
|
||||
|
||||
执行:
|
||||
- 调用 req-prototype 的 upload 模式生成独立 HTML
|
||||
- 上传并关联 Requirement
|
||||
- iframe 回填 PRD,验证访问和关键交互
|
||||
- 请用户评审;行为性反馈回到问答 → PRD → defect-analysis → 新原型版本
|
||||
|
||||
输出:
|
||||
- 已验证、已关联的 HTML 原型
|
||||
- PRD 与讨论文档中的版本/反馈/确认记录
|
||||
```
|
||||
|
||||
### 6. 评审验证
|
||||
|
||||
```
|
||||
评审维度:
|
||||
@@ -436,6 +512,10 @@ mcp__ai-proj__export_task_document_to_file
|
||||
- 修改意见
|
||||
```
|
||||
|
||||
模块设计访谈模式下,本阶段必须调用 `defect-analysis`,并按访谈协议将每轮发现、处置、PRD 修订和收敛结论回写到同一讨论文档。
|
||||
|
||||
UI 模块还必须核对最终 HTML 原型与最新版 PRD 一致,并取得用户对二者的联合确认;无 UI 模块则核对已记录的不适用理由和用户确认。
|
||||
|
||||
---
|
||||
|
||||
## 竞品分析
|
||||
@@ -480,6 +560,14 @@ mcp__ai-proj__export_task_document_to_file
|
||||
|
||||
### PRD 完整性检查
|
||||
|
||||
- [ ] 模块/系统设计已完成单轮单问访谈,且全过程已写入 ai-proj 讨论文档
|
||||
- [ ] 讨论结论已由用户明确确认
|
||||
- [ ] `defect-analysis` 已基于最新版 PRD 收敛到一轮 0 个新缺陷
|
||||
- [ ] 无未处置的致命/高严重度缺陷
|
||||
- [ ] UI 模块 HTML 原型已生成、上传并关联 Requirement;无 UI 模块已记录不适用理由和用户确认
|
||||
- [ ] 原型基线指向最新版 PRD,PRD `4.2` 已回填 iframe、版本说明和验证结果
|
||||
- [ ] 原型反馈导致的行为变更已回到问答、PRD 和 defect 全量重审,并生成新原型版本
|
||||
- [ ] 用户已联合确认最终 PRD 与 HTML 原型
|
||||
- [ ] 背景与目标明确
|
||||
- [ ] 用户群体定义清晰
|
||||
- [ ] 功能需求完整
|
||||
@@ -492,6 +580,8 @@ mcp__ai-proj__export_task_document_to_file
|
||||
### 交互设计检查
|
||||
|
||||
- [ ] 用户流程完整
|
||||
- [ ] HTML 原型覆盖核心入口、主流程及 PRD 指定的关键状态
|
||||
- [ ] 原型 URL 可访问,Requirement 关联可读取,iframe 可展示,核心交互可操作
|
||||
- [ ] 边界情况处理
|
||||
- [ ] 错误提示友好
|
||||
- [ ] 反馈及时
|
||||
@@ -512,7 +602,8 @@ mcp__ai-proj__export_task_document_to_file
|
||||
## 常用工具
|
||||
|
||||
### 原型设计
|
||||
- **Stitch** (Google AI) — 集成在 `/req prototype`,自动从 PRD 生成原型
|
||||
- **HTML upload(默认交付)** — `/req prototype upload` 生成可交互独立 HTML,上传后以 iframe 关联 Requirement 和 PRD
|
||||
- **Stitch** (Google AI) — `/req prototype` 视觉探索与多屏草图,可作为 HTML 原型输入但不替代最终闭环
|
||||
- Figma — 手动精细设计
|
||||
- Sketch
|
||||
- Axure
|
||||
|
||||
@@ -0,0 +1,245 @@
|
||||
# 模块设计访谈、缺陷收敛与 HTML 原型闭环协议
|
||||
|
||||
本协议用于模块、系统、跨域流程等需要先澄清关键产品决策的设计任务。目标是让设计依据可追溯,让 PRD 在提交评审前经过可验证的缺陷收敛,并让 UI 模块通过可访问的 HTML 原型完成交互验证。
|
||||
|
||||
## 1. 进入与退出条件
|
||||
|
||||
满足任一条件时进入访谈模式:
|
||||
|
||||
- 用户明确要求“你问我答”、逐项讨论或产品访谈;
|
||||
- 设计对象是模块、系统、跨域流程或涉及多个角色/组织;
|
||||
- 目标、范围、数据归属、权限、状态流转、冲突优先级、异常策略中存在关键未决项。
|
||||
|
||||
需求范围小、上述决策均已明确时,可以直接编写 PRD。不要为了流程而重复询问用户已经回答的问题。
|
||||
|
||||
访谈模式只有同时满足以下条件才可结束:
|
||||
|
||||
1. 未决问题已清零,或明确列为非目标/后续项;
|
||||
2. AI 已给出结构化讨论结论;
|
||||
3. 用户明确确认讨论结论;
|
||||
4. PRD 已按结论创建或更新;
|
||||
5. `defect-analysis` 已对最新版 PRD 收敛;
|
||||
6. UI 模块的 HTML 原型已生成、上传、关联、回填和验证;无 UI 模块已记录不适用理由并获得用户确认;
|
||||
7. 用户联合确认收敛后的最终 PRD 与原型(或无 UI 的跳过结论)。
|
||||
|
||||
## 2. 讨论文档是跨轮次事实源
|
||||
|
||||
当当前工作已有 ai-proj Requirement 时,在提第一个问题前查找其已关联的讨论文档;没有时创建一个 documentation 角色的关联任务,并为任务创建文档:
|
||||
|
||||
- 任务标题:`【讨论】需求讨论: {需求标题}`
|
||||
- 文档标题:`{REQ-ID} 需求讨论记录`
|
||||
- 一个 Requirement 只维护一个当前讨论文档,不因会话中断重复创建。
|
||||
|
||||
查找时同时核对 Requirement 关联关系、任务角色和标题,不能只按相似标题猜测。发现多个候选讨论文档时,列出标识和最近更新时间,请用户指定或授权合并;在此之前不得静默选择其中一个继续写入。
|
||||
|
||||
初始化文档时,先把触发本次设计的用户原始消息按时间和消息边界逐条写入“原始诉求”,再记录 `Q001`。不得只留下 AI 总结而丢失原始上下文。
|
||||
|
||||
“完整过程”指可供产品决策审计的模型可见内容:用户原话、AI 向用户展示的问题/建议/权衡、工具写入结果、确认、决策变更、PRD 修订和缺陷处置。不得记录或声称记录隐藏推理、系统提示、访问凭据及其他不可披露的内部信息。
|
||||
|
||||
若尚未指定 Requirement,先请用户提供已有 Requirement,或明确授权创建。取得 Requirement 和讨论文档前不得开始声称“已留痕”的正式访谈;不得仅为执行本技能本身擅自创建 Requirement。用户明确要求“创建需求并设计”才构成创建授权。
|
||||
|
||||
每次恢复会话时,先读取 Requirement、现有 PRD 和讨论文档,从最后一个未决问题继续。讨论文档是跨会话、上下文压缩后的权威记录;模型记忆不能覆盖文档中的用户原话和已确认决策。
|
||||
|
||||
### 写入纪律
|
||||
|
||||
- 提问时先写入问题原文、问题意图和 AI 建议,再向用户提问。
|
||||
- 收到回答后,先把用户原话和由此形成的决策写入,再提出下一问。
|
||||
- 每轮使用稳定编号 `Q001`、`Q002`……;重试写入时复用编号,禁止重复追加同一轮。
|
||||
- AI 提供推荐方案或选项时,为待确认内容写出明确编号或完整原文。用户仅回复“确认”“是”“前者”等短答案时,最终决策必须引用对应编号和被确认的完整内容,不能只记录孤立短词。
|
||||
- 用户原话逐字保留在引用块中;AI 的解释、推论和建议必须分栏,不能伪装成用户决定。访问令牌、密码、私钥及依法需要保护的个人敏感信息不得落库,用 `[敏感信息已脱敏]` 替代并注明脱敏原因。
|
||||
- 文档以追加式记录为主。状态为“待回答”的问题块可以在收到回答后原位补全一次;变为“已确认”后不得静默改写。纠正已确认结论时追加“决策变更”,并引用被替代的编号。
|
||||
- 更新整篇文档前重新读取最新版并保留未知内容;若读取后文档又发生变化,基于最新版合并后重试,不能用旧副本覆盖其他会话的记录。
|
||||
- 写入后读取文档确认本轮编号和正文存在。写入或校验失败时立即报告,停止进入下一轮,且不得声称“已记录”。
|
||||
- Requirement 描述只同步用户确认后的“讨论结论”摘要;完整过程保留在讨论文档中。
|
||||
|
||||
## 3. 单轮单问访谈
|
||||
|
||||
每轮只问一个会实质改变产品方案的问题。优先按依赖关系覆盖以下决策面,而不是机械地逐项提问:
|
||||
|
||||
1. 用户问题、目标与成功指标;
|
||||
2. 角色、主体和数据归属;
|
||||
3. 范围、非目标及版本边界;
|
||||
4. 实体关系与基数,例如一对一、一对多、多对多;
|
||||
5. 权限来源、授权人和信任边界;
|
||||
6. 创建、加入、变更、退出、撤销等状态与生命周期;
|
||||
7. 多来源冲突时的优先级和人工覆盖规则;
|
||||
8. 失败、超时、失联、重复请求和恢复策略;
|
||||
9. 兼容、迁移、审计、数据隔离和验收方式。
|
||||
|
||||
问题应让用户做产品决策,不要求用户代替 AI 设计实现细节。用户让 AI 建议时,先给出一个推荐方案和主要权衡,再请用户确认或修正。若回答引入新的实体、状态或例外规则,沿其影响继续追问;若答案已能从用户原话或现有文档确定,则直接记录,不重复确认。
|
||||
|
||||
每轮记录以下内容:
|
||||
|
||||
```markdown
|
||||
### Q001 · {决策主题}
|
||||
|
||||
- 状态:待回答 | 已确认 | 已替代
|
||||
- AI 问题(原文):...
|
||||
- 提问意图:这个答案会影响哪些设计部分
|
||||
- AI 建议与权衡:推荐方案、替代方案及主要代价
|
||||
- 待确认内容:方案/选项编号及完整表述
|
||||
- 用户回答(原文):
|
||||
> ...
|
||||
- 最终决策:只写由用户回答直接支持的结论
|
||||
- 影响范围:PRD 章节、实体、流程、权限或验收标准
|
||||
- 未决项:无 | 下一步待确认内容
|
||||
- 记录时间:ISO 8601 时间
|
||||
```
|
||||
|
||||
## 4. 方案确认闸门
|
||||
|
||||
问题收敛后,在讨论文档追加“当前决策快照”,至少包含:
|
||||
|
||||
- 目标与成功条件;
|
||||
- 用户/角色及核心场景;
|
||||
- 范围与非目标;
|
||||
- 核心实体、关系和数据归属;
|
||||
- 权限、状态流转和冲突规则;
|
||||
- 异常、降级、撤销和审计;
|
||||
- 版本边界与后续项;
|
||||
- 可验证的验收标准草案;
|
||||
- 尚存风险和假设。
|
||||
|
||||
然后向用户展示同一份摘要并询问是否确认。只有用户明确表示确认,才能:
|
||||
|
||||
1. 将摘要同步到 Requirement 描述的 `## 讨论结论`;
|
||||
2. 创建或更新 PRD;
|
||||
3. 进入缺陷收敛循环。
|
||||
|
||||
每一步完成后重新读取目标对象确认写入成功。讨论结论未同步成功时不得开始写 PRD;PRD 未写入或读取到的内容与本次版本不一致时不得开始缺陷审计。
|
||||
|
||||
若用户修改任何结论,记录为新的问答或“决策变更”,更新快照后重新确认。
|
||||
|
||||
## 5. PRD 与 defect-analysis 收敛循环
|
||||
|
||||
讨论确认后,先按 `req-prd` 的完整模板生成或更新 PRD,再完整读取并调用 `defect-analysis`。每次审计都以**当前最新版完整 PRD**、已确认讨论记录和必要的真实代码/数据契约为输入,不能只审查上轮改动片段。首次基线审计必须覆盖 `defect-analysis` 中所有适用的架构、运行时、数据和体验/维护维度;不能因为尚未覆盖其他维度时某个单独维度为 0 个新缺陷而提前结束基线。
|
||||
|
||||
循环执行:
|
||||
|
||||
1. `defect-analysis` 检查最新版 PRD,并按其规则输出带严重度和轮次的缺陷;
|
||||
2. 将本轮输入版本、检查维度、完整发现和证据写入讨论文档;PRD 输入版本至少包含文档/任务标识、更新时间和内容摘要或哈希,避免审计结果关联到错误版本;审计轮使用稳定编号 `Round 001`、`Round 002`……,重试不得重复计轮;
|
||||
3. 对每个发现标记处置:接受、误报、延后;
|
||||
4. 接受的产品缺陷必须修订 PRD,并同步影响到验收标准、风险、非目标或版本边界;纯技术实现发现若不改变产品行为,记录为后续 `req-design` 约束或开发风险,不向 PRD 填入未经验证的实现细节;
|
||||
5. 误报必须记录反证;延后必须记录原因、风险、负责人或后续需求,不得静默忽略;
|
||||
6. 记录 PRD 修改摘要和仍未解决的问题,重新读取 PRD 确认修订已经持久化;
|
||||
7. 对修改后的完整 PRD 重新调用 `defect-analysis`。
|
||||
|
||||
若某个修复会改变已确认的目标、范围、实体关系、权限、用户流程、冲突规则或验收口径,不能由 AI 静默应用。将它追加为新的问答或“决策变更”,说明缺陷证据、推荐方案和代价,获得用户确认并更新决策快照后,再修订 PRD;随后重新开始最新版 PRD 的全量审计。
|
||||
|
||||
完成全维度基线后,只有 `defect-analysis` 对最新版完整 PRD 出现一轮“0 个新缺陷”时才能标记 PRD 收敛。达到 20 轮仍有新发现只是阶段复盘点:汇总剩余风险并请求用户决定是否继续;不得把“达到轮数”写成“已收敛”。用户已明确要求持续审计时,按该技能规则继续下一阶段。
|
||||
|
||||
存在以下任一情况时,不得提交 PRD 评审或宣称完成:
|
||||
|
||||
- 未处置的致命或高严重度缺陷;
|
||||
- 讨论文档缺失或有未成功写入的轮次;
|
||||
- PRD 与已确认决策不一致;
|
||||
- 缺少 0 新增缺陷的收敛轮;
|
||||
- UI 模块缺少已验证并关联的最终 HTML 原型,或原型与最新版 PRD 不一致;
|
||||
- 无 UI 模块没有记录跳过理由及用户确认;
|
||||
- 用户尚未联合确认收敛后的最终 PRD 与原型(或跳过结论)。
|
||||
|
||||
## 6. HTML 原型闭环
|
||||
|
||||
### 6.1 适用性判断
|
||||
|
||||
PRD 包含页面、表单、列表、可视状态、用户操作或跨页面流程时,必须执行 `req-prototype` 的 HTML upload 模式。Stitch 截图或其他静态图片可以辅助探索,但不能替代可交互 HTML、Requirement 关联和 iframe 回填。
|
||||
|
||||
纯后端、批处理、基础设施等无用户界面的模块可以跳过。跳过前必须把理由、影响范围和待确认内容写入讨论文档,取得用户明确确认,并在 PRD `4.2 界面原型` 留下“不适用”记录。
|
||||
|
||||
### 6.2 生成基线与覆盖范围
|
||||
|
||||
1. 重新读取最新版 PRD,记录任务/文档标识、更新时间、版本和内容摘要或哈希;
|
||||
2. 从功能需求、交互设计和验收标准提取页面清单、角色入口、主流程与关键状态;
|
||||
3. 调用 `req-prototype` 生成独立 HTML。至少覆盖核心入口、主流程,以及 PRD 明确要求的空态、加载态、失败态、无权限态、确认和撤销反馈;
|
||||
4. 原型不得引入 PRD 未确认的新权限、状态、自动化规则或默认值。为了连贯展示所作的推断必须显式标注为待确认,不能伪装成既定需求。
|
||||
|
||||
### 6.3 上传、关联、回填与验证
|
||||
|
||||
1. 通过 `upload_prototype` 上传 HTML,并记录 Requirement 数字 ID、原型 URL、版本说明和上传时间;
|
||||
2. 重新读取 Requirement,确认返回的原型 URL/版本确实已关联。仅拿到上传成功响应不足以通过;
|
||||
3. 将 iframe、PRD 基线、原型版本、版本说明和验证结果回填 PRD `4.2 界面原型`;
|
||||
4. 用浏览器或等价方式验证 URL 可访问、iframe 可展示、核心导航和交互可操作、关键状态可识别。使用临时浏览器时按环境规则关闭;
|
||||
5. 将生成输入、上传结果、验证证据和待确认差异写入讨论文档。任何写入或验证失败都必须停止,不得声称原型已完成。
|
||||
|
||||
### 6.4 用户评审与回流
|
||||
|
||||
向用户展示最终关联的原型,并请其同时检查信息结构、流程、状态、权限提示和关键文案:
|
||||
|
||||
- 仅视觉样式、间距、颜色等不改变产品行为的反馈,可以直接生成新原型版本,并记录修改摘要;
|
||||
- 反馈改变目标、范围、实体关系、权限、状态、流程、异常策略、默认值或验收口径时,追加新的问答/决策变更,更新决策快照和 PRD,重新执行完整 `defect-analysis`,收敛后再生成新 HTML 原型版本;
|
||||
- 每个新版本都必须重新执行关联、PRD 回填和可访问性/交互验证,不得覆盖或伪造历史版本;
|
||||
- 只有用户明确确认“最终 PRD 与当前原型一致”后,模块产品设计才可结束。
|
||||
|
||||
## 7. 讨论文档结构
|
||||
|
||||
```markdown
|
||||
# {REQ-ID} 需求讨论记录
|
||||
|
||||
## 元数据
|
||||
- Requirement:...
|
||||
- 状态:访谈中 | 待方案确认 | PRD 优化中 | 原型制作中 | 待最终确认 | 已收敛
|
||||
- 最新 PRD:任务/文档标识
|
||||
- 更新时间:...
|
||||
|
||||
## 原始诉求
|
||||
> 用户原话,按时间追加
|
||||
|
||||
## 问答记录
|
||||
### Q001 · ...
|
||||
...
|
||||
|
||||
## 决策变更
|
||||
### D001 · 替代 Qxxx 的结论
|
||||
...
|
||||
|
||||
## 当前决策快照
|
||||
...
|
||||
|
||||
## 未决问题
|
||||
- ...
|
||||
|
||||
## 方案确认
|
||||
- 用户确认原话:...
|
||||
- 确认时间:...
|
||||
|
||||
## PRD / 缺陷优化记录
|
||||
### Round 1 · {检查维度}
|
||||
- PRD 版本/摘要:...
|
||||
- 新缺陷:...
|
||||
- 处置与证据:...
|
||||
- PRD 修订:...
|
||||
- 剩余风险:...
|
||||
|
||||
## HTML 原型记录
|
||||
### Prototype v1 · {版本说明}
|
||||
- PRD 基线:任务/文档标识、版本、更新时间、摘要或哈希
|
||||
- 是否适用:是 | 否(理由与用户确认)
|
||||
- 原型 URL:...
|
||||
- Requirement 关联校验:...
|
||||
- iframe / 可访问性 / 关键交互验证:...
|
||||
- 用户反馈:...
|
||||
- 行为性变更回流:无 | 对应 Q/D、PRD 版本和 defect 轮次
|
||||
- 状态:待验证 | 待用户确认 | 已替代 | 已确认
|
||||
|
||||
## 收敛结论
|
||||
- 收敛轮次:...
|
||||
- 0 新增缺陷证据:...
|
||||
- 最终原型版本/URL:... | 无 UI,不适用(确认记录:...)
|
||||
- PRD 与原型一致性确认:...
|
||||
- 未解决的中/低风险及接受理由:...
|
||||
- 用户最终确认原话:...
|
||||
```
|
||||
|
||||
## 8. 最终交付说明
|
||||
|
||||
最终回复必须同时给出:
|
||||
|
||||
- ai-proj Requirement 标识;
|
||||
- 讨论任务/文档标识;
|
||||
- PRD 任务/文档标识;
|
||||
- 问答轮数、缺陷审计轮数和收敛轮;
|
||||
- HTML 原型版本、URL、Requirement 关联与验证状态;无 UI 时给出跳过理由和用户确认;
|
||||
- 仍被接受的中/低风险;
|
||||
- 用户两次确认:讨论方案确认、最终 PRD 与原型(或无 UI 结论)的联合确认。
|
||||
|
||||
任何标识或写入状态无法验证时,用“未验证/未写入”如实标注。
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "req-prototype-plugin",
|
||||
"description": "原型生成与关联。支持 HTML 上传(/req prototype upload,iframe 嵌入详情页)和 Stitch AI 生成两种模式。",
|
||||
"version": "2.0.0",
|
||||
"description": "原型生成与关联。支持 HTML 正式交付、Requirement 关联、iframe 验证闭环及 Stitch AI 视觉探索。",
|
||||
"version": "2.1.0",
|
||||
"author": {
|
||||
"name": "qiudl"
|
||||
},
|
||||
|
||||
@@ -1,19 +1,20 @@
|
||||
---
|
||||
name: req-prototype
|
||||
description: 原型生成与关联。支持两种模式:(1) Stitch AI 基于 PRD 自动生成 UI 原型截图;(2) AI 编写 HTML 原型并上传关联到需求详情页 iframe。当执行 /req prototype 或需要生成/上传界面原型时使用。
|
||||
arguments: <REQ-ID> [subcommand] [options]
|
||||
---
|
||||
|
||||
# 原型设计 Skill (req-prototype)
|
||||
|
||||
用法:`/req prototype <REQ-ID> [subcommand] [options]`
|
||||
|
||||
## 概述
|
||||
|
||||
支持两种原型工作流:
|
||||
|
||||
| 模式 | 命令 | 适用场景 | 输出 |
|
||||
|------|------|----------|------|
|
||||
| **HTML 上传** | `/req prototype upload` | 快速展示、评审用静态原型 | iframe 嵌入需求详情页 |
|
||||
| **Stitch AI** | `/req prototype` | 精细 UI 设计、多屏交互 | 截图回填 PRD 文档 |
|
||||
| **HTML 上传** | `/req prototype upload` | UI 模块正式产品设计交付、评审与交互验证 | 可交互 HTML + Requirement 关联 + PRD iframe |
|
||||
| **Stitch AI** | `/req prototype` | 精细 UI 视觉探索、多屏草图 | 截图回填 PRD,后续仍需转为 HTML 正式原型 |
|
||||
|
||||
## 前置条件
|
||||
|
||||
@@ -22,24 +23,30 @@ arguments: <REQ-ID> [subcommand] [options]
|
||||
| 检查项 | 方式 | 失败处理 |
|
||||
|--------|------|----------|
|
||||
| 需求存在 | `mcp__ai-proj__get_requirement` | 报错:需求不存在 |
|
||||
| PRD 文档存在(Stitch 模式)| 找 linkRole=prd 任务 + 检查文档 | 报错:请先执行 req-prd |
|
||||
| PRD 文档存在(两种模式)| 找 linkRole=prd 任务 + 检查文档 | 报错:请先执行 req-prd |
|
||||
| PRD 已完成 defect 收敛(正式 HTML 模式) | 读取讨论文档的收敛轮和最新版 PRD 标识 | 报错:先完成 req-prd/defect-analysis 收敛 |
|
||||
| UI 原型适用 | PRD 含页面、操作流程或可视状态 | 无 UI 时记录不适用理由与用户确认,不生成空壳原型 |
|
||||
|
||||
## 子命令
|
||||
|
||||
### 0. `/req prototype upload [REQ-ID] [--note "版本说明"]` — 上传 HTML 原型(**推荐**)
|
||||
|
||||
**适用场景**:快速为需求关联一个带样式的 HTML 原型,直接在需求详情页以 iframe 展示,供评审人预览交互流程。
|
||||
**适用场景**:为 UI 模块生成正式 HTML 原型,直接在需求详情页以 iframe 展示,供评审人预览和验证交互流程。模块产品设计默认使用此模式完成原型闸门。
|
||||
|
||||
**执行流程**:
|
||||
|
||||
```
|
||||
1. 获取需求信息(mcp__ai-proj__get_requirement),取得数字 id
|
||||
2. 读取 PRD 或需求描述,提炼 UI 关键信息
|
||||
3. AI 编写带完整样式的 HTML 原型文件(见设计规范)
|
||||
4. 保存到 /tmp/proto_<req_id>_<timestamp>.html
|
||||
5. Base64 编码:base64 < /tmp/proto_<req_id>_<timestamp>.html
|
||||
6. 调用 mcp__ai-proj__upload_prototype 上传(传入 requirementId + base64 content)
|
||||
7. 确认上传成功,输出 COS 预览 URL
|
||||
1. 获取需求信息(mcp__ai-proj__get_requirement),取得数字 id,并定位唯一 PRD 与讨论文档
|
||||
2. 完整读取最新版 PRD,记录任务/文档 ID、版本、更新时间和内容摘要或哈希;正式交付还要核对 defect 收敛轮
|
||||
3. 从 PRD 提取页面清单、角色入口、主流程、关键状态和验收条件,形成覆盖矩阵
|
||||
4. AI 编写带完整样式和必要原生交互的独立 HTML 原型文件(见设计规范)
|
||||
5. 保存到 /tmp/proto_<req_id>_<timestamp>.html,并在本地做结构、大小和敏感信息检查
|
||||
6. Base64 编码:base64 < /tmp/proto_<req_id>_<timestamp>.html
|
||||
7. 调用 mcp__ai-proj__upload_prototype 上传(传入 requirementId + base64 content)
|
||||
8. 重新读取 Requirement,确认原型 URL/版本已关联;不得只相信上传响应
|
||||
9. 将 iframe、PRD 基线、原型版本/说明和验证状态回填 PRD「4.2 界面原型」
|
||||
10. 打开最终 URL 或需求详情页,验证 iframe 展示和核心交互;记录证据后关闭临时浏览器
|
||||
11. 将生成、关联、验证、用户反馈和版本状态写入同一讨论文档
|
||||
```
|
||||
|
||||
**Step 5-6 执行方式**:
|
||||
@@ -103,6 +110,9 @@ AI 生成的 HTML 原型必须满足以下要求:
|
||||
- 覆盖需求描述中的核心功能点
|
||||
- 展示关键数据状态(列表、表单、卡片等)
|
||||
- 按钮/操作有视觉反馈样式(hover 色等)
|
||||
- 对 PRD 明确要求的空态、加载态、失败态、无权限态、二次确认和撤销反馈提供可切换或可识别的展示
|
||||
- 不得自行引入 PRD 未确认的权限、状态、自动化规则或默认值;不可避免的展示推断必须标为待确认
|
||||
- 不包含访问令牌、真实手机号/邮箱、生产数据等敏感信息
|
||||
|
||||
**模板参考**(顶部 topbar + 侧边栏 + 主内容区):
|
||||
|
||||
@@ -147,6 +157,41 @@ AI 生成的 HTML 原型必须满足以下要求:
|
||||
|
||||
---
|
||||
|
||||
#### HTML 原型 PRD 回填
|
||||
|
||||
定位 PRD `### 4.2 界面原型`,写入或更新以下内容;保留历史版本记录,不把旧 URL 静默改写成新版本:
|
||||
|
||||
```markdown
|
||||
### 4.2 界面原型
|
||||
|
||||
**原型基线**:
|
||||
- PRD 任务/文档:#... / #...
|
||||
- PRD 版本/更新时间/摘要:...
|
||||
- defect 收敛轮:Round ...(0 个新缺陷)
|
||||
- HTML 原型:v... · [版本说明]
|
||||
- Requirement 关联:已复读验证
|
||||
- 验证结果:URL 可访问;iframe 可展示;核心交互通过
|
||||
|
||||
<iframe src="[prototype_url]"
|
||||
width="100%" height="600" frameborder="0"
|
||||
style="border-radius:8px;border:1px solid #e5e7eb;">
|
||||
</iframe>
|
||||
```
|
||||
|
||||
原型反馈改变目标、范围、实体关系、权限、状态、流程、异常策略、默认值或验收口径时,不得只改 HTML。回到 `req-prd` 追加问答/决策变更,修订 PRD,重新执行完整 `defect-analysis`,收敛后再上传新原型版本。纯视觉反馈可以直接生成新版本,但仍需重新关联、回填和验证。
|
||||
|
||||
#### HTML 上传后验证清单
|
||||
|
||||
- [ ] 上传响应成功且 Requirement 复读能看到同一 URL/版本
|
||||
- [ ] 原型 URL 返回可展示的 HTML,不是下载错误页、登录页或 404
|
||||
- [ ] 需求详情页使用 iframe 展示,没有降级为截图或图片
|
||||
- [ ] 核心入口、主流程和覆盖矩阵中的关键状态可识别/可操作
|
||||
- [ ] 600px iframe 下内容可用,没有关键操作被固定栏遮挡
|
||||
- [ ] 浏览器控制台无阻断交互的错误,原型不依赖外部 CDN
|
||||
- [ ] PRD `4.2` 与讨论文档均记录基线、版本、URL、验证和反馈状态
|
||||
|
||||
---
|
||||
|
||||
### 1. `/req prototype [REQ-ID]` — Stitch AI 生成原型
|
||||
|
||||
**流程**:
|
||||
@@ -160,6 +205,7 @@ AI 生成的 HTML 原型必须满足以下要求:
|
||||
6. 生成页面(mcp__stitch__generate_screen_from_text)
|
||||
7. 获取截图(mcp__stitch__get_screen)
|
||||
8. 回填 PRD「4.2 界面原型」章节
|
||||
9. 若用于模块正式交付,将选定设计转换为 HTML upload 原型,并完成关联、iframe 和验证闭环
|
||||
```
|
||||
|
||||
**参数**:
|
||||
@@ -285,6 +331,8 @@ generated_at: "<timestamp>"
|
||||
| HTML 文件超过 5MB | 精简样式或拆分多版本上传 |
|
||||
| iframe 不显示 | 检查 `prototype_urls` 字段是否非空:`mcp__ai-proj__get_requirement` 确认 |
|
||||
| base64 命令失败 | macOS 用 `base64 < file`,Linux 用 `base64 -w 0 < file` |
|
||||
| Requirement 复读没有新 URL | 视为关联失败,停止回填“已验证”,检查 requirementId 和上传响应后再处理 |
|
||||
| URL 可访问但关键交互失败 | 修复 HTML、上传新版本并重新验证,不覆盖失败版本的记录 |
|
||||
|
||||
### 原型展示规则
|
||||
|
||||
@@ -303,6 +351,8 @@ generated_at: "<timestamp>"
|
||||
|
||||
> 背景:REQ-20260420-0031 反馈原型图用图片方式展示,无法交互预览,改为 iframe 后可正常使用。
|
||||
|
||||
Stitch 截图只用于视觉探索,不满足模块产品设计的最终 HTML 原型闸门。
|
||||
|
||||
|
||||
### Stitch 模式
|
||||
|
||||
|
||||
@@ -13,10 +13,10 @@ mkdir -p "$TEST_HOME"
|
||||
cp "$PROJECT_DIR/install-skills.sh" "$FIXTURE_REPO/install-skills.sh"
|
||||
|
||||
write_manifest() {
|
||||
local plugin="$1" name="$2" version="$3"
|
||||
local plugin="$1" name="$2" version="$3" install_type="${4:-skill}"
|
||||
mkdir -p "$FIXTURE_REPO/skills-dev/${plugin}-plugin/.claude-plugin"
|
||||
cat > "$FIXTURE_REPO/skills-dev/${plugin}-plugin/.claude-plugin/plugin.json" <<JSON
|
||||
{"name":"${plugin}-plugin","version":"${version}","install_name":"${name}","install_type":"skill","dir_category":"dev"}
|
||||
{"name":"${plugin}-plugin","version":"${version}","install_name":"${name}","install_type":"${install_type}","dir_category":"dev"}
|
||||
JSON
|
||||
}
|
||||
|
||||
@@ -31,7 +31,7 @@ EOF
|
||||
printf 'reference one\n' > "$FIXTURE_REPO/skills-dev/example-plugin/skills/references/guide.md"
|
||||
|
||||
HOME="$TEST_HOME" "$FIXTURE_REPO/install-skills.sh" >/dev/null
|
||||
test -f "$TEST_HOME/.claude/skills/example/references/guide.md"
|
||||
test -f "$TEST_HOME/.agents/skills/example/references/guide.md"
|
||||
|
||||
# A repository version upgrade replaces an unchanged prior install.
|
||||
write_manifest example example 2.0.0
|
||||
@@ -43,17 +43,17 @@ description: Installer fixture version two.
|
||||
version two
|
||||
EOF
|
||||
HOME="$TEST_HOME" "$FIXTURE_REPO/install-skills.sh" >/dev/null
|
||||
grep -q 'version two' "$TEST_HOME/.claude/skills/example/SKILL.md"
|
||||
grep -q '"version": "2.0.0"' "$TEST_HOME/.claude/.installed-skills.json"
|
||||
grep -q 'version two' "$TEST_HOME/.agents/skills/example/SKILL.md"
|
||||
grep -q '"version": "2.0.0"' "$TEST_HOME/.agents/.ai-proj-helper-installed-skills.json"
|
||||
|
||||
# A local edit is preserved even when the repository advances again.
|
||||
printf 'local edit\n' >> "$TEST_HOME/.claude/skills/example/SKILL.md"
|
||||
printf 'local edit\n' >> "$TEST_HOME/.agents/skills/example/SKILL.md"
|
||||
write_manifest example example 3.0.0
|
||||
printf 'repository version three\n' >> "$FIXTURE_REPO/skills-dev/example-plugin/skills/SKILL.md"
|
||||
output="$(HOME="$TEST_HOME" "$FIXTURE_REPO/install-skills.sh")"
|
||||
grep -q 'local files were modified' <<<"$output"
|
||||
grep -q 'local edit' "$TEST_HOME/.claude/skills/example/SKILL.md"
|
||||
if grep -q 'repository version three' "$TEST_HOME/.claude/skills/example/SKILL.md"; then
|
||||
grep -q 'local edit' "$TEST_HOME/.agents/skills/example/SKILL.md"
|
||||
if grep -q 'repository version three' "$TEST_HOME/.agents/skills/example/SKILL.md"; then
|
||||
echo 'local modification was overwritten' >&2
|
||||
exit 1
|
||||
fi
|
||||
@@ -70,9 +70,45 @@ description: Legacy installation fixture.
|
||||
legacy content
|
||||
EOF
|
||||
printf 'legacy reference\n' > "$FIXTURE_REPO/skills-dev/legacy-plugin/skills/references/guide.md"
|
||||
mkdir -p "$TEST_HOME/.claude/skills/legacy"
|
||||
cp "$FIXTURE_REPO/skills-dev/legacy-plugin/skills/SKILL.md" "$TEST_HOME/.claude/skills/legacy/SKILL.md"
|
||||
mkdir -p "$TEST_HOME/.agents/skills/legacy"
|
||||
cp "$FIXTURE_REPO/skills-dev/legacy-plugin/skills/SKILL.md" "$TEST_HOME/.agents/skills/legacy/SKILL.md"
|
||||
HOME="$TEST_HOME" "$FIXTURE_REPO/install-skills.sh" >/dev/null
|
||||
test -f "$TEST_HOME/.claude/skills/legacy/references/guide.md"
|
||||
test -f "$TEST_HOME/.agents/skills/legacy/references/guide.md"
|
||||
|
||||
# Command manifests become standard Codex skills, while explicit Claude
|
||||
# installs retain the legacy single-file command layout. Both must be stable on
|
||||
# a second run despite the Claude filename change.
|
||||
write_manifest sample-command sample-command 1.0.0 command
|
||||
mkdir -p "$FIXTURE_REPO/skills-dev/sample-command-plugin/skills"
|
||||
cat > "$FIXTURE_REPO/skills-dev/sample-command-plugin/skills/SKILL.md" <<'EOF'
|
||||
---
|
||||
name: sample-command
|
||||
description: Command installation fixture.
|
||||
---
|
||||
command content
|
||||
EOF
|
||||
|
||||
CODEX_TEST_HOME="$TEST_ROOT/codex-home"
|
||||
mkdir -p "$CODEX_TEST_HOME"
|
||||
HOME="$CODEX_TEST_HOME" "$FIXTURE_REPO/install-skills.sh" >/dev/null
|
||||
test -f "$CODEX_TEST_HOME/.agents/skills/sample-command/SKILL.md"
|
||||
test ! -e "$CODEX_TEST_HOME/.claude/commands/sample-command.md"
|
||||
codex_output="$(HOME="$CODEX_TEST_HOME" "$FIXTURE_REPO/install-skills.sh" --dry-run)"
|
||||
grep -q '0 plugins would be installed/updated' <<<"$codex_output"
|
||||
if grep -q 'sample-command: local files were modified' <<<"$codex_output"; then
|
||||
echo 'Codex command skill was reported as modified' >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
CLAUDE_TEST_HOME="$TEST_ROOT/claude-home"
|
||||
mkdir -p "$CLAUDE_TEST_HOME"
|
||||
HOME="$CLAUDE_TEST_HOME" "$FIXTURE_REPO/install-skills.sh" --agent claude >/dev/null
|
||||
test -f "$CLAUDE_TEST_HOME/.claude/commands/sample-command.md"
|
||||
claude_output="$(HOME="$CLAUDE_TEST_HOME" "$FIXTURE_REPO/install-skills.sh" --agent claude --dry-run)"
|
||||
grep -q '0 plugins would be installed/updated' <<<"$claude_output"
|
||||
if grep -q 'sample-command: local files were modified' <<<"$claude_output"; then
|
||||
echo 'Claude command was reported as modified after filename conversion' >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo 'install-skills tests passed'
|
||||
|
||||
Reference in New Issue
Block a user