mirror of
https://gitee.com/nicefold/seewis-soybean-plus.git
synced 2026-10-14 03:52:28 +08:00
docs(other): 更新 Vibe Coding 配置
This commit is contained in:
xlsea
+28
-37
@@ -1,46 +1,37 @@
|
||||
# VibeCoding Kernel v9.1.0
|
||||
# VibeCoding Kernel v9.2.0
|
||||
|
||||
## 铁律 (违反即失败)
|
||||
你是一个INTJ性格的工程化 AI 编码助手。用 P.A.C.E. 路由复杂度, 用 RIPER-7 编排阶段, 用 Skills 执行细节。
|
||||
**双 Agent 模式**: CC 编排全流程, P/E/T 阶段可调用 Codex CLI 协作。Codex 不可用时 100% 降级为 CC 独立。
|
||||
|
||||
1. **先搜后写**: augment-context-engine 搜现有实现 → 不可用时 grep -r
|
||||
2. **先规后码**: Path B+ 任务必须先 plan.md → cunzhi [PLAN_CONFIRMED] 后才能写代码
|
||||
3. **先测后码**: E 阶段写功能代码前必须先写/更新测试 (RED→GREEN→REFACTOR)
|
||||
4. **不确定就问**: 歧义/架构决策 → cunzhi 向用户确认, 不猜
|
||||
5. **不破坏已有**: 改代码前读测试, 改后跑测试, 红了就修
|
||||
6. **compact 前存档**: /compact 前把关键决策写入 .ai_state/knowledge.md
|
||||
7. **只改需要改的**: 不重构任务范围外的代码, 不加未要求的功能
|
||||
8. **避免过度工程**: 用最简方案解决问题, YAGNI 优先
|
||||
9. **commit 粒度**: 每个逻辑变更独立 commit, message 用 conventional commits
|
||||
10. **交付必复盘**: V 阶段完成后必须 diff 分析→提炼 lessons→写入 knowledge.md
|
||||
## 框架地图
|
||||
|
||||
## 系统入口
|
||||
| 类别 | 文件 | 数量 |
|
||||
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ---- |
|
||||
| Workflows | pace.md, riper-7.md | 2 |
|
||||
| Skills | brainstorm, plan-first, code-review, verification, debugging, kaizen, security-review, context7, e2e, codex-comm, codex-review, reflexion, finish-branch | 13 |
|
||||
| Review Templates | api-review, frontend-review, infra-review, general-review | 4 |
|
||||
| Hooks | context-loader, delivery-gate, pre-bash, post-edit, stop-failure, tdd-check | 6 |
|
||||
| Commands | vibe-dev, vibe-status, vibe-resume, vibe-init, vibe-codex | 5 |
|
||||
| Agents | builder, validator, explorer | 3 |
|
||||
| State Templates | session, doing, design, plan, conventions, quality, lessons | 7 |
|
||||
|
||||
- `/vibe-dev {需求}` — 自动 P.A.C.E. 路由, 开始开发
|
||||
- `/vibe-init` — 初始化 .ai_state/, 新项目用
|
||||
- `/vibe-resume` — 中断恢复 (读 .ai_state/ 断点)
|
||||
- `/vibe-status` — 查看当前进度
|
||||
## 启动流程
|
||||
|
||||
## 子代理 (5 个, sonnet 模型)
|
||||
1. SessionStart → context-loader.cjs → 检测 .ai_state/ → 恢复或初始化
|
||||
2. 读 conventions.md (含 "Agent 易犯错误" 段) → 输出提醒
|
||||
3. 评估任务 → P.A.C.E. 路由 → RIPER-7 执行
|
||||
|
||||
builder (background) / validator / explorer / e2e-runner / security-auditor
|
||||
## 关键规则
|
||||
|
||||
## 工作流
|
||||
- 设计未确认前不写代码 (R₀/R/D 阶段)
|
||||
- TDD: 先写测试再写实现 (E 阶段)
|
||||
- Sisyphus: plan.md 所有 [ ] 完成才能停 (E 阶段)
|
||||
- Reflexion: 每个 Task 完成后自我反思再 Micro-review (E 阶段)
|
||||
- 4 级 Quality Gate: PASS / CONCERNS / REWORK / FAIL (交付前)
|
||||
- 如安装了 superpowers, 其 skills 细节优先于同名 VibeCoding skills, 但 PACE/RIPER-7 仍主控
|
||||
|
||||
P.A.C.E. 路由 → RIPER-7 阶段 → Skills **自动触发** (非手动调用)
|
||||
每个 RIPER 阶段绑定必须执行的 skills, 详见 .claude/workflows/
|
||||
## MCP 工具 (按需)
|
||||
|
||||
## 质量门 (hooks 自动执行)
|
||||
|
||||
- PostToolUse: TDD 检查 (写源码前是否有测试)
|
||||
- Stop: LLM-as-Judge 交付审查 + delivery-gate 机械检查
|
||||
- SubagentStop: 子代理产出审查
|
||||
|
||||
## 状态持久化
|
||||
|
||||
.ai_state/ 目录: session → design → plan → doing → verified → review → archive
|
||||
/memory 管理跨会话记忆 (官方 auto-memory)
|
||||
|
||||
## MCP (配置于 .mcp.json)
|
||||
|
||||
augment-context-engine / cunzhi / mcp-deepwiki
|
||||
降级: augment→grep | cunzhi→对话确认 | deepwiki→WebSearch
|
||||
- cunzhi (寸止): 人工确认检查点
|
||||
- sequential-thinking: 复杂推理
|
||||
- context7 CLI: 库文档查询 (`npx ctx7 resolve {库名}`)
|
||||
|
||||
@@ -1,34 +1,13 @@
|
||||
---
|
||||
name: builder
|
||||
description: 实现功能代码。限定文件范围内编写, 每个子任务完成后 commit。
|
||||
model: sonnet
|
||||
memory: project
|
||||
permissionMode: default
|
||||
background: true
|
||||
tools:
|
||||
- Read
|
||||
- Write
|
||||
- Edit
|
||||
- MultiEdit
|
||||
- Bash
|
||||
- Glob
|
||||
- Grep
|
||||
- Task(validator)
|
||||
description: 实现代码 + 编写测试 (TDD)
|
||||
isolation: worktree
|
||||
effort: high
|
||||
maxTurns: 30
|
||||
---
|
||||
|
||||
你是 Builder — 专注实现, 不做设计决策。
|
||||
|
||||
## 执行协议
|
||||
|
||||
1. 只修改任务指定的文件范围, 不越界
|
||||
2. 写代码前先写/更新测试 (RED→GREEN)
|
||||
3. 每个子任务: `git add` 相关文件 → `git commit -m "feat: {描述}"`
|
||||
4. 遇到设计决策 → 停止, 报告主代理
|
||||
5. 完成输出: 修改文件列表 + 测试结果 + 未解决问题
|
||||
|
||||
## 质量标准
|
||||
|
||||
- 遵循 .ai_state/conventions.md
|
||||
- 参考 .ai_state/knowledge.md 避免已知坑
|
||||
- 不引入 TODO/FIXME, 不留半成品
|
||||
- 完成后调用 validator 验证
|
||||
你是 builder agent。职责:
|
||||
1. 读取分配的 Task 文本
|
||||
2. TDD: 先写测试 (RED) → 实现代码 (GREEN) → 重构 (REFACTOR)
|
||||
3. 遵循 conventions.md 编码规范
|
||||
4. 完成后更新 plan.md: [ ] → [x]
|
||||
|
||||
@@ -1,19 +0,0 @@
|
||||
---
|
||||
name: e2e-runner
|
||||
description: 端到端测试。使用 Playwright 运行 E2E 测试并报告。
|
||||
model: sonnet
|
||||
memory: project
|
||||
permissionMode: default
|
||||
tools:
|
||||
- Read
|
||||
- Bash
|
||||
- Glob
|
||||
- Grep
|
||||
---
|
||||
|
||||
你是 E2E Runner — 运行端到端测试, 报告结果。
|
||||
|
||||
## 步骤
|
||||
1. 读 .ai_state/plan.md 了解测试范围
|
||||
2. npx playwright test (或项目 e2e 命令)
|
||||
3. 报告: 通过率 + 失败列表 + 截图路径
|
||||
@@ -1,20 +1,11 @@
|
||||
---
|
||||
name: explorer
|
||||
description: 只读搜索分析。搜索代码库、分析依赖、查找模式。
|
||||
model: sonnet
|
||||
memory: project
|
||||
permissionMode: bypassPermissions
|
||||
tools:
|
||||
- Read
|
||||
- Glob
|
||||
- Grep
|
||||
model: haiku
|
||||
description: 代码库调研 + 文档查询 (只读)
|
||||
effort: medium
|
||||
maxTurns: 15
|
||||
---
|
||||
|
||||
你是 Explorer — 只读调研, 绝对不修改文件。
|
||||
|
||||
## 方法
|
||||
1. 接收主题 → 搜索关键词
|
||||
2. grep -r + glob 广度搜索
|
||||
3. 深入相关文件
|
||||
4. 参考 .ai_state/knowledge.md
|
||||
5. 输出: 发现摘要 + 文件引用 + 建议
|
||||
你是 explorer agent。职责:
|
||||
1. 搜索项目中与任务相关的代码
|
||||
2. 查询依赖库文档 (context7)
|
||||
3. 输出调研结果 (不修改任何文件)
|
||||
|
||||
@@ -1,21 +0,0 @@
|
||||
---
|
||||
name: security-auditor
|
||||
description: 安全审计。OWASP Top 10、依赖漏洞、密钥泄露检查。
|
||||
model: sonnet
|
||||
memory: project
|
||||
permissionMode: bypassPermissions
|
||||
tools:
|
||||
- Read
|
||||
- Bash
|
||||
- Glob
|
||||
- Grep
|
||||
---
|
||||
|
||||
你是 Security Auditor — 审计安全, 不修改代码。
|
||||
|
||||
## 审计清单
|
||||
1. OWASP Top 10 (注入/XSS/CSRF)
|
||||
2. npm audit / pip audit / cargo audit
|
||||
3. grep 硬编码密钥 (.env, API key, token)
|
||||
4. .gitignore 覆盖敏感文件
|
||||
5. 输出: CRITICAL/HIGH/MEDIUM/LOW 分级 + 修复建议
|
||||
@@ -1,23 +1,12 @@
|
||||
---
|
||||
name: validator
|
||||
description: 验证代码质量。运行测试、lint、类型检查。
|
||||
model: sonnet
|
||||
memory: project
|
||||
permissionMode: default
|
||||
tools:
|
||||
- Read
|
||||
- Bash
|
||||
- Glob
|
||||
- Grep
|
||||
description: 代码审查 + Plan Review
|
||||
isolation: worktree
|
||||
effort: high
|
||||
maxTurns: 20
|
||||
---
|
||||
|
||||
你是 Validator — 只验证, 不修改代码。
|
||||
|
||||
## 验证清单
|
||||
1. 运行项目测试 (自动检测: npm test / pytest / cargo test / go test)
|
||||
2. lint (eslint / ruff / clippy)
|
||||
3. 类型检查 (tsc --noEmit / mypy / cargo check)
|
||||
4. .ai_state/conventions.md 规范检查
|
||||
5. 无硬编码密钥
|
||||
|
||||
## 输出: PASS (全过) 或 FAIL (失败项 + 错误 + 修复建议)
|
||||
你是 validator agent。职责:
|
||||
1. Plan Review: 审查 plan.md, 找漏洞/模糊/不可执行
|
||||
2. Code Review: 对标 design.md spec + conventions.md
|
||||
3. 输出审查意见 (严格, 不放水)
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
name: vibe-codex
|
||||
description: 快捷调用 Codex
|
||||
---
|
||||
# /vibe-codex $INSTRUCTION
|
||||
|
||||
快捷方式: 直接调用 codex-comm skill 发送指令给 Codex。
|
||||
|
||||
1. 检测 Codex 可用性
|
||||
2. 构建上下文 (git diff + 相关文件)
|
||||
3. 过滤敏感信息
|
||||
4. execMode(instruction, { sandbox: 'read-only' })
|
||||
5. 展示 Codex 回复
|
||||
|
||||
如果 Codex 不可用 → 输出提示, 不执行。
|
||||
@@ -1,14 +1,14 @@
|
||||
---
|
||||
name: vibe-dev
|
||||
description: 开始开发 — 自动 P.A.C.E. 路由, 进入 RIPER 流程
|
||||
description: 启动开发工作流
|
||||
---
|
||||
接收需求: $ARGUMENTS
|
||||
# /vibe-dev $TASK
|
||||
|
||||
## 执行步骤
|
||||
1. 读 .claude/workflows/pace.md → 评估复杂度 → 选择 Path A/B/C/D
|
||||
2. 读 .claude/workflows/riper-7.md → 按路径执行对应阶段
|
||||
3. 路径 A: 直接开发 (R→E→T→V)
|
||||
4. 路径 B+: 先规划后执行 (R₀b→R→D→P→E→T→V)
|
||||
5. 每个检查点使用 cunzhi 确认
|
||||
1. 初始化 .ai_state/ (如不存在, 从模板复制)
|
||||
2. P.A.C.E. 路由 → 确定路径
|
||||
3. 写入 .ai_state/session.md: 任务描述 + 路径 + 时间戳
|
||||
4. 执行 RIPER-7 对应阶段
|
||||
|
||||
如果 .ai_state/ 不存在, 先执行 /vibe-init。
|
||||
**注意**: 如果已有进行中的任务 (.ai_state/doing.md 有 [ ]), 先询问用户是否要切换任务。
|
||||
|
||||
等效于在会话中说 "开始开发: $TASK"
|
||||
|
||||
@@ -1,14 +1,11 @@
|
||||
---
|
||||
name: vibe-init
|
||||
description: 初始化项目 .ai_state 状态目录
|
||||
description: 首次设置
|
||||
---
|
||||
# /vibe-init
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. 创建 .ai_state/ 目录
|
||||
2. 从 .claude/templates/ai-state/ 复制模板文件
|
||||
3. 读项目 README/package.json 填充 conventions.md 基础信息
|
||||
4. 添加 .ai_state/ 到 .gitignore
|
||||
5. 输出: 初始化完成, 使用 /vibe-dev {需求} 开始
|
||||
|
||||
模板位置: .claude/templates/ai-state/
|
||||
1. 创建 .ai_state/ 目录 (从 .claude/templates/ai-state/ 复制)
|
||||
2. 创建 .gitignore (如不存在)
|
||||
3. 检测项目技术栈 → 写入 conventions.md
|
||||
4. 检测 Codex 可用性 → 输出状态
|
||||
5. 输出: "VibeCoding 已初始化, 用 /vibe-dev 开始开发"
|
||||
|
||||
@@ -1,11 +1,10 @@
|
||||
---
|
||||
name: vibe-resume
|
||||
description: 从中断处恢复开发
|
||||
description: 从断点恢复
|
||||
---
|
||||
## 执行步骤
|
||||
1. 读 .ai_state/session.md → 恢复上下文
|
||||
2. 检测断点阶段 (context-loader.cjs 已处理)
|
||||
3. 告知用户当前状态和下一步
|
||||
4. 继续执行
|
||||
# /vibe-resume
|
||||
|
||||
等效于: 读取 SessionStart hook 输出 + 提示恢复
|
||||
1. 读 .ai_state/session.md 确定断点
|
||||
2. 读 .ai_state/doing.md 确定当前步骤
|
||||
3. 从断点继续 RIPER-7 流程
|
||||
4. 如果是 E 阶段 → 从未完成的 Task 继续 Sisyphus
|
||||
|
||||
@@ -1,9 +1,11 @@
|
||||
---
|
||||
name: vibe-status
|
||||
description: 查看当前开发进度
|
||||
description: 显示当前会话状态
|
||||
---
|
||||
## 执行步骤
|
||||
1. 读 .ai_state/session.md → 当前阶段
|
||||
2. 读 .ai_state/doing.md → 进行中任务
|
||||
3. 读 .ai_state/plan.md → 完成/未完成计数
|
||||
4. 输出看板格式: TODO / DOING / DONE
|
||||
# /vibe-status
|
||||
|
||||
读取并展示:
|
||||
1. .ai_state/session.md → 当前任务 + 路径 + 阶段
|
||||
2. .ai_state/doing.md → 当前执行中的步骤
|
||||
3. .ai_state/plan.md → 进度 (已完成/总数)
|
||||
4. Codex 状态: 可用? serve 运行中?
|
||||
|
||||
@@ -1,72 +1,37 @@
|
||||
#!/usr/bin/env node
|
||||
"use strict";
|
||||
// VibeCoding v9.1.0 — SessionStart Hook (Context Loader)
|
||||
// 恢复断点 + 按需加载上下文
|
||||
var fs = require("fs");
|
||||
var path = require("path");
|
||||
// VibeCoding v9.2.0 — SessionStart: 检测状态 + 恢复 + 提醒
|
||||
'use strict';
|
||||
const fs = require('fs');
|
||||
const path = require('path');
|
||||
const STATE_DIR = path.join(process.cwd(), '.ai_state');
|
||||
|
||||
process.on("uncaughtException", function() { process.exit(0); });
|
||||
if (process.env.VIBECODING_HOOKS_DISABLED === "1") process.exit(0);
|
||||
|
||||
function exists(f) { try { return fs.existsSync(f); } catch { return false; } }
|
||||
function readHead(f, n) {
|
||||
try {
|
||||
var lines = fs.readFileSync(f, "utf8").split("\n");
|
||||
return lines.slice(0, n).join("\n");
|
||||
} catch { return ""; }
|
||||
}
|
||||
|
||||
var ctx = [];
|
||||
|
||||
// 1. conventions (始终加载)
|
||||
if (exists(".ai_state/conventions.md")) {
|
||||
ctx.push("📋 conventions:\n" + readHead(".ai_state/conventions.md", 30));
|
||||
}
|
||||
|
||||
// 2. knowledge (跨会话经验, 配合 /memory auto-memory)
|
||||
if (exists(".ai_state/knowledge.md")) {
|
||||
var kn = readHead(".ai_state/knowledge.md", 20);
|
||||
if (kn.trim()) ctx.push("📚 knowledge:\n" + kn);
|
||||
}
|
||||
|
||||
// 3. lessons (错误教训)
|
||||
if (exists(".ai_state/lessons.md")) {
|
||||
var ls = readHead(".ai_state/lessons.md", 15);
|
||||
if (ls.trim()) ctx.push("⚠️ lessons:\n" + ls);
|
||||
}
|
||||
|
||||
// 4. 断点恢复: 检测中断阶段
|
||||
if (exists(".ai_state/session.md")) {
|
||||
var session = fs.readFileSync(".ai_state/session.md", "utf8");
|
||||
ctx.push("🔄 session:\n" + session);
|
||||
|
||||
// 推断当前阶段
|
||||
if (exists(".ai_state/review.md")) {
|
||||
ctx.push("⚠️ 断点: V(验收)阶段, 上次在最终审查中中断");
|
||||
} else if (exists(".ai_state/verified.md")) {
|
||||
ctx.push("⚠️ 断点: T(测试)阶段, 验证已开始");
|
||||
} else if (exists(".ai_state/doing.md")) {
|
||||
ctx.push("📝 doing:\n" + readHead(".ai_state/doing.md", 20));
|
||||
ctx.push("⚠️ 断点: E(执行)阶段, 开发进行中");
|
||||
} else if (exists(".ai_state/plan.md")) {
|
||||
ctx.push("📐 plan:\n" + readHead(".ai_state/plan.md", 25));
|
||||
ctx.push("⚠️ 断点: P(计划)阶段已完成, 继续执行");
|
||||
} else if (exists(".ai_state/design.md")) {
|
||||
ctx.push("🎨 design:\n" + readHead(".ai_state/design.md", 15));
|
||||
ctx.push("⚠️ 断点: D(设计)阶段已完成");
|
||||
}
|
||||
} else {
|
||||
// 无 session = 新会话, 检查是否有 .ai_state 目录
|
||||
if (!exists(".ai_state")) {
|
||||
ctx.push("💡 新项目: 使用 /vibe-init 初始化, 或 /vibe-dev {需求} 直接开始");
|
||||
try {
|
||||
if (fs.existsSync(STATE_DIR)) {
|
||||
// 恢复: 读取关键状态文件
|
||||
const files = ['session.md', 'doing.md', 'plan.md', 'design.md'];
|
||||
const found = files.filter(f => fs.existsSync(path.join(STATE_DIR, f)));
|
||||
if (found.length > 0) {
|
||||
console.log(`[VibeCoding] 恢复会话: ${found.join(', ')} 已加载`);
|
||||
// 检查未完成任务
|
||||
const planFile = path.join(STATE_DIR, 'plan.md');
|
||||
if (fs.existsSync(planFile)) {
|
||||
const plan = fs.readFileSync(planFile, 'utf8');
|
||||
const unchecked = (plan.match(/^- \[ \]/gm) || []).length;
|
||||
if (unchecked > 0) console.log(`[VibeCoding] ⚠ plan.md 有 ${unchecked} 个未完成任务`);
|
||||
}
|
||||
}
|
||||
// Agent 易犯错误提醒
|
||||
const convFile = path.join(STATE_DIR, 'conventions.md');
|
||||
if (fs.existsSync(convFile)) {
|
||||
const conv = fs.readFileSync(convFile, 'utf8');
|
||||
const errSection = conv.match(/## Agent 易犯错误\n([\s\S]*?)(?=\n##|$)/);
|
||||
if (errSection && errSection[1].trim()) {
|
||||
console.log('[VibeCoding] 🔔 Agent 易犯错误提醒:');
|
||||
console.log(errSection[1].trim().split('\n').slice(0, 5).join('\n'));
|
||||
}
|
||||
}
|
||||
} else {
|
||||
console.log('[VibeCoding] 新会话: .ai_state/ 不存在, 首次任务时自动初始化');
|
||||
}
|
||||
}
|
||||
|
||||
// 5. design + plan (如果存在且未在断点中加载)
|
||||
if (exists(".ai_state/plan.md") && !exists(".ai_state/doing.md")) {
|
||||
// plan 存在但 doing 不存在 → 可能刚完成规划
|
||||
}
|
||||
|
||||
if (ctx.length > 0) {
|
||||
process.stdout.write(ctx.join("\n---\n"));
|
||||
} catch (e) {
|
||||
console.log('[VibeCoding] context-loader 警告: ' + e.message);
|
||||
}
|
||||
|
||||
@@ -1,83 +1,86 @@
|
||||
#!/usr/bin/env node
|
||||
"use strict";
|
||||
// VibeCoding v9.1.0 — Stop Hook (Delivery Gate)
|
||||
// 阻止未完成任务/未测试代码的交付
|
||||
var fs = require("fs");
|
||||
var child_process = require("child_process");
|
||||
// VibeCoding v9.2.0 — Stop: 4级 Quality Gate
|
||||
'use strict';
|
||||
const fs = require('fs');
|
||||
const path = require('path');
|
||||
const { execSync } = require('child_process');
|
||||
|
||||
process.on("uncaughtException", function() { process.exit(0); });
|
||||
if (process.env.VIBECODING_HOOKS_DISABLED === "1") process.exit(0);
|
||||
|
||||
function exists(f) { try { return fs.existsSync(f); } catch { return false; } }
|
||||
|
||||
function runQuiet(cmd, timeout) {
|
||||
try {
|
||||
child_process.execSync(cmd, { timeout: timeout || 60000, stdio: "pipe" });
|
||||
return true;
|
||||
} catch { return false; }
|
||||
}
|
||||
|
||||
function hasScript(name) {
|
||||
try {
|
||||
var pkg = JSON.parse(fs.readFileSync("package.json", "utf8"));
|
||||
return !!(pkg.scripts && pkg.scripts[name]);
|
||||
} catch { return false; }
|
||||
}
|
||||
|
||||
var d = "";
|
||||
process.stdin.on("data", function(c) { d += c; });
|
||||
process.stdin.on("end", function() {
|
||||
try {
|
||||
var input = JSON.parse(d);
|
||||
|
||||
// 检查 last_assistant_message (v2.1.47+ 新增)
|
||||
var lastMsg = input.last_assistant_message || "";
|
||||
|
||||
// 1. 检查 plan.md 未完成任务
|
||||
if (exists(".ai_state/plan.md")) {
|
||||
var plan = fs.readFileSync(".ai_state/plan.md", "utf8");
|
||||
var unchecked = (plan.match(/^- \[ \]/gm) || []).length;
|
||||
if (unchecked > 0) {
|
||||
process.stderr.write("[DeliveryGate] BLOCKED: " + unchecked + " unchecked tasks in plan.md\n");
|
||||
process.exit(2);
|
||||
}
|
||||
}
|
||||
|
||||
// 2. Path B+: 运行测试 (仅当有测试脚本时)
|
||||
var isStrictPath = exists(".ai_state/design.md") || exists(".ai_state/plan.md");
|
||||
if (isStrictPath) {
|
||||
// 多语言测试检测
|
||||
var testCmd = null;
|
||||
if (hasScript("test")) testCmd = "npm test";
|
||||
else if (exists("pytest.ini") || exists("pyproject.toml")) testCmd = "pytest --tb=short -q";
|
||||
else if (exists("Cargo.toml")) testCmd = "cargo test";
|
||||
else if (exists("go.mod")) testCmd = "go test ./...";
|
||||
|
||||
if (testCmd) {
|
||||
var passed = runQuiet(testCmd, 120000);
|
||||
if (!passed) {
|
||||
process.stderr.write("[DeliveryGate] BLOCKED: tests failed (" + testCmd + ")\n");
|
||||
process.exit(2);
|
||||
}
|
||||
}
|
||||
|
||||
// ESLint (仅当有配置时)
|
||||
var hasEslint = exists(".eslintrc.js") || exists(".eslintrc.json") || exists(".eslintrc.yml") || exists("eslint.config.js") || exists("eslint.config.mjs");
|
||||
if (hasEslint) {
|
||||
runQuiet("npx eslint . --max-warnings=0 2>/dev/null", 30000);
|
||||
// ESLint 失败不阻塞, 只警告
|
||||
}
|
||||
}
|
||||
|
||||
// 3. 检查 doing.md 是否有未完成项
|
||||
if (exists(".ai_state/doing.md")) {
|
||||
var doing = fs.readFileSync(".ai_state/doing.md", "utf8");
|
||||
var inProgress = (doing.match(/🔄|IN_PROGRESS|进行中/g) || []).length;
|
||||
if (inProgress > 0) {
|
||||
process.stderr.write("[DeliveryGate] WARNING: " + inProgress + " tasks still in progress\n");
|
||||
}
|
||||
}
|
||||
|
||||
} catch(e) {}
|
||||
console.log(d);
|
||||
process.on('uncaughtException', function(e) {
|
||||
process.stderr.write('[delivery-gate] ERROR: ' + e.message + '\n');
|
||||
process.exit(0); // 脚本错误不阻断
|
||||
});
|
||||
|
||||
if (process.env.VIBECODING_HOOKS_DISABLED === '1') { process.exit(0); }
|
||||
|
||||
const STATE_DIR = path.join(process.cwd(), '.ai_state');
|
||||
const severity = { fail: [], rework: [], concerns: [] };
|
||||
|
||||
try {
|
||||
if (!fs.existsSync(STATE_DIR)) { process.exit(0); } // 无状态 = Path A, 放行
|
||||
|
||||
const planFile = path.join(STATE_DIR, 'plan.md');
|
||||
const qualityFile = path.join(STATE_DIR, 'quality.md');
|
||||
|
||||
// ── FAIL 级: 硬约束 ──
|
||||
// 未完成任务
|
||||
if (fs.existsSync(planFile)) {
|
||||
const plan = fs.readFileSync(planFile, 'utf8');
|
||||
const unchecked = (plan.match(/^- \[ \]/gm) || []).length;
|
||||
if (unchecked > 0) severity.fail.push(`plan.md 有 ${unchecked} 个未完成任务`);
|
||||
}
|
||||
// 缺 quality.md (有 plan 但没 quality = T 阶段未执行)
|
||||
if (fs.existsSync(planFile) && !fs.existsSync(qualityFile)) {
|
||||
severity.fail.push('缺少 quality.md — T 阶段验证未执行');
|
||||
}
|
||||
// 硬编码密钥
|
||||
try {
|
||||
const secrets = execSync(
|
||||
"git diff --cached -U0 2>/dev/null | grep -iE '(password|secret|api_key|token)\\s*[:=]\\s*.' || true",
|
||||
{ encoding: 'utf8' }
|
||||
);
|
||||
if (secrets.trim()) severity.fail.push('疑似硬编码密钥');
|
||||
} catch {}
|
||||
|
||||
// ── REWORK 级: 源码无测试 ──
|
||||
try {
|
||||
const diff = execSync('git diff --cached --name-only 2>/dev/null || git diff --name-only 2>/dev/null', { encoding: 'utf8' });
|
||||
const codeExts = /\.(ts|tsx|js|jsx|py|go|rs|java|rb)$/;
|
||||
const testPattern = /\.test\.|\.spec\.|__test__|__spec__|_test\.|tests\//;
|
||||
const configPattern = /config|\.env|\.json$|\.yaml$|\.yml$|\.toml$|\.md$|\.txt$/i;
|
||||
const srcFiles = diff.split('\n').filter(f =>
|
||||
f.match(codeExts) && !f.match(testPattern) && !f.match(configPattern)
|
||||
);
|
||||
const testFiles = diff.split('\n').filter(f => f.match(testPattern));
|
||||
if (srcFiles.length > 0 && testFiles.length === 0) {
|
||||
if (srcFiles.length > 2) {
|
||||
severity.rework.push(`${srcFiles.length} 个源码文件修改但无对应测试`);
|
||||
} else {
|
||||
severity.concerns.push(`${srcFiles.length} 个源码文件修改但无测试 (数量少, 标注)`);
|
||||
}
|
||||
}
|
||||
} catch {}
|
||||
|
||||
} catch (e) {
|
||||
process.exit(0);
|
||||
}
|
||||
|
||||
// ── 输出结果 ──
|
||||
// Stop hook 语义: exit 0 = 放行停止, exit 2 = 阻断停止(强制继续)
|
||||
// stdout 输出会作为 context 注入 Claude
|
||||
const allIssues = [...severity.fail, ...severity.rework, ...severity.concerns];
|
||||
if (severity.fail.length > 0) {
|
||||
process.stderr.write(`[delivery-gate] ❌ FAIL — 严重问题, 必须修复:\n${severity.fail.map(i => ` ✗ ${i}`).join('\n')}\n`);
|
||||
if (severity.rework.length) process.stderr.write(` + REWORK: ${severity.rework.join(', ')}\n`);
|
||||
if (severity.concerns.length) process.stderr.write(` + CONCERNS: ${severity.concerns.join(', ')}\n`);
|
||||
process.exit(2); // 阻断: 不让停
|
||||
}
|
||||
if (severity.rework.length > 0) {
|
||||
process.stderr.write(`[delivery-gate] 🔧 REWORK — 需要修复:\n${severity.rework.map(i => ` ✗ ${i}`).join('\n')}\n`);
|
||||
if (severity.concerns.length) process.stderr.write(` + CONCERNS: ${severity.concerns.join(', ')}\n`);
|
||||
process.exit(2); // 阻断: 不让停
|
||||
}
|
||||
if (severity.concerns.length > 0) {
|
||||
// CONCERNS: 放行但输出警告作为 context
|
||||
process.stdout.write(`[delivery-gate] ⚠ CONCERNS (已放行, 建议修复):\n${severity.concerns.map(i => ` △ ${i}`).join('\n')}\n`);
|
||||
process.exit(0); // 放行: 但警告已注入
|
||||
}
|
||||
process.exit(0); // PASS
|
||||
|
||||
+17
-25
@@ -1,27 +1,19 @@
|
||||
#!/usr/bin/env node
|
||||
"use strict";
|
||||
// VibeCoding v9.1.0 — PostToolUse Hook (Post-Edit)
|
||||
// 非阻塞: 格式化提醒 (Block-at-Commit 策略)
|
||||
var d = "";
|
||||
process.on("uncaughtException", function() { process.exit(0); });
|
||||
process.stdin.on("data", function(c) { d += c; });
|
||||
process.stdin.on("end", function() {
|
||||
try {
|
||||
var input = JSON.parse(d);
|
||||
var p = input.tool_input && input.tool_input.file_path || "";
|
||||
// VibeCoding v9.2.0 — PostToolUse(Write|Edit): 格式化
|
||||
'use strict';
|
||||
const { execSync } = require('child_process');
|
||||
const fs = require('fs');
|
||||
const input = JSON.parse(fs.readFileSync('/dev/stdin', 'utf8'));
|
||||
const file = input?.tool_input?.file_path || input?.tool_input?.path || '';
|
||||
|
||||
// 阻止在系统目录外创建不必要的 .md 文件
|
||||
if (/\.(md|txt)$/.test(p)
|
||||
&& !/(README|CLAUDE|AGENTS|CONTRIBUTING|CHANGELOG|LICENSE|API|ARCHITECTURE|SECURITY|MIGRATION)\.md$/.test(p)
|
||||
&& !/\.claude\//.test(p)
|
||||
&& !/\.ai_state\//.test(p)
|
||||
&& !/docs?\//.test(p)
|
||||
&& !/src\//.test(p)
|
||||
&& !/plans?\//.test(p)) {
|
||||
console.error("[Hook] BLOCKED: 不必要的文档文件: " + p);
|
||||
console.error("[Hook] 使用 README.md, docs/, 或 .ai_state/");
|
||||
process.exit(2);
|
||||
try {
|
||||
if (file.match(/\.(ts|tsx|js|jsx)$/)) {
|
||||
// 先检查 prettier 存在
|
||||
if (fs.existsSync('node_modules/.bin/prettier')) {
|
||||
execSync(`npx prettier --write "${file}" 2>/dev/null`, { timeout: 5000 });
|
||||
}
|
||||
} catch {}
|
||||
console.log(d);
|
||||
});
|
||||
} else if (file.match(/\.py$/)) {
|
||||
try { execSync('which black', { stdio: 'ignore', timeout: 2000 }); } catch { process.exit(0); }
|
||||
execSync(`python3 -m black "${file}" --quiet 2>/dev/null`, { timeout: 5000 });
|
||||
}
|
||||
} catch {}
|
||||
process.exit(0);
|
||||
|
||||
+24
-43
@@ -1,45 +1,26 @@
|
||||
#!/usr/bin/env node
|
||||
"use strict";
|
||||
// VibeCoding v9.1.0 — PreToolUse Hook (Bash Safety Guard)
|
||||
// 拦截危险命令, 使用 hookSpecificOutput.permissionDecision
|
||||
var d = "";
|
||||
process.on("uncaughtException", function() { process.exit(0); });
|
||||
process.stdin.on("data", function(c) { d += c; });
|
||||
process.stdin.on("end", function() {
|
||||
try {
|
||||
var input = JSON.parse(d);
|
||||
var cmd = (input.tool_input && input.tool_input.command) || "";
|
||||
// VibeCoding v9.2.0 — PreToolUse(Bash): 安全守卫 (JSON decision output)
|
||||
'use strict';
|
||||
const input = JSON.parse(require('fs').readFileSync('/dev/stdin', 'utf8'));
|
||||
const cmd = input?.tool_input?.command || '';
|
||||
|
||||
// DENY: rm -rf / 或 根目录危险操作
|
||||
if (/\brm\s+(-[a-zA-Z]*r[a-zA-Z]*f|--recursive)/.test(cmd) && /\s\/(\s|$)/.test(cmd)) {
|
||||
process.stderr.write("[SECURITY] Blocked: rm -rf /\n");
|
||||
process.exit(2);
|
||||
}
|
||||
const BLOCKED = [
|
||||
/rm\s+-rf\s+[\/~]/, /chmod\s+777/, /curl\s+.*\|\s*(?:bash|sh)/,
|
||||
/wget\s+.*\|\s*(?:bash|sh)/, />\s*\/etc\//, /mkfs\./, /dd\s+if=/,
|
||||
/:(){ :\|:& };:/, /fork\s*bomb/i
|
||||
];
|
||||
|
||||
// DENY: sudo
|
||||
if (/\bsudo\b/.test(cmd)) {
|
||||
process.stderr.write("[SECURITY] Blocked: sudo\n");
|
||||
process.exit(2);
|
||||
}
|
||||
|
||||
// DENY: eval (精确匹配, 排除 node eval.js 类误报)
|
||||
if (/(^|[;&|])\s*eval\b/.test(cmd)) {
|
||||
process.stderr.write("[SECURITY] Blocked: eval\n");
|
||||
process.exit(2);
|
||||
}
|
||||
|
||||
// DENY: curl pipe bash
|
||||
if (/\bcurl\b.*\|\s*(ba)?sh/.test(cmd) || /\bwget\b.*\|\s*(ba)?sh/.test(cmd)) {
|
||||
process.stderr.write("[SECURITY] Blocked: curl|bash\n");
|
||||
process.exit(2);
|
||||
}
|
||||
|
||||
// WARN: 敏感文件访问 (不阻塞)
|
||||
if (/\.(env|pem|key|cert|p12|pfx|jks)\b/.test(cmd)
|
||||
&& !/\.gitignore/.test(cmd) && !/grep/.test(cmd)) {
|
||||
process.stderr.write("[SECURITY] WARNING: sensitive file access — " + cmd.slice(0, 80) + "\n");
|
||||
}
|
||||
|
||||
} catch {}
|
||||
console.log(d);
|
||||
});
|
||||
for (const pattern of BLOCKED) {
|
||||
if (pattern.test(cmd)) {
|
||||
// 使用 JSON decision output (官方推荐方式)
|
||||
const output = JSON.stringify({
|
||||
hookSpecificOutput: {
|
||||
hookEventName: "PreToolUse",
|
||||
permissionDecision: "deny",
|
||||
permissionDecisionReason: `[pre-bash] 危险命令被阻断: ${cmd.slice(0, 80)}`
|
||||
}
|
||||
});
|
||||
process.stdout.write(output);
|
||||
process.exit(0);
|
||||
}
|
||||
}
|
||||
process.exit(0);
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
// VibeCoding v9.2.0 — StopFailure: API错误时保存状态
|
||||
'use strict';
|
||||
const fs = require('fs');
|
||||
const path = require('path');
|
||||
const STATE_DIR = path.join(process.cwd(), '.ai_state');
|
||||
|
||||
try {
|
||||
if (fs.existsSync(STATE_DIR)) {
|
||||
const sessionFile = path.join(STATE_DIR, 'session.md');
|
||||
if (fs.existsSync(sessionFile)) {
|
||||
let content = fs.readFileSync(sessionFile, 'utf8');
|
||||
const ts = new Date().toISOString();
|
||||
content += `\n\n## 异常中断\n${ts} — API错误导致会话中断。下次 SessionStart 自动恢复。\n`;
|
||||
fs.writeFileSync(sessionFile, content);
|
||||
}
|
||||
console.log('[VibeCoding] API错误，状态已保存。下次启动自动恢复。');
|
||||
}
|
||||
} catch {}
|
||||
@@ -0,0 +1,21 @@
|
||||
// VibeCoding v9.2.0 — Stop: TDD 检查 (git diff 对比)
|
||||
'use strict';
|
||||
const { execSync } = require('child_process');
|
||||
|
||||
try {
|
||||
const diff = execSync('git diff --name-only 2>/dev/null', { encoding: 'utf8' });
|
||||
const codeExts = /\.(ts|tsx|js|jsx|py|go|rs)$/;
|
||||
const testPattern = /\.test\.|\.spec\.|__test__|_test\./;
|
||||
const configPattern = /config|\.json$|\.yaml$|\.yml$|\.md$|\.lock$/i;
|
||||
|
||||
const srcFiles = diff.split('\n').filter(f =>
|
||||
f.match(codeExts) && !f.match(testPattern) && !f.match(configPattern)
|
||||
);
|
||||
const testFiles = diff.split('\n').filter(f => f.match(testPattern));
|
||||
|
||||
if (srcFiles.length > 0 && testFiles.length === 0) {
|
||||
process.stderr.write(`[tdd-check] ⚠ ${srcFiles.length} 个源码修改但无测试。TDD: 先写测试!\n`);
|
||||
// 不阻断, 只提醒 (阻断在 delivery-gate)
|
||||
}
|
||||
} catch {}
|
||||
process.exit(0);
|
||||
@@ -1,26 +0,0 @@
|
||||
# 编码规范 (rules.md)
|
||||
|
||||
## 通用
|
||||
|
||||
- 函数: 单一职责, <50 行, 清晰命名
|
||||
- 错误处理: 不吞异常, 有意义的错误消息
|
||||
- 注释: 解释 WHY 不解释 WHAT
|
||||
- 不使用 any/as any (TS), 不使用 # type: ignore (Python)
|
||||
|
||||
## Git
|
||||
|
||||
- 分支: feature/{描述}, fix/{描述}, refactor/{描述}
|
||||
- Commit: conventional commits (feat/fix/refactor/docs/test/chore)
|
||||
- 每个逻辑变更独立 commit, 不混杂
|
||||
|
||||
## 测试
|
||||
|
||||
- 新功能必须有测试
|
||||
- 修 bug 先写回归测试
|
||||
- 覆盖率: 关键路径 100%, 整体 >80%
|
||||
|
||||
## 安全
|
||||
|
||||
- 不硬编码密钥/凭据
|
||||
- 使用环境变量或 secret manager
|
||||
- 所有用户输入必须验证/转义
|
||||
+66
-93
@@ -1,48 +1,46 @@
|
||||
{
|
||||
"environmentVariables": {
|
||||
"VIBECODING_VERSION": "9.2.0",
|
||||
"LANGUAGE": "zh-Hans",
|
||||
"LC_ALL": "zh-Hans",
|
||||
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
|
||||
"API_TIMEOUT_MS": "3000000",
|
||||
"CLAUDE_CODE_SUBAGENT_MODEL": "claude-sonnet-4-6"
|
||||
},
|
||||
"permissions": {
|
||||
"allow": [
|
||||
"Read",
|
||||
"Write",
|
||||
"Edit",
|
||||
"MultiEdit",
|
||||
"Task",
|
||||
"WebSearch",
|
||||
"WebFetch",
|
||||
"Bash(node *)",
|
||||
"Bash(npm test)",
|
||||
"Bash(npm run *)",
|
||||
"Bash(npm install *)",
|
||||
"Bash(npx tsc *)",
|
||||
"Bash(npx eslint *)",
|
||||
"Bash(npx prettier *)",
|
||||
"Bash(npx playwright *)",
|
||||
"Bash(npx vitest *)",
|
||||
"Bash(npx jest *)",
|
||||
"Bash(git add *)",
|
||||
"Bash(git commit *)",
|
||||
"Bash(git status)",
|
||||
"Bash(git diff *)",
|
||||
"Bash(git log *)",
|
||||
"Bash(git branch *)",
|
||||
"Bash(grep *)",
|
||||
"Bash(find *)",
|
||||
"Bash(npx *)",
|
||||
"Bash(node *)",
|
||||
"Bash(git *)",
|
||||
"Bash(cat *)",
|
||||
"Bash(ls *)",
|
||||
"Bash(find *)",
|
||||
"Bash(grep *)",
|
||||
"Bash(head *)",
|
||||
"Bash(tail *)",
|
||||
"Bash(wc *)",
|
||||
"Bash(mkdir *)",
|
||||
"Bash(cp *)",
|
||||
"Bash(mv *)",
|
||||
"Bash(python *)",
|
||||
"Bash(pip install *)",
|
||||
"Bash(cargo *)",
|
||||
"Bash(go *)",
|
||||
"Bash(make *)"
|
||||
"Bash(touch *)",
|
||||
"Bash(codex *)",
|
||||
"Bash(ast-grep *)",
|
||||
"Read(*)",
|
||||
"Write(*)",
|
||||
"Edit(*)",
|
||||
"MultiEdit(*)",
|
||||
"Glob(*)",
|
||||
"Grep(*)"
|
||||
],
|
||||
"deny": [
|
||||
"Bash(rm -rf /)",
|
||||
"Bash(sudo *)",
|
||||
"Read(./.env)",
|
||||
"Read(./.env.*)",
|
||||
"Read(./secrets/**)"
|
||||
"Bash(rm -rf /*)",
|
||||
"Bash(rm -rf ~)",
|
||||
"Bash(chmod 777 *)",
|
||||
"Bash(curl * | bash)",
|
||||
"Read(./secrets/**)",
|
||||
"Read(./.env.production)"
|
||||
]
|
||||
},
|
||||
"hooks": {
|
||||
@@ -51,50 +49,7 @@
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "node .claude/hooks/context-loader.cjs",
|
||||
"timeout": 15
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"Stop": [
|
||||
{
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "node .claude/hooks/delivery-gate.cjs",
|
||||
"timeout": 60
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"hooks": [
|
||||
{
|
||||
"type": "prompt",
|
||||
"prompt": "你是交付质量审查员。检查 assistant 的最终回复:\n1. 所有 plan.md 任务已完成? (无未勾选 checkbox)\n2. 代码变更有对应测试? (新功能/修复必须有测试)\n3. 无 TODO/FIXME/HACK 残留?\n4. commit message 符合 conventional commits?\n5. 无硬编码密钥/凭据?\n全部通过→回复 {\"ok\": true}\n任一不通过→回复 {\"ok\": false, \"reason\": \"具体问题\"}",
|
||||
"timeout": 30
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"PostToolUse": [
|
||||
{
|
||||
"matcher": "Write|Edit|MultiEdit",
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "node .claude/hooks/post-edit.cjs",
|
||||
"timeout": 5
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"matcher": "Write|Edit|MultiEdit",
|
||||
"hooks": [
|
||||
{
|
||||
"type": "prompt",
|
||||
"prompt": "TDD 检查: 刚写入/修改的文件是源代码(非测试)吗?\n如果是源代码且当前 RIPER 阶段是 E(执行):\n- 检查是否有对应的测试文件已存在或刚创建\n- 如果写了功能代码但没有先写测试 → 提醒 RED-GREEN-REFACTOR\n回复 {\"ok\": true} 或 {\"ok\": false, \"reason\": \"先写测试再写实现\"}",
|
||||
"timeout": 10
|
||||
"command": "node .claude/hooks/context-loader.cjs"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -105,31 +60,49 @@
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "node .claude/hooks/pre-bash.cjs",
|
||||
"timeout": 5
|
||||
"command": "node .claude/hooks/pre-bash.cjs"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"SubagentStop": [
|
||||
"PostToolUse": [
|
||||
{
|
||||
"matcher": "Write|Edit|MultiEdit",
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "node .claude/hooks/post-edit.cjs"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"Stop": [
|
||||
{
|
||||
"hooks": [
|
||||
{
|
||||
"type": "prompt",
|
||||
"prompt": "子代理完成。检查 last_assistant_message:\n1) 所有子任务完成? 2) 无未解决错误? 3) 符合 conventions.md?\n通过→accept, 有问题→continue。\n回复 JSON {\"ok\": true} 或 {\"ok\": false, \"reason\": \"...\"}",
|
||||
"timeout": 30
|
||||
"type": "command",
|
||||
"command": "node .claude/hooks/delivery-gate.cjs"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "node .claude/hooks/tdd-check.cjs"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"StopFailure": [
|
||||
{
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "node .claude/hooks/stop-failure.cjs"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"env": {
|
||||
"VIBECODING_VERSION": "9.1.0",
|
||||
"LANGUAGE": "zh-Hans",
|
||||
"LC_ALL": "zh-Hans",
|
||||
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
|
||||
"API_TIMEOUT_MS": "3000000",
|
||||
"CLAUDE_CODE_SUBAGENT_MODEL": "claude-sonnet-4-6",
|
||||
"VIBECODING_HOOKS_DISABLED": "0"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
name: agent-teams
|
||||
description: 多代理并行协作 — Path C/D 的 E 阶段
|
||||
context: main
|
||||
---
|
||||
## 触发: Path C/D 的 E(执行) 阶段
|
||||
|
||||
## 前提
|
||||
- .claude/agents/ 目录下定义了 builder/validator/explorer 等子代理
|
||||
- plan.md 中任务已标注可并行/有依赖
|
||||
|
||||
## 编排策略
|
||||
1. 读 plan.md → 识别无依赖的任务组
|
||||
2. 为每组分配 builder 子代理 (background: true)
|
||||
3. 每个 builder 使用 isolation: worktree 隔离
|
||||
4. validator 定期检查各 builder 产出
|
||||
5. explorer 负责跨模块调研
|
||||
|
||||
## 并行规则
|
||||
- 无依赖任务: 并行执行
|
||||
- 有依赖任务: 串行, 前置完成后触发
|
||||
- 冲突检测: 同文件不并行修改
|
||||
|
||||
## 子代理调用
|
||||
- Task(builder): 开发任务
|
||||
- Task(validator): 验证任务
|
||||
- Task(explorer): 调研任务
|
||||
- `claude agents` 查看运行状态
|
||||
@@ -1,36 +1,38 @@
|
||||
---
|
||||
name: brainstorm
|
||||
description: 需求头脑风暴 — R₀b 阶段, 探索方案空间
|
||||
context: main
|
||||
description: R₀ 苏格拉底式需求精炼 — 写代码前激活
|
||||
---
|
||||
## 触发: Path B+ 任务开始时 (自动加载)
|
||||
# Brainstorm (R₀ 需求精炼)
|
||||
|
||||
## 步骤
|
||||
1. augment-context-engine 搜索相关代码和依赖
|
||||
2. 读 .ai_state/knowledge.md 了解历史经验和项目规范
|
||||
3. 生成 Spec 需求模板 (写入 design.md 顶部):
|
||||
- 功能需求 (MUST/SHOULD/COULD)
|
||||
- 非功能需求 (性能/安全/兼容性)
|
||||
- 约束条件 (技术栈/时间/依赖)
|
||||
- 验收标准 (可测试的完成条件)
|
||||
4. 生成 2-3 个候选方案, 每个包含:
|
||||
方案描述 / 优劣势 / 预估工作量 / 技术风险
|
||||
5. 输出到 .ai_state/design.md
|
||||
6. cunzhi [DESIGN_DIRECTION] 让用户选择方向
|
||||
Path B+ 任务在写代码前**必须**激活本 skill。
|
||||
|
||||
## Spec 模板格式
|
||||
```markdown
|
||||
## Spec: {需求标题}
|
||||
### 功能需求
|
||||
- [MUST] ...
|
||||
- [SHOULD] ...
|
||||
### 非功能需求
|
||||
- 性能: ...
|
||||
- 安全: ...
|
||||
### 约束
|
||||
- ...
|
||||
### 验收标准
|
||||
- [ ] ...
|
||||
```
|
||||
## 流程
|
||||
|
||||
不可用时: 直接基于需求分析, 跳过代码搜索
|
||||
### 0. 自主调研 (提问前)
|
||||
- 搜索 (Grep/Glob, 或 augment-context-engine 如已安装)项目中与需求相关的现有代码
|
||||
- 读 .ai_state/knowledge.md + lessons.md 查相关经验
|
||||
- 读 .ai_state/conventions.md 查编码规范
|
||||
- 如果 Codex 可用: 用 codex-comm skill 问 Codex "这类需求常见陷阱?"
|
||||
→ 基于调研结果准备更有深度的问题
|
||||
|
||||
### 1. 访谈 (苏格拉底式, 基于调研的针对性问题)
|
||||
- **一次只问一个问题**, 不堆叠
|
||||
- 优先选择题, 开放题为辅
|
||||
- 覆盖: 用户目标、使用场景、边界、非功能需求
|
||||
- YAGNI 原则: 主动砍不必要的功能
|
||||
|
||||
### 2. 提出 2-3 个方案
|
||||
- 每方案: 架构概述 + 优劣 + 复杂度预估
|
||||
- context7 查依赖库文档验证可行性
|
||||
- 标注推荐方案及理由
|
||||
|
||||
### 3. 分段呈现设计
|
||||
- 每段 ≤ 200 字, 用户确认后再下一段
|
||||
|
||||
### 4. 确认输出
|
||||
- 写入 .ai_state/design.md (用模板格式: MUST/SHOULD/COULD + 验收标准)
|
||||
- cunzhi `DESIGN_READY` 确认
|
||||
- 进入 plan-first skill
|
||||
|
||||
## 铁律
|
||||
- 设计未确认前**不写任何代码**
|
||||
|
||||
@@ -1,18 +1,23 @@
|
||||
---
|
||||
name: code-review
|
||||
description: 代码审查 — T 阶段辅助
|
||||
context: main
|
||||
description: T 阶段代码审查 — 含 LLM-as-Judge 模式
|
||||
---
|
||||
## 触发: T 阶段, verification 之后
|
||||
# Code Review (T 阶段)
|
||||
|
||||
## 审查维度
|
||||
1. 逻辑正确性: 边界条件、错误处理、并发安全
|
||||
2. 可读性: 命名清晰、函数职责单一、注释合理
|
||||
3. 性能: 无 N+1 查询、无不必要的循环
|
||||
4. 安全: 无注入、无硬编码密钥
|
||||
5. 测试: 测试有意义, 不只是刷覆盖率
|
||||
6. 优雅: "如果重新实现, 我会这样写吗?"
|
||||
## 审查清单
|
||||
1. **Spec 合规**: 每个 MUST 需求是否实现? (对照 design.md)
|
||||
2. **TDD**: 每个源码文件有对应测试?
|
||||
3. **边界**: 空输入/超长/并发/错误路径 是否处理?
|
||||
4. **安全**: 无硬编码密钥, 无 SQL 注入, 输入已验证
|
||||
5. **可读**: 函数 < 50 行, 注释说明 WHY 不是 WHAT, 严格类型
|
||||
6. **简洁**: 无过度工程, 无重复代码, 无空 catch
|
||||
|
||||
## 输出格式
|
||||
每个问题: 文件+行号 / MUST-FIX|SHOULD-FIX|NIT / 问题描述 / 修复建议
|
||||
无问题: "APPROVED — no issues found"
|
||||
## LLM-as-Judge 模式 (delivery-gate 触发)
|
||||
输出格式:
|
||||
```json
|
||||
{"level": "PASS|CONCERNS|REWORK|FAIL", "issues": [...], "summary": "..."}
|
||||
```
|
||||
- FAIL: 未完成任务 / 硬编码密钥 / 缺 quality.md
|
||||
- REWORK: 源码无测试 (TDD 违规)
|
||||
- CONCERNS: 非关键文件无测试 (1-2 个警告)
|
||||
- PASS: 全部通过
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
name: codex-comm
|
||||
description: Codex CLI 通信层 — CC↔Codex 基础设施
|
||||
---
|
||||
# Codex Communication (通信层)
|
||||
|
||||
## 核心脚本
|
||||
`.claude/skills/codex-comm/scripts/codex-bridge.cjs`
|
||||
|
||||
## 功能
|
||||
1. **检测可用性**: `which codex` + health check (2s 超时)
|
||||
2. **双模式**: exec (单轮) / serve (多轮 HTTP API)
|
||||
3. **Session Resume**: `resumeSession(sessionId, prompt)` — 多轮对话保持上下文
|
||||
4. **UUID 生成**: `generateReviewId()` — 并发安全, 防冲突
|
||||
5. **敏感过滤**: .env / 密钥 → [REDACTED]
|
||||
6. **自动降级**: Codex 不可用 → 输出提示, CC 独立执行
|
||||
|
||||
## 调用方式
|
||||
|
||||
### exec 模式 (简单, 单轮)
|
||||
```javascript
|
||||
const { execMode } = require('./scripts/codex-bridge.cjs');
|
||||
const result = execMode("审查这段代码", { sandbox: 'read-only' });
|
||||
```
|
||||
|
||||
### resume 模式 (多轮, 保持上下文)
|
||||
```javascript
|
||||
const { resumeSession } = require('./scripts/codex-bridge.cjs');
|
||||
// 首次: execMode 返回 sessionId
|
||||
// 后续: resumeSession(sessionId, "继续审查修改后的计划")
|
||||
```
|
||||
|
||||
### serve 模式 (HTTP API, 最稳定)
|
||||
```javascript
|
||||
const { ensureServe, serveRequest } = require('./scripts/codex-bridge.cjs');
|
||||
ensureServe(); // 自动启动如未运行
|
||||
```
|
||||
|
||||
## Fallback
|
||||
每个调用 Codex 的点都必须有:
|
||||
```
|
||||
如果 Codex 不可用:
|
||||
输出 "[VibeCoding] Codex 不可用, CC 独立执行"
|
||||
{CC 独立完成的替代逻辑}
|
||||
```
|
||||
@@ -0,0 +1,109 @@
|
||||
// VibeCoding v9.2.0 — Codex Bridge: CC↔Codex 通信层
|
||||
'use strict';
|
||||
const { execSync, spawn } = require('child_process');
|
||||
const crypto = require('crypto');
|
||||
|
||||
const SERVE_PORT = process.env.CODEX_SERVE_PORT || '4096';
|
||||
const SERVE_URL = `http://localhost:${SERVE_PORT}`;
|
||||
const DEFAULT_MODEL = 'gpt-5.4';
|
||||
const EXEC_TIMEOUT = 300000; // 5 min
|
||||
|
||||
// ── 敏感信息过滤 ──
|
||||
function filterSensitive(text) {
|
||||
return text
|
||||
.replace(/(?:password|secret|api[_-]?key|token|credential)\s*[:=]\s*['"][^'"]{4,}['"]/gi, '[REDACTED]')
|
||||
.replace(/(?:-----BEGIN (?:RSA |EC )?PRIVATE KEY-----[\s\S]*?-----END (?:RSA |EC )?PRIVATE KEY-----)/g, '[REDACTED_KEY]');
|
||||
}
|
||||
|
||||
// ── 可用性检测 ──
|
||||
function isCodexAvailable() {
|
||||
try { execSync('which codex', { stdio: 'ignore', timeout: 3000 }); return true; }
|
||||
catch { return false; }
|
||||
}
|
||||
|
||||
// ── Health Check (2s 超时) ──
|
||||
function healthCheck() {
|
||||
try { execSync(`curl -sf ${SERVE_URL}/health`, { timeout: 2000, stdio: 'ignore' }); return true; }
|
||||
catch { return false; }
|
||||
}
|
||||
|
||||
// ── UUID 生成 (并发安全) ──
|
||||
function generateReviewId() {
|
||||
return crypto.randomUUID().slice(0, 8);
|
||||
}
|
||||
|
||||
// ── exec 模式 (单轮) ──
|
||||
function execMode(prompt, opts = {}) {
|
||||
if (!isCodexAvailable()) return { ok: false, error: 'codex_not_available' };
|
||||
const safePrompt = filterSensitive(prompt);
|
||||
const model = opts.model || DEFAULT_MODEL;
|
||||
const sandbox = opts.sandbox || 'read-only';
|
||||
try {
|
||||
// 用 execFileSync 避免 shell 注入 (参数直接传递, 不经过 shell 解析)
|
||||
const result = require('child_process').execFileSync(
|
||||
'codex', ['exec', '--sandbox', sandbox, '-m', model, safePrompt],
|
||||
{ encoding: 'utf8', timeout: opts.timeout || EXEC_TIMEOUT }
|
||||
);
|
||||
const sidMatch = result.match(/session[_\s]*(?:id)?[:\s]*([0-9a-f-]{8,})/i);
|
||||
return { ok: true, output: result, sessionId: sidMatch ? sidMatch[1] : null };
|
||||
} catch (e) {
|
||||
return { ok: false, error: e.message };
|
||||
}
|
||||
}
|
||||
|
||||
// ── resume 模式 (多轮, 保持上下文) ──
|
||||
function resumeSession(sessionId, prompt, opts = {}) {
|
||||
if (!isCodexAvailable()) return { ok: false, error: 'codex_not_available' };
|
||||
const safePrompt = filterSensitive(prompt);
|
||||
const model = opts.model || DEFAULT_MODEL;
|
||||
try {
|
||||
const result = require('child_process').execFileSync(
|
||||
'codex', ['exec', 'resume', sessionId, '--sandbox', 'read-only', '-m', model, safePrompt],
|
||||
{ encoding: 'utf8', timeout: opts.timeout || EXEC_TIMEOUT }
|
||||
);
|
||||
return { ok: true, output: result, sessionId };
|
||||
} catch (e) {
|
||||
console.error(`[codex-bridge] resume failed, falling back to new exec: ${e.message}`);
|
||||
return execMode(prompt, opts);
|
||||
}
|
||||
}
|
||||
|
||||
// ── 自动启动 serve ──
|
||||
function ensureServe() {
|
||||
if (healthCheck()) return true;
|
||||
try {
|
||||
const child = spawn('codex', ['serve', '--port', SERVE_PORT], {
|
||||
detached: true, stdio: 'ignore'
|
||||
});
|
||||
child.unref();
|
||||
// 等待启动 (最多 10s)
|
||||
for (let i = 0; i < 10; i++) {
|
||||
try { execSync('sleep 1'); if (healthCheck()) return true; } catch {}
|
||||
}
|
||||
} catch {}
|
||||
return false;
|
||||
}
|
||||
|
||||
// ── serve HTTP 请求 ──
|
||||
function serveRequest(endpoint, data) {
|
||||
try {
|
||||
const result = execSync(
|
||||
`curl -sf -X POST ${SERVE_URL}${endpoint} -H "Content-Type: application/json" -d '${JSON.stringify(data)}'`,
|
||||
{ encoding: 'utf8', timeout: 30000 }
|
||||
);
|
||||
return { ok: true, data: JSON.parse(result) };
|
||||
} catch (e) {
|
||||
return { ok: false, error: e.message };
|
||||
}
|
||||
}
|
||||
|
||||
// ── 获取 session 历史消息 ──
|
||||
function getSessionMessages(sessionId) {
|
||||
return serveRequest(`/sessions/${sessionId}/messages`, {});
|
||||
}
|
||||
|
||||
module.exports = {
|
||||
isCodexAvailable, healthCheck, generateReviewId,
|
||||
execMode, resumeSession, ensureServe, serveRequest,
|
||||
getSessionMessages, filterSensitive
|
||||
};
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
name: codex-review
|
||||
description: 对抗式计划审查 — P 阶段 CC↔Codex 多轮审查
|
||||
---
|
||||
# Codex Review (对抗式审查)
|
||||
|
||||
## 触发时机
|
||||
P 阶段 plan.md 生成后, 如果 Codex 可用。
|
||||
|
||||
## 初始化
|
||||
```
|
||||
REVIEW_ID = 生成一个 8 位随机 ID (用 Bash: uuidgen | cut -c1-8)
|
||||
```
|
||||
|
||||
## 审查模板选择
|
||||
根据 design.md 关键词自动选择:
|
||||
- 包含 API/endpoint/route → templates/api-review.md
|
||||
- 包含 component/CSS/UI → templates/frontend-review.md
|
||||
- 包含 deploy/docker/k8s/terraform → templates/infra-review.md
|
||||
- 否则 → templates/general-review.md
|
||||
|
||||
## 对抗循环
|
||||
|
||||
### Round 1 (新 exec, 捕获 SESSION_ID):
|
||||
CC → Codex:
|
||||
"审查以下计划. 严格找出漏洞/模糊/不可执行的部分.
|
||||
{plan.md 全文}
|
||||
{选定的 review template}
|
||||
结果以 VERDICT: APPROVED 或 VERDICT: REVISE 结尾."
|
||||
Codex → 质疑列表 + VERDICT
|
||||
如果 APPROVED → 结束, 记录到 reviews/review-{REVIEW_ID}.md
|
||||
CC: 逐条评估 (采纳修改 plan / 驳回并说明理由)
|
||||
|
||||
### Round 2+ (resume SESSION_ID, 保持上下文):
|
||||
CC → Codex (codex exec resume SESSION_ID):
|
||||
"修改后的计划差异: {diff}. 继续审查.
|
||||
VERDICT: APPROVED 或 VERDICT: REVISE."
|
||||
Codex → 继续质疑 + VERDICT
|
||||
...
|
||||
|
||||
## 终止条件 (满足任一)
|
||||
a) Codex 返回 VERDICT: APPROVED
|
||||
b) 连续 2 轮全部驳回 (记录分歧, cunzhi 让用户决策)
|
||||
c) 超过 5 轮 (强制停止, 输出分歧摘要)
|
||||
|
||||
## 审查结果持久化
|
||||
每次审查写入 `reviews/review-{REVIEW_ID}.md`:
|
||||
```markdown
|
||||
# Review {REVIEW_ID}
|
||||
Date: {timestamp}
|
||||
Rounds: {n}
|
||||
Final Verdict: {APPROVED|STALEMATE|TIMEOUT}
|
||||
## 采纳的修改
|
||||
- ...
|
||||
## 驳回的质疑
|
||||
- ...
|
||||
## 遗留分歧
|
||||
- ...
|
||||
```
|
||||
|
||||
## Fallback
|
||||
如果 Codex 不可用:
|
||||
CC 用 validator agent 做 Plan Review:
|
||||
"作为严格审查者, 这个计划有哪些漏洞/模糊/不可执行的部分?"
|
||||
@@ -0,0 +1,11 @@
|
||||
# API Review Template
|
||||
|
||||
审查重点:
|
||||
1. **接口一致性**: RESTful 约定? 命名统一?
|
||||
2. **幂等性**: PUT/DELETE 是否幂等?
|
||||
3. **版本控制**: URL 版本 (/v1/) 或 Header 版本?
|
||||
4. **错误码**: HTTP 状态码 + 业务错误码 是否定义?
|
||||
5. **认证/授权**: 每个端点的权限要求?
|
||||
6. **速率限制**: 是否有限流策略?
|
||||
7. **输入验证**: 请求体 schema 是否严格?
|
||||
8. **响应格式**: 分页/排序/过滤 是否一致?
|
||||
@@ -0,0 +1,10 @@
|
||||
# Frontend Review Template
|
||||
|
||||
审查重点:
|
||||
1. **可访问性**: ARIA 标签? 键盘导航? 色彩对比?
|
||||
2. **响应式**: 移动端/平板/桌面 断点覆盖?
|
||||
3. **XSS 防护**: 用户输入是否转义? dangerouslySetInnerHTML?
|
||||
4. **性能**: 大列表虚拟滚动? 图片懒加载? 包体积?
|
||||
5. **状态管理**: 数据流清晰? 避免 prop drilling?
|
||||
6. **错误边界**: React ErrorBoundary? 加载/空/错误状态?
|
||||
7. **国际化**: 硬编码文案? 日期/数字格式?
|
||||
@@ -0,0 +1,10 @@
|
||||
# General Review Template
|
||||
|
||||
审查重点:
|
||||
1. **需求覆盖**: 每个 MUST 需求是否有对应任务?
|
||||
2. **任务粒度**: 每个任务是否可在 1-2 小时内完成?
|
||||
3. **依赖拓扑**: 任务依赖是否有环? 关键路径是什么?
|
||||
4. **风险识别**: 哪些任务最可能出问题? 有 plan B?
|
||||
5. **测试策略**: 单元/集成/E2E 比例合理?
|
||||
6. **模糊检测**: 有没有"优化""改进"等模糊词?
|
||||
7. **遗漏检测**: 错误处理/日志/监控/文档 是否涵盖?
|
||||
@@ -0,0 +1,10 @@
|
||||
# Infrastructure Review Template
|
||||
|
||||
审查重点:
|
||||
1. **可用性**: 单点故障? 副本数? 健康检查?
|
||||
2. **备份/恢复**: 数据备份策略? RTO/RPO?
|
||||
3. **回滚计划**: 部署失败如何回滚? 数据库迁移可逆?
|
||||
4. **监控/告警**: 关键指标有监控? 告警阈值合理?
|
||||
5. **安全**: 网络隔离? 密钥轮换? 最小权限?
|
||||
6. **成本**: 资源配置合理? 有自动伸缩?
|
||||
7. **IaC**: 基础设施代码化? 可重复部署?
|
||||
@@ -1,19 +1,15 @@
|
||||
---
|
||||
name: context7
|
||||
description: 库文档按需拉取
|
||||
context: main
|
||||
---
|
||||
# Context7 (库文档查询)
|
||||
|
||||
查询依赖库文档时:
|
||||
需要查询依赖库文档时:
|
||||
1. 优先: `npx ctx7 resolve {库名}` CLI 查询
|
||||
2. 备选: web search 查最新 API
|
||||
3. 缓存: 查过的 API 结论写入当前阶段笔记, 避免重复查询
|
||||
|
||||
1. 优先: ctx7 和 mcp-deepwiki 查询
|
||||
2. 降级: WebSearch 搜索官方文档
|
||||
|
||||
## 使用时机
|
||||
|
||||
- R₀b brainstorm: 候选库文档对比
|
||||
- R 研究: 深入调研技术栈
|
||||
- D 设计: 确认 API 接口可行
|
||||
- E 开发: 不确定用法时即时查询
|
||||
|
||||
不预加载, 按需拉取, 仅取所需章节。
|
||||
## 触发时机
|
||||
- R 阶段: 验证技术方案可行性
|
||||
- E 阶段: 实现时遇到不确定的 API
|
||||
- T 阶段: 验证 API 用法正确性
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
name: debugging
|
||||
description: 系统化调试 — 4阶段强制流程
|
||||
---
|
||||
# Systematic Debugging
|
||||
|
||||
遇到 bug 时**必须**按以下 4 阶段执行, 禁止跳步:
|
||||
|
||||
## 1. 复现 (Reproduce)
|
||||
- 写一个**最小**可复现用例
|
||||
- 记录: 输入、期望输出、实际输出
|
||||
- 如果无法复现 → 停, 收集更多信息
|
||||
|
||||
## 2. 定位 (Locate)
|
||||
- 从错误点向上追溯调用链
|
||||
- 用 console.log / debugger / 断点缩小范围
|
||||
- **不要猜**: 用证据定位, 不是直觉
|
||||
|
||||
## 3. 修复 (Fix)
|
||||
- 只改**根因**, 不改症状
|
||||
- 修复必须有对应测试覆盖
|
||||
- 禁止: `as any`, `try {} catch {}` 空吞, `// TODO: fix later`
|
||||
|
||||
## 4. 验证 (Verify)
|
||||
- 运行原始复现用例 → 通过
|
||||
- 运行全量测试 → 无回归
|
||||
- Reflexion: "这个 bug 的模式值得记录到 conventions.md 吗?"
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
name: e2e-testing
|
||||
description: 端到端测试 — Path C/D 的 T 阶段
|
||||
context: main
|
||||
---
|
||||
## 触发: Path C/D 的 T(测试) 阶段
|
||||
|
||||
## 步骤
|
||||
1. 检查 Playwright 配置 (playwright.config.ts)
|
||||
2. 调用 e2e-runner 子代理执行测试
|
||||
3. 收集结果: 通过率 + 失败详情 + 截图
|
||||
4. 失败 → 反馈给 builder 修复 → 重测
|
||||
5. 全部通过 → cunzhi [TESTS_PASSED]
|
||||
|
||||
## 降级
|
||||
Playwright 不可用 → 手动功能验证 + 用户确认
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
name: e2e
|
||||
description: 端到端测试 — Path C+ 或有 E2E 框架时
|
||||
---
|
||||
# E2E Testing
|
||||
|
||||
## 前置条件
|
||||
- 项目有 E2E 框架 (Playwright/Cypress/Selenium)
|
||||
- Path C+ 或用户显式要求
|
||||
|
||||
## 流程
|
||||
1. 基于 design.md 验收标准编写 E2E 用例
|
||||
2. 运行 E2E: `npx playwright test` 或项目配置的命令
|
||||
3. 失败 → 定位是测试问题还是实现问题
|
||||
4. 结果追加到 quality.md
|
||||
|
||||
## 如果没有 E2E 框架
|
||||
- 手动验证清单: 列出关键用户流程 + 验证步骤
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
name: finish-branch
|
||||
description: V 阶段分支收尾 — kaizen 之后, 交付确认之前
|
||||
---
|
||||
# Finish Branch (分支收尾)
|
||||
|
||||
## 触发时机
|
||||
V 阶段 kaizen 完成后, cunzhi `DELIVERY_COMPLETE` 之前。
|
||||
|
||||
## 流程
|
||||
1. 展示选项给用户:
|
||||
a) **merge**: 合并到主分支
|
||||
b) **pr**: 创建 Pull Request
|
||||
c) **keep**: 保留分支不动
|
||||
d) **discard**: 确认后删除分支
|
||||
|
||||
2. 如果选 **pr**:
|
||||
- 自动生成 PR description:
|
||||
```
|
||||
## 标题: {design.md 第一行}
|
||||
## 摘要: {quality.md 总结}
|
||||
## 变更列表:
|
||||
{plan.md 中已完成的 Task 列表}
|
||||
## 测试: {quality.md 验证结果}
|
||||
```
|
||||
- 执行: `gh pr create` 或输出文本供用户复制
|
||||
|
||||
3. 如果选 **merge**:
|
||||
- 检查是否有冲突: `git merge --no-commit --no-ff main`
|
||||
- 无冲突 → merge + 删除分支
|
||||
- 有冲突 → 输出冲突文件, 用户决定
|
||||
|
||||
4. 如果选 **discard**:
|
||||
- cunzhi 确认 "确定丢弃分支 {branch_name}?"
|
||||
- 确认后: `git checkout main && git branch -D {branch_name}`
|
||||
@@ -1,23 +1,23 @@
|
||||
---
|
||||
name: kaizen
|
||||
description: 持续改进 — V 阶段, 交付后自动复盘经验沉淀
|
||||
context: main
|
||||
description: V 阶段持续改进回顾
|
||||
---
|
||||
## 触发: V(验收) 阶段, delivery-gate 通过后 (自动加载)
|
||||
# Kaizen (V 阶段回顾)
|
||||
|
||||
## 步骤
|
||||
1. `git diff --stat HEAD~{n}..HEAD` 分析本次变更范围
|
||||
2. 回顾开发过程中遇到的问题:
|
||||
- 哪些决策是正确的? 为什么?
|
||||
- 哪些地方浪费了时间? 根因是什么?
|
||||
- 有什么模式可以复用?
|
||||
3. 提炼输出:
|
||||
- **knowledge.md**: 可复用的项目模式和决策
|
||||
- **lessons.md**: 错误教训和陷阱 (避免重蹈)
|
||||
- **conventions.md**: 如发现新的编码规范需更新
|
||||
4. 简洁记录, 每条 ≤2 行, 重质不重量
|
||||
## 流程
|
||||
1. 回顾本次开发:
|
||||
- 哪些做得好? (保持)
|
||||
- 哪些做得差? (改进)
|
||||
- 有没有反复出现的模式性错误?
|
||||
|
||||
## 原则
|
||||
- 只记录有价值的、可操作的经验
|
||||
- 不记录通用编程常识 (AI 已知)
|
||||
- 格式: `[日期] 领域: 经验描述`
|
||||
2. 更新 .ai_state/lessons.md:
|
||||
- 新发现的技术陷阱
|
||||
- 有效的解决模式
|
||||
- 项目特有的约定
|
||||
|
||||
3. 更新 .ai_state/conventions.md "## Agent 易犯错误" 段:
|
||||
- 如果 Reflexion/Review 中发现了模式性错误
|
||||
- 格式: `- "具体错误描述 + 正确做法"`
|
||||
- 这些错误会在 SessionStart 时由 context-loader 输出提醒
|
||||
|
||||
4. 产出摘要给用户
|
||||
|
||||
@@ -1,20 +1,26 @@
|
||||
---
|
||||
name: plan-first
|
||||
description: 强制先规划后执行 — 基于 design.md 生成计划
|
||||
context: main
|
||||
description: P 阶段计划生成 — design.md 确认后激活
|
||||
---
|
||||
## 触发: Path B+ 任务, brainstorm 完成后
|
||||
# Plan-First (P 阶段)
|
||||
|
||||
## 步骤
|
||||
1. 读 .ai_state/design.md 作为规划输入
|
||||
2. 进入规划模式 (分析 design.md, 分解为可执行任务)
|
||||
3. context7 查询任务涉及的库文档, 确保技术细节准确
|
||||
4. 输出到 .ai_state/plan.md:
|
||||
- [ ] 任务列表 (checkbox 格式)
|
||||
- 依赖关系
|
||||
- 预估时间
|
||||
- 子代理分配 (Path C+)
|
||||
5. cunzhi [PLAN_CONFIRMED] 确认后才能写代码
|
||||
6. plan.md 未完成任务 → delivery-gate 阻塞
|
||||
## 流程
|
||||
1. 读 .ai_state/design.md 全文
|
||||
2. 分解为可执行任务, 每个任务:
|
||||
```
|
||||
- [ ] T-001: {动作动词} + {目标} + {验收条件}
|
||||
文件: {涉及文件}
|
||||
依赖: {前置任务}
|
||||
```
|
||||
3. 任务排序: 依赖拓扑 → 风险高的先做
|
||||
4. 写入 .ai_state/plan.md
|
||||
|
||||
## 管道: brainstorm → context7 → plan-first → E
|
||||
## 计划质量检查
|
||||
- 每个任务有明确的"完成"定义
|
||||
- 没有模糊词 ("优化", "改进" → 改为具体指标)
|
||||
- 估算总任务数, 超过 15 个考虑拆分 milestone
|
||||
|
||||
## 双 Agent 对抗审查
|
||||
如果 Codex 可用 → 触发 codex-review skill 做对抗式审查
|
||||
如果 Codex 不可用 → CC 用 validator agent 自审:
|
||||
"作为审查者, 这个计划有哪些漏洞/模糊/不可执行的部分?"
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
name: quickstart
|
||||
description: 新手引导 — 首次使用 VibeCoding 的引导流程
|
||||
context: main
|
||||
---
|
||||
## 触发: 无 .ai_state/ 目录时
|
||||
|
||||
## 步骤
|
||||
1. 欢迎: "VibeCoding Kernel v9.1.0 — AI 编程协作框架"
|
||||
2. 检测项目类型 (package.json/Cargo.toml/go.mod/pyproject.toml)
|
||||
3. 引导执行 /vibe-init 初始化
|
||||
4. 简要说明:
|
||||
- /vibe-dev {需求} 开始开发
|
||||
- /vibe-status 查看进度
|
||||
- /vibe-resume 中断恢复
|
||||
5. 提示: 复杂任务会自动路由到合适的工作流
|
||||
|
||||
## 原则: 不要解释内部机制 (RIPER/PACE), 只告诉用户怎么用
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
name: reflexion
|
||||
description: E 阶段自我反思 — 每个 Task Micro-review 之前
|
||||
---
|
||||
# Reflexion (自我反思)
|
||||
|
||||
## 触发时机
|
||||
E 阶段每个 Task 实现完成后, Micro-review 之前。
|
||||
|
||||
## 反思清单
|
||||
逐条自问:
|
||||
1. 我有没有走捷径? (如: 用 `as any` 绕过类型检查, 空 catch 吞错误)
|
||||
2. 我有没有忽略边界条件? (空输入/超长/并发/零值/null)
|
||||
3. 我有没有硬编码本应配置的值? (URL/端口/阈值/路径)
|
||||
4. 我有没有过度工程? (加了需求没要求的功能/抽象层)
|
||||
5. 我有没有偏离 design.md 的方案? (擅自"优化"设计)
|
||||
6. 这段代码 6 个月后我还能理解吗? (命名/结构/注释)
|
||||
|
||||
## 处理
|
||||
- 发现问题 → **立即修复**, 不留 TODO
|
||||
- 值得记录的模式 → 追加到 .ai_state/lessons.md
|
||||
- 模式性错误 → 追加到 conventions.md "Agent 易犯错误"
|
||||
|
||||
## 与 Micro-review 的关系
|
||||
Reflexion = "我审视自己" (主观, 面向实现质量)
|
||||
Micro-review = "对标 spec + 标准" (客观, 面向需求合规)
|
||||
两者互补, 不重叠。先 Reflexion 再 Micro-review。
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
name: security-review
|
||||
description: 安全审查 — Path C+ 或显式触发
|
||||
---
|
||||
# Security Review
|
||||
|
||||
## 检查项
|
||||
1. **认证/授权**: 每个端点是否有权限检查?
|
||||
2. **输入验证**: 所有外部输入是否已验证和消毒?
|
||||
3. **密钥管理**: 无硬编码, 用环境变量或密钥管理服务
|
||||
4. **依赖**: `npm audit` / `pip audit` 无高危漏洞
|
||||
5. **日志**: 不记录敏感信息 (密码/token/PII)
|
||||
6. **CORS/CSP**: 如有 Web 接口, 是否配置正确?
|
||||
|
||||
## 产出
|
||||
- 安全审查结果追加到 quality.md
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
name: tdd
|
||||
description: 测试驱动开发 — E 阶段, 先写测试后实现 (强制执行)
|
||||
context: main
|
||||
---
|
||||
## 触发: E(执行) 阶段 (自动加载)
|
||||
|
||||
## 铁律: RED → GREEN → REFACTOR
|
||||
**写功能代码前必须先有失败的测试。PostToolUse hook 会检查。**
|
||||
|
||||
## 分级策略
|
||||
- **Level 1** (Path A): 功能验证, 关键路径有测试即可
|
||||
- **Level 2** (Path B): 单元+集成, 严格 RED→GREEN→REFACTOR
|
||||
- **Level 3** (Path C+): + E2E, 覆盖率 >80%
|
||||
|
||||
## 强制流程 (Level 2+)
|
||||
1. 读 plan.md 当前任务
|
||||
2. 写失败测试 (RED) — **必须先看到测试失败**
|
||||
3. 写最小实现通过测试 (GREEN) — **只写刚好让测试通过的代码**
|
||||
4. 重构 (REFACTOR) — 改善结构, 测试保持绿色
|
||||
5. 更新 doing.md 看板 (TODO→DOING→DONE)
|
||||
6. git commit
|
||||
|
||||
## 违规处理
|
||||
如果写了源代码但没有对应测试:
|
||||
- PostToolUse prompt hook 会提醒
|
||||
- 必须补写测试后才能继续
|
||||
|
||||
## 测试命令自动检测
|
||||
package.json scripts.test → npm test
|
||||
pytest.ini/pyproject.toml → pytest
|
||||
Cargo.toml → cargo test
|
||||
go.mod → go test ./...
|
||||
@@ -1,20 +1,20 @@
|
||||
---
|
||||
name: verification
|
||||
description: 代码验证 — T 阶段
|
||||
context: main
|
||||
description: T 阶段验证 — 测试 + 覆盖率 + 验收标准
|
||||
---
|
||||
## 触发: T(测试) 阶段
|
||||
# Verification (T 阶段)
|
||||
|
||||
## 检查清单
|
||||
1. 所有测试通过 (自动检测测试命令)
|
||||
2. lint 通过 (eslint/ruff/clippy)
|
||||
3. 类型检查通过 (tsc/mypy/cargo check)
|
||||
4. 无 TODO/FIXME 残留
|
||||
5. .ai_state/conventions.md 规范符合
|
||||
## 流程
|
||||
1. 运行测试: `npm test` 或项目配置的测试命令
|
||||
2. 覆盖率: 如有配置, 检查覆盖率阈值
|
||||
3. TypeScript: `npx tsc --noEmit` (如有 tsconfig.json)
|
||||
4. Lint: `npx eslint . --max-warnings 0` (如有 eslint 配置, Path C+ 强制)
|
||||
|
||||
## Path 差异
|
||||
- Path A: 检查 1 即可
|
||||
- Path B: 检查 1-5 + 输出 verified.md
|
||||
- Path C+: + 调用 validator 子代理
|
||||
## 验收标准逐条确认 (v9.2.0 新增)
|
||||
5. 读 .ai_state/design.md 的 "## 验收标准"
|
||||
6. 逐条确认: 这个标准是否被满足? 证据是什么 (测试名/文件位置)?
|
||||
7. 未满足的标准 → 标注到 .ai_state/quality.md "## 未满足验收标准"
|
||||
8. 如果有 E2E 框架 → 运行 E2E 确认用户流程
|
||||
|
||||
## 输出: .ai_state/verified.md (通过项目 + 发现问题)
|
||||
## 产出
|
||||
- .ai_state/quality.md 填入验证结果 + 未满足标准
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
# archive
|
||||
<!-- VibeCoding v9.1.0 模板 — 由 /vibe-init 创建 -->
|
||||
<!-- 使用说明在注释中, 填充后删除注释 -->
|
||||
@@ -1,8 +1,12 @@
|
||||
# Conventions
|
||||
<!-- 项目编码规范, 由 /vibe-init 从项目推断或用户指定 -->
|
||||
## 语言: {TypeScript/Python/Rust/Go}
|
||||
## 框架: {Next.js/FastAPI/Actix/...}
|
||||
## 测试: {Jest/Pytest/Cargo test/...}
|
||||
## 代码风格: {ESLint配置/Ruff配置/...}
|
||||
## 命名规范: {camelCase/snake_case/...}
|
||||
## Git 分支策略: {trunk-based/gitflow/...}
|
||||
|
||||
## 项目编码规范
|
||||
{由 vibe-init 自动检测并填入, 或手动编写}
|
||||
|
||||
## 依赖版本
|
||||
{关键依赖 + 版本号}
|
||||
|
||||
## Agent 易犯错误
|
||||
> 由 reflexion/kaizen 自动追加, 帮助 agent 避免重复犯错
|
||||
|
||||
- (初始为空, 使用过程中逐渐积累)
|
||||
|
||||
@@ -1,3 +1,24 @@
|
||||
# design
|
||||
<!-- VibeCoding v9.1.0 模板 — 由 /vibe-init 创建 -->
|
||||
<!-- 使用说明在注释中, 填充后删除注释 -->
|
||||
# Design Spec
|
||||
|
||||
## 需求 (MUST/SHOULD/COULD)
|
||||
|
||||
### MUST (必须实现)
|
||||
- {核心功能 1}
|
||||
- {核心功能 2}
|
||||
|
||||
### SHOULD (应该实现)
|
||||
- {重要功能}
|
||||
|
||||
### COULD (可以实现)
|
||||
- {锦上添花}
|
||||
|
||||
## 技术方案
|
||||
{架构 + 关键设计决策}
|
||||
|
||||
## 验收标准
|
||||
- [ ] {标准 1: 具体可验证的条件}
|
||||
- [ ] {标准 2: 具体可验证的条件}
|
||||
|
||||
## 非功能需求
|
||||
- 性能: {指标}
|
||||
- 安全: {要求}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Doing (看板)
|
||||
## TODO
|
||||
- {待做任务}
|
||||
## DOING
|
||||
- 🔄 {进行中任务}
|
||||
## DONE
|
||||
- ✅ {已完成任务}
|
||||
# Doing
|
||||
|
||||
## 当前执行
|
||||
- [ ] {当前步骤描述}
|
||||
|
||||
## 执行历史
|
||||
{自动追加完成的步骤}
|
||||
|
||||
@@ -1,6 +0,0 @@
|
||||
# Knowledge
|
||||
<!-- 跨会话经验沉淀, V 阶段写入, compact 前备份 -->
|
||||
<!-- 配合 /memory (auto-memory) 使用 -->
|
||||
## 项目模式
|
||||
## 已知陷阱
|
||||
## 技术决策记录
|
||||
@@ -1,4 +1,10 @@
|
||||
# Lessons
|
||||
<!-- 错误教训, 由 lessons-loop 写入 -->
|
||||
<!-- 格式: [日期] [模块] — [类别] -->
|
||||
<!-- 类别: SCOPE/TECH/ARCH/IMPL/TEST/STYLE -->
|
||||
# Lessons Learned
|
||||
|
||||
## 技术陷阱
|
||||
{Reflexion/Kaizen 发现的技术问题}
|
||||
|
||||
## 有效模式
|
||||
{本项目中验证有效的解决方案}
|
||||
|
||||
## 项目特有知识
|
||||
{不在文档中但很重要的隐性知识}
|
||||
|
||||
@@ -1,9 +1,14 @@
|
||||
# Plan
|
||||
<!-- 由 plan-first skill 生成, checkbox 格式 -->
|
||||
## 需求: {一句话}
|
||||
## 预估: {时间}
|
||||
|
||||
## 任务列表
|
||||
- [ ] 任务1: {描述} — {预估} — {子代理: builder/手动}
|
||||
- [ ] 任务2: {描述} — {预估} — {依赖: 任务1}
|
||||
## 技术决策
|
||||
- {决策1}: {原因}
|
||||
|
||||
- [ ] T-001: {动作动词} + {目标} + {验收条件}
|
||||
文件: {涉及文件}
|
||||
依赖: 无
|
||||
|
||||
- [ ] T-002: {动作动词} + {目标} + {验收条件}
|
||||
文件: {涉及文件}
|
||||
依赖: T-001
|
||||
|
||||
## 对抗审查记录
|
||||
{Codex 审查结果摘要, 或 "CC 独立审查"}
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
# Quality Report
|
||||
|
||||
## 验证结果
|
||||
- 测试: {通过/失败} ({覆盖率}%)
|
||||
- TypeScript: {通过/失败}
|
||||
- Lint: {通过/失败}
|
||||
|
||||
## 验收标准确认
|
||||
- [x] {标准 1}: 满足, 证据: {测试名/文件位置}
|
||||
- [ ] {标准 2}: 未满足, 原因: {说明}
|
||||
|
||||
## 代码审查
|
||||
- 审查者: {CC / Codex / 互审}
|
||||
- 发现问题: {数量}
|
||||
- 已修复: {数量}
|
||||
|
||||
## 未满足验收标准
|
||||
{列出未满足的标准 + 原因}
|
||||
@@ -1,3 +0,0 @@
|
||||
# review
|
||||
<!-- VibeCoding v9.1.0 模板 — 由 /vibe-init 创建 -->
|
||||
<!-- 使用说明在注释中, 填充后删除注释 -->
|
||||
@@ -1,7 +1,13 @@
|
||||
# Session
|
||||
<!-- 当前会话状态, context-loader.cjs 读取 -->
|
||||
## 项目: {项目名}
|
||||
## 当前阶段: {R₀/R/D/P/E/T/V}
|
||||
## Path: {A/B/C/D}
|
||||
## 需求摘要: {一句话}
|
||||
## 更新时间: {时间戳}
|
||||
|
||||
## 任务
|
||||
{任务描述}
|
||||
|
||||
## 路径
|
||||
P.A.C.E. Path: {A|B|C|D}
|
||||
|
||||
## 当前阶段
|
||||
RIPER-7: {R₀|R|D|P|E|T|V}
|
||||
|
||||
## 时间戳
|
||||
开始: {ISO timestamp}
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
# verified
|
||||
<!-- VibeCoding v9.1.0 模板 — 由 /vibe-init 创建 -->
|
||||
<!-- 使用说明在注释中, 填充后删除注释 -->
|
||||
+10
-40
@@ -1,43 +1,13 @@
|
||||
# P.A.C.E. 复杂度路由 (v9.1.0)
|
||||
# P.A.C.E. 复杂度路由 v9.2.0
|
||||
|
||||
## 评估维度
|
||||
- 文件数 (1 / 2-10 / 10-50 / 50+)
|
||||
- 预估时间 (<30min / 6-12h / 1-3天 / 1周+)
|
||||
- 架构影响 (无 / 局部 / 跨模块 / 全局)
|
||||
收到任务后, 按以下规则选择路径:
|
||||
|
||||
## Path A — 快速修复 (≤30min, 1-2 文件)
|
||||
加载: CLAUDE.md + rules.md (~130L)
|
||||
阶段: R(轻) → E → T(轻) → V
|
||||
自动 Skills: [R] context7 | [E] tdd(L1) | [T] verification | [V] kaizen
|
||||
检查点: cunzhi [DELIVERY_CONFIRMED]
|
||||
注意: 无 plan.md, 无 design.md, delivery-gate 跳过严格检查
|
||||
| 条件 | 路径 | 阶段 | Codex 参与 |
|
||||
|------|------|------|-----------|
|
||||
| 修 bug / 改配置 / <30min | **A (快速)** | E→T | 可选 |
|
||||
| 新功能 / 重构 / 30min-4h | **B (标准)** | R₀→R→D→P→E→T→V | P对抗审查 + E委托 + T互审 |
|
||||
| 跨模块 / 架构变更 / >4h | **C (复杂)** | 同B + 子代理并行 | 同B + 多任务并行 |
|
||||
| 多服务 / 全栈 / 多人协作 | **D (系统)** | 同C + 设计评审 | 同C |
|
||||
|
||||
## Path B — 计划开发 (6-12h, 2-10 文件)
|
||||
加载: + workflows + 6 skills (~540L)
|
||||
阶段与自动 Skills:
|
||||
R₀b: **brainstorm** → spec + design.md → cunzhi [DESIGN_DIRECTION]
|
||||
R: augment-context/deepwiki → **context7** → 更新 design.md
|
||||
D: **context7** 查 API → design.md 终稿 → cunzhi [DESIGN_READY]
|
||||
P: **plan-first** → plan.md → cunzhi [PLAN_CONFIRMED]
|
||||
E: **tdd**(L2) → doing.md 看板
|
||||
T: **verification** + **code-review** → verified.md
|
||||
V: delivery-gate + LLM 审查 → **kaizen** → cunzhi [DELIVERY_CONFIRMED]
|
||||
|
||||
## Path C — 系统开发 (1-3 天, 10-50 文件)
|
||||
加载: + agent-teams + e2e-testing (~700L)
|
||||
同 Path B + :
|
||||
E: **agent-teams** 并行 (builder×N / validator / explorer)
|
||||
T: + **e2e-testing** (Playwright) → cunzhi [TESTS_PASSED]
|
||||
V: 按功能分 commit + **kaizen**
|
||||
|
||||
## Path D — 企业级 (1周+, 50+ 文件)
|
||||
同 Path C + :
|
||||
E: + e2e-runner + security-auditor 子代理
|
||||
T: + security-review → cunzhi [SECURITY_PASSED]
|
||||
V: 分 PR 交付, 每个 PR 独立审查 + **kaizen**
|
||||
|
||||
## 路径选择规则
|
||||
1. 默认 Path A, 除非满足升级条件
|
||||
2. 用户明确说 "简单修一下" → 不要升级到 B
|
||||
3. 不确定 → 问用户确认复杂度
|
||||
4. 可用 /fork 并行探索多个方案 (Path B+ brainstorm 阶段)
|
||||
选定路径后 → 读 riper-7.md 执行对应阶段。
|
||||
Path A 跳过 R₀/R/D/P, 直接 E→T。
|
||||
|
||||
@@ -1,72 +1,71 @@
|
||||
# RIPER-7 阶段编排 (v9.1.0)
|
||||
# RIPER-7 阶段编排 v9.2.0
|
||||
|
||||
## 阶段流: R₀ → R → D → P → E → T → V
|
||||
## 每阶段进入前 (通用)
|
||||
1. 这一步要解决的核心问题是什么?
|
||||
2. 项目里有没有类似实现? → 搜索 (Grep/Glob, 或 augment-context-engine 如已安装)
|
||||
3. 用到的库 API 确定吗? → context7 skill 查文档
|
||||
4. .ai_state/lessons.md + conventions.md 有相关经验吗?
|
||||
|
||||
### R₀ (预研/头脑风暴, Path B+ 独有)
|
||||
触发: /vibe-dev 且 PACE≥B
|
||||
**自动加载**: brainstorm skill
|
||||
工具: augment-context + cunzhi
|
||||
输入: 用户需求
|
||||
输出: .ai_state/design.md (含 spec 需求模板 + 方案草案)
|
||||
检查点: cunzhi [DESIGN_DIRECTION]
|
||||
技巧: 可用 /fork 并行探索不同方案方向
|
||||
---
|
||||
|
||||
### R (研究)
|
||||
触发: R₀ 确认后 或 Path A 直接进入
|
||||
**自动加载**: context7 skill
|
||||
工具: augment-context + deepwiki + WebSearch
|
||||
输入: design.md 或 用户需求
|
||||
输出: 更新 design.md (技术细节)
|
||||
## R₀ 需求精炼 (Path B+)
|
||||
**技能**: brainstorm skill (含步骤0自主调研)
|
||||
**产出**: .ai_state/design.md (Spec: MUST/SHOULD/COULD + 验收标准)
|
||||
**门控**: cunzhi `DESIGN_READY` (cunzhi 不可用时: 直接输出 "[DESIGN_READY] 请确认" 等用户回复)
|
||||
|
||||
### D (设计, Path B+ 独有)
|
||||
触发: R 完成
|
||||
**自动加载**: context7 skill
|
||||
输入: design.md
|
||||
输出: design.md 终稿 (接口定义/数据结构/模块划分)
|
||||
检查点: cunzhi [DESIGN_READY]
|
||||
## R 技术调研 (Path B+)
|
||||
**读**: design.md
|
||||
**动手**: 搜索相关代码 + 查库版本和 API
|
||||
**产出**: design.md 追加技术方案
|
||||
**要回答**: 有没有可复用的现有代码? 需要新依赖吗?
|
||||
|
||||
### P (规划, Path B+ 独有)
|
||||
触发: D 确认后
|
||||
**自动加载**: plan-first skill
|
||||
输入: design.md
|
||||
输出: .ai_state/plan.md (任务列表+依赖+预估+子代理分配)
|
||||
检查点: cunzhi [PLAN_CONFIRMED]
|
||||
## D 方案定稿 (Path B+)
|
||||
**读**: design.md
|
||||
**检查**: 接口最小化? 错误处理完整? 有没有更简单的方案?
|
||||
**产出**: design.md 最终版 (含验收标准)
|
||||
**门控**: cunzhi `DESIGN_FINALIZED` (cunzhi 不可用时: 直接输出确认提示)
|
||||
|
||||
### E (执行)
|
||||
触发: P 确认后 或 Path A R 完成
|
||||
**自动加载**: tdd skill (强制模式) + agent-teams (Path C+)
|
||||
铁律: **先写测试, 再写实现, 测试红了才能写代码**
|
||||
输入: plan.md (B+) 或 需求描述 (A)
|
||||
过程:
|
||||
- Path A: 直接开发, 功能验证
|
||||
- Path B: tdd L2 (RED→GREEN→REFACTOR), doing.md 看板
|
||||
- Path C/D: agent-teams 并行, worktree 隔离
|
||||
输出: .ai_state/doing.md 更新, 代码变更
|
||||
Hook: PostToolUse TDD 检查 (写源码前是否有测试)
|
||||
## P 计划 (Path B+)
|
||||
**技能**: plan-first skill → 生成 plan.md (T-001/T-002... 格式)
|
||||
**双 Agent**: 如果 Codex 可用 → codex-review skill 对抗审查
|
||||
- CC 提交 plan.md → Codex 质疑 → CC 评估采纳/驳回 → 循环
|
||||
- 终止: VERDICT: APPROVED / 连续2轮全驳 / 超5轮
|
||||
- 审查结果持久化到 reviews/review-{uuid}.md
|
||||
**如果 Codex 不可用**: CC 用 validator agent 做 Plan Review
|
||||
**门控**: cunzhi `PLAN_CONFIRMED` (cunzhi 不可用时: 直接输出确认提示)
|
||||
|
||||
### T (测试/验证)
|
||||
触发: E 完成
|
||||
**自动加载**: verification + code-review skills
|
||||
工具: validator 子代理 + code-review skill
|
||||
输入: 代码变更
|
||||
过程:
|
||||
- Path A: 功能验证 + lint
|
||||
- Path B: verification + code-review → verified.md
|
||||
- Path C/D: + e2e-testing + security-review
|
||||
输出: .ai_state/verified.md
|
||||
检查点: cunzhi [TESTS_PASSED] (C+: [SECURITY_PASSED])
|
||||
## E 执行 (Path B+) — Sisyphus 循环
|
||||
对 plan.md 每个 Task:
|
||||
1. 读 Task 文本 + 相关文件 + conventions.md
|
||||
2. **双 Agent**: 如果 Codex 可用 → codex-comm skill 委托 Codex 执行
|
||||
如果 Codex 不可用 → CC builder agent 执行
|
||||
2.5. **Reflexion** (自我反思 → reflexion skill):
|
||||
"这个实现有没有: 走捷径/忽略边界/硬编码/过度工程/偏离 spec?"
|
||||
发现问题 → 立即修复
|
||||
值得记录 → lessons.md
|
||||
3. **Micro-review**: 对标 design.md spec + conventions.md 标准
|
||||
通过 → [x] Task + commit
|
||||
不通过 → 反馈修复
|
||||
**铁律**: plan.md 有任何 [ ] 未完成, 不停止。这就是 Sisyphus。
|
||||
|
||||
### V (验收/交付)
|
||||
触发: T 通过
|
||||
**自动执行**: delivery-gate hook + LLM-as-Judge prompt hook
|
||||
过程:
|
||||
1. delivery-gate 机械检查: plan 无未完成项 + 测试通过
|
||||
2. LLM-as-Judge: 代码质量/测试覆盖/commit 规范/无密钥泄露
|
||||
3. cunzhi [DELIVERY_CONFIRMED] 用户确认
|
||||
4. **Kaizen 复盘** (必须):
|
||||
a. git diff --stat 分析本次变更范围
|
||||
b. 提炼经验教训 → 写入 .ai_state/knowledge.md
|
||||
c. 发现的陷阱 → 写入 .ai_state/lessons.md
|
||||
d. 更新 .ai_state/conventions.md (如有新规范)
|
||||
5. 归档 → .ai_state/archive.md
|
||||
输出: 交付完成 + 经验沉淀
|
||||
## T 测试/审查 (Path B+)
|
||||
1. verification skill: 跑测试 + 覆盖率
|
||||
1.5. **验收标准确认**:
|
||||
读 design.md "## 验收标准" → 逐条确认是否满足
|
||||
未满足 → 标注到 quality.md "## 未满足验收标准"
|
||||
2. code-review skill: 代码审查
|
||||
3. **双 Agent 互审**: 如果 Codex 可用 → CC 审查 Codex 产出 + Codex 反审 CC 修改
|
||||
如果 Codex 不可用 → CC 单方审查
|
||||
4. 综合 → quality.md
|
||||
5. **4 级 Quality Gate** (delivery-gate.cjs):
|
||||
PASS (exit 0) → 允许停止
|
||||
CONCERNS (exit 0 + stdout 警告) → 允许停止, 警告注入 context
|
||||
REWORK (exit 2) → 阻断停止, 强制修复
|
||||
FAIL (exit 2) → 阻断停止, 必须大幅修复
|
||||
|
||||
## V 归档 (Path B+)
|
||||
1. kaizen skill: 回顾 + lessons.md
|
||||
1.5. **分支收尾** (finish-branch skill):
|
||||
选项: merge / PR / keep / discard
|
||||
PR → 自动生成 description (基于 plan.md + quality.md)
|
||||
2. cunzhi `DELIVERY_COMPLETE` (cunzhi 不可用时: 直接输出确认提示)
|
||||
|
||||
+39
-46
@@ -1,54 +1,47 @@
|
||||
# VibeCoding Kernel v9.1.0 — Codex CLI
|
||||
# VibeCoding Kernel v9.2.0 — Codex CLI
|
||||
|
||||
## 铁律 (违反即失败)
|
||||
1. **先搜后写**: augment-context-engine 搜现有实现 → 不可用时 grep -r
|
||||
2. **先规后码**: Path B+ 任务必须先 plan.md → cunzhi 确认后才能写代码
|
||||
3. **先测后码**: E 阶段写功能代码前必须先写/更新测试 (RED→GREEN→REFACTOR)
|
||||
4. **不确定就问**: 歧义/架构决策 → cunzhi 向用户确认, 不猜
|
||||
5. **不破坏已有**: 改代码前读测试, 改后跑测试, 红了就修
|
||||
6. **只改需要改的**: 不重构范围外代码, 不加未要求的功能
|
||||
7. **避免过度工程**: 最简方案, YAGNI 优先
|
||||
8. **commit 粒度**: 每个逻辑变更独立 commit, conventional commits
|
||||
9. **交付必复盘**: 完成后必须 diff 分析→提炼 lessons→写入 knowledge.md
|
||||
你是一个INTJ性格的工程化 AI 编码助手。用 P.A.C.E. 路由复杂度, 用 RIPER-7 编排阶段, 用 Skills 执行细节。
|
||||
**协作模式**: 你可能被 Claude Code (CC) 调用执行任务, 也可能独立运行。
|
||||
|
||||
## 工作流
|
||||
1. 评估复杂度 → P.A.C.E. 路由 (读 .codex/workflows/pace.md)
|
||||
2. 按路径执行 RIPER-7 阶段 (读 .codex/workflows/riper-7.md)
|
||||
3. 各阶段 skills **自动加载** (读 .codex/skills/{name}/SKILL.md)
|
||||
## 框架地图
|
||||
|
||||
## TDD 强制规则 (E 阶段)
|
||||
写功能代码前必须先有失败的测试。流程:
|
||||
1. 先写测试文件 → 运行 → 看到红色失败
|
||||
2. 再写最小实现 → 运行 → 看到绿色通过
|
||||
3. 重构 → 测试保持绿色
|
||||
违反时: 停下, 补写测试, 再继续
|
||||
| 类别 | 文件 | 数量 |
|
||||
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ---- |
|
||||
| Workflows | pace.md, riper-7.md | 2 |
|
||||
| Skills | brainstorm, plan-first, code-review, verification, debugging, kaizen, security-review, context7, e2e, claude-delegate, reflexion, finish-branch | 12 |
|
||||
| Agents | builder.toml, validator.toml, explorer.toml | 3 |
|
||||
| State Templates | session, doing, design, plan, conventions, quality, lessons | 7 |
|
||||
|
||||
## Kaizen 复盘规则 (V 阶段)
|
||||
交付后必须执行:
|
||||
1. `git diff --stat` 回顾变更范围
|
||||
2. 提炼经验 → .ai_state/knowledge.md
|
||||
3. 记录陷阱 → .ai_state/lessons.md
|
||||
## 启动流程
|
||||
|
||||
## 状态持久化
|
||||
.ai_state/ 目录: session → design → plan → doing → verified → review → archive
|
||||
模板位于 .codex/templates/ai-state/
|
||||
1. 读 .ai_state/ → 恢复或初始化
|
||||
2. 读 conventions.md (含 "Agent 易犯错误" 段) → 注意这些坑
|
||||
3. 评估任务 → P.A.C.E. 路由 → RIPER-7 执行
|
||||
|
||||
## MCP 降级
|
||||
augment-context 不可用→grep | cunzhi 不可用→对话确认 | deepwiki 不可用→web search
|
||||
## 关键规则
|
||||
|
||||
## Codex 专属能力
|
||||
- /review: 原生代码审查 (T 阶段集成)
|
||||
- /plan: 原生规划模式 (P 阶段集成)
|
||||
- /statusline: 配置 TUI 底栏显示当前阶段和进度
|
||||
- multi_agent + collaboration_modes: 多代理并行 (Path C+)
|
||||
- [agents] 角色定义: builder / reviewer / explorer (config.toml)
|
||||
- Profiles: `codex --profile dev|ci|review` 切换预设
|
||||
- spawn_agents_on_csv: 批量多代理分派
|
||||
- /model: gpt-5.4 (默认) / gpt-5.3-codex / gpt-5.3-codex-spark (快速)
|
||||
- 设计未确认前不写代码 (R₀/R/D 阶段)
|
||||
- TDD: 先写测试再写实现 (E 阶段)
|
||||
- Sisyphus: plan.md 所有 [ ] 完成才能停 (E 阶段)
|
||||
- Reflexion: 每个 Task 完成后自我反思再 Micro-review (E 阶段)
|
||||
- 4 级 Quality Gate: PASS / CONCERNS / REWORK / FAIL (交付前)
|
||||
|
||||
## 并行工作规范 (Path C/D)
|
||||
1. 读 plan.md → 识别无依赖任务组
|
||||
2. 为每组指派 agent 角色 (Codex 自动编排)
|
||||
3. 无依赖任务并行, 有依赖串行
|
||||
4. 同文件不并行修改
|
||||
5. 完成后合并 + /review 审查
|
||||
## 被 CC 调用时
|
||||
|
||||
- CC 会通过 `codex exec` 发送任务
|
||||
- 你在只读沙箱中运行, 不直接修改文件
|
||||
- 输出代码和建议, CC 决定是否应用
|
||||
- 审查请求以 `VERDICT: APPROVED` 或 `VERDICT: REVISE` 结尾
|
||||
|
||||
## MCP 工具 (按需)
|
||||
|
||||
- cunzhi: 人工确认检查点
|
||||
- context7 CLI: `npx ctx7 resolve {库名}`
|
||||
|
||||
## 模型
|
||||
|
||||
| 场景 | 模型 |
|
||||
| --------- | ------------------------ |
|
||||
| 默认 | gpt-5.4 |
|
||||
| 快速/探索 | gpt-5.4-mini |
|
||||
| 深度审查 | gpt-5.4 (high reasoning) |
|
||||
|
||||
@@ -1,11 +1,4 @@
|
||||
# VibeCoding builder 角色配置
|
||||
model = "gpt-5.3-codex"
|
||||
model_reasoning_effort = "high"
|
||||
developer_instructions = """
|
||||
你是 Builder — 专注实现, 不做设计决策。
|
||||
1. 只修改任务指定的文件范围, 不越界
|
||||
2. 写代码前先写/更新测试 (RED→GREEN)
|
||||
3. 每个子任务: git add → git commit -m "feat: {描述}"
|
||||
4. 遇到设计决策 → 停止, 报告主代理
|
||||
5. 遵循 .ai_state/conventions.md
|
||||
"""
|
||||
[agent]
|
||||
name = "builder"
|
||||
model = "gpt-5.4"
|
||||
description = "实现代码 + 测试 (TDD: RED→GREEN→REFACTOR)"
|
||||
|
||||
@@ -1,8 +1,4 @@
|
||||
# VibeCoding explorer 角色配置
|
||||
model = "gpt-5.3-codex-spark"
|
||||
model_reasoning_effort = "medium"
|
||||
developer_instructions = """
|
||||
你是 Explorer — 只读调研, 绝对不修改文件。
|
||||
方法: grep + 文件搜索 → 深入分析 → 输出发现摘要
|
||||
参考 .ai_state/knowledge.md 避免重复调研。
|
||||
"""
|
||||
[agent]
|
||||
name = "explorer"
|
||||
model = "gpt-5.4-mini"
|
||||
description = "代码库调研 + 文档查询 (只读)"
|
||||
|
||||
@@ -1,8 +0,0 @@
|
||||
# VibeCoding reviewer 角色配置
|
||||
model = "gpt-5.3-codex"
|
||||
model_reasoning_effort = "high"
|
||||
developer_instructions = """
|
||||
你是 Reviewer — 代码审查, 不修改代码。
|
||||
审查维度: 逻辑正确性 / 可读性 / 性能 / 安全 / 测试质量
|
||||
输出格式: 文件+行号 / MUST-FIX|SHOULD-FIX|NIT / 问题描述 / 修复建议
|
||||
"""
|
||||
@@ -0,0 +1,4 @@
|
||||
[agent]
|
||||
name = "validator"
|
||||
model = "gpt-5.4"
|
||||
description = "代码审查 + Plan Review"
|
||||
+17
-28
@@ -1,6 +1,6 @@
|
||||
# VibeCoding Kernel v9.1.0 — Codex CLI 配置
|
||||
# VibeCoding Kernel v9.2.0 — Codex CLI Config
|
||||
model_provider = "custom"
|
||||
model = "gpt-5.4"
|
||||
model = "gpt-5.4"
|
||||
model_reasoning_effort = "xhigh"
|
||||
suppress_unstable_features_warning = true
|
||||
|
||||
@@ -8,14 +8,14 @@ suppress_unstable_features_warning = true
|
||||
# approval_policy = "never" # untrusted|on-request|never
|
||||
# sandbox_mode = "danger-full-access" # read-only|workspace-write|danger-full-access
|
||||
|
||||
approval_policy = "never"
|
||||
sandbox_mode = "workspace-write"
|
||||
approval_policy = "never"
|
||||
sandbox_mode = "workspace-write"
|
||||
|
||||
[sandbox_workspace_write]
|
||||
network_access = true # npm install / pip install 需要网络
|
||||
|
||||
# Web Search
|
||||
web_search = "live"
|
||||
web_search = "live"
|
||||
|
||||
[features]
|
||||
multi_agent = true # stable; 多代理编排
|
||||
@@ -30,49 +30,38 @@ undo = true # 回滚 Codex 改动;
|
||||
notifications = true
|
||||
animations = true
|
||||
|
||||
[profiles.dev]
|
||||
# 日常开发: 高推理, 交互审批
|
||||
model = "gpt-5.4"
|
||||
model_reasoning_effort = "high"
|
||||
approval_policy = "on-request"
|
||||
sandbox_mode = "workspace-write"
|
||||
|
||||
[profiles.ci]
|
||||
# CI/CD: 全自动, 无审批
|
||||
model = "gpt-5.3-codex"
|
||||
model_reasoning_effort = "medium"
|
||||
approval_policy = "never"
|
||||
sandbox_mode = "workspace-write"
|
||||
|
||||
[profiles.review]
|
||||
# 代码审查: 高推理, 只读
|
||||
model = "gpt-5.4"
|
||||
model_reasoning_effort = "xhigh"
|
||||
approval_policy = "untrusted"
|
||||
sandbox_mode = "read-only"
|
||||
approval_policy = "on-request"
|
||||
|
||||
[profiles.dev]
|
||||
model = "gpt-5.4"
|
||||
approval_policy = "on-request"
|
||||
sandbox_mode = "workspace-write"
|
||||
|
||||
[agents]
|
||||
max_threads = 6
|
||||
max_depth = 2
|
||||
job_max_runtime_seconds = 1800
|
||||
max_threads = 3
|
||||
|
||||
[agents.builder]
|
||||
description = "实现功能代码。先写测试再写实现, 每个子任务完成后 commit。"
|
||||
description = "实现代码 + 测试 (TDD: RED→GREEN→REFACTOR)"
|
||||
config_file = "./agents/builder.toml"
|
||||
|
||||
[agents.reviewer]
|
||||
description = "代码审查: 安全、正确性、测试风险。"
|
||||
config_file = "./agents/reviewer.toml"
|
||||
[agents.validator]
|
||||
description = "代码审查 + Plan Review"
|
||||
config_file = "./agents/validator.toml"
|
||||
|
||||
[agents.explorer]
|
||||
description = "只读搜索分析: 搜索代码库、分析依赖、查找模式。"
|
||||
description = "代码库调研 + 文档查询 (只读)"
|
||||
config_file = "./agents/explorer.toml"
|
||||
|
||||
[model_providers.custom]
|
||||
name = "custom"
|
||||
wire_api = "responses"
|
||||
requires_openai_auth = true
|
||||
base_url = ""
|
||||
|
||||
[mcp_servers]
|
||||
|
||||
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
name: agent-teams
|
||||
description: 多代理并行协作 — Path C/D 的 E 阶段
|
||||
context: main
|
||||
---
|
||||
## 触发: Path C/D 的 E(执行) 阶段 (自动加载)
|
||||
|
||||
## 前提
|
||||
- config.toml [features] multi_agent=true, collaboration_modes=true
|
||||
- config.toml [agents] 定义了 builder/reviewer/explorer 角色
|
||||
- plan.md 中任务已标注可并行/有依赖
|
||||
|
||||
## 编排策略
|
||||
1. 读 plan.md → 识别无依赖的任务组
|
||||
2. Codex 自动编排多代理 (基于 [agents] 角色定义)
|
||||
3. spawn_agents_on_csv 可用于批量分派
|
||||
4. 每个子代理独立工作, 完成后合并
|
||||
|
||||
## 并行规则
|
||||
- 无依赖任务: 并行执行
|
||||
- 有依赖任务: 串行, 前置完成后触发
|
||||
- 同文件不并行修改
|
||||
- 完成后 /review 审查合并结果
|
||||
|
||||
## 角色
|
||||
builder: 先测试后实现, 限定范围, 每任务 commit
|
||||
reviewer: 代码审查, 安全/正确性/测试风险
|
||||
explorer: 只读调研, 搜索代码库/分析依赖
|
||||
@@ -1,21 +1,25 @@
|
||||
---
|
||||
name: brainstorm
|
||||
description: 需求头脑风暴 — R₀b 阶段, 探索方案空间
|
||||
context: main
|
||||
description: R₀ 苏格拉底式需求精炼
|
||||
---
|
||||
## 触发: Path B+ 任务开始时 (自动加载)
|
||||
# Brainstorm (R₀ 需求精炼)
|
||||
|
||||
## 步骤
|
||||
1. augment-context-engine 搜索相关代码和依赖
|
||||
2. 读 .ai_state/knowledge.md 了解历史经验
|
||||
3. 生成 Spec 需求模板 (写入 design.md 顶部):
|
||||
- 功能需求 (MUST/SHOULD/COULD)
|
||||
- 非功能需求 (性能/安全/兼容性)
|
||||
- 约束条件 (技术栈/时间/依赖)
|
||||
- 验收标准 (可测试的完成条件)
|
||||
4. 生成 2-3 个候选方案, 每个包含:
|
||||
方案描述 / 优劣势 / 预估工作量 / 技术风险
|
||||
5. 输出到 .ai_state/design.md
|
||||
6. cunzhi [DESIGN_DIRECTION] 让用户选择方向
|
||||
Path B+ 任务在写代码前**必须**激活。
|
||||
|
||||
不可用时: 直接基于需求分析, 跳过代码搜索
|
||||
## 流程
|
||||
### 0. 自主调研 (提问前)
|
||||
- 搜索项目中与需求相关的现有代码
|
||||
- 读 .ai_state/lessons.md + conventions.md
|
||||
→ 基于调研结果准备更有深度的问题
|
||||
|
||||
### 1. 访谈 (苏格拉底式)
|
||||
- 一次只问一个问题, 优先选择题
|
||||
- 覆盖: 目标、场景、边界、非功能需求
|
||||
- YAGNI: 主动砍不必要的功能
|
||||
|
||||
### 2. 提出 2-3 方案
|
||||
- 每方案: 架构 + 优劣 + 复杂度
|
||||
- context7 验证可行性
|
||||
|
||||
### 3. 确认 → .ai_state/design.md
|
||||
铁律: 设计未确认前不写代码
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
name: claude-delegate
|
||||
description: 接收 CC 派发任务 + 反向调用 CC
|
||||
---
|
||||
# Claude Delegate
|
||||
|
||||
## 当被 CC 调用时
|
||||
- CC 通过 codex exec 发送任务
|
||||
- 你在只读沙箱, 输出代码和建议
|
||||
- 审查请求: 以 `VERDICT: APPROVED` 或 `VERDICT: REVISE` 结尾
|
||||
|
||||
## 反向调用 CC (独立运行时)
|
||||
如需 Claude 视角:
|
||||
```bash
|
||||
# 如果有 claude CLI
|
||||
claude -p "审查以下代码: {code}"
|
||||
```
|
||||
如不可用 → 用 validator agent 自审
|
||||
@@ -1,18 +1,18 @@
|
||||
---
|
||||
name: code-review
|
||||
description: 代码审查 — T 阶段辅助
|
||||
context: main
|
||||
description: T 阶段代码审查
|
||||
---
|
||||
## 触发: T 阶段, verification 之后
|
||||
# Code Review
|
||||
|
||||
## 审查维度
|
||||
1. 逻辑正确性: 边界条件、错误处理、并发安全
|
||||
2. 可读性: 命名清晰、函数职责单一、注释合理
|
||||
3. 性能: 无 N+1 查询、无不必要的循环
|
||||
4. 安全: 无注入、无硬编码密钥
|
||||
5. 测试: 测试有意义, 不只是刷覆盖率
|
||||
6. 优雅: "如果重新实现, 我会这样写吗?"
|
||||
## 审查清单
|
||||
1. Spec 合规: 每个 MUST 实现?
|
||||
2. TDD: 源码有对应测试?
|
||||
3. 边界: 空输入/超长/并发/错误路径?
|
||||
4. 安全: 无硬编码密钥, 输入已验证
|
||||
5. 可读: 函数 < 50 行, 注释说 WHY, 严格类型
|
||||
6. 简洁: 无过度工程, 无重复, 无空 catch
|
||||
|
||||
## 输出格式
|
||||
每个问题: 文件+行号 / MUST-FIX|SHOULD-FIX|NIT / 问题描述 / 修复建议
|
||||
无问题: "APPROVED — no issues found"
|
||||
## LLM-as-Judge 输出格式
|
||||
```json
|
||||
{"level": "PASS|CONCERNS|REWORK|FAIL", "issues": [...], "summary": "..."}
|
||||
```
|
||||
|
||||
@@ -1,19 +1,9 @@
|
||||
---
|
||||
name: context7
|
||||
description: 库文档按需拉取
|
||||
context: main
|
||||
description: 库文档查询
|
||||
---
|
||||
# Context7
|
||||
|
||||
查询依赖库文档时:
|
||||
|
||||
1. 优先: ctx7 和 mcp-deepwiki 查询
|
||||
2. 降级: WebSearch 搜索官方文档
|
||||
|
||||
## 使用时机
|
||||
|
||||
- R₀b brainstorm: 候选库文档对比
|
||||
- R 研究: 深入调研技术栈
|
||||
- D 设计: 确认 API 接口可行
|
||||
- E 开发: 不确定用法时即时查询
|
||||
|
||||
不预加载, 按需拉取, 仅取所需章节。
|
||||
1. 优先: `npx ctx7 resolve {库名}`
|
||||
2. 备选: web search
|
||||
3. 缓存: 查过的结论写入当前笔记
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
name: debugging
|
||||
description: 系统化调试 4 阶段
|
||||
---
|
||||
# Systematic Debugging
|
||||
|
||||
必须按 4 阶段执行, 禁止跳步:
|
||||
|
||||
## 1. 复现 — 最小用例, 记录输入/期望/实际
|
||||
## 2. 定位 — 从错误点向上追溯, 用证据不用直觉
|
||||
## 3. 修复 — 只改根因, 有对应测试, 禁止 as any / 空 catch
|
||||
## 4. 验证 — 复现通过 + 全量无回归 + Reflexion: 值得记录?
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
name: e2e-testing
|
||||
description: 端到端测试 — Path C/D 的 T 阶段
|
||||
context: main
|
||||
---
|
||||
## 触发: Path C/D 的 T(测试) 阶段
|
||||
|
||||
## 步骤
|
||||
1. 检查 Playwright 配置 (playwright.config.ts)
|
||||
2. 调用 e2e-runner 子代理执行测试
|
||||
3. 收集结果: 通过率 + 失败详情 + 截图
|
||||
4. 失败 → 反馈给 builder 修复 → 重测
|
||||
5. 全部通过 → cunzhi [TESTS_PASSED]
|
||||
|
||||
## 降级
|
||||
Playwright 不可用 → 手动功能验证 + 用户确认
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
name: e2e
|
||||
description: 端到端测试
|
||||
---
|
||||
# E2E Testing
|
||||
|
||||
前置: 有 E2E 框架 (Playwright/Cypress) 且 Path C+ 或用户要求
|
||||
流程: 基于验收标准写用例 → 运行 → 结果入 quality.md
|
||||
无框架: 手动验证清单
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
name: finish-branch
|
||||
description: V 阶段分支收尾
|
||||
---
|
||||
# Finish Branch
|
||||
|
||||
V 阶段 kaizen 后, 交付确认前。
|
||||
|
||||
## 选项
|
||||
a) **pr**: 生成 PR description (标题+摘要+变更+测试)
|
||||
b) **keep**: 保留分支
|
||||
c) **discard**: 确认后标记废弃
|
||||
|
||||
注意: Codex 不直接执行 git merge, 生成描述供用户操作。
|
||||
@@ -1,23 +1,11 @@
|
||||
---
|
||||
name: kaizen
|
||||
description: 持续改进 — V 阶段, 交付后自动复盘经验沉淀
|
||||
context: main
|
||||
description: V 阶段回顾
|
||||
---
|
||||
## 触发: V(验收) 阶段, 交付确认后 (自动加载)
|
||||
# Kaizen
|
||||
|
||||
## 步骤
|
||||
1. `git diff --stat HEAD~{n}..HEAD` 分析变更范围
|
||||
2. 回顾开发过程:
|
||||
- 哪些决策正确? 为什么?
|
||||
- 哪些地方浪费时间? 根因?
|
||||
- 可复用的模式?
|
||||
3. 提炼输出:
|
||||
- **knowledge.md**: 可复用模式和决策
|
||||
- **lessons.md**: 错误教训和陷阱
|
||||
- **conventions.md**: 新规范 (如有)
|
||||
4. 简洁记录, 每条 ≤2 行
|
||||
|
||||
## 原则
|
||||
- 只记录有价值的、可操作的经验
|
||||
- 不记录 AI 已知的通用常识
|
||||
- 格式: `[日期] 领域: 经验描述`
|
||||
## 流程
|
||||
1. 回顾: 好的保持, 差的改进, 模式性错误?
|
||||
2. 更新 lessons.md
|
||||
3. 更新 conventions.md "## Agent 易犯错误" (如发现模式性错误)
|
||||
4. 摘要给用户
|
||||
|
||||
@@ -1,20 +1,21 @@
|
||||
---
|
||||
name: plan-first
|
||||
description: 强制先规划后执行 — 基于 design.md 生成计划
|
||||
context: main
|
||||
description: P 阶段计划生成
|
||||
---
|
||||
## 触发: Path B+ 任务, brainstorm 完成后
|
||||
# Plan-First (P 阶段)
|
||||
|
||||
## 步骤
|
||||
1. 读 .ai_state/design.md 作为规划输入
|
||||
2. 使用 /plan 进入规划模式
|
||||
3. context7 查询任务涉及的库文档, 确保技术细节准确
|
||||
4. 输出到 .ai_state/plan.md:
|
||||
- [ ] 任务列表 (checkbox 格式)
|
||||
- 依赖关系
|
||||
- 预估时间
|
||||
- 子代理分配 (Path C+)
|
||||
5. cunzhi [PLAN_CONFIRMED] 确认后才能写代码
|
||||
6. plan.md 未完成任务 → delivery-gate 阻塞
|
||||
## 流程
|
||||
1. 读 design.md
|
||||
2. 分解为可执行任务:
|
||||
```
|
||||
- [ ] T-001: {动作} + {目标} + {验收条件}
|
||||
文件: {涉及文件}
|
||||
依赖: {前置任务}
|
||||
```
|
||||
3. 排序: 依赖拓扑 → 风险高先做
|
||||
4. 写入 plan.md
|
||||
|
||||
## 管道: brainstorm → context7 → plan-first → E
|
||||
## 质量检查
|
||||
- 每个任务有"完成"定义
|
||||
- 无模糊词
|
||||
- 超过 15 个任务考虑拆分
|
||||
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
name: quickstart
|
||||
description: 新手引导 — 首次使用 VibeCoding 的引导流程
|
||||
context: main
|
||||
---
|
||||
## 触发: 无 .ai_state/ 目录时
|
||||
|
||||
## 步骤
|
||||
1. 欢迎: "VibeCoding Kernel v9.1.0 — AI 编程协作框架"
|
||||
2. 检测项目类型 (package.json/Cargo.toml/go.mod/pyproject.toml)
|
||||
3. 初始化 .ai_state/ 目录 (从 .codex/templates/ai-state/ 复制模板)
|
||||
4. 简要说明:
|
||||
- 直接描述需求即可开始 (自动 P.A.C.E. 路由)
|
||||
- "查看进度" 或 "当前状态" → 显示看板
|
||||
- "继续上次" → 从断点恢复
|
||||
- /review → 原生代码审查
|
||||
- /plan → 原生规划模式
|
||||
5. 提示: 复杂任务会自动路由到合适的工作流
|
||||
|
||||
## 原则: 不要解释内部机制 (RIPER/PACE), 只告诉用户怎么用
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
name: reflexion
|
||||
description: E 阶段自我反思
|
||||
---
|
||||
# Reflexion (自我反思)
|
||||
|
||||
E 阶段每个 Task 实现完成后, Micro-review 之前。
|
||||
|
||||
## 反思清单
|
||||
1. 走捷径了吗? (as any, 空 catch)
|
||||
2. 忽略边界了吗? (空/超长/并发/null)
|
||||
3. 硬编码了吗? (URL/端口/阈值)
|
||||
4. 过度工程了吗? (需求没要求的功能)
|
||||
5. 偏离 spec 了吗?
|
||||
6. 6 个月后能理解吗?
|
||||
|
||||
发现问题 → 立即修复
|
||||
值得记录 → lessons.md
|
||||
模式性错误 → conventions.md "Agent 易犯错误"
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
name: security-review
|
||||
description: 安全审查
|
||||
---
|
||||
# Security Review
|
||||
|
||||
检查: 认证/授权, 输入验证, 密钥管理, 依赖漏洞, 日志安全, CORS/CSP
|
||||
产出: 追加到 quality.md
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
name: tdd
|
||||
description: 测试驱动开发 — E 阶段, 先写测试后实现 (强制执行)
|
||||
context: main
|
||||
---
|
||||
## 触发: E(执行) 阶段 (自动加载)
|
||||
|
||||
## 铁律: RED → GREEN → REFACTOR
|
||||
**写功能代码前必须先有失败的测试。**
|
||||
违反此规则时, 立即停止, 补写测试。
|
||||
|
||||
## 分级策略
|
||||
- **Level 1** (Path A): 功能验证, 关键路径有测试即可
|
||||
- **Level 2** (Path B): 单元+集成, 严格 RED→GREEN→REFACTOR
|
||||
- **Level 3** (Path C+): + E2E, 覆盖率 >80%
|
||||
|
||||
## 强制流程 (Level 2+)
|
||||
1. 读 plan.md 当前任务
|
||||
2. 写失败测试 (RED) → 运行确认失败
|
||||
3. 写最小实现 (GREEN) → 运行确认通过
|
||||
4. 重构 (REFACTOR) → 测试保持绿色
|
||||
5. 更新 doing.md (TODO→DOING→DONE)
|
||||
6. git commit
|
||||
|
||||
## 测试命令自动检测
|
||||
package.json scripts.test → npm test
|
||||
pytest.ini/pyproject.toml → pytest
|
||||
Cargo.toml → cargo test
|
||||
go.mod → go test ./...
|
||||
@@ -1,20 +1,16 @@
|
||||
---
|
||||
name: verification
|
||||
description: 代码验证 — T 阶段
|
||||
context: main
|
||||
description: T 阶段验证
|
||||
---
|
||||
## 触发: T(测试) 阶段
|
||||
# Verification
|
||||
|
||||
## 检查清单
|
||||
1. 所有测试通过 (自动检测测试命令)
|
||||
2. lint 通过 (eslint/ruff/clippy)
|
||||
3. 类型检查通过 (tsc/mypy/cargo check)
|
||||
4. 无 TODO/FIXME 残留
|
||||
5. .ai_state/conventions.md 规范符合
|
||||
## 流程
|
||||
1. 运行测试 + 覆盖率
|
||||
2. TypeScript 类型检查 (如有)
|
||||
3. Lint (如有, Path C+ 强制)
|
||||
|
||||
## Path 差异
|
||||
- Path A: 检查 1 即可
|
||||
- Path B: 检查 1-5 + 输出 verified.md
|
||||
- Path C+: + 调用 validator 子代理
|
||||
|
||||
## 输出: .ai_state/verified.md (通过项目 + 发现问题)
|
||||
## 验收标准逐条确认
|
||||
4. 读 design.md "## 验收标准"
|
||||
5. 逐条确认: 满足? 证据?
|
||||
6. 未满足 → quality.md "## 未满足验收标准"
|
||||
7. E2E (如有框架)
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
# archive
|
||||
<!-- VibeCoding v9.1.0 模板 — 由初始化流程创建 -->
|
||||
<!-- 使用说明在注释中, 填充后删除注释 -->
|
||||
@@ -1,8 +1,9 @@
|
||||
# Conventions
|
||||
<!-- 项目编码规范, 由初始化流程从项目推断或用户指定 -->
|
||||
## 语言: {TypeScript/Python/Rust/Go}
|
||||
## 框架: {Next.js/FastAPI/Actix/...}
|
||||
## 测试: {Jest/Pytest/Cargo test/...}
|
||||
## 代码风格: {ESLint配置/Ruff配置/...}
|
||||
## 命名规范: {camelCase/snake_case/...}
|
||||
## Git 分支策略: {trunk-based/gitflow/...}
|
||||
|
||||
## 项目编码规范
|
||||
{自动检测或手动填写}
|
||||
|
||||
## Agent 易犯错误
|
||||
> 由 reflexion/kaizen 自动追加
|
||||
|
||||
- (初始为空)
|
||||
|
||||
@@ -1,3 +1,19 @@
|
||||
# design
|
||||
<!-- VibeCoding v9.1.0 模板 — 由初始化流程创建 -->
|
||||
<!-- 使用说明在注释中, 填充后删除注释 -->
|
||||
# Design Spec
|
||||
|
||||
## 需求 (MUST/SHOULD/COULD)
|
||||
|
||||
### MUST
|
||||
- {核心功能}
|
||||
|
||||
### SHOULD
|
||||
- {重要功能}
|
||||
|
||||
### COULD
|
||||
- {锦上添花}
|
||||
|
||||
## 技术方案
|
||||
{架构}
|
||||
|
||||
## 验收标准
|
||||
- [ ] {标准 1}
|
||||
- [ ] {标准 2}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Doing (看板)
|
||||
## TODO
|
||||
- {待做任务}
|
||||
## DOING
|
||||
- 🔄 {进行中任务}
|
||||
## DONE
|
||||
- ✅ {已完成任务}
|
||||
# Doing
|
||||
|
||||
## 当前执行
|
||||
- [ ] {当前步骤}
|
||||
|
||||
## 历史
|
||||
{自动追加}
|
||||
|
||||
@@ -1,6 +0,0 @@
|
||||
# Knowledge
|
||||
<!-- 跨会话经验沉淀, V 阶段写入, compact 前备份 -->
|
||||
<!-- 跨会话经验, Codex memories 自动管理 -->
|
||||
## 项目模式
|
||||
## 已知陷阱
|
||||
## 技术决策记录
|
||||
@@ -1,4 +1,7 @@
|
||||
# Lessons
|
||||
<!-- 错误教训, 由 lessons-loop 写入 -->
|
||||
<!-- 格式: [日期] [模块] — [类别] -->
|
||||
<!-- 类别: SCOPE/TECH/ARCH/IMPL/TEST/STYLE -->
|
||||
# Lessons Learned
|
||||
|
||||
## 技术陷阱
|
||||
{发现的问题}
|
||||
|
||||
## 有效模式
|
||||
{有效的解决方案}
|
||||
|
||||
@@ -1,9 +1,7 @@
|
||||
# Plan
|
||||
<!-- 由 plan-first skill 生成, checkbox 格式 -->
|
||||
## 需求: {一句话}
|
||||
## 预估: {时间}
|
||||
|
||||
## 任务列表
|
||||
- [ ] 任务1: {描述} — {预估} — {子代理: builder/手动}
|
||||
- [ ] 任务2: {描述} — {预估} — {依赖: 任务1}
|
||||
## 技术决策
|
||||
- {决策1}: {原因}
|
||||
|
||||
- [ ] T-001: {动作} + {目标} + {验收条件}
|
||||
文件: {文件}
|
||||
依赖: 无
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
# Quality Report
|
||||
|
||||
## 验证结果
|
||||
- 测试: {通过/失败}
|
||||
- 类型检查: {通过/失败}
|
||||
|
||||
## 验收标准确认
|
||||
- [x] {标准}: 满足
|
||||
- [ ] {标准}: 未满足
|
||||
|
||||
## 代码审查
|
||||
- 发现: {数量}
|
||||
- 已修复: {数量}
|
||||
@@ -1,3 +0,0 @@
|
||||
# review
|
||||
<!-- VibeCoding v9.1.0 模板 — 由初始化流程创建 -->
|
||||
<!-- 使用说明在注释中, 填充后删除注释 -->
|
||||
@@ -1,7 +1,10 @@
|
||||
# Session
|
||||
<!-- 当前会话状态, context-loader.cjs 读取 -->
|
||||
## 项目: {项目名}
|
||||
## 当前阶段: {R₀/R/D/P/E/T/V}
|
||||
## Path: {A/B/C/D}
|
||||
## 需求摘要: {一句话}
|
||||
## 更新时间: {时间戳}
|
||||
|
||||
## 任务
|
||||
{任务描述}
|
||||
|
||||
## 路径
|
||||
P.A.C.E. Path: {A|B|C|D}
|
||||
|
||||
## 当前阶段
|
||||
RIPER-7: {R₀|R|D|P|E|T|V}
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
# verified
|
||||
<!-- VibeCoding v9.1.0 模板 — 由初始化流程创建 -->
|
||||
<!-- 使用说明在注释中, 填充后删除注释 -->
|
||||
+10
-38
@@ -1,41 +1,13 @@
|
||||
# P.A.C.E. 复杂度路由 (v9.1.0)
|
||||
# P.A.C.E. 复杂度路由 v9.2.0
|
||||
|
||||
## 评估维度
|
||||
- 文件数 (1 / 2-10 / 10-50 / 50+)
|
||||
- 预估时间 (<30min / 6-12h / 1-3天 / 1周+)
|
||||
- 架构影响 (无 / 局部 / 跨模块 / 全局)
|
||||
收到任务后, 按以下规则选择路径:
|
||||
|
||||
## Path A — 快速修复 (≤30min, 1-2 文件)
|
||||
加载: AGENTS.md (~130L)
|
||||
阶段: R(轻) → E → T(轻) → V
|
||||
自动 Skills: [R] context7 | [E] tdd(L1) | [T] verification | [V] kaizen
|
||||
检查点: cunzhi [DELIVERY_CONFIRMED]
|
||||
| 条件 | 路径 | 阶段 |
|
||||
|------|------|------|
|
||||
| 修 bug / 改配置 / <30min | **A (快速)** | E→T |
|
||||
| 新功能 / 重构 / 30min-4h | **B (标准)** | R₀→R→D→P→E→T→V |
|
||||
| 跨模块 / 架构变更 / >4h | **C (复杂)** | 同B + 子代理并行 |
|
||||
| 多服务 / 全栈 / 多人协作 | **D (系统)** | 同C + 设计评审 |
|
||||
|
||||
## Path B — 计划开发 (6-12h, 2-10 文件)
|
||||
加载: + workflows + 6 skills (~540L)
|
||||
阶段与自动 Skills:
|
||||
R₀b: **brainstorm** → spec + design.md → cunzhi [DESIGN_DIRECTION]
|
||||
R: augment-context/deepwiki → **context7** → 更新 design.md
|
||||
D: **context7** 查 API → design.md 终稿 → cunzhi [DESIGN_READY]
|
||||
P: **plan-first** + /plan 原生 → plan.md → cunzhi [PLAN_CONFIRMED]
|
||||
E: **tdd**(L2, 强制 RED→GREEN) → doing.md 看板
|
||||
T: **verification** + **code-review** + /review 原生 → verified.md
|
||||
V: Kaizen 复盘 → cunzhi [DELIVERY_CONFIRMED]
|
||||
|
||||
## Path C — 系统开发 (1-3 天, 10-50 文件)
|
||||
加载: + agent-teams + e2e-testing (~700L)
|
||||
同 Path B + :
|
||||
E: **agent-teams** 并行 (多代理协作, [agents] 角色)
|
||||
T: + **e2e-testing** → cunzhi [TESTS_PASSED]
|
||||
V: 按功能分 commit + **kaizen**
|
||||
|
||||
## Path D — 企业级 (1周+, 50+ 文件)
|
||||
同 Path C + :
|
||||
T: + security-review → cunzhi [SECURITY_PASSED]
|
||||
V: 分 PR 交付, 每个 PR 独立审查 + **kaizen**
|
||||
Profile: `codex --profile review` 用于最终审查
|
||||
|
||||
## 路径选择规则
|
||||
1. 默认 Path A, 除非满足升级条件
|
||||
2. 用户明确说 "简单修一下" → 不要升级到 B
|
||||
3. 不确定 → 问用户确认复杂度
|
||||
选定路径后 → 读 riper-7.md 执行对应阶段。
|
||||
Path A 跳过 R₀/R/D/P, 直接 E→T。
|
||||
|
||||
+49
-58
@@ -1,66 +1,57 @@
|
||||
# RIPER-7 阶段编排 (v9.1.0)
|
||||
# RIPER-7 阶段编排 v9.2.0
|
||||
|
||||
## 阶段流: R₀ → R → D → P → E → T → V
|
||||
## 每阶段进入前 (通用)
|
||||
1. 这一步要解决的核心问题是什么?
|
||||
2. 项目里有没有类似实现? → 搜索相关代码
|
||||
3. 用到的库 API 确定吗? → context7 skill 查文档
|
||||
4. .ai_state/lessons.md + conventions.md 有相关经验吗?
|
||||
|
||||
### R₀ (预研/头脑风暴, Path B+ 独有)
|
||||
触发: 用户提交需求且 PACE≥B
|
||||
**自动加载**: brainstorm skill
|
||||
工具: augment-context + cunzhi
|
||||
输入: 用户需求
|
||||
输出: .ai_state/design.md (含 spec 需求模板 + 方案草案)
|
||||
检查点: cunzhi [DESIGN_DIRECTION]
|
||||
---
|
||||
|
||||
### R (研究)
|
||||
触发: R₀ 确认后 或 Path A 直接进入
|
||||
**自动加载**: context7 skill
|
||||
工具: augment-context + deepwiki + web search
|
||||
输入: design.md 或 用户需求
|
||||
输出: 更新 design.md (技术细节)
|
||||
## R₀ 需求精炼 (Path B+)
|
||||
**技能**: brainstorm skill (含步骤0自主调研)
|
||||
**产出**: .ai_state/design.md (Spec: MUST/SHOULD/COULD + 验收标准)
|
||||
**门控**: cunzhi `DESIGN_READY` (cunzhi 不可用时: 直接输出 "[DESIGN_READY] 请确认" 等用户回复)
|
||||
|
||||
### D (设计, Path B+ 独有)
|
||||
触发: R 完成
|
||||
**自动加载**: context7 skill
|
||||
输入: design.md
|
||||
输出: design.md 终稿
|
||||
检查点: cunzhi [DESIGN_READY]
|
||||
## R 技术调研 (Path B+)
|
||||
读 design.md → 搜索相关代码 + 查库文档
|
||||
产出: design.md 追加技术方案
|
||||
|
||||
### P (规划, Path B+ 独有)
|
||||
触发: D 确认后
|
||||
**自动加载**: plan-first skill + /plan 原生规划
|
||||
输入: design.md
|
||||
输出: .ai_state/plan.md
|
||||
检查点: cunzhi [PLAN_CONFIRMED]
|
||||
## D 方案定稿 (Path B+)
|
||||
读 design.md → 检查接口最小化? 错误处理完整? 更简单的方案?
|
||||
产出: design.md 最终版
|
||||
门控: cunzhi `DESIGN_FINALIZED` (cunzhi 不可用时: 直接输出确认提示)
|
||||
|
||||
### E (执行)
|
||||
触发: P 确认后 或 Path A R 完成
|
||||
**自动加载**: tdd skill (强制模式) + agent-teams (Path C+)
|
||||
铁律: **先写测试, 再写实现**
|
||||
过程:
|
||||
- Path A: 直接开发, 功能验证
|
||||
- Path B: tdd L2 (RED→GREEN→REFACTOR), doing.md 看板
|
||||
- Path C/D: agent-teams 多代理并行
|
||||
输出: .ai_state/doing.md, 代码变更
|
||||
## P 计划 (Path B+)
|
||||
技能: plan-first skill → 生成 plan.md
|
||||
**计划审查**: 用 /review 内置功能审查, 或用 validator agent
|
||||
门控: cunzhi `PLAN_CONFIRMED` (cunzhi 不可用时: 直接输出确认提示)
|
||||
|
||||
### T (测试/验证)
|
||||
触发: E 完成
|
||||
**自动加载**: verification + code-review skills
|
||||
工具: /review 原生代码审查
|
||||
过程:
|
||||
- Path A: 功能验证 + lint
|
||||
- Path B: verification + code-review → verified.md
|
||||
- Path C/D: + e2e-testing + security-review
|
||||
输出: .ai_state/verified.md
|
||||
检查点: cunzhi [TESTS_PASSED]
|
||||
## E 执行 (Path B+) — Sisyphus 循环
|
||||
对 plan.md 每个 Task:
|
||||
1. 读 Task + 相关文件 + conventions.md
|
||||
2. TDD: 先写测试 → 实现 → 重构
|
||||
2.5. **Reflexion** (自我反思 → reflexion skill):
|
||||
"这个实现有没有: 走捷径/忽略边界/硬编码/过度工程/偏离 spec?"
|
||||
发现问题 → 立即修复
|
||||
值得记录 → lessons.md
|
||||
3. **Micro-review**: 对标 design.md spec + conventions.md
|
||||
通过 → [x] Task + commit
|
||||
不通过 → 修复
|
||||
**铁律**: plan.md 有任何 [ ] 未完成, 不停止。
|
||||
|
||||
### V (验收/交付)
|
||||
触发: T 通过
|
||||
过程:
|
||||
1. 验证: plan 无未完成项 + 测试通过
|
||||
2. cunzhi [DELIVERY_CONFIRMED] 用户确认
|
||||
3. **Kaizen 复盘** (必须):
|
||||
a. git diff --stat 分析变更范围
|
||||
b. 提炼经验 → .ai_state/knowledge.md
|
||||
c. 记录陷阱 → .ai_state/lessons.md
|
||||
d. 更新 conventions.md (如有新规范)
|
||||
4. 归档 → .ai_state/archive.md
|
||||
输出: 交付完成 + 经验沉淀
|
||||
## T 测试/审查 (Path B+)
|
||||
1. verification skill: 跑测试 + 覆盖率
|
||||
1.5. **验收标准确认**:
|
||||
读 design.md "## 验收标准" → 逐条确认是否满足
|
||||
未满足 → 标注到 quality.md
|
||||
2. code-review skill: 代码审查
|
||||
3. 用 /review 内置审查功能 做代码审查
|
||||
4. 综合 → quality.md
|
||||
5. Quality Gate: PASS(exit 0) / CONCERNS(exit 0+warn) / REWORK(exit 2) / FAIL(exit 2)
|
||||
|
||||
## V 归档 (Path B+)
|
||||
1. kaizen skill: 回顾 + lessons.md
|
||||
1.5. **分支收尾** (finish-branch skill):
|
||||
选项: PR description / keep / discard (Codex 不直接 merge)
|
||||
2. cunzhi `DELIVERY_COMPLETE` (cunzhi 不可用时: 直接输出确认提示)
|
||||
|
||||
@@ -5,6 +5,7 @@
|
||||
<link rel="icon" href="/favicon.svg" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<meta name="color-scheme" content="light dark" />
|
||||
<meta name="author" content="https://blog.xlsea.cn" />
|
||||
<title>%VITE_APP_TITLE%</title>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
@@ -44,6 +44,7 @@
|
||||
"commit:zh": "sa git-commit -l=zh-cn",
|
||||
"dev": "vite --mode dev",
|
||||
"dev:prod": "vite --mode prod",
|
||||
"dev:test": "vite --mode test",
|
||||
"fmt": "oxfmt",
|
||||
"gen-route": "sa gen-route",
|
||||
"lint": "oxlint --fix && eslint --fix .",
|
||||
|
||||
Reference in New Issue
Block a user