docs(zh-CN): translate code block(plain text) (#753)

Co-authored-by: neo <neo.dowithless@gmail.com>
This commit is contained in:
zdoc.app
2026-03-23 06:39:24 +08:00
committed by GitHub
parent fd2a8edb53
commit 4f6f587700
118 changed files with 1807 additions and 1835 deletions

View File

@@ -146,14 +146,14 @@
## 项目结构
```
agents/ — 28 specialized subagents
skills/ — 115 workflow skills and domain knowledge
commands/ — 59 slash commands
hooks/ — Trigger-based automations
rules/ — Always-follow guidelines (common + per-language)
scripts/ — Cross-platform Node.js utilities
mcp-configs/ — 14 MCP server configurations
tests/ — Test suite
agents/ — 28 个专业子代理
skills/ — 115 个工作流技能和领域知识
commands/ — 59 个斜杠命令
hooks/ — 基于触发的自动化
rules/ — 始终遵循的指导方针(通用 + 每种语言)
scripts/ — 跨平台 Node.js 实用工具
mcp-configs/ — 14 MCP 服务器配置
tests/ — 测试套件
```
## 成功指标

View File

@@ -390,11 +390,11 @@ ECC 为其他平台提供了技能子集:
### 1. PR 标题格式
```
feat(skills): add rust-patterns skill
feat(agents): add api-designer agent
feat(hooks): add auto-format hook
fix(skills): update React patterns
docs: improve contributing guide
feat(skills): 新增 Rust 模式技能
feat(agents): 新增 API 设计器代理
feat(hooks): 新增自动格式化钩子
fix(skills): 更新 React 模式
docs: 完善贡献指南
```
### 2. PR 描述

View File

@@ -567,7 +567,7 @@ claude --version
Claude Code v2.1+ **会自动加载** 任何已安装插件中的 `hooks/hooks.json`(按约定)。在 `plugin.json` 中显式声明会导致重复检测错误:
```
Duplicate hooks file detected: ./hooks/hooks.json resolves to already-loaded file
重复的钩子文件检测到:./hooks/hooks.json 解析到已加载的文件
```
**历史背景:** 这已导致此仓库中多次修复/还原循环([#29](https://github.com/affaan-m/everything-claude-code/issues/29), [#52](https://github.com/affaan-m/everything-claude-code/issues/52), [#103](https://github.com/affaan-m/everything-claude-code/issues/103)。Claude Code 版本之间的行为发生了变化,导致了混淆。我们现在有一个回归测试来防止这种情况再次发生。
@@ -726,12 +726,12 @@ model: opus
```
rules/
common/ # Universal principles (always install)
typescript/ # TS/JS specific patterns and tools
python/ # Python specific patterns and tools
golang/ # Go specific patterns and tools
swift/ # Swift specific patterns and tools
php/ # PHP specific patterns and tools
common/ # 通用原则(始终安装)
typescript/ # TS/JS 特定模式与工具
python/ # Python 特定模式与工具
golang/ # Go 特定模式与工具
swift/ # Swift 特定模式与工具
php/ # PHP 特定模式与工具
```
有关安装和结构详情,请参阅 [`rules/README.md`](rules/README.md)。
@@ -763,26 +763,26 @@ rules/
**开始新功能:**
```
/everything-claude-code:plan "Add user authentication with OAuth"
planner creates implementation blueprint
/tdd → tdd-guide enforces write-tests-first
/code-review → code-reviewer checks your work
/everything-claude-code:plan "使用 OAuth 添加用户身份验证"
规划器创建实现蓝图
/tdd → tdd-guide 强制执行先写测试
/code-review → 代码审查员检查你的工作
```
**修复错误:**
```
/tdd → tdd-guide: write a failing test that reproduces it
implement the fix, verify test passes
/code-review → code-reviewer: catch regressions
/tdd → tdd-guide:编写一个能复现问题的失败测试
实现修复,验证测试通过
/code-review → code-reviewer:捕捉回归问题
```
**准备生产环境:**
```
/security-scan → security-reviewer: OWASP Top 10 audit
/e2e → e2e-runner: critical user flow tests
/test-coverage → verify 80%+ coverage
/security-scan → security-reviewer: OWASP Top 10 审计
/e2e → e2e-runner: 关键用户流程测试
/test-coverage → verify 80%+ 覆盖率
```
***
@@ -970,7 +970,7 @@ Cursor 的**钩子事件比 Claude Code 多**20 对 8。`.cursor/hooks/ada
```
Cursor stdin JSON → adapter.js → transforms → scripts/hooks/*.js
(shared with Claude Code)
( Claude Code 共享)
```
关键钩子:

View File

@@ -64,7 +64,7 @@ gog calendar events --today --all --max 30
```
```text
# Slack (via MCP)
# Slack(通过 MCP
conversations_search_messages(search_query: "YOUR_NAME", filter_date_during: "Today")
channels_list(channel_types: "im,mpim") → conversations_history(limit: "4h")
```
@@ -109,26 +109,26 @@ channels_list(channel_types: "im,mpim") → conversations_history(limit: "4h")
## 简报输出格式
```
# Today's Briefing — [Date]
# 今日简报 — [日期]
## Schedule (N)
| Time | Event | Location | Prep? |
## 日程安排 (N)
| 时间 | 事项 | 地点 | 准备? |
|------|-------|----------|-------|
## Email — Skipped (N) → auto-archived
## Email — Action Required (N)
### 1. Sender <email>
**Subject**: ...
**Summary**: ...
**Draft reply**: ...
→ [Send] [Edit] [Skip]
## 邮件 — 已跳过 (N) → 自动归档
## 邮件 — 需处理 (N)
### 1. 发件人 <邮箱>
**主题**: ...
**摘要**: ...
**回复草稿**: ...
→ [发送] [编辑] [跳过]
## Slack — Action Required (N)
## LINE — Action Required (N)
## Slack — 需处理 (N)
## LINE — 需处理 (N)
## Triage Queue
- Stale pending responses: N
- Overdue tasks: N
## 待处理队列
- 待回复超时事项: N
- 逾期任务: N
```
## 关键设计原则

View File

@@ -178,13 +178,13 @@ const usersWithPosts = await db.query(`
按严重程度组织发现的问题。对于每个问题:
```
[CRITICAL] Hardcoded API key in source
File: src/api/client.ts:42
Issue: API key "sk-abc..." exposed in source code. This will be committed to git history.
Fix: Move to environment variable and add to .gitignore/.env.example
[严重] 源代码中存在硬编码的API密钥
文件: src/api/client.ts:42
问题: API密钥 "sk-abc..." 在源代码中暴露。这将提交到git历史记录中。
修复: 移至环境变量并添加到 .gitignore/.env.example
const apiKey = "sk-abc123"; // BAD
const apiKey = process.env.API_KEY; // GOOD
const apiKey = "sk-abc123"; // 错误做法
const apiKey = process.env.API_KEY; // 正确做法
```
### 摘要格式
@@ -192,16 +192,16 @@ Fix: Move to environment variable and add to .gitignore/.env.example
每次审查结束时使用:
```
## Review Summary
## 审查摘要
| Severity | Count | Status |
| 严重程度 | 数量 | 状态 |
|----------|-------|--------|
| CRITICAL | 0 | pass |
| HIGH | 2 | warn |
| MEDIUM | 3 | info |
| LOW | 1 | note |
| CRITICAL | 0 | 通过 |
| HIGH | 2 | 警告 |
| MEDIUM | 3 | 信息 |
| LOW | 1 | 备注 |
Verdict: WARNING — 2 HIGH issues should be resolved before merge.
裁决:警告 — 2 HIGH 级别问题应在合并前解决。
```
## 批准标准

View File

@@ -31,11 +31,11 @@ cppcheck --enable=all src/ 2>/dev/null || echo "cppcheck not available"
## 解决工作流程
```text
1. cmake --build build -> Parse error message
2. Read affected file -> Understand context
3. Apply minimal fix -> Only what's needed
4. cmake --build build -> Verify fix
5. ctest --test-dir build -> Ensure nothing broke
1. cmake --build build -> 解析错误信息
2. 读取受影响的文件 -> 理解上下文
3. 应用最小修复 -> 仅修复必需部分
4. cmake --build build -> 验证修复
5. ctest --test-dir build -> 确保未破坏其他功能
```
## 常见修复模式
@@ -80,10 +80,10 @@ cmake --build build --clean-first
## 输出格式
```text
[FIXED] src/handler/user.cpp:42
Error: undefined reference to `UserService::create`
Fix: Added missing method implementation in user_service.cpp
Remaining errors: 3
[已修复] src/handler/user.cpp:42
错误:未定义的引用 `UserService::create`
修复:在 user_service.cpp 中添加了缺失的方法实现
剩余错误:3
```
最终:`Build Status: SUCCESS/FAILED | Errors Fixed: N | Files Modified: list`

View File

@@ -44,12 +44,12 @@ npx jsdoc2md src/**/*.ts # Extract JSDoc
```
docs/CODEMAPS/
├── INDEX.md # Overview of all areas
├── frontend.md # Frontend structure
├── backend.md # Backend/API structure
├── database.md # Database schema
├── integrations.md # External services
└── workers.md # Background jobs
├── INDEX.md # 所有区域概览
├── frontend.md # 前端结构
├── backend.md # 后端/API 结构
├── database.md # 数据库模式
├── integrations.md # 外部服务
└── workers.md # 后台任务
```
### 4. 代码映射格式

View File

@@ -214,15 +214,15 @@ model: sonnet
## 输出格式
```
[CRITICAL] Domain layer imports Flutter framework
File: packages/domain/lib/src/usecases/user_usecase.dart:3
Issue: `import 'package:flutter/material.dart'` — domain must be pure Dart.
Fix: Move widget-dependent logic to presentation layer.
[CRITICAL] 领域层导入了 Flutter 框架
文件: packages/domain/lib/src/usecases/user_usecase.dart:3
问题: `import 'package:flutter/material.dart'` — 领域层必须是纯 Dart
修复: 将依赖于 widget 的逻辑移至表示层。
[HIGH] State consumer wraps entire screen
File: lib/features/cart/presentation/cart_page.dart:42
Issue: Consumer rebuilds entire page on every state change.
Fix: Narrow scope to the subtree that depends on changed state, or use a selector.
[HIGH] 状态消费者包裹了整个屏幕
文件: lib/features/cart/presentation/cart_page.dart:42
问题: 每次状态变化时Consumer 都会重建整个页面。
修复: 将范围缩小到依赖于已更改状态的子树,或使用选择器。
```
## 总结格式
@@ -230,16 +230,16 @@ Fix: Narrow scope to the subtree that depends on changed state, or use a selecto
每次评审结束时附上:
```
## Review Summary
## 审查摘要
| Severity | Count | Status |
|----------|-------|--------|
| CRITICAL | 0 | pass |
| HIGH | 1 | block |
| MEDIUM | 2 | info |
| LOW | 0 | note |
| 严重性 | 数量 | 状态 |
|--------|------|----------|
| 严重 | 0 | 通过 |
| | 1 | 阻塞 |
| | 2 | 信息提示 |
| | 0 | 备注 |
Verdict: BLOCK — HIGH issues must be fixed before merge.
裁决:阻塞 — 必须修复高严重性问题后方可合并。
```
## 批准标准

View File

@@ -33,12 +33,12 @@ go mod tidy -v
## 解决工作流
```text
1. go build ./... -> Parse error message
2. Read affected file -> Understand context
3. Apply minimal fix -> Only what's needed
4. go build ./... -> Verify fix
5. go vet ./... -> Check for warnings
6. go test ./... -> Ensure nothing broke
1. go build ./... -> 解析错误信息
2. 读取受影响文件 -> 理解上下文
3. 应用最小化修复 -> 仅修复必要部分
4. go build ./... -> 验证修复
5. go vet ./... -> 检查警告
6. go test ./... -> 确保未破坏原有功能
```
## 常见修复模式
@@ -84,10 +84,10 @@ go clean -modcache && go mod download # Fix checksum issues
## 输出格式
```text
[FIXED] internal/handler/user.go:42
Error: undefined: UserService
Fix: Added import "project/internal/service"
Remaining errors: 3
[已修复] internal/handler/user.go:42
错误:未定义:UserService
修复:添加了导入 "project/internal/service"
剩余错误:3
```
最终:`Build Status: SUCCESS/FAILED | Errors Fixed: N | Files Modified: list`

View File

@@ -36,11 +36,11 @@ model: sonnet
## 解决工作流
```text
1. ./mvnw compile OR ./gradlew build -> Parse error message
2. Read affected file -> Understand context
3. Apply minimal fix -> Only what's needed
4. ./mvnw compile OR ./gradlew build -> Verify fix
5. ./mvnw test OR ./gradlew test -> Ensure nothing broke
1. ./mvnw compile ./gradlew build -> 解析错误信息
2. 读取受影响的文件 -> 理解上下文
3. 应用最小修复 -> 仅处理必需项
4. ./mvnw compile ./gradlew build -> 验证修复
5. ./mvnw test ./gradlew test -> 确保未破坏其他功能
```
## 常见修复模式
@@ -143,10 +143,10 @@ grep -A5 "annotationProcessorPaths\|annotationProcessor" pom.xml build.gradle
## 输出格式
```text
[FIXED] src/main/java/com/example/service/PaymentService.java:87
Error: cannot find symbol — symbol: class IdempotencyKey
Fix: Added import com.example.domain.IdempotencyKey
Remaining errors: 1
[已修复] src/main/java/com/example/service/PaymentService.java:87
错误: 找不到符号 — 符号: 类 IdempotencyKey
修复: 添加了 import com.example.domain.IdempotencyKey
剩余错误: 1
```
最终:`Build Status: SUCCESS/FAILED | Errors Fixed: N | Files Modified: list`

View File

@@ -31,11 +31,11 @@ model: sonnet
## 解决工作流
```text
1. ./gradlew build -> Parse error message
2. Read affected file -> Understand context
3. Apply minimal fix -> Only what's needed
4. ./gradlew build -> Verify fix
5. ./gradlew test -> Ensure nothing broke
1. ./gradlew build -> 解析错误信息
2. 读取受影响的文件 -> 理解上下文
3. 应用最小修复 -> 仅解决必要问题
4. ./gradlew build -> 验证修复
5. ./gradlew test -> 确保无新增问题
```
## 常见修复模式
@@ -108,10 +108,10 @@ kotlin {
## 输出格式
```text
[FIXED] src/main/kotlin/com/example/service/UserService.kt:42
Error: Unresolved reference: UserRepository
Fix: Added import com.example.repository.UserRepository
Remaining errors: 2
[已修复] src/main/kotlin/com/example/service/UserService.kt:42
错误:未解析的引用:UserRepository
修复:已添加导入 com.example.repository.UserRepository
剩余错误:2
```
最终:`Build Status: SUCCESS/FAILED | Errors Fixed: N | Files Modified: list`

View File

@@ -127,15 +127,15 @@ Button(onClick = onClick)
## 输出格式
```
[CRITICAL] Domain module imports Android framework
File: domain/src/main/kotlin/com/app/domain/UserUseCase.kt:3
Issue: `import android.content.Context` — domain must be pure Kotlin with no framework dependencies.
Fix: Move Context-dependent logic to data or platforms layer. Pass data via repository interface.
[CRITICAL] Domain 模块导入了 Android 框架
文件: domain/src/main/kotlin/com/app/domain/UserUseCase.kt:3
问题: `import android.content.Context` — domain 层必须是纯 Kotlin不能有框架依赖。
修复: 将依赖 Context 的逻辑移到 data 层或 platforms 层。通过 repository 接口传递数据。
[HIGH] StateFlow holding mutable list
File: presentation/src/main/kotlin/com/app/ui/ListViewModel.kt:25
Issue: `_state.value.items.add(newItem)` mutates the list inside StateFlow — Compose won't detect the change.
Fix: Use `_state.update { it.copy(items = it.items + newItem) }`
[HIGH] StateFlow 持有可变列表
文件: presentation/src/main/kotlin/com/app/ui/ListViewModel.kt:25
问题: `_state.value.items.add(newItem)` StateFlow 内部修改了列表 — Compose 将无法检测到此更改。
修复: 使用 `_state.update { it.copy(items = it.items + newItem) }`
```
## 摘要格式
@@ -143,16 +143,16 @@ Fix: Use `_state.update { it.copy(items = it.items + newItem) }`
每次审查结束时附上:
```
## Review Summary
## 审查摘要
| Severity | Count | Status |
| 严重程度 | 数量 | 状态 |
|----------|-------|--------|
| CRITICAL | 0 | pass |
| HIGH | 1 | block |
| MEDIUM | 2 | info |
| LOW | 0 | note |
| CRITICAL | 0 | 通过 |
| HIGH | 1 | 阻止 |
| MEDIUM | 2 | 信息 |
| LOW | 0 | 备注 |
Verdict: BLOCK — HIGH issues must be fixed before merge.
裁决:阻止 — 必须修复 HIGH 级别问题后方可合并。
```
## 批准标准

View File

@@ -79,10 +79,10 @@ pytest --cov=app --cov-report=term-missing # Test coverage
## 审查输出格式
```text
[SEVERITY] Issue title
File: path/to/file.py:42
Issue: Description
Fix: What to change
[严重性] 问题标题
文件:path/to/file.py:42
问题:描述
修复:修改内容
```
## 批准标准

View File

@@ -33,12 +33,12 @@ python -c "import torch; x = torch.randn(2,3).cuda(); print('CUDA tensor test: O
## 解决工作流
```text
1. Read error traceback -> Identify failing line and error type
2. Read affected file -> Understand model/training context
3. Trace tensor shapes -> Print shapes at key points
4. Apply minimal fix -> Only what's needed
5. Run failing script -> Verify fix
6. Check gradients flow -> Ensure backward pass works
1. 阅读错误回溯 -> 定位失败行和错误类型
2. 阅读受影响文件 -> 理解模型/训练上下文
3. 追踪张量形状 -> 在关键点打印形状
4. 应用最小修复 -> 仅修改必要部分
5. 运行失败脚本 -> 验证修复
6. 检查梯度流动 -> 确保反向传播正常工作
```
## 常见修复模式
@@ -109,10 +109,10 @@ print(f'Max allocated: {torch.cuda.max_memory_allocated()/1e9:.2f} GB')
## 输出格式
```text
[FIXED] train.py:42
Error: RuntimeError: mat1 and mat2 shapes cannot be multiplied (32x512 and 256x10)
Fix: Changed nn.Linear(256, 10) to nn.Linear(512, 10) to match encoder output
Remaining errors: 0
[已修复] train.py:42
错误:RuntimeError:无法相乘 mat1 mat2 的形状(32x512 256x10
修复:将 nn.Linear(256, 10) 更改为 nn.Linear(512, 10) 以匹配编码器输出
剩余错误:0
```
最终:`Status: SUCCESS/FAILED | Errors Fixed: N | Files Modified: list`

View File

@@ -32,12 +32,12 @@ if command -v cargo-audit >/dev/null; then cargo audit; else echo "cargo-audit n
## 解决工作流
```text
1. cargo check -> Parse error message and error code
2. Read affected file -> Understand ownership and lifetime context
3. Apply minimal fix -> Only what's needed
4. cargo check -> Verify fix
5. cargo clippy -> Check for warnings
6. cargo test -> Ensure nothing broke
1. cargo check -> 解析错误信息和错误代码
2. 读取受影响的文件 -> 理解所有权和生命周期的上下文
3. 应用最小修复 -> 仅做必要的修改
4. cargo check -> 验证修复
5. cargo clippy -> 检查警告
6. cargo test -> 确保没有破坏原有功能
```
## 常见修复模式
@@ -138,10 +138,10 @@ grep "rust-version" Cargo.toml
## 输出格式
```text
[FIXED] src/handler/user.rs:42
Error: E0502 — cannot borrow `map` as mutable because it is also borrowed as immutable
Fix: Cloned value from immutable borrow before mutable insert
Remaining errors: 3
[已修复] src/handler/user.rs:42
错误: E0502 — 无法以可变方式借用 `map`,因为它同时也被不可变借用
修复: 在可变插入前从不可变借用克隆值
剩余错误: 3
```
最终:`Build Status: SUCCESS/FAILED | Errors Fixed: N | Files Modified: list`

View File

@@ -35,12 +35,12 @@ echo "$(date +%Y-%m-%d-%H:%M) | $CHECKPOINT_NAME | $(git rev-parse --short HEAD)
3. 报告:
```
CHECKPOINT COMPARISON: $NAME
检查点对比:$NAME
============================
Files changed: X
Tests: +Y passed / -Z failed
Coverage: +X% / -Y%
Build: [PASS/FAIL]
文件更改数:X
测试结果:通过数 +Y / 失败数 -Z
覆盖率:+X% / -Y%
构建状态:[通过/失败]
```
## 列出检查点

View File

@@ -29,18 +29,18 @@ npm run claw
## REPL 命令
```text
/help Show help
/clear Clear current session history
/history Print full conversation history
/sessions List saved sessions
/model [name] Show/set model
/load <skill-name> Hot-load a skill into context
/branch <session-name> Branch current session
/search <query> Search query across sessions
/compact Compact old turns, keep recent context
/export <md|json|txt> [path] Export session
/metrics Show session metrics
exit Quit
/help 显示帮助信息
/clear 清除当前会话历史
/history 打印完整对话历史
/sessions 列出已保存的会话
/model [name] 显示/设置模型
/load <skill-name> 热加载技能到上下文
/branch <session-name> 分支当前会话
/search <query> 跨会话搜索查询
/compact 压缩旧轮次,保留近期上下文
/export <md|json|txt> [path] 导出会话
/metrics 显示会话指标
exit 退出
```
## 说明

View File

@@ -41,18 +41,16 @@ cppcheck --enable=all src/
## 示例会话
````text
User: /cpp-build
# C++ 构建问题解决
Agent:
# C++ Build Resolution
## Initial Diagnostics
## 初始诊断
```bash
$ cmake --build build
src/service/user.cpp:25:15: error: use of undeclared identifier 'UserRepository'
src/handler/api.cpp:42:9: error: no matching function for call to 'process'
src/handler/api.cpp:58:1: error: non-void function does not return a value
````
发现的错误3
@@ -133,45 +131,43 @@ All tests passed.
构建状态:✅ 成功
```
## 常见错误修复
## Common Errors Fixed
| Error | Typical Fix |
| 错误 | 典型修复方法 |
|-------|-------------|
| `undeclared identifier` | Add `#include` or fix typo |
| `no matching function` | Fix argument types or add overload |
| `undefined reference` | Link library or add implementation |
| `multiple definition` | Use `inline` or move to .cpp |
| `incomplete type` | Replace forward decl with `#include` |
| `no member named X` | Fix member name or include |
| `cannot convert X to Y` | Add appropriate cast |
| `CMake Error` | Fix CMakeLists.txt configuration |
| `undeclared identifier` | 添加 `#include` 或修正拼写错误 |
| `no matching function` | 修正参数类型或添加重载函数 |
| `undefined reference` | 链接库或添加实现 |
| `multiple definition` | 使用 `inline` 或移至 .cpp 文件 |
| `incomplete type` | 将前向声明替换为 `#include` |
| `no member named X` | 修正成员名称或包含头文件 |
| `cannot convert X to Y` | 添加适当的类型转换 |
| `CMake Error` | 修正 CMakeLists.txt 配置 |
## Fix Strategy
## 修复策略
1. **Compilation errors first** - Code must compile
2. **Linker errors second** - Resolve undefined references
3. **Warnings third** - Fix with `-Wall -Wextra`
4. **One fix at a time** - Verify each change
5. **Minimal changes** - Don't refactor, just fix
1. **优先处理编译错误** - 代码必须能够编译
2. **其次处理链接器错误** - 解决未定义引用
3. **第三处理警告** - 使用 `-Wall -Wextra` 进行修复
4. **一次只修复一个问题** - 验证每个更改
5. **最小化改动** - 仅修复问题,不重构代码
## Stop Conditions
## 停止条件
The agent will stop and report if:
- Same error persists after 3 attempts
- Fix introduces more errors
- Requires architectural changes
- Missing external dependencies
在以下情况下,代理将停止并报告:
- 同一错误经过 3 次尝试后仍然存在
- 修复引入了更多错误
- 需要架构性更改
- 缺少外部依赖项
## Related Commands
## 相关命令
- `/cpp-test` - Run tests after build succeeds
- `/cpp-review` - Review code quality
- `/verify` - Full verification loop
- `/cpp-test` - 构建成功后运行测试
- `/cpp-review` - 审查代码质量
- `/verify` - 完整验证循环
## Related
- Agent: `agents/cpp-build-resolver.md`
- Skill: `skills/cpp-coding-standards/`
## 相关
- 代理: `agents/cpp-build-resolver.md`
- 技能: `skills/cpp-coding-standards/`
```

View File

@@ -68,26 +68,23 @@ cmake --build build -- -Wall -Wextra -Wpedantic
## 使用示例
````text
User: /cpp-review
# C++ 代码审查报告
Agent:
# C++ Code Review Report
## 已审查文件
- src/handler/user.cpp (已修改)
- src/service/auth.cpp (已修改)
## Files Reviewed
- src/handler/user.cpp (modified)
- src/service/auth.cpp (modified)
## 静态分析结果
✓ clang-tidy: 2 个警告
✓ cppcheck: 无问题
## Static Analysis Results
✓ clang-tidy: 2 warnings
✓ cppcheck: No issues
## 发现的问题
## Issues Found
[CRITICAL] Memory Leak
File: src/service/auth.cpp:45
Issue: Raw `new` without matching `delete`
[严重] 内存泄漏
文件: src/service/auth.cpp:45
问题: 使用了原始的 `new` 而没有匹配的 `delete`
```cpp
auto* session = new Session(userId); // Memory leak!
auto* session = new Session(userId); // 内存泄漏!
cache[userId] = session;
````
@@ -121,25 +118,23 @@ void processUser(const User& user) {
建议:❌ 在严重问题修复前阻止合并
```
## 批准标准
## Approval Criteria
| Status | Condition |
| 状态 | 条件 |
|--------|-----------|
| ✅ Approve | No CRITICAL or HIGH issues |
| ⚠️ Warning | Only MEDIUM issues (merge with caution) |
| ❌ Block | CRITICAL or HIGH issues found |
| ✅ 批准 | 没有 CRITICAL HIGH 级别的问题 |
| ⚠️ 警告 | 仅有 MEDIUM 级别的问题(谨慎合并) |
| ❌ 阻止 | 发现 CRITICAL HIGH 级别的问题 |
## Integration with Other Commands
## 与其他命令的集成
- Use `/cpp-test` first to ensure tests pass
- Use `/cpp-build` if build errors occur
- Use `/cpp-review` before committing
- Use `/code-review` for non-C++ specific concerns
- 首先使用 `/cpp-test` 确保测试通过
- 如果出现构建错误,请使用 `/cpp-build`
- 在提交前使用 `/cpp-review`
- 对于非 C++ 特定的问题,请使用 `/code-review`
## Related
- Agent: `agents/cpp-reviewer.md`
- Skills: `skills/cpp-coding-standards/`, `skills/cpp-testing/`
## 相关
- 代理:`agents/cpp-reviewer.md`
- 技能:`skills/cpp-coding-standards/`, `skills/cpp-testing/`
```

View File

@@ -28,10 +28,10 @@ description: 为 C++ 强制执行 TDD 工作流程。先编写 GoogleTest 测试
## TDD 循环
```
RED → Write failing GoogleTest test
GREEN → Implement minimal code to pass
REFACTOR → Improve code, tests stay green
REPEAT → Next test case
RED → 编写失败的 GoogleTest 测试
GREEN → 实现最小化代码以通过测试
REFACTOR → 改进代码,测试保持通过
REPEAT → 下一个测试用例
```
## 示例会话

View File

@@ -11,14 +11,14 @@ description: 通过Claude DevFleet协调并行Claude Code代理——从自然
## 流程
```
User describes project
→ plan_project(prompt) → mission DAG with dependencies
Show plan, get approval
→ dispatch_mission(M1) → Agent spawns in worktree
→ M1 completes → auto-merge → M2 auto-dispatches (depends_on M1)
→ M2 completes → auto-merge
→ get_report(M2) → files_changed, what_done, errors, next_steps
Report summary to user
用户描述项目
→ plan_project(prompt) → 任务DAG与依赖关系
展示计划,获取批准
→ dispatch_mission(M1) → 代理在工作区中生成
→ M1完成 → 自动合并 → M2自动调度依赖于M1
→ M2完成 → 自动合并
→ get_report(M2) → 文件变更、完成内容、错误、后续步骤
向用户报告总结
```
## 工作流
@@ -26,7 +26,7 @@ User describes project
1. **根据用户描述规划项目**
```
mcp__devfleet__plan_project(prompt="<user's description>")
mcp__devfleet__plan_project(prompt="<用户描述>")
```
这将返回一个包含链式任务的项目。向用户展示:

View File

@@ -38,24 +38,24 @@ e2e-runner 代理将:
## 使用示例
````
User: /e2e Test the market search and view flow
用户:/e2e 测试市场搜索和查看流程
Agent (e2e-runner):
# E2E Test Generation: Market Search and View Flow
代理(e2e-runner
# E2E 测试生成:市场搜索和查看流程
## Test Scenario Identified
## 已识别测试场景
**User Journey:** Market Search → View Results → Click Market → View Details
**用户旅程:** 市场搜索 → 查看结果 → 点击市场 → 查看详情
**Test Coverage:**
1. Navigate to markets page
2. Perform semantic search
3. Verify search results
4. Click on first result
5. Verify market details page loads
6. Verify chart renders
**测试覆盖范围:**
1. 导航至市场页面
2. 执行语义搜索
3. 验证搜索结果
4. 点击第一个结果
5. 验证市场详情页面加载
6. 验证图表渲染
## Generated Test Code
## 生成的测试代码
```typescript
// tests/e2e/markets/search-and-view.spec.ts
@@ -155,6 +155,7 @@ test.describe('Market Search and View Flow', () => {
expect(finalCount).toBe(initialCount)
})
})
````
## 运行测试
@@ -181,55 +182,55 @@ Artifacts generated:
```
╔══════════════════════════════════════════════════════════════╗
║ E2E Test Results
║ E2E 测试结果
╠══════════════════════════════════════════════════════════════╣
Status: ✅ ALL TESTS PASSED
Total: 3 tests
Passed: 3 (100%) ║
Failed: 0 ║
Flaky: 0 ║
Duration: 9.1s ║
状态: ✅ 所有测试通过
总计: 3 项测试
通过: 3 (100%) ║
失败: 0 ║
不稳定: 0 ║
耗时: 9.1s ║
╚══════════════════════════════════════════════════════════════╝
Artifacts:
📸 Screenshots: 2 files
📹 Videos: 0 files (only on failure)
🔍 Traces: 0 files (only on failure)
📊 HTML Report: playwright-report/index.html
产物:
📸 截图: 2 个文件
📹 视频: 0 个文件(仅在失败时生成)
🔍 追踪文件: 0 个文件(仅在失败时生成)
📊 HTML 报告: playwright-report/index.html
View report: npx playwright show-report
查看报告: npx playwright show-report
```
✅ E2E 测试套件已准备好进行 CI/CD 集成!
````
## 测试产物
## Test Artifacts
当测试运行时,会捕获以下产物:
When tests run, the following artifacts are captured:
**所有测试:**
- 包含时间线和结果的 HTML 报告
- 用于 CI 集成的 JUnit XML 文件
**On All Tests:**
- HTML Report with timeline and results
- JUnit XML for CI integration
**仅在失败时:**
- 失败状态的截图
- 测试的视频录制
- 用于调试的追踪文件(逐步重放)
- 网络日志
- 控制台日志
**On Failure Only:**
- Screenshot of the failing state
- Video recording of the test
- Trace file for debugging (step-by-step replay)
- Network logs
- Console logs
## Viewing Artifacts
## 查看产物
```bash
# View HTML report in browser
# 在浏览器中查看 HTML 报告
npx playwright show-report
# View specific trace file
# 查看特定的追踪文件
npx playwright show-trace artifacts/trace-abc123.zip
# Screenshots are saved in artifacts/ directory
# 截图保存在 artifacts/ 目录中
open artifacts/search-results.png
````
## 不稳定测试检测
@@ -239,18 +240,18 @@ open artifacts/search-results.png
```
⚠️ FLAKY TEST DETECTED: tests/e2e/markets/trade.spec.ts
Test passed 7/10 runs (70% pass rate)
测试通过了 7/10 次运行 (70% 通过率)
Common failure:
"Timeout waiting for element '[data-testid="confirm-btn"]'"
常见失败原因:
"等待元素 '[data-testid="confirm-btn"]' 超时"
Recommended fixes:
1. Add explicit wait: await page.waitForSelector('[data-testid="confirm-btn"]')
2. Increase timeout: { timeout: 10000 }
3. Check for race conditions in component
4. Verify element is not hidden by animation
推荐修复方法:
1. 添加显式等待: await page.waitForSelector('[data-testid="confirm-btn"]')
2. 增加超时时间: { timeout: 10000 }
3. 检查组件中的竞争条件
4. 确认元素未被动画遮挡
Quarantine recommendation: Mark as test.fixme() until fixed
隔离建议: 在修复前标记为 test.fixme()
```
## 浏览器配置

View File

@@ -54,9 +54,9 @@
```
EVAL CHECK: feature-name
========================
Capability: X/Y passing
Regression: X/Y passing
Status: IN PROGRESS / READY
功能X/Y 通过
回归测试X/Y 通过
状态:进行中 / 就绪
```
## 报告评估
@@ -68,31 +68,31 @@ Status: IN PROGRESS / READY
```
EVAL REPORT: feature-name
=========================
Generated: $(date)
生成时间: $(date)
CAPABILITY EVALS
能力评估
----------------
[eval-1]: PASS (pass@1)
[eval-2]: PASS (pass@2) - required retry
[eval-3]: FAIL - see notes
[eval-1]: 通过 (pass@1)
[eval-2]: 通过 (pass@2) - 需要重试
[eval-3]: 失败 - 参见备注
REGRESSION EVALS
回归测试
----------------
[test-1]: PASS
[test-2]: PASS
[test-3]: PASS
[test-1]: 通过
[test-2]: 通过
[test-3]: 通过
METRICS
指标
-------
Capability pass@1: 67%
Capability pass@3: 100%
Regression pass^3: 100%
能力 pass@1: 67%
能力 pass@3: 100%
回归 pass^3: 100%
NOTES
备注
-----
[Any issues, edge cases, or observations]
[任何问题、边界情况或观察结果]
RECOMMENDATION
建议
--------------
[SHIP / NEEDS WORK / BLOCKED]
```
@@ -104,11 +104,11 @@ RECOMMENDATION
显示所有评估定义:
```
EVAL DEFINITIONS
功能模块定义
================
feature-auth [3/5 passing] IN PROGRESS
feature-search [5/5 passing] READY
feature-export [0/4 passing] NOT STARTED
feature-auth [3/5 通过] 进行中
feature-search [5/5 通过] 就绪
feature-export [0/4 通过] 未开始
```
## 参数

View File

@@ -29,8 +29,8 @@ python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py evolve [
## 使用方法
```
/evolve # Analyze all instincts and suggest evolutions
/evolve --generate # Also generate files under evolved/{skills,commands,agents}
/evolve # 分析所有本能并建议进化方向
/evolve --generate # 同时在 evolved/{skills,commands,agents} 目录下生成文件
```
## 演化规则
@@ -102,29 +102,29 @@ python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py evolve [
```
============================================================
EVOLVE ANALYSIS - 12 instincts
Project: my-app (a1b2c3d4e5f6)
Project-scoped: 8 | Global: 4
演进分析 - 12 种直觉
项目:my-app (a1b2c3d4e5f6)
项目范围8 | 全局:4
============================================================
High confidence instincts (>=80%): 5
高置信度直觉 (>=80%)5
## SKILL CANDIDATES
1. Cluster: "adding tests"
Instincts: 3
Avg confidence: 82%
Domains: testing
Scopes: project
## 技能候选
1. 聚类:"adding tests"
直觉:3
平均置信度:82%
领域:testing
范围:project
## COMMAND CANDIDATES (2)
## 命令候选 (2)
/adding-tests
From: test-first-workflow [project]
Confidence: 84%
来源:test-first-workflow [project]
置信度:84%
## AGENT CANDIDATES (1)
## 代理候选 (1)
adding-tests-agent
Covers 3 instincts
Avg confidence: 82%
涵盖 3 种直觉
平均置信度:82%
```
## 标志

View File

@@ -45,18 +45,16 @@ go mod tidy -v
## 示例会话
````text
User: /go-build
# Go Build 解析
Agent:
# Go Build Resolution
## Initial Diagnostics
## 初始诊断
```bash
$ go build ./...
internal/service/user.go:25:15: undefined: UserRepository
internal/handler/api.go:42:9: cannot use x (type string) as type int
internal/handler/api.go:58:2: missing return at end of function
````
发现错误3
@@ -144,44 +142,42 @@ ok project/internal/handler 0.023s
构建状态:✅ 成功
```
## 常见错误修复
## Common Errors Fixed
| Error | Typical Fix |
| 错误 | 典型修复 |
|-------|-------------|
| `undefined: X` | Add import or fix typo |
| `cannot use X as Y` | Type conversion or fix assignment |
| `missing return` | Add return statement |
| `X does not implement Y` | Add missing method |
| `import cycle` | Restructure packages |
| `declared but not used` | Remove or use variable |
| `cannot find package` | `go get` or `go mod tidy` |
| `undefined: X` | 添加导入或修正拼写错误 |
| `cannot use X as Y` | 类型转换或修正赋值 |
| `missing return` | 添加返回语句 |
| `X does not implement Y` | 添加缺失的方法 |
| `import cycle` | 重构包结构 |
| `declared but not used` | 移除或使用变量 |
| `cannot find package` | `go get` `go mod tidy` |
## Fix Strategy
## 修复策略
1. **Build errors first** - Code must compile
2. **Vet warnings second** - Fix suspicious constructs
3. **Lint warnings third** - Style and best practices
4. **One fix at a time** - Verify each change
5. **Minimal changes** - Don't refactor, just fix
1. **优先处理构建错误** - 代码必须能够编译
2. **其次处理 vet 警告** - 修复可疑结构
3. **再次处理 lint 警告** - 风格和最佳实践
4. **一次修复一个问题** - 验证每个更改
5. **最小化更改** - 不要重构,只修复
## Stop Conditions
## 停止条件
The agent will stop and report if:
- Same error persists after 3 attempts
- Fix introduces more errors
- Requires architectural changes
- Missing external dependencies
在以下情况下,代理将停止并报告:
- 相同错误经过 3 次尝试后仍然存在
- 修复引入了更多错误
- 需要架构性更改
- 缺少外部依赖
## Related Commands
## 相关命令
- `/go-test` - Run tests after build succeeds
- `/go-review` - Review code quality
- `/verify` - Full verification loop
- `/go-test` - 构建成功后运行测试
- `/go-review` - 审查代码质量
- `/verify` - 完整验证循环
## Related
- Agent: `agents/go-build-resolver.md`
- Skill: `skills/golang-patterns/`
## 相关
- 代理: `agents/go-build-resolver.md`
- 技能: `skills/golang-patterns/`
```

View File

@@ -73,29 +73,26 @@ govulncheck ./...
## 使用示例
````text
User: /go-review
# Go 代码审查报告
Agent:
# Go Code Review Report
## 已审查文件
- internal/handler/user.go已修改
- internal/service/auth.go已修改
## Files Reviewed
- internal/handler/user.go (modified)
- internal/service/auth.go (modified)
## 静态分析结果
✓ go vet: 无问题
✓ staticcheck: 无问题
## Static Analysis Results
✓ go vet: No issues
✓ staticcheck: No issues
## 发现的问题
## Issues Found
[CRITICAL] Race Condition
File: internal/service/auth.go:45
Issue: Shared map accessed without synchronization
[严重] 竞态条件
文件: internal/service/auth.go:45
问题: 共享映射访问未同步
```go
var cache = map[string]*Session{} // Concurrent access!
var cache = map[string]*Session{} // 并发访问!
func GetSession(id string) *Session {
return cache[id] // Race condition
return cache[id] // 竞态条件
}
````
@@ -137,25 +134,23 @@ return fmt.Errorf("get user %s: %w", userID, err)
建议:❌ 在严重问题修复前阻止合并
```
## 批准标准
## Approval Criteria
| Status | Condition |
| 状态 | 条件 |
|--------|-----------|
| ✅ Approve | No CRITICAL or HIGH issues |
| ⚠️ Warning | Only MEDIUM issues (merge with caution) |
| ❌ Block | CRITICAL or HIGH issues found |
| ✅ 批准 | CRITICAL HIGH 级别问题 |
| ⚠️ 警告 | 仅有 MEDIUM 级别问题 (谨慎合并) |
| ❌ 阻止 | 发现 CRITICAL HIGH 级别问题 |
## Integration with Other Commands
## 与其他命令的集成
- Use `/go-test` first to ensure tests pass
- Use `/go-build` if build errors occur
- Use `/go-review` before committing
- Use `/code-review` for non-Go specific concerns
- 首先使用 `/go-test` 确保测试通过
- 如果出现构建错误,请使用 `/go-build`
- 提交前使用 `/go-review`
- 对于非 Go 语言特定问题,请使用 `/code-review`
## Related
## 相关
- Agent: `agents/go-reviewer.md`
- Skills: `skills/golang-patterns/`, `skills/golang-testing/`
```

View File

@@ -28,34 +28,34 @@ description: 为Go强制执行TDD工作流程。首先编写表驱动测试
## TDD 循环
```
RED → Write failing table-driven test
GREEN → Implement minimal code to pass
REFACTOR → Improve code, tests stay green
REPEAT → Next test case
RED → 编写失败的表格驱动测试
GREEN → 实现最小化代码以通过测试
REFACTOR → 改进代码,保持测试通过
REPEAT → 下一个测试用例
```
## 示例会话
````
User: /go-test I need a function to validate email addresses
用户: /go-test 我需要一个验证电子邮箱地址的函数
Agent:
# TDD Session: Email Validator
代理:
# TDD 会话: 电子邮件验证器
## Step 1: Define Interface
## 步骤 1: 定义接口
```go
// validator/email.go
package validator
// ValidateEmail checks if the given string is a valid email address.
// Returns nil if valid, error describing the issue otherwise.
// ValidateEmail 检查给定的字符串是否为有效的电子邮件地址。
// 如果有效则返回 nil否则返回描述问题的错误。
func ValidateEmail(email string) error {
panic("not implemented")
}
```
## Step 2: Write Table-Driven Tests (RED)
## 步骤 2: 编写表驱动测试 (RED)
```go
// validator/email_test.go
@@ -71,13 +71,13 @@ func TestValidateEmail(t *testing.T) {
email string
wantErr bool
}{
// Valid emails
// 有效邮箱
{"simple email", "user@example.com", false},
{"with subdomain", "user@mail.example.com", false},
{"with plus", "user+tag@example.com", false},
{"with dots", "first.last@example.com", false},
// Invalid emails
// 无效邮箱
{"empty string", "", true},
{"no at sign", "userexample.com", true},
{"no domain", "user@", true},
@@ -101,7 +101,7 @@ func TestValidateEmail(t *testing.T) {
}
```
## Step 3: Run Tests - Verify FAIL
## 步骤 3: 运行测试 - 验证失败
```bash
$ go test ./validator/...
@@ -113,9 +113,9 @@ $ go test ./validator/...
FAIL
```
Tests fail as expected (panic).
测试按预期失败 (panic)
## Step 4: Implement Minimal Code (GREEN)
## 步骤 4: 实现最小化代码 (GREEN)
```go
// validator/email.go
@@ -144,7 +144,7 @@ func ValidateEmail(email string) error {
}
```
## Step 5: Run Tests - Verify PASS
## 步骤 5: 运行测试 - 验证通过
```bash
$ go test ./validator/...
@@ -153,9 +153,9 @@ PASS
ok project/validator 0.003s
```
All tests passing!
所有测试通过!
## Step 6: Check Coverage
## 步骤 6: 检查覆盖率
```bash
$ go test -cover ./validator/...
@@ -165,9 +165,9 @@ coverage: 100.0% of statements
ok project/validator 0.003s
```
Coverage: 100%
覆盖率: 100%
## TDD Complete!
## TDD 完成!
````
## 测试模式

View File

@@ -53,15 +53,15 @@ node scripts/harness-audit.js <scope> --format <text|json>
## 结果示例
```text
Harness Audit (repo): 66/70
- Tool Coverage: 10/10 (10/10 pts)
- Context Efficiency: 9/10 (9/10 pts)
- Quality Gates: 10/10 (10/10 pts)
Harness 审计 (代码库): 66/70
- 工具覆盖率: 10/10 (10/10 )
- 上下文效率: 9/10 (9/10 )
- 质量门禁: 10/10 (10/10 )
Top 3 Actions:
1) [Security Guardrails] Add prompt/tool preflight security guards in hooks/hooks.json. (hooks/hooks.json)
2) [Tool Coverage] Sync commands/harness-audit.md and .opencode/commands/harness-audit.md. (.opencode/commands/harness-audit.md)
3) [Eval Coverage] Increase automated test coverage across scripts/hooks/lib. (tests/)
首要三项行动:
1) [安全防护] 在 hooks/hooks.json 中添加提示/工具预检安全防护。 (hooks/hooks.json)
2) [工具覆盖率] 同步 commands/harness-audit.md .opencode/commands/harness-audit.md (.opencode/commands/harness-audit.md)
3) [评估覆盖率] 提升 scripts/hooks/lib 目录下的自动化测试覆盖率。 (tests/)
```
## 参数

View File

@@ -15,9 +15,9 @@ command: /instinct-export
## 用法
```
/instinct-export # Export all personal instincts
/instinct-export --domain testing # Export only testing instincts
/instinct-export --min-confidence 0.7 # Only export high-confidence instincts
/instinct-export # 导出所有个人本能
/instinct-export --domain testing # 仅导出测试相关本能
/instinct-export --min-confidence 0.7 # 仅导出高置信度本能
/instinct-export --output team-instincts.yaml
/instinct-export --scope project --output project-instincts.yaml
```

View File

@@ -44,33 +44,33 @@ python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py import <
## 导入过程
```
📥 Importing instincts from: team-instincts.yaml
📥 team-instincts.yaml 导入本能
================================================
Found 12 instincts to import.
发现 12 个待导入的本能。
Analyzing conflicts...
正在分析冲突...
## New Instincts (8)
These will be added:
✓ use-zod-validation (confidence: 0.7)
✓ prefer-named-exports (confidence: 0.65)
✓ test-async-functions (confidence: 0.8)
## 新本能 (8)
这些将被添加:
✓ use-zod-validation (置信度: 0.7)
✓ prefer-named-exports (置信度: 0.65)
✓ test-async-functions (置信度: 0.8)
...
## Duplicate Instincts (3)
Already have similar instincts:
## 重复本能 (3)
已存在类似本能:
⚠️ prefer-functional-style
Local: 0.8 confidence, 12 observations
Import: 0.7 confidence
Keep local (higher confidence)
本地: 0.8 置信度, 12 次观察
导入: 0.7 置信度
保留本地 (置信度更高)
⚠️ test-first-workflow
Local: 0.75 confidence
Import: 0.9 confidence
Update to import (higher confidence)
本地: 0.75 置信度
导入: 0.9 置信度
更新为导入 (置信度更高)
Import 8 new, update 1?
导入 8 个新的,更新 1 个?
```
## 合并行为
@@ -105,13 +105,13 @@ project_name: "my-project"
导入后:
```
Import complete!
导入完成!
Added: 8 instincts
Updated: 1 instinct
Skipped: 3 instincts (equal/higher confidence already exists)
新增8 项本能
更新1 项本能
跳过3 项本能(已存在同等或更高置信度的版本)
New instincts saved to: ~/.claude/homunculus/instincts/inherited/
新本能已保存至:~/.claude/homunculus/instincts/inherited/
Run /instinct-status to see all instincts.
运行 /instinct-status 以查看所有本能。
```

View File

@@ -40,20 +40,20 @@ python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py status
```
============================================================
INSTINCT STATUS - 12 total
INSTINCT 状态 - 总计 12
============================================================
Project: my-app (a1b2c3d4e5f6)
Project instincts: 8
Global instincts: 4
项目: my-app (a1b2c3d4e5f6)
项目 instincts: 8
全局 instincts: 4
## PROJECT-SCOPED (my-app)
### WORKFLOW (3)
## 项目范围内 (my-app)
### 工作流 (3)
███████░░░ 70% grep-before-edit [project]
trigger: when modifying code
触发条件: 当修改代码时
## GLOBAL (apply to all projects)
### SECURITY (2)
## 全局 (适用于所有项目)
### 安全 (2)
█████████░ 85% validate-user-input [global]
trigger: when handling user input
触发条件: 当处理用户输入时
```

View File

@@ -28,21 +28,21 @@ description: 为Kotlin强制执行TDD工作流程。首先编写Kotest测试
## TDD 循环
```
RED -> Write failing Kotest test
GREEN -> Implement minimal code to pass
REFACTOR -> Improve code, tests stay green
REPEAT -> Next test case
RED -> 编写失败的 Kotest 测试
GREEN -> 实现最小化代码以通过测试
REFACTOR -> 改进代码,测试保持通过状态
REPEAT -> 进入下一个测试用例
```
## 示例会话
````text
User: /kotlin-test I need a function to validate user registration requests
用户:/kotlin-test 我需要一个验证用户注册请求的函数
Agent:
# TDD Session: Registration Validator
代理:
# TDD 会话:注册验证器
## Step 1: Define Interface
## 第一步:定义接口
```kotlin
// validator/RegistrationValidator.kt
@@ -64,7 +64,7 @@ fun validateRegistration(request: RegistrationRequest): ValidationResult {
}
```
## Step 2: Write Kotest Tests (RED)
## 第二步:编写 Kotest 测试(RED
```kotlin
// validator/RegistrationValidatorTest.kt
@@ -141,7 +141,7 @@ class RegistrationValidatorTest : FunSpec({
})
```
## Step 3: Run Tests - Verify FAIL
## 第三步:运行测试 - 验证失败
```bash
$ ./gradlew test
@@ -152,9 +152,9 @@ RegistrationValidatorTest > valid registration returns Valid FAILED
FAILED (5 tests, 0 passed, 5 failed)
```
Tests fail as expected (NotImplementedError).
测试按预期失败(NotImplementedError)。
## Step 4: Implement Minimal Code (GREEN)
## 第四步:实现最小代码(GREEN
```kotlin
// validator/RegistrationValidator.kt
@@ -175,7 +175,7 @@ fun validateRegistration(request: RegistrationRequest): ValidationResult {
}
```
## Step 5: Run Tests - Verify PASS
## 第五步:运行测试 - 验证通过
```bash
$ ./gradlew test
@@ -189,9 +189,9 @@ RegistrationValidatorTest > multiple errors returns all errors PASSED
PASSED (5 tests, 5 passed, 0 failed)
```
All tests passing!
所有测试通过!
## Step 6: Check Coverage
## 第六步:检查覆盖率
```bash
$ ./gradlew koverHtmlReport
@@ -199,9 +199,9 @@ $ ./gradlew koverHtmlReport
Coverage: 100.0% of statements
```
Coverage: 100%
覆盖率:100%
## TDD Complete!
## TDD 完成!
````
## 测试模式

View File

@@ -93,15 +93,15 @@ origin: auto-extracted
## 步骤 5 的输出格式
```
### Checklist
- [x] skills/ grep: no overlap (or: overlap found → details)
- [x] MEMORY.md: no overlap (or: overlap found → details)
- [x] Existing skill append: new file appropriate (or: should append to [X])
- [x] Reusability: confirmed (or: one-off → Drop)
### 检查清单
- [x] skills/ grep: 无重叠 (或: 发现重叠 → 详情)
- [x] MEMORY.md: 无重叠 (或: 发现重叠 → 详情)
- [x] 现有技能追加: 新文件合适 (或: 应追加到 [X])
- [x] 可复用性: 已确认 (或: 一次性 → 丢弃)
### Verdict: Save / Improve then Save / Absorb into [X] / Drop
### 裁决: 保存 / 改进后保存 / 吸收到 [X] / 丢弃
**Rationale:** (1-2 sentences explaining the verdict)
**理由:** (1-2 句话解释裁决)
```
## 设计原理

View File

@@ -31,34 +31,34 @@
**调用语法**
```
# New session call
# 新会话调用
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend codex - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
ROLE_FILE: <角色提示路径>
<TASK>
Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)>
Context: <project context and analysis from previous phases>
需求: <增强后的需求(若未增强则为 $ARGUMENTS>
上下文: <来自先前阶段的项目上下文与分析>
</TASK>
OUTPUT: Expected output format
OUTPUT: 期望的输出格式
EOF",
run_in_background: false,
timeout: 3600000,
description: "Brief description"
description: "简要描述"
})
# Resume session call
# 恢复会话调用
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend codex resume <SESSION_ID> - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
ROLE_FILE: <角色提示路径>
<TASK>
Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)>
Context: <project context and analysis from previous phases>
需求: <增强后的需求(若未增强则为 $ARGUMENTS>
上下文: <来自先前阶段的项目上下文与分析>
</TASK>
OUTPUT: Expected output format
OUTPUT: 期望的输出格式
EOF",
run_in_background: false,
timeout: 3600000,
description: "Brief description"
description: "简要描述"
})
```

View File

@@ -21,7 +21,7 @@ $ARGUMENTS
**调用语法**(并行:使用 `run_in_background: true`
```
# Resume session call (recommended) - Implementation Prototype
# 恢复会话调用(推荐)- 实现原型
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
@@ -33,10 +33,10 @@ OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
EOF",
run_in_background: true,
timeout: 3600000,
description: "Brief description"
description: "简要描述"
})
# New session call - Implementation Prototype
# 新建会话调用 - 实现原型
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
@@ -48,7 +48,7 @@ OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
EOF",
run_in_background: true,
timeout: 3600000,
description: "Brief description"
description: "简要描述"
})
```
@@ -59,21 +59,21 @@ Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
<TASK>
Scope: Audit the final code changes.
Scope: 审计最终的代码变更。
Inputs:
- The applied patch (git diff / final unified diff)
- The touched files (relevant excerpts if needed)
- 已应用的补丁 (git diff / final unified diff)
- 涉及的文件 (必要时提供相关摘录)
Constraints:
- Do NOT modify any files.
- Do NOT output tool commands that assume filesystem access.
- 请勿修改任何文件。
- 请勿输出假设有文件系统访问权限的工具命令。
</TASK>
OUTPUT:
1) A prioritized list of issues (severity, file, rationale)
2) Concrete fixes; if code changes are needed, include a Unified Diff Patch in a fenced code block.
1) 一个按优先级排序的问题列表 (严重程度, 文件, 理由)
2) 具体的修复方案;如果需要更改代码,请包含在一个用围栏代码块包裹的 Unified Diff Patch 中。
EOF",
run_in_background: true,
timeout: 3600000,
description: "Brief description"
description: "简要描述"
})
```
@@ -144,7 +144,7 @@ TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })
```
mcp__ace-tool__search_context({
query: "<semantic query based on plan content, including key files, modules, function names>",
query: "<基于计划内容的语义查询,包括关键文件、模块、函数名>",
project_root_path: "$PWD"
})
```

View File

@@ -31,34 +31,34 @@
**调用语法**:
```
# New session call
# 新会话调用
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
ROLE_FILE: <角色提示文件路径>
<TASK>
Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)>
Context: <project context and analysis from previous phases>
需求: <增强后的需求(若未增强则为$ARGUMENTS>
上下文: <来自先前阶段的项目上下文与分析>
</TASK>
OUTPUT: Expected output format
OUTPUT: 期望的输出格式
EOF",
run_in_background: false,
timeout: 3600000,
description: "Brief description"
description: "简要描述"
})
# Resume session call
# 恢复会话调用
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview resume <SESSION_ID> - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
ROLE_FILE: <角色提示文件路径>
<TASK>
Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)>
Context: <project context and analysis from previous phases>
需求: <增强后的需求(若未增强则为$ARGUMENTS>
上下文: <来自先前阶段的项目上下文与分析>
</TASK>
OUTPUT: Expected output format
OUTPUT: 期望的输出格式
EOF",
run_in_background: false,
timeout: 3600000,
description: "Brief description"
description: "简要描述"
})
```

View File

@@ -93,7 +93,7 @@ mcp__ace-tool__enhance_prompt({
```
mcp__ace-tool__search_context({
query: "<semantic query based on enhanced requirement>",
query: "<基于增强需求的语义查询>",
project_root_path: "$PWD"
})
```

View File

@@ -35,34 +35,34 @@
**调用语法**(并行:`run_in_background: true`,串行:`false`
```
# New session call
# 新会话调用
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
ROLE_FILE: <角色提示文件路径>
<TASK>
Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)>
Context: <project context and analysis from previous phases>
需求: <增强后的需求(如未增强则为$ARGUMENTS>
上下文: <来自先前阶段的项目上下文和分析>
</TASK>
OUTPUT: Expected output format
OUTPUT: 期望的输出格式
EOF",
run_in_background: true,
timeout: 3600000,
description: "Brief description"
description: "简要描述"
})
# Resume session call
# 恢复会话调用
Bash({
command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF'
ROLE_FILE: <role prompt path>
ROLE_FILE: <角色提示文件路径>
<TASK>
Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)>
Context: <project context and analysis from previous phases>
需求: <增强后的需求(如未增强则为$ARGUMENTS>
上下文: <来自先前阶段的项目上下文和分析>
</TASK>
OUTPUT: Expected output format
OUTPUT: 期望的输出格式
EOF",
run_in_background: true,
timeout: 3600000,
description: "Brief description"
description: "简要描述"
})
```

View File

@@ -17,7 +17,7 @@ description: 针对多智能体工作流程的顺序和tmux/worktree编排指南
完整功能实现工作流:
```
planner -> tdd-guide -> code-reviewer -> security-reviewer
规划者 -> 测试驱动开发指南 -> 代码审查员 -> 安全审查员
```
### bugfix
@@ -33,7 +33,7 @@ planner -> tdd-guide -> code-reviewer
安全重构工作流:
```
architect -> code-reviewer -> tdd-guide
架构师 -> 代码审查员 -> 测试驱动开发指南
```
### security
@@ -112,38 +112,38 @@ security-reviewer -> code-reviewer -> architect
## 最终报告格式
```
ORCHESTRATION REPORT
编排报告
====================
Workflow: feature
Task: Add user authentication
Agents: planner -> tdd-guide -> code-reviewer -> security-reviewer
工作流:功能
任务:添加用户认证
智能体:规划者 -> TDD指南 -> 代码审查员 -> 安全审查员
SUMMARY
概要
-------
[One paragraph summary]
[一段总结]
AGENT OUTPUTS
智能体输出
-------------
Planner: [summary]
TDD Guide: [summary]
Code Reviewer: [summary]
Security Reviewer: [summary]
规划者:[总结]
TDD指南:[总结]
代码审查员:[总结]
安全审查员:[总结]
FILES CHANGED
已更改文件
-------------
[List all files modified]
[列出所有修改的文件]
TEST RESULTS
测试结果
------------
[Test pass/fail summary]
[测试通过/失败总结]
SECURITY STATUS
安全状态
---------------
[Security findings]
[安全发现]
RECOMMENDATION
建议
--------------
[SHIP / NEEDS WORK / BLOCKED]
[可发布 / 需要改进 / 已阻止]
```
## 并行执行
@@ -230,7 +230,7 @@ $ARGUMENTS:
## 自定义工作流示例
```
/orchestrate custom "architect,tdd-guide,code-reviewer" "Redesign caching layer"
/orchestrate 自定义 "architect,tdd-guide,code-reviewer" "重新设计缓存层"
```
## 提示

View File

@@ -37,59 +37,59 @@ planner 代理将:
## 使用示例
```
User: /plan I need to add real-time notifications when markets resolve
User: /plan 我需要为市场结算时添加实时通知功能
Agent (planner):
# Implementation Plan: Real-Time Market Resolution Notifications
# 实施计划:实时市场结算通知
## Requirements Restatement
- Send notifications to users when markets they're watching resolve
- Support multiple notification channels (in-app, email, webhook)
- Ensure notifications are delivered reliably
- Include market outcome and user's position result
## 需求重述
- 当用户关注的市场结算时,向用户发送通知
- 支持多种通知渠道应用内、电子邮件、Webhook
- 确保通知可靠送达
- 包含市场结果和用户持仓结果
## Implementation Phases
## 实施阶段
### Phase 1: Database Schema
- Add notifications table with columns: id, user_id, market_id, type, status, created_at
- Add user_notification_preferences table for channel preferences
- Create indexes on user_id and market_id for performance
### 第一阶段:数据库架构
- 添加 notifications 表,包含列:id, user_id, market_id, type, status, created_at
- 添加 user_notification_preferences 表用于存储渠道偏好设置
- user_id market_id 上创建索引以提升性能
### Phase 2: Notification Service
- Create notification service in lib/notifications.ts
- Implement notification queue using BullMQ/Redis
- Add retry logic for failed deliveries
- Create notification templates
### 第二阶段:通知服务
- lib/notifications.ts 中创建通知服务
- 使用 BullMQ/Redis 实现通知队列
- 为发送失败的情况添加重试逻辑
- 创建通知模板
### Phase 3: Integration Points
- Hook into market resolution logic (when status changes to "resolved")
- Query all users with positions in market
- Enqueue notifications for each user
### 第三阶段:集成点
- 接入市场结算逻辑(当状态变为 "resolved" 时)
- 查询在市场中有持仓的所有用户
- 为每个用户将通知加入队列
### Phase 4: Frontend Components
- Create NotificationBell component in header
- Add NotificationList modal
- Implement real-time updates via Supabase subscriptions
- Add notification preferences page
### 第四阶段:前端组件
- 在头部创建 NotificationBell 组件
- 添加 NotificationList 模态框
- 通过 Supabase 订阅实现实时更新
- 添加通知偏好设置页面
## Dependencies
- Redis (for queue)
- Email service (SendGrid/Resend)
- Supabase real-time subscriptions
## 依赖项
- Redis(用于队列)
- 电子邮件服务(SendGrid/Resend
- Supabase 实时订阅
## Risks
- HIGH: Email deliverability (SPF/DKIM required)
- MEDIUM: Performance with 1000+ users per market
- MEDIUM: Notification spam if markets resolve frequently
- LOW: Real-time subscription overhead
## 风险
- 高:电子邮件送达率(需要配置 SPF/DKIM
- 中:市场用户超过 1000+ 时的性能问题
- 中:市场频繁结算可能导致通知泛滥
- 低:实时订阅开销
## Estimated Complexity: MEDIUM
- Backend: 4-6 hours
- Frontend: 3-4 hours
- Testing: 2-3 hours
- Total: 9-13 hours
## 预估复杂度:中
- 后端4-6 小时
- 前端3-4 小时
- 测试2-3 小时
- 总计9-13 小时
**WAITING FOR CONFIRMATION**: Proceed with this plan? (yes/no/modify)
**等待确认**:是否按此计划进行?(是/否/修改)
```
## 重要说明

View File

@@ -34,21 +34,21 @@
```
project/
├── ecosystem.config.cjs # PM2 config
├── {backend}/start.cjs # Python wrapper (if applicable)
├── ecosystem.config.cjs # PM2 配置文件
├── {backend}/start.cjs # Python 包装器(如适用)
└── .claude/
├── commands/
│ ├── pm2-all.md # Start all + monit
│ ├── pm2-all-stop.md # Stop all
│ ├── pm2-all-restart.md # Restart all
│ ├── pm2-{port}.md # Start single + logs
│ ├── pm2-{port}-stop.md # Stop single
│ ├── pm2-{port}-restart.md # Restart single
│ ├── pm2-logs.md # View all logs
│ └── pm2-status.md # View status
│ ├── pm2-all.md # 启动所有 + 监控
│ ├── pm2-all-stop.md # 停止所有
│ ├── pm2-all-restart.md # 重启所有
│ ├── pm2-{port}.md # 启动单个 + 日志
│ ├── pm2-{port}-stop.md # 停止单个
│ ├── pm2-{port}-restart.md # 重启单个
│ ├── pm2-logs.md # 查看所有日志
│ └── pm2-status.md # 查看状态
└── scripts/
├── pm2-logs-{port}.ps1 # Single service logs
└── pm2-monit.ps1 # PM2 monitor
├── pm2-logs-{port}.ps1 # 单个服务日志
└── pm2-monit.ps1 # PM2 监控器
```
***
@@ -255,29 +255,29 @@ pm2 resurrect # Restore saved list
所有文件生成后,输出:
```
## PM2 Init Complete
## PM2 初始化完成
**Services:**
**服务列表:**
| Port | Name | Type |
| 端口 | 名称 | 类型 |
|------|------|------|
| {port} | {name} | {type} |
**Claude Commands:** /pm2-all, /pm2-all-stop, /pm2-{port}, /pm2-{port}-stop, /pm2-logs, /pm2-status
**Claude 指令:** /pm2-all, /pm2-all-stop, /pm2-{port}, /pm2-{port}-stop, /pm2-logs, /pm2-status
**Terminal Commands:**
## First time (with config file)
**终端命令:**
## 首次运行(使用配置文件)
pm2 start ecosystem.config.cjs && pm2 save
## After first time (simplified)
pm2 start all # Start all
pm2 stop all # Stop all
pm2 restart all # Restart all
pm2 start {name} # Start single
pm2 stop {name} # Stop single
pm2 logs # View logs
pm2 monit # Monitor panel
pm2 resurrect # Restore saved processes
## 首次之后(简化命令)
pm2 start all # 启动全部
pm2 stop all # 停止全部
pm2 restart all # 重启全部
pm2 start {name} # 启动单个
pm2 stop {name} # 停止单个
pm2 logs # 查看日志
pm2 monit # 监控面板
pm2 resurrect # 恢复已保存进程
**Tip:** Run `pm2 save` after first start to enable simplified commands.
**提示:** 首次启动后运行 `pm2 save` 以启用简化命令。
```

View File

@@ -178,54 +178,53 @@ with open("config.json") as f: # Good
运行:`black app/routes/user.py app/services/auth.py`
````
## 审批标准
## Approval Criteria
| Status | Condition |
| 状态 | 条件 |
|--------|-----------|
| ✅ Approve | No CRITICAL or HIGH issues |
| ⚠️ Warning | Only MEDIUM issues (merge with caution) |
| ❌ Block | CRITICAL or HIGH issues found |
| ✅ 批准 | CRITICAL HIGH 级别问题 |
| ⚠️ 警告 | 仅存在 MEDIUM 级别问题(谨慎合并) |
| ❌ 阻止 | 发现 CRITICAL HIGH 级别问题 |
## Integration with Other Commands
## 与其他命令的集成
- Use `/tdd` first to ensure tests pass
- Use `/code-review` for non-Python specific concerns
- Use `/python-review` before committing
- Use `/build-fix` if static analysis tools fail
- 首先使用 `/tdd` 确保测试通过
- 使用 `/code-review` 处理非 Python 特定问题
- 在提交前使用 `/python-review`
- 如果静态分析工具失败,请使用 `/build-fix`
## Framework-Specific Reviews
## 框架特定审查
### Django Projects
The reviewer checks for:
- N+1 query issues (use `select_related` and `prefetch_related`)
- Missing migrations for model changes
- Raw SQL usage when ORM could work
- Missing `transaction.atomic()` for multi-step operations
### Django 项目
审查员检查:
- N+1 查询问题(使用 `select_related` `prefetch_related`
- 模型更改缺少迁移
- 在 ORM 可用时使用原始 SQL
- 多步骤操作缺少 `transaction.atomic()`
### FastAPI Projects
The reviewer checks for:
- CORS misconfiguration
- Pydantic models for request validation
- Response models correctness
- Proper async/await usage
- Dependency injection patterns
### FastAPI 项目
审查员检查:
- CORS 配置错误
- 用于请求验证的 Pydantic 模型
- 响应模型的正确性
- 正确的 async/await 使用
- 依赖注入模式
### Flask Projects
The reviewer checks for:
- Context management (app context, request context)
- Proper error handling
- Blueprint organization
- Configuration management
### Flask 项目
审查员检查:
- 上下文管理(应用上下文、请求上下文)
- 正确的错误处理
- Blueprint 组织
- 配置管理
## Related
## 相关
- Agent: `agents/python-reviewer.md`
- Skills: `skills/python-patterns/`, `skills/python-testing/`
## Common Fixes
## 常见修复
### Add Type Hints
### 添加类型提示
```python
# Before
def calculate(x, y):

View File

@@ -18,7 +18,7 @@
如果没有可用工具,使用 Grep 查找零次导入的导出:
```
# Find exports, then check if they're imported anywhere
# 查找导出项,然后检查是否有任何地方导入了它们
```
## 步骤 2分类发现结果
@@ -64,15 +64,15 @@
报告结果:
```
Dead Code Cleanup
无用代码清理
──────────────────────────────
Deleted: 12 unused functions
3 unused files
5 unused dependencies
Skipped: 2 items (tests failed)
Saved: ~450 lines removed
已删除: 12 个未使用函数
3 个未使用文件
5 个未使用依赖项
已跳过: 2 个项目(测试失败)
已节省: ~450 行代码被移除
──────────────────────────────
All tests passing
所有测试通过
```
## 规则

View File

@@ -17,10 +17,10 @@ description: 从 ~/.claude/sessions/ 加载最新的会话文件,并从上次
## 用法
```
/resume-session # loads most recent file in ~/.claude/sessions/
/resume-session 2024-01-15 # loads most recent session for that date
/resume-session ~/.claude/sessions/2024-01-15-session.tmp # loads a specific legacy-format file
/resume-session ~/.claude/sessions/2024-01-15-abc123de-session.tmp # loads a current short-id session file
/resume-session # 加载 ~/.claude/sessions/ 目录下最新的文件
/resume-session 2024-01-15 # 加载该日期最新的会话
/resume-session ~/.claude/sessions/2024-01-15-session.tmp # 加载特定的旧格式文件
/resume-session ~/.claude/sessions/2024-01-15-abc123de-session.tmp # 加载当前短ID格式的会话文件
```
## 流程
@@ -55,31 +55,31 @@ description: 从 ~/.claude/sessions/ 加载最新的会话文件,并从上次
使用以下确切格式回复一份结构化简报:
```
SESSION LOADED: [actual resolved path to the file]
会话已加载:[文件的实际解析路径]
════════════════════════════════════════════════
PROJECT: [project name / topic from file]
项目:[文件中的项目名称/主题]
WHAT WE'RE BUILDING:
[2-3 sentence summary in your own words]
我们正在构建什么:
[用你自己的话总结 2-3 句话]
CURRENT STATE:
Working: [count] items confirmed
🔄 In Progress: [list files that are in progress]
🗒️ Not Started: [list planned but untouched]
当前状态:
已完成:[数量] 项已确认
🔄 进行中:[列出进行中的文件]
🗒️ 未开始:[列出计划但未开始的文件]
WHAT NOT TO RETRY:
[list every failed approach with its reason — this is critical]
不应重试的内容:
[列出每个失败的方法及其原因——此部分至关重要]
OPEN QUESTIONS / BLOCKERS:
[list any blockers or unanswered questions]
待解决问题/阻碍:
[列出任何阻碍或未解答的问题]
NEXT STEP:
[exact next step if defined in the file]
[if not defined: "No next step defined — recommend reviewing 'What Has NOT Been Tried Yet' together before starting"]
下一步:
[如果文件中已定义,则列出确切下一步]
[如果未定义:"未定义下一步——建议在开始前共同回顾'尚未尝试的方法'"]
════════════════════════════════════════════════
Ready to continue. What would you like to do?
准备就绪。您希望做什么?
```
### 步骤 4等待用户
@@ -117,32 +117,31 @@ Ready to continue. What would you like to do?
SESSION LOADED: /Users/you/.claude/sessions/2024-01-15-abc123de-session.tmp
════════════════════════════════════════════════
PROJECT: my-app — JWT Authentication
项目:my-app — JWT 认证
WHAT WE'RE BUILDING:
User authentication with JWT tokens stored in httpOnly cookies.
Register and login endpoints are partially done. Route protection
via middleware hasn't been started yet.
构建目标:
使用存储在 httpOnly cookie 中的 JWT 令牌实现用户认证。
注册和登录端点已部分完成。通过中间件进行路由保护尚未开始。
CURRENT STATE:
Working: 3 items (register endpoint, JWT generation, password hashing)
🔄 In Progress: app/api/auth/login/route.ts (token works, cookie not set yet)
🗒️ Not Started: middleware.ts, app/login/page.tsx
当前状态:
已完成3 项注册端点、JWT 生成、密码哈希)
🔄 进行中:app/api/auth/login/route.ts(令牌有效,但 cookie 尚未设置)
🗒️ 未开始:middleware.tsapp/login/page.tsx
WHAT NOT TO RETRY:
❌ Next-Auth — conflicts with custom Prisma adapter, threw adapter error on every request
❌ localStorage for JWT — causes SSR hydration mismatch, incompatible with Next.js
需避免的事项:
❌ Next-Auth — 与自定义 Prisma 适配器冲突,每次请求均抛出适配器错误
❌ localStorage 存储 JWT — 导致 SSR 水合不匹配,与 Next.js 不兼容
OPEN QUESTIONS / BLOCKERS:
- Does cookies().set() work inside a Route Handler or only Server Actions?
待解决问题 / 阻碍:
- cookies().set() 在路由处理器中是否有效,还是仅适用于服务器操作?
NEXT STEP:
In app/api/auth/login/route.ts — set the JWT as an httpOnly cookie using
下一步:
app/api/auth/login/route.ts 中 — 使用以下方式将 JWT 设置为 httpOnly cookie
cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' })
then test with Postman for a Set-Cookie header in the response.
随后使用 Postman 测试响应中是否包含 Set-Cookie 标头。
════════════════════════════════════════════════
Ready to continue. What would you like to do?
准备继续。您希望做什么?
```
***

View File

@@ -28,10 +28,10 @@ description: 为Rust强制执行TDD工作流。先写测试然后实现。使
## TDD 循环
```
RED -> Write failing test first
GREEN -> Implement minimal code to pass
REFACTOR -> Improve code, tests stay green
REPEAT -> Next test case
RED -> 先编写失败的测试
GREEN -> 实现最小化代码以通过测试
REFACTOR -> 改进代码,保持测试通过
REPEAT -> 下一个测试用例
```
## 示例会话

View File

@@ -56,9 +56,9 @@ mkdir -p ~/.claude/sessions
写入后,显示完整内容并询问:
```
Session saved to [actual resolved path to the session file]
会话已保存至 [实际解析的会话文件路径]
Does this look accurate? Anything to correct or add before we close?
这看起来准确吗?在关闭之前,还有什么需要纠正或补充的吗?
```
等待确认。如果用户要求,进行编辑。

View File

@@ -138,24 +138,23 @@ src/
└── services/ # API 和外部服务
```
## 工作流
## Workflows
### 添加新组件
1. 创建 `src/components/ComponentName.tsx`
2. 在 `src/components/__tests__/ComponentName.test.tsx` 中添加测试
3. 从 `src/components/index.ts` 导出
### Adding a New Component
1. Create `src/components/ComponentName.tsx`
2. Add tests in `src/components/__tests__/ComponentName.test.tsx`
3. Export from `src/components/index.ts`
### 数据库迁移
1. 修改 `src/db/schema.ts`
2. 运行 `pnpm db:generate`
3. 运行 `pnpm db:migrate`
### Database Migration
1. Modify `src/db/schema.ts`
2. Run `pnpm db:generate`
3. Run `pnpm db:migrate`
## 测试模式
## Testing Patterns
- Test files: `__tests__/` directories or `.test.ts` suffix
- Coverage target: 80%+
- Framework: Vitest
- 测试文件:`__tests__/` 目录或 `.test.ts` 后缀
- 覆盖率目标80%+
- 框架Vitest
```
## GitHub 应用集成

View File

@@ -34,9 +34,9 @@ node "$ECC_ROOT/scripts/skills-health.js" --dashboard --json
## 使用方法
```
/skill-health # Full dashboard view
/skill-health --panel failures # Only failure clustering panel
/skill-health --json # Machine-readable JSON output
/skill-health # 完整仪表盘视图
/skill-health --panel failures # 仅故障聚类面板
/skill-health --json # 机器可读的 JSON 输出
```
## 操作步骤

View File

@@ -41,10 +41,10 @@ tdd-guide 代理将:
```
RED → GREEN → REFACTOR → REPEAT
RED: Write a failing test
GREEN: Write minimal code to pass
REFACTOR: Improve code, keep tests passing
REPEAT: Next feature/scenario
RED: 编写一个失败测试
GREEN: 编写通过测试的最简代码
REFACTOR: 改进代码,保持测试通过
REPEAT: 开始下一个功能/场景
```
## 使用示例
@@ -254,79 +254,77 @@ Coverage: 100% ✅ (Target: 80%)
✅ TDD 会话完成!
```
## TDD 最佳实践
## TDD Best Practices
**应做:**
- ✅ 先写测试,再写实现
- ✅ 运行测试并确认失败,再实现功能
- ✅ 编写最少代码使测试通过
- ✅ 仅在测试通过后进行重构
- ✅ 添加边界情况和错误场景
- ✅ 目标覆盖率 80% 以上(关键代码 100%
**DO:**
- ✅ Write the test FIRST, before any implementation
- ✅ Run tests and verify they FAIL before implementing
- ✅ Write minimal code to make tests pass
- ✅ Refactor only after tests are green
- ✅ Add edge cases and error scenarios
- ✅ Aim for 80%+ coverage (100% for critical code)
**不应做:**
- ❌ 先写实现再写测试
- ❌ 每次更改后跳过运行测试
- ❌ 一次性编写过多代码
- ❌ 忽略失败的测试
- ❌ 测试实现细节(应测试行为)
- ❌ 过度模拟(优先使用集成测试)
**DON'T:**
- ❌ Write implementation before tests
- ❌ Skip running tests after each change
- ❌ Write too much code at once
- ❌ Ignore failing tests
- ❌ Test implementation details (test behavior)
- ❌ Mock everything (prefer integration tests)
## 应包含的测试类型
## Test Types to Include
**单元测试**(函数级别):
- 正常路径场景
- 边界情况空值、null、最大值
- 错误条件
- 边界值
**Unit Tests** (Function-level):
- Happy path scenarios
- Edge cases (empty, null, max values)
- Error conditions
- Boundary values
**集成测试**(组件级别):
- API 端点
- 数据库操作
- 外部服务调用
- 包含钩子的 React 组件
**Integration Tests** (Component-level):
- API endpoints
- Database operations
- External service calls
- React components with hooks
**端到端测试**(使用 `/e2e` 命令):
- 关键用户流程
- 多步骤流程
- 全栈集成
**E2E Tests** (use `/e2e` command):
- Critical user flows
- Multi-step processes
- Full stack integration
## 覆盖率要求
## Coverage Requirements
- 所有代码**最低 80%**
- **必须达到 100%** 的代码:
- 财务计算
- 认证逻辑
- 安全关键代码
- 核心业务逻辑
- **80% minimum** for all code
- **100% required** for:
- Financial calculations
- Authentication logic
- Security-critical code
- Core business logic
## 重要说明
## Important Notes
**强制要求**测试必须在实现之前编写。TDD 循环是:
**MANDATORY**: Tests must be written BEFORE implementation. The TDD cycle is:
1. **红** - 编写失败的测试
2. **绿** - 实现功能使测试通过
3. **重构** - 改进代码
1. **RED** - Write failing test
2. **GREEN** - Implement to pass
3. **REFACTOR** - Improve code
切勿跳过红阶段。切勿在测试之前编写代码。
Never skip the RED phase. Never write code before tests.
## 与其他命令的集成
## Integration with Other Commands
- 首先使用 `/plan` 来了解要构建什么
- 使用 `/tdd` 进行带测试的实现
- 如果出现构建错误,请使用 `/build-fix`
- 使用 `/code-review` 审查实现
- 使用 `/test-coverage` 验证覆盖率
- Use `/plan` first to understand what to build
- Use `/tdd` to implement with tests
- Use `/build-fix` if build errors occur
- Use `/code-review` to review implementation
- Use `/test-coverage` to verify coverage
## 相关代理
## Related Agents
此命令调用由 ECC 提供的 `tdd-guide` 代理。
This command invokes the `tdd-guide` agent provided by ECC.
相关的 `tdd-workflow` 技能也随 ECC 捆绑提供。
The related `tdd-workflow` skill is also bundled with ECC.
For manual installs, the source files live at:
对于手动安装,源文件位于:
- `agents/tdd-guide.md`
- `skills/tdd-workflow/SKILL.md`
```

View File

@@ -51,13 +51,13 @@
显示前后对比:
```
Coverage Report
覆盖率报告
──────────────────────────────
File Before After
文件 变更前 变更后
src/services/auth.ts 45% 88%
src/utils/validation.ts 32% 82%
──────────────────────────────
Overall: 67% 84% ✅
总计: 67% 84% ✅
```
## 重点关注领域

View File

@@ -69,12 +69,12 @@
## 步骤 7显示摘要
```
Documentation Update
文档更新
──────────────────────────────
Updated: docs/CONTRIBUTING.md (scripts table)
Updated: docs/ENV.md (3 new variables)
Flagged: docs/DEPLOY.md (142 days stale)
Skipped: docs/API.md (no changes detected)
已更新:docs/CONTRIBUTING.md(脚本表格)
已更新:docs/ENV.md新增3个变量
已标记:docs/DEPLOY.md142天未更新)
已跳过:docs/API.md(未检测到变更)
──────────────────────────────
```

View File

@@ -36,16 +36,16 @@
生成一份简洁的验证报告:
```
VERIFICATION: [PASS/FAIL]
验证: [通过/失败]
Build: [OK/FAIL]
Types: [OK/X errors]
Lint: [OK/X issues]
Tests: [X/Y passed, Z% coverage]
Secrets: [OK/X found]
Logs: [OK/X console.logs]
构建: [成功/失败]
类型: [成功/X 错误]
代码检查: [成功/X 问题]
测试: [X/Y 通过Z% 覆盖率]
密钥检查: [成功/X 发现]
日志: [成功/X console.logs]
Ready for PR: [YES/NO]
准备提交 PR [是/否]
```
如果存在任何关键问题,列出它们并提供修复建议。

View File

@@ -43,11 +43,11 @@
```
src/
|-- app/ # Next.js app router
|-- components/ # Reusable UI components
|-- hooks/ # Custom React hooks
|-- lib/ # Utility libraries
|-- types/ # TypeScript definitions
|-- app/ # Next.js 应用路由
|-- components/ # 可复用的 UI 组件
|-- hooks/ # 自定义 React 钩子
|-- lib/ # 工具库
|-- types/ # TypeScript 定义
```
## 关键模式

View File

@@ -97,38 +97,38 @@ class InsufficientStockError(APIException):
```
config/
settings/
base.py # Shared settings
local.py # Dev overrides (DEBUG=True)
production.py # Production settings
urls.py # Root URL config
celery.py # Celery app configuration
base.py # 共享设置
local.py # 开发环境覆盖设置 (DEBUG=True)
production.py # 生产环境设置
urls.py # URL 配置
celery.py # Celery 应用配置
apps/
accounts/ # User auth, registration, profile
accounts/ # 用户认证、注册、个人资料
models.py
serializers.py
views.py
services.py # Business logic
services.py # 业务逻辑
tests/
test_views.py
test_services.py
factories.py # Factory Boy factories
orders/ # Order management
factories.py # Factory Boy 工厂
orders/ # 订单管理
models.py
serializers.py
views.py
services.py
tasks.py # Celery tasks
tasks.py # Celery 任务
tests/
products/ # Product catalog
products/ # 产品目录
models.py
serializers.py
views.py
tests/
core/
exceptions.py # Custom API exceptions
permissions.py # Shared permission classes
pagination.py # Custom pagination
middleware.py # Request logging, timing
exceptions.py # 自定义 API 异常
permissions.py # 共享权限类
pagination.py # 自定义分页
middleware.py # 请求日志记录、计时
tests/
```

View File

@@ -66,31 +66,31 @@ func toGRPCError(err error) error {
```
cmd/
server/
main.go # Entrypoint, Wire injection, graceful shutdown
main.go # 入口点Wire注入优雅关闭
internal/
domain/ # Business types and interfaces
user.go # User entity and repository interface
errors.go # Sentinel errors
service/ # Business logic
domain/ # 业务类型和接口
user.go # 用户实体和仓库接口
errors.go # 哨兵错误
service/ # 业务逻辑
user_service.go
user_service_test.go
repository/ # Data access (sqlc-generated + custom)
repository/ # 数据访问sqlc生成 + 自定义)
postgres/
user_repo.go
user_repo_test.go # Integration tests with testcontainers
handler/ # gRPC + REST handlers
user_repo_test.go # 使用testcontainers的集成测试
handler/ # gRPC + REST处理程序
grpc/
user_handler.go
rest/
user_handler.go
config/ # Configuration loading
config/ # 配置加载
config.go
proto/ # Protobuf definitions
proto/ # Protobuf定义
user/v1/
user.proto
queries/ # SQL queries for sqlc
queries/ # sqlc的SQL查询
user.sql
migrations/ # Database migrations
migrations/ # 数据库迁移
001_create_users.up.sql
001_create_users.down.sql
```

View File

@@ -92,36 +92,36 @@ impl IntoResponse for AppError {
```
src/
main.rs # Entrypoint, server setup, graceful shutdown
lib.rs # Re-exports for integration tests
config.rs # Environment config with envy or figment
router.rs # Axum router with all routes
main.rs # 入口点、服务器设置、优雅关闭
lib.rs # 用于集成测试的重新导出
config.rs # 使用 envy figment 的环境配置
router.rs # 包含所有路由的 Axum 路由器
middleware/
auth.rs # JWT extraction and validation
logging.rs # Request/response tracing
auth.rs # JWT 提取与验证
logging.rs # 请求/响应追踪
handlers/
mod.rs # Route handlers (thin — delegate to services)
mod.rs # 路由处理器(精简版——委托给服务层)
users.rs
orders.rs
services/
mod.rs # Business logic
mod.rs # 业务逻辑
users.rs
orders.rs
repositories/
mod.rs # Database access (SQLx queries)
mod.rs # 数据库访问SQLx 查询)
users.rs
orders.rs
domain/
mod.rs # Domain types, error enums
mod.rs # 领域类型、错误枚举
user.rs
order.rs
migrations/
001_create_users.sql
002_create_orders.sql
tests/
common/mod.rs # Shared test helpers, test server setup
api_users.rs # Integration tests for user endpoints
api_orders.rs # Integration tests for order endpoints
common/mod.rs # 共享测试辅助工具、测试服务器设置
api_users.rs # 用户端点的集成测试
api_orders.rs # 订单端点的集成测试
```
## 关键模式

View File

@@ -45,24 +45,24 @@
```
src/
app/
(auth)/ # Auth pages (login, signup, forgot-password)
(dashboard)/ # Protected dashboard pages
(auth)/ # 认证页面(登录、注册、忘记密码)
(dashboard)/ # 受保护的仪表板页面
api/
webhooks/ # Stripe, Supabase webhooks
layout.tsx # Root layout with providers
webhooks/ # StripeSupabase webhooks
layout.tsx # 根布局(包含 providers
components/
ui/ # Shadcn/ui components
forms/ # Form components with validation
dashboard/ # Dashboard-specific components
hooks/ # Custom React hooks
ui/ # Shadcn/ui 组件
forms/ # 带验证的表单组件
dashboard/ # 仪表板专用组件
hooks/ # 自定义 React hooks
lib/
supabase/ # Supabase client factories
stripe/ # Stripe client and helpers
utils.ts # General utilities
types/ # Shared TypeScript types
supabase/ # Supabase 客户端工厂
stripe/ # Stripe 客户端与辅助工具
utils.ts # 通用工具函数
types/ # 共享 TypeScript 类型
supabase/
migrations/ # Database migrations
seed.sql # Development seed data
migrations/ # 数据库迁移
seed.sql # 开发用种子数据
```
## 关键模式

View File

@@ -5,7 +5,7 @@
## 钩子如何工作
```
User request → Claude picks a tool → PreToolUse hook runs → Tool executes → PostToolUse hook runs
用户请求 → Claude 选择工具 → PreToolUse 钩子运行 → 工具执行 → PostToolUse 钩子运行
```
* **PreToolUse** 钩子在工具执行前运行。它们可以**阻止**(退出码 2或**警告**stderr 输出但不阻止)。

View File

@@ -82,8 +82,8 @@ claude plugin marketplace add https://github.com/mixedbread-ai/mgrep
```
~/.claude/plugins/
|-- cache/ # Downloaded plugins
|-- installed_plugins.json # Installed list
|-- known_marketplaces.json # Added marketplaces
|-- marketplaces/ # Marketplace data
|-- cache/ # 已下载的插件
|-- installed_plugins.json # 已安装列表
|-- known_marketplaces.json # 已添加的市场
|-- marketplaces/ # 市场数据
```

View File

@@ -6,7 +6,7 @@
```
rules/
├── common/ # Language-agnostic principles (always install)
├── common/ # 语言无关原则(始终安装)
│ ├── coding-style.md
│ ├── git-workflow.md
│ ├── testing.md
@@ -15,11 +15,11 @@ rules/
│ ├── hooks.md
│ ├── agents.md
│ └── security.md
├── typescript/ # TypeScript/JavaScript specific
├── python/ # Python specific
├── golang/ # Go specific
├── swift/ # Swift specific
└── php/ # PHP specific
├── typescript/ # TypeScript/JavaScript 特定
├── python/ # Python 特定
├── golang/ # Go 特定
├── swift/ # Swift 特定
└── php/ # PHP 特定
```
* **common/** 包含通用原则 —— 没有语言特定的代码示例。

View File

@@ -5,9 +5,9 @@
始终创建新对象,绝不改变现有对象:
```
// Pseudocode
WRONG: modify(original, field, value) → changes original in-place
CORRECT: update(original, field, value) → returns new copy with change
// 伪代码
WRONG: modify(original, field, value) → 原地修改 original
CORRECT: update(original, field, value) → 返回包含更改的新副本
```
理由:不可变数据可以防止隐藏的副作用,使调试更容易,并支持安全的并发。

View File

@@ -18,10 +18,10 @@ paths:
```
src/test/java/com/example/app/
service/ # Unit tests for service layer
controller/ # Web layer / API tests
repository/ # Data access tests
integration/ # Cross-layer integration tests
service/ # 服务层单元测试
controller/ # Web 层/API 测试
repository/ # 数据访问测试
integration/ # 跨层集成测试
```
`src/test/java` 中镜像 `src/main/java` 的包结构。

View File

@@ -120,10 +120,10 @@ fun `delete item emits updated list without deleted item`() = runTest { }
```
src/
├── commonTest/kotlin/ # Shared tests (ViewModel, UseCase, Repository)
├── androidUnitTest/kotlin/ # Android unit tests (JUnit)
├── androidInstrumentedTest/kotlin/ # Instrumented tests (Room, UI)
└── iosTest/kotlin/ # iOS-specific tests
├── commonTest/kotlin/ # 共享测试(ViewModelUseCaseRepository
├── androidUnitTest/kotlin/ # Android 单元测试(JUnit
├── androidInstrumentedTest/kotlin/ # 仪器化测试(RoomUI
└── iosTest/kotlin/ # iOS 专用测试
```
最低测试覆盖率:每个功能都需要覆盖 ViewModel + UseCase。

View File

@@ -28,10 +28,10 @@ paths:
使用 **perltidy** 并采用以下设置:
```
-i=4 # 4-space indent
-l=100 # 100 char line length
-ce # cuddled else
-bar # opening brace always right
-i=4 # 4 空格缩进
-l=100 # 100 字符行宽
-ce # else 紧贴前括号
-bar # 左花括号始终在右侧
```
## 代码检查

View File

@@ -129,15 +129,15 @@ for user in &users {
src/
├── main.rs
├── lib.rs
├── auth/ # Domain module
├── auth/ # 领域模块
│ ├── mod.rs
│ ├── token.rs
│ └── middleware.rs
├── orders/ # Domain module
├── orders/ # 领域模块
│ ├── mod.rs
│ ├── model.rs
│ └── service.rs
└── db/ # Infrastructure
└── db/ # 基础设施
├── mod.rs
└── pool.rs
```

View File

@@ -20,17 +20,17 @@ paths:
```text
my_crate/
├── src/
│ ├── lib.rs # Unit tests in #[cfg(test)] modules
│ ├── lib.rs # 位于 #[cfg(test)] 模块中的单元测试
│ ├── auth/
│ │ └── mod.rs # #[cfg(test)] mod tests { ... }
│ └── orders/
│ └── service.rs # #[cfg(test)] mod tests { ... }
├── tests/ # Integration tests (each file = separate binary)
├── tests/ # 集成测试(每个文件 = 独立的二进制文件)
│ ├── api_test.rs
│ ├── db_test.rs
│ └── common/ # Shared test utilities
│ └── common/ # 共享的测试工具
│ └── mod.rs
└── benches/ # Criterion benchmarks
└── benches/ # Criterion 基准测试
└── benchmark.rs
```

View File

@@ -21,25 +21,25 @@ origin: ECC
当 AI 编写代码然后审查其自身工作时,它会将相同的假设带入这两个步骤。这会形成一个可预测的失败模式:
```
AI writes fix → AI reviews fix → AI says "looks correct" → Bug still exists
AI 编写修复 → AI 审查修复 → AI 表示“看起来正确” → 漏洞依然存在
```
**实际示例**(在生产环境中观察到):
```
Fix 1: Added notification_settings to API response
Forgot to add it to the SELECT query
→ AI reviewed and missed it (same blind spot)
修复 1向 API 响应添加了 notification_settings
忘记将其添加到 SELECT 查询中
→ AI 审核时遗漏了(相同的盲点)
Fix 2: Added it to SELECT query
→ TypeScript build error (column not in generated types)
→ AI reviewed Fix 1 but didn't catch the SELECT issue
修复 2将其添加到 SELECT 查询中
→ TypeScript 构建错误(列不在生成的类型中)
→ AI 审核了修复 1但未发现 SELECT 问题
Fix 3: Changed to SELECT *
Fixed production path, forgot sandbox path
→ AI reviewed and missed it AGAIN (4th occurrence)
修复 3改为 SELECT *
修复了生产路径,忘记了沙箱路径
→ AI 审核时再次遗漏(第 4 次出现)
Fix 4: Test caught it instantly on first run
修复 4测试在首次运行时立即捕获了问题
```
模式:**沙盒/生产环境路径不一致**是 AI 引入的 #1 回归问题。
@@ -228,18 +228,18 @@ describe("GET /api/user/messages (conversation list)", () => {
User: "バグチェックして" (or "/bug-check")
├─ Step 1: npm run test
│ ├─ FAIL → Bug found mechanically (no AI judgment needed)
│ └─ PASS → Continue
│ ├─ FAIL → 发现机械性错误无需AI判断
│ └─ PASS → 继续
├─ Step 2: npm run build
│ ├─ FAIL → Type error found mechanically
│ └─ PASS → Continue
│ ├─ FAIL → 发现类型错误
│ └─ PASS → 继续
├─ Step 3: AI code review (with known blind spots in mind)
│ └─ Findings reported
├─ Step 3: AI代码审查(考虑已知盲点)
│ └─ 报告发现的问题
└─ Step 4: For each fix, write a regression test
└─ Next bug-check catches if fix breaks
└─ Step 4: 对每个修复编写回归测试
└─ 下次bug-check时捕获修复是否破坏功能
```
## 常见的 AI 回归模式
@@ -345,10 +345,10 @@ const handleRemove = async (id: string) => {
不要追求 100% 的覆盖率。相反:
```
Bug found in /api/user/profile → Write test for profile API
Bug found in /api/user/messages → Write test for messages API
Bug found in /api/user/favorites → Write test for favorites API
No bug in /api/user/notifications → Don't write test (yet)
/api/user/profile 发现 bug → 为 profile API 编写测试
/api/user/messages 发现 bug → 为 messages API 编写测试
/api/user/favorites 发现 bug → 为 favorites API 编写测试
/api/user/notifications 没有发现 bug → 暂时不编写测试
```
**为什么这在 AI 开发中有效:**

View File

@@ -22,13 +22,13 @@ origin: ECC
```
project/
├── app/ # Android entry point, DI wiring, Application class
├── core/ # Shared utilities, base classes, error types
├── domain/ # UseCases, domain models, repository interfaces (pure Kotlin)
├── data/ # Repository implementations, DataSources, DB, network
├── presentation/ # Screens, ViewModels, UI models, navigation
├── design-system/ # Reusable Compose components, theme, typography
└── feature/ # Feature modules (optional, for larger projects)
├── app/ # Android 入口点DI 装配,Application
├── core/ # 共享工具类,基类,错误类型
├── domain/ # 用例,领域模型,仓库接口(纯 Kotlin
├── data/ # 仓库实现,数据源,数据库,网络
├── presentation/ # 界面ViewModelUI 模型,导航
├── design-system/ # 可复用的 Compose 组件,主题,排版
└── feature/ # 功能模块(可选,用于大型项目)
├── auth/
├── settings/
└── profile/
@@ -37,11 +37,11 @@ project/
### 依赖规则
```
app → presentation, domain, data, core
presentation → domain, design-system, core
data → domain, core
domain → core (or no dependencies)
core → (nothing)
app → presentation, domain, data, core
presentation → domain, design-system, core
data → domain, core
domain → core (或无依赖)
core → (无依赖)
```
**关键**`domain` 绝不能依赖 `data``presentation` 或任何框架。它仅包含纯 Kotlin 代码。

View File

@@ -22,7 +22,7 @@ origin: ECC
### URL 结构
```
# Resources are nouns, plural, lowercase, kebab-case
# 资源使用名词、复数、小写、短横线连接
GET /api/v1/users
GET /api/v1/users/:id
POST /api/v1/users
@@ -30,11 +30,11 @@ PUT /api/v1/users/:id
PATCH /api/v1/users/:id
DELETE /api/v1/users/:id
# Sub-resources for relationships
# 用于关系的子资源
GET /api/v1/users/:id/orders
POST /api/v1/users/:id/orders
# Actions that don't map to CRUD (use verbs sparingly)
# 非 CRUD 映射的操作(谨慎使用动词)
POST /api/v1/orders/:id/cancel
POST /api/v1/auth/login
POST /api/v1/auth/refresh
@@ -43,16 +43,16 @@ POST /api/v1/auth/refresh
### 命名规则
```
# GOOD
/api/v1/team-members # kebab-case for multi-word resources
/api/v1/orders?status=active # query params for filtering
/api/v1/users/123/orders # nested resources for ownership
# 良好
/api/v1/team-members # 多单词资源使用 kebab-case
/api/v1/orders?status=active # 查询参数用于过滤
/api/v1/users/123/orders # 嵌套资源表示所有权关系
# BAD
/api/v1/getUsers # verb in URL
/api/v1/user # singular (use plural)
/api/v1/team_members # snake_case in URLs
/api/v1/users/123/getOrders # verb in nested resource
# 不良
/api/v1/getUsers # URL 中包含动词
/api/v1/user # 使用单数形式(应使用复数)
/api/v1/team_members # URL 中使用 snake_case
/api/v1/users/123/getOrders # 嵌套资源路径中包含动词
```
## HTTP 方法和状态码
@@ -72,41 +72,41 @@ POST /api/v1/auth/refresh
### 状态码参考
```
# Success
200 OK — GET, PUT, PATCH (with response body)
201 Created — POST (include Location header)
204 No Content — DELETE, PUT (no response body)
# 成功
200 OK — GETPUTPATCH(包含响应体)
201 Created — POST(包含 Location 头部)
204 No Content — DELETEPUT(无响应体)
# Client Errors
400 Bad Request — Validation failure, malformed JSON
401 Unauthorized — Missing or invalid authentication
403 Forbidden — Authenticated but not authorized
404 Not Found — Resource doesn't exist
409 Conflict — Duplicate entry, state conflict
422 Unprocessable Entity — Semantically invalid (valid JSON, bad data)
429 Too Many Requests — Rate limit exceeded
# 客户端错误
400 Bad Request — 验证失败、JSON 格式错误
401 Unauthorized — 缺少或无效的身份验证
403 Forbidden — 已认证但未授权
404 Not Found — 资源不存在
409 Conflict — 重复条目、状态冲突
422 Unprocessable Entity — 语义无效JSON 格式正确但数据错误)
429 Too Many Requests — 超出速率限制
# Server Errors
500 Internal Server Error — Unexpected failure (never expose details)
502 Bad Gateway — Upstream service failed
503 Service Unavailable — Temporary overload, include Retry-After
# 服务器错误
500 Internal Server Error — 意外故障(切勿暴露细节)
502 Bad Gateway — 上游服务失败
503 Service Unavailable — 临时过载,需包含 Retry-After 头部
```
### 常见错误
```
# BAD: 200 for everything
# 错误:对所有请求都返回 200
{ "status": 200, "success": false, "error": "Not found" }
# GOOD: Use HTTP status codes semantically
# 正确:按语义使用 HTTP 状态码
HTTP/1.1 404 Not Found
{ "error": { "code": "not_found", "message": "User not found" } }
# BAD: 500 for validation errors
# GOOD: 400 or 422 with field-level details
# 错误:验证错误返回 500
# 正确:返回 400 422 并包含字段级详情
# BAD: 200 for created resources
# GOOD: 201 with Location header
# 错误:创建资源返回 200
# 正确:返回 201 并包含 Location 标头
HTTP/1.1 201 Created
Location: /api/v1/users/abc-123
```
@@ -202,7 +202,7 @@ interface ApiError {
```
GET /api/v1/users?page=2&per_page=20
# Implementation
# 实现
SELECT * FROM users
ORDER BY created_at DESC
LIMIT 20 OFFSET 20;
@@ -216,11 +216,11 @@ LIMIT 20 OFFSET 20;
```
GET /api/v1/users?cursor=eyJpZCI6MTIzfQ&limit=20
# Implementation
# 实现
SELECT * FROM users
WHERE id > :cursor_id
ORDER BY id ASC
LIMIT 21; -- fetch one extra to determine has_next
LIMIT 21; -- 多取一条以判断是否有下一页
```
```json
@@ -250,44 +250,44 @@ LIMIT 21; -- fetch one extra to determine has_next
### 过滤
```
# Simple equality
# 简单相等
GET /api/v1/orders?status=active&customer_id=abc-123
# Comparison operators (use bracket notation)
# 比较运算符(使用括号表示法)
GET /api/v1/products?price[gte]=10&price[lte]=100
GET /api/v1/orders?created_at[after]=2025-01-01
# Multiple values (comma-separated)
# 多个值(逗号分隔)
GET /api/v1/products?category=electronics,clothing
# Nested fields (dot notation)
# 嵌套字段(点表示法)
GET /api/v1/orders?customer.country=US
```
### 排序
```
# Single field (prefix - for descending)
# 单字段排序(前缀 - 表示降序)
GET /api/v1/products?sort=-created_at
# Multiple fields (comma-separated)
# 多字段排序(逗号分隔)
GET /api/v1/products?sort=-featured,price,-created_at
```
### 全文搜索
```
# Search query parameter
# 搜索查询参数
GET /api/v1/products?q=wireless+headphones
# Field-specific search
# 字段特定搜索
GET /api/v1/users?email=alice
```
### 稀疏字段集
```
# Return only specified fields (reduces payload)
# 仅返回指定字段(减少负载)
GET /api/v1/users?fields=id,name,email
GET /api/v1/orders?fields=id,total,status&include=customer.name
```
@@ -334,7 +334,7 @@ X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1640000000
# When exceeded
# 超出限制时
HTTP/1.1 429 Too Many Requests
Retry-After: 60
{
@@ -379,21 +379,21 @@ Accept: application/vnd.myapp.v2+json
### 版本控制策略
```
1. Start with /api/v1/ — don't version until you need to
2. Maintain at most 2 active versions (current + previous)
3. Deprecation timeline:
- Announce deprecation (6 months notice for public APIs)
- Add Sunset header: Sunset: Sat, 01 Jan 2026 00:00:00 GMT
- Return 410 Gone after sunset date
4. Non-breaking changes don't need a new version:
- Adding new fields to responses
- Adding new optional query parameters
- Adding new endpoints
5. Breaking changes require a new version:
- Removing or renaming fields
- Changing field types
- Changing URL structure
- Changing authentication method
1. 从 /api/v1/ 开始 —— 除非必要,否则不要急于版本化
2. 最多同时维护 2 个活跃版本(当前版本 + 前一个版本)
3. 弃用时间线:
- 宣布弃用(公共 API 需提前 6 个月通知)
- 添加 Sunset 响应头:Sunset: Sat, 01 Jan 2026 00:00:00 GMT
- 在弃用日期后返回 410 Gone 状态
4. 非破坏性变更无需创建新版本:
- 向响应中添加新字段
- 添加新的可选查询参数
- 添加新的端点
5. 破坏性变更需要创建新版本:
- 移除或重命名字段
- 更改字段类型
- 更改 URL 结构
- 更改身份验证方法
```
## 实现模式

View File

@@ -96,11 +96,11 @@ origin: ECC
```
docs/
└── adr/
├── README.md ← index of all ADRs
├── README.md ← 所有 ADR 的索引
├── 0001-use-nextjs.md
├── 0002-postgres-over-mongo.md
├── 0003-rest-over-graphql.md
└── template.md ← blank template for manual use
└── template.md ← 供手动使用的空白模板
```
### ADR 索引格式

View File

@@ -147,13 +147,13 @@ CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/cl
### 架构:双提示系统
```
PROMPT 1 (Orchestrator) PROMPT 2 (Sub-Agents)
PROMPT 1(协调器) PROMPT 2(子代理)
┌─────────────────────┐ ┌──────────────────────┐
Parse spec file │ │ Receive full context
Scan output dir │ deploys │ Read assigned number
Plan iteration │────────────│ Follow spec exactly
Assign creative dirs │ N agents │ Generate unique output
Manage waves │ │ Save to output dir
解析规范文件 │ │ 接收完整上下文
扫描输出目录 │ 部署 │ 读取分配编号
规划迭代 │────────────│ 严格遵循规范
分配创作目录 │ N个代理 │ 生成唯一输出
管理批次 │ │ 保存至输出目录
└─────────────────────┘ └──────────────────────┘
```
@@ -218,20 +218,20 @@ PROMPT 1 (Orchestrator) PROMPT 2 (Sub-Agents)
```
┌─────────────────────────────────────────────────────┐
CONTINUOUS CLAUDE ITERATION
持续 CLAUDE 迭代
│ │
│ 1. Create branch (continuous-claude/iteration-N) │
│ 2. Run claude -p with enhanced prompt
│ 3. (Optional) Reviewer pass — separate claude -p │
│ 4. Commit changes (claude generates message)
│ 5. Push + create PR (gh pr create) │
│ 6. Wait for CI checks (poll gh pr checks) │
│ 7. CI failure? → Auto-fix pass (claude -p) │
│ 8. Merge PR (squash/merge/rebase) │
│ 9. Return to main → repeat
│ 1. 创建分支 (continuous-claude/iteration-N)
│ 2. 使用增强提示运行 claude -p
│ 3. (可选) 审查者通过 — 单独的 claude -p
│ 4. 提交更改 (claude 生成提交信息)
│ 5. 推送 + 创建 PR (gh pr create)
│ 6. 等待 CI 检查 (轮询 gh pr checks)
│ 7. CI 失败? → 自动修复通过 (claude -p)
│ 8. 合并 PR (squash/merge/rebase)
│ 9. 返回 main → 重复
│ │
Limit by: --max-runs N | --max-cost $X
│ --max-duration 2h | completion signal
限制条件: --max-runs N | --max-cost $X │
│ --max-duration 2h | 完成信号
└─────────────────────────────────────────────────────┘
```
@@ -390,27 +390,27 @@ done
### 架构概述
```
RFC/PRD Document
RFC/PRD 文档
DECOMPOSITION (AI)
Break RFC into work units with dependency DAG
分解(AI
将 RFC 分解为具有依赖关系 DAG 的工作单元
┌──────────────────────────────────────────────────────┐
│ RALPH LOOP (up to 3 passes)
│ RALPH 循环(最多 3 轮)
│ │
For each DAG layer (sequential, by dependency):
针对每个 DAG 层级(按依赖关系顺序):
│ │
│ ┌── Quality Pipelines (parallel per unit) ───────┐
│ │ Each unit in its own worktree:
│ │ Research → Plan → Implement → Test → Review │
│ │ (depth varies by complexity tier)
│ ┌── 质量流水线(每个单元并行) ───────┐
│ │ 每个单元在其独立的工作树中:
│ │ 研究 → 规划 → 实现 → 测试 → 评审 │
│ │ (深度根据复杂度层级变化) │
│ └────────────────────────────────────────────────┘ │
│ │
│ ┌── Merge Queue ─────────────────────────────────┐ │
│ │ Rebase onto main → Run tests → Land or evict │
│ │ Evicted units re-enter with conflict context │
│ ┌── 合并队列 ─────────────────────────────────┐
│ │ 变基到主分支 → 运行测试 → 合并或移除 │
│ │ 被移除的单元携带冲突上下文重新进入 │
│ └────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────┘
@@ -442,9 +442,9 @@ interface WorkUnit {
依赖关系 DAG 决定了执行顺序:
```
Layer 0: [unit-a, unit-b] ← no deps, run in parallel
Layer 1: [unit-c] ← depends on unit-a
Layer 2: [unit-d, unit-e] ← depend on unit-c
Layer 0: [unit-a, unit-b] ← 无依赖,并行运行
Layer 1: [unit-c] ← 依赖于 unit-a
Layer 2: [unit-d, unit-e] ← 依赖于 unit-c
```
### 复杂度层级
@@ -484,13 +484,13 @@ Layer 2: [unit-d, unit-e] ← depend on unit-c
```
Unit branch
├─ Rebase onto main
│ └─ Conflict? → EVICT (capture conflict context)
├─ 变基到 main 分支
│ └─ 冲突?→ 移除(捕获冲突上下文)
├─ Run build + tests
│ └─ Fail? → EVICT (capture test output)
├─ 运行构建 + 测试
│ └─ 失败?→ 移除(捕获测试输出)
└─ Pass → Fast-forward main, push, delete branch
└─ 通过 → 快进合并 main 分支,推送,删除分支
```
**文件重叠智能:**
@@ -513,13 +513,13 @@ Unit branch
### 阶段间的数据流
```
research.contextFilePath ──────────────────→ plan
plan.implementationSteps ──────────────────→ implement
implement.{filesCreated, whatWasDone} ─────→ test, reviews
test.failingSummary ───────────────────────→ reviews, implement (next pass)
reviews.{feedback, issues} ────────────────→ review-fix → implement (next pass)
final-review.reasoning ────────────────────→ implement (next pass)
evictionContext ───────────────────────────→ implement (after merge conflict)
research.contextFilePath ──────────────────→ 方案
plan.implementationSteps ──────────────────→ 实施
implement.{filesCreated, whatWasDone} ─────→ 测试, 审查
test.failingSummary ───────────────────────→ 审查, 实施(下一轮)
reviews.{feedback, issues} ────────────────→ 审查修复 → 实施(下一轮)
final-review.reasoning ────────────────────→ 实施(下一轮)
evictionContext ───────────────────────────→ 实施(合并冲突后)
```
### 工作树隔离
@@ -560,15 +560,15 @@ evictionContext ─────────────────────
### 决策矩阵
```
Is the task a single focused change?
├─ Yes → Sequential Pipeline or NanoClaw
└─ NoIs there a written spec/RFC?
├─ Yes → Do you need parallel implementation?
│ ├─ Yes → Ralphinho (DAG orchestration)
│ └─ No → Continuous Claude (iterative PR loop)
└─ NoDo you need many variations of the same thing?
├─ Yes → Infinite Agentic Loop (spec-driven generation)
└─ NoSequential Pipeline with de-sloppify
该任务是否是一个单一的、专注的变更?
├─ 是 → 顺序管道或NanoClaw
└─ 是否有书面的规范/RFC
├─ 有 → 是否需要并行实现?
│ ├─ → RalphinhoDAG编排)
│ └─ → Continuous Claude迭代式PR循环
└─ 是否需要同一事物的多种变体?
├─ 是 → 无限代理循环(规范驱动生成)
└─ 顺序管道与去杂乱化
```
### 模式组合

View File

@@ -33,7 +33,7 @@ Blueprint 自动检测 git/gh 可用性。如果具备 git + GitHub CLI它会
### 基本用法
```
/blueprint myapp "migrate database to PostgreSQL"
/blueprint myapp "将数据库迁移到PostgreSQL"
```
生成 `plans/myapp-migrate-database-to-postgresql.md`,包含类似以下的步骤:
@@ -47,7 +47,7 @@ Blueprint 自动检测 git/gh 可用性。如果具备 git + GitHub CLI它会
### 多代理项目
```
/blueprint chatbot "extract LLM providers into a plugin system"
/blueprint chatbot "将LLM提供商提取到插件系统中"
```
生成一个尽可能包含并行步骤的计划(例如,在插件接口步骤完成后,“实现 Anthropic 插件”和“实现 OpenAI 插件”可以并行运行),分配模型层级(接口设计步骤使用最强模型,实现步骤使用默认模型),并在每个步骤后验证不变量(例如“所有现有测试通过”、“核心模块无提供商导入”)。

View File

@@ -19,21 +19,21 @@ claude mcp add devfleet --transport http http://localhost:18801/mcp
## 工作原理
```
User → "Build a REST API with auth and tests"
用户 → "构建一个带有身份验证和测试的 REST API"
plan_project(prompt) → project_id + mission DAG
plan_project(prompt) → 项目ID + 任务DAG
Show plan to user → get approval
向用户展示计划 → 获取批准
dispatch_mission(M1) → Agent 1 spawns in worktree
dispatch_mission(M1) → 代理1在工作树中生成
M1 completes → auto-merge → auto-dispatch M2 (depends_on M1)
M1完成 → 自动合并 → 自动分发M2 (依赖于M1)
M2 completes → auto-merge
M2完成 → 自动合并
get_report(M2) → files_changed, what_done, errors, next_steps
get_report(M2) → 更改的文件、完成的工作、错误、后续步骤
Report back to user
向用户报告
```
### 工具

View File

@@ -23,28 +23,28 @@ origin: ECC
在不阅读每个文件的情况下,收集关于项目的原始信息。并行运行以下检查:
```
1. Package manifest detection
→ package.json, go.mod, Cargo.toml, pyproject.toml, pom.xml, build.gradle,
Gemfile, composer.json, mix.exs, pubspec.yaml
1. 包清单检测
→ package.jsongo.modCargo.tomlpyproject.tomlpom.xmlbuild.gradle
Gemfilecomposer.jsonmix.exspubspec.yaml
2. Framework fingerprinting
→ next.config.*, nuxt.config.*, angular.json, vite.config.*,
django settings, flask app factory, fastapi main, rails config
2. 框架指纹识别
→ next.config.*nuxt.config.*angular.jsonvite.config.*
django 设置、flask 应用工厂、fastapi 主程序、rails 配置
3. Entry point identification
→ main.*, index.*, app.*, server.*, cmd/, src/main/
3. 入口点识别
→ main.*index.*app.*server.*cmd/src/main/
4. Directory structure snapshot
Top 2 levels of the directory tree, ignoring node_modules, vendor,
.git, dist, build, __pycache__, .next
4. 目录结构快照
目录树的前 2 层,忽略 node_modulesvendor
.gitdistbuild__pycache__.next
5. Config and tooling detection
→ .eslintrc*, .prettierrc*, tsconfig.json, Makefile, Dockerfile,
docker-compose*, .github/workflows/, .env.example, CI configs
5. 配置与工具检测
→ .eslintrc*.prettierrc*tsconfig.jsonMakefileDockerfile
docker-compose*.github/workflows/.env.exampleCI 配置
6. Test structure detection
→ tests/, test/, __tests__/, *_test.go, *.spec.ts, *.test.js,
pytest.ini, jest.config.*, vitest.config.*
6. 测试结构检测
→ tests/test/__tests__/*_test.go*.spec.ts*.test.js
pytest.inijest.config.*vitest.config.*
```
### 阶段 2架构映射
@@ -71,12 +71,12 @@ origin: ECC
<!-- Example for a React project — replace with detected directories -->
```
src/components/ → React UI components
src/api/ → API route handlers
src/lib/ → Shared utilities
src/db/ → Database models and migrations
tests/ → Test suites
scripts/ → Build and deployment scripts
src/components/ → React UI 组件
src/api/ → API 路由处理程序
src/lib/ → 共享工具库
src/db/ → 数据库模型和迁移文件
tests/ → 测试套件
scripts/ → 构建和部署脚本
```
**数据流**

View File

@@ -244,14 +244,14 @@ setCount(count + 1) // Can be stale in async scenarios
### REST API 约定
```
GET /api/markets # List all markets
GET /api/markets/:id # Get specific market
POST /api/markets # Create new market
PUT /api/markets/:id # Update market (full)
PATCH /api/markets/:id # Update market (partial)
DELETE /api/markets/:id # Delete market
GET /api/markets # 列出所有市场
GET /api/markets/:id # 获取特定市场
POST /api/markets # 创建新市场
PUT /api/markets/:id # 更新市场(完整)
PATCH /api/markets/:id # 更新市场(部分)
DELETE /api/markets/:id # 删除市场
# Query parameters for filtering
# 用于筛选的查询参数
GET /api/markets?status=active&limit=10&offset=0
```
@@ -341,10 +341,10 @@ src/
### 文件命名
```
components/Button.tsx # PascalCase for components
hooks/useAuth.ts # camelCase with 'use' prefix
lib/formatDate.ts # camelCase for utilities
types/market.types.ts # camelCase with .types suffix
components/Button.tsx # 组件使用帕斯卡命名法
hooks/useAuth.ts # 使用 'use' 前缀的驼峰命名法
lib/formatDate.ts # 工具函数使用驼峰命名法
types/market.types.ts # 使用 .types 后缀的驼峰命名法
```
## 注释与文档

View File

@@ -44,11 +44,11 @@ git clone https://github.com/affaan-m/everything-claude-code.git /tmp/everything
使用 `AskUserQuestion` 询问用户安装位置:
```
Question: "Where should ECC components be installed?"
Options:
- "User-level (~/.claude/)" — "Applies to all your Claude Code projects"
- "Project-level (.claude/)" — "Applies only to the current project"
- "Both" — "Common/shared items user-level, project-specific items project-level"
问题:"ECC组件应安装在哪里"
选项:
- "用户级别 (~/.claude/)" — "适用于您所有的Claude Code项目"
- "项目级别 (.claude/)" — "仅适用于当前项目"
- "两者" — "通用/共享项在用户级别,项目特定项在项目级别"
```
将选择存储为 `INSTALL_LEVEL`。设置目标目录:
@@ -74,12 +74,12 @@ mkdir -p $TARGET/skills $TARGET/rules
使用 `AskUserQuestion`(单选):
```
Question: "Install core skills only, or include niche/framework packs?"
Options:
- "Core only (recommended)" — "tdd, e2e, evals, verification, research-first, security, frontend patterns, compacting, cross-functional Anthropic skills"
- "Core + selected niche" — "Add framework/domain-specific skills after core"
- "Niche only" — "Skip core, install specific framework/domain skills"
Default: Core only
问题:"只安装核心技能,还是包含小众/框架包?"
选项:
- "仅核心(推荐)" — "tdd, e2e, evals, verification, research-first, security, frontend patterns, compacting, cross-functional Anthropic skills"
- "核心 + 精选小众" — "在核心基础上添加框架/领域特定技能"
- "仅小众" — "跳过核心,安装特定框架/领域技能"
默认:仅核心
```
如果用户选择细分领域或核心 + 细分领域,则继续下面的类别选择,并且仅包含他们选择的那些细分领域技能。
@@ -89,16 +89,16 @@ Default: Core only
下方有7个可选的类别组。后续的详细确认列表涵盖了8个类别中的45项技能外加1个独立模板。使用 `AskUserQuestion``multiSelect: true`
```
Question: "Which skill categories do you want to install?"
Options:
- "Framework & Language""Django, Laravel, Spring Boot, Go, Python, Java, Frontend, Backend patterns"
- "Database""PostgreSQL, ClickHouse, JPA/Hibernate patterns"
- "Workflow & Quality""TDD, verification, learning, security review, compaction"
- "Research & APIs""Deep research, Exa search, Claude API patterns"
- "Social & Content Distribution""X/Twitter API, crossposting alongside content-engine"
- "Media Generation""fal.ai image/video/audio alongside VideoDB"
- "Orchestration""dmux multi-agent workflows"
- "All skills" — "Install every available skill"
问题:“您希望安装哪些技能类别?”
选项:
- “框架与语言”Django, Laravel, Spring Boot, Go, Python, Java, 前端, 后端模式”
- “数据库”PostgreSQL, ClickHouse, JPA/Hibernate 模式”
- “工作流与质量”TDD, 验证, 学习, 安全审查, 压缩”
- “研究与 API“深度研究, Exa 搜索, Claude API 模式”
- “社交与内容分发”X/Twitter API, 内容引擎并行交叉发布”
- “媒体生成”fal.ai 图像/视频/音频与 VideoDB 并行”
- “编排”dmux 多智能体工作流”
- “所有技能” — “安装所有可用技能”
```
### 2c: 确认个人技能
@@ -213,12 +213,12 @@ cp -r $ECC_ROOT/skills/<skill-name> $TARGET/skills/
使用 `AskUserQuestion``multiSelect: true`
```
Question: "Which rule sets do you want to install?"
Options:
- "Common rules (Recommended)" — "Language-agnostic principles: coding style, git workflow, testing, security, etc. (8 files)"
- "TypeScript/JavaScript" — "TS/JS patterns, hooks, testing with Playwright (5 files)"
- "Python" — "Python patterns, pytest, black/ruff formatting (5 files)"
- "Go" — "Go patterns, table-driven tests, gofmt/staticcheck (5 files)"
问题:"您希望安装哪些规则集?"
选项:
- "通用规则(推荐)" — "语言无关原则编码风格、Git工作流、测试、安全等8个文件"
- "TypeScript/JavaScript" — "TS/JS模式、钩子、Playwright测试5个文件"
- "Python" — "Python模式、pytestblack/ruff格式化5个文件"
- "Go" — "Go模式、表驱动测试、gofmt/staticcheck5个文件"
```
执行安装:
@@ -300,12 +300,12 @@ grep -rn "skills/" $TARGET/skills/
使用 `AskUserQuestion`
```
Question: "Would you like to optimize the installed files for your project?"
Options:
- "Optimize skills" — "Remove irrelevant sections, adjust paths, tailor to your tech stack"
- "Optimize rules" — "Adjust coverage targets, add project-specific patterns, customize tool configs"
- "Optimize both" — "Full optimization of all installed files"
- "Skip" — "Keep everything as-is"
问题:"您想要优化项目中的已安装文件吗?"
选项:
- "优化技能" — "移除无关部分,调整路径,适配您的技术栈"
- "优化规则" — "调整覆盖目标,添加项目特定模式,自定义工具配置"
- "两者都优化" — "对所有已安装文件进行全面优化"
- "跳过" — "保持原样不变"
```
### 如果优化技能:
@@ -341,26 +341,26 @@ rm -rf /tmp/everything-claude-code
然后打印摘要报告:
```
## ECC Installation Complete
## ECC 安装完成
### Installation Target
- Level: [user-level / project-level / both]
- Path: [target path]
### 安装目标
- 级别:[用户级别 / 项目级别 / 两者]
- 路径:[目标路径]
### Skills Installed ([count])
- skill-1, skill-2, skill-3, ...
### 已安装技能 ([数量])
- 技能-1, 技能-2, 技能-3, ...
### Rules Installed ([count])
- common (8 files)
- typescript (5 files)
### 已安装规则 ([数量])
- 通用规则 (8 个文件)
- TypeScript 规则 (5 个文件)
- ...
### Verification Results
- [count] issues found, [count] fixed
- [list any remaining issues]
### 验证结果
- 发现 [数量] 个问题,已修复 [数量] 个
- [列出任何剩余问题]
### Optimizations Applied
- [list changes made, or "None"]
### 已应用的优化
- [列出所做的更改,或 "无"]
```
***

View File

@@ -76,16 +76,16 @@ origin: ECC
生成上下文预算报告:
```
Context Budget Report
上下文预算报告
═══════════════════════════════════════
Total estimated overhead: ~XX,XXX tokens
Context model: Claude Sonnet (200K window)
Effective available context: ~XXX,XXX tokens (XX%)
总预估开销:约 XX,XXX 个词元
上下文模型:Claude Sonnet (200K 窗口)
有效可用上下文:约 XXX,XXX 个词元 (XX%)
Component Breakdown:
组件细分:
┌─────────────────┬────────┬───────────┐
Component │ Count │ Tokens
组件 │ 数量 │ 词元数
├─────────────────┼────────┼───────────┤
│ Agents │ N │ ~X,XXX │
│ Skills │ N │ ~X,XXX │
@@ -94,15 +94,15 @@ Component Breakdown:
│ CLAUDE.md │ N │ ~X,XXX │
└─────────────────┴────────┴───────────┘
Issues Found (N):
[ranked by token savings]
发现的问题 (N)
[按可节省词元数排序]
Top 3 Optimizations:
1. [action] → save ~X,XXX tokens
2. [action] → save ~X,XXX tokens
3. [action] → save ~X,XXX tokens
前 3 项优化建议:
1. [action] → 节省约 X,XXX 个词元
2. [action] → 节省约 X,XXX 个词元
3. [action] → 节省约 X,XXX 个词元
Potential savings: ~XX,XXX tokens (XX% of current overhead)
潜在节省空间:约 XX,XXX 个词元 (占当前开销的 XX%)
```
在详细模式下,额外输出每个文件的令牌计数、最繁重文件的行级细分、重叠组件之间的具体冗余行,以及 MCP 工具列表和每个工具模式大小的估算。
@@ -112,26 +112,26 @@ Potential savings: ~XX,XXX tokens (XX% of current overhead)
**基本审计**
```
User: /context-budget
Skill: Scans setup → 16 agents (12,400 tokens), 28 skills (6,200), 87 MCP tools (43,500), 2 CLAUDE.md (1,200)
Flags: 3 heavy agents, 14 MCP servers (3 CLI-replaceable)
Top saving: remove 3 MCP servers → -27,500 tokens (47% overhead reduction)
/context-budget
技能:扫描设置 → 16个代理12,400个令牌28个技能6,20087MCP工具(43,5002个CLAUDE.md1,200
标记3个重型代理14MCP服务器3个可替换为CLI
最高节省移除3个MCP服务器 → -27,500个令牌减少47%开销)
```
**详细模式**
```
User: /context-budget --verbose
Skill: Full report + per-file breakdown showing planner.md (213 lines, 1,840 tokens),
MCP tool list with per-tool sizes, duplicated rule lines side by side
/context-budget --verbose
技能:完整报告 + 按文件细目显示 planner.md213 1,840 个令牌),
MCP 工具列表及每个工具的大小,重复规则行并排显示
```
**扩容前检查**
```
User: I want to add 5 more MCP servers, do I have room?
Skill: Current overhead 33% → adding 5 servers (~50 tools) would add ~25,000 tokens → pushes to 45% overhead
Recommendation: remove 2 CLI-replaceable servers first to stay under 40%
User: 我想再添加5个MCP服务器有空间吗
Skill: 当前开销33% → 添加5个服务器约50个工具会增加约25,000tokens → 开销将升至45%
建议先移除2个可用CLI替代的服务器以保持在40%以下
```
## 最佳实践

View File

@@ -13,11 +13,11 @@ origin: ECC
```text
Start
|
+-- Need strict CI/PR control? -- yes --> continuous-pr
+-- 需要严格的 CI/PR 控制? -- yes --> continuous-pr
|
+-- Need RFC decomposition? -- yes --> rfc-dag
+-- 需要 RFC 分解? -- yes --> rfc-dag
|
+-- Need exploratory parallel generation? -- yes --> infinite
+-- 需要探索性并行生成? -- yes --> infinite
|
+-- default --> sequential
```

View File

@@ -82,43 +82,43 @@ Use functional patterns over classes when appropriate.
## 工作原理
```
Session Activity (in a git repo)
会话活动(在 git 仓库中)
|
| Hooks capture prompts + tool use (100% reliable)
| + detect project context (git remote / repo path)
| 钩子捕获提示 + 工具使用100% 可靠)
| + 检测项目上下文(git remote / 仓库路径)
v
+---------------------------------------------+
| projects/<project-hash>/observations.jsonl |
| (prompts, tool calls, outcomes, project) |
| (提示、工具调用、结果、项目) |
+---------------------------------------------+
|
| Observer agent reads (background, Haiku)
| 观察者代理读取(后台,Haiku
v
+---------------------------------------------+
| PATTERN DETECTION |
| * User corrections -> instinct |
| * Error resolutions -> instinct |
| * Repeated workflows -> instinct |
| * Scope decision: project or global? |
| 模式检测 |
| * 用户修正 -> 直觉 |
| * 错误解决 -> 直觉 |
| * 重复工作流 -> 直觉 |
| * 范围决策:项目级或全局? |
+---------------------------------------------+
|
| Creates/updates
| 创建/更新
v
+---------------------------------------------+
| projects/<project-hash>/instincts/personal/ |
| * prefer-functional.yaml (0.7) [project] |
| * use-react-hooks.yaml (0.9) [project] |
| * prefer-functional.yaml (0.7) [项目] |
| * use-react-hooks.yaml (0.9) [项目] |
+---------------------------------------------+
| instincts/personal/ (GLOBAL) |
| * always-validate-input.yaml (0.85) [global]|
| * grep-before-edit.yaml (0.6) [global] |
| instincts/personal/ (全局) |
| * always-validate-input.yaml (0.85) [全局] |
| * grep-before-edit.yaml (0.6) [全局] |
+---------------------------------------------+
|
| /evolve clusters + /promote
| /evolve 聚类 + /promote
v
+---------------------------------------------+
| projects/<hash>/evolved/ (project-scoped) |
| evolved/ (global) |
| projects/<hash>/evolved/ (项目范围) |
| evolved/ (全局) |
| * commands/new-feature.md |
| * skills/testing-workflow.md |
| * agents/refactor-specialist.md |
@@ -248,29 +248,29 @@ mkdir -p ~/.claude/homunculus/{instincts/{personal,inherited},evolved/{agents,sk
```
~/.claude/homunculus/
+-- identity.json # Your profile, technical level
+-- projects.json # Registry: project hash -> name/path/remote
+-- observations.jsonl # Global observations (fallback)
+-- identity.json # 你的个人资料,技术水平
+-- projects.json # 注册表:项目哈希 -> 名称/路径/远程地址
+-- observations.jsonl # 全局观察记录(备用)
+-- instincts/
| +-- personal/ # Global auto-learned instincts
| +-- inherited/ # Global imported instincts
| +-- personal/ # 全局自动学习的本能
| +-- inherited/ # 全局导入的本能
+-- evolved/
| +-- agents/ # Global generated agents
| +-- skills/ # Global generated skills
| +-- commands/ # Global generated commands
| +-- agents/ # 全局生成的代理
| +-- skills/ # 全局生成的技能
| +-- commands/ # 全局生成的命令
+-- projects/
+-- a1b2c3d4e5f6/ # Project hash (from git remote URL)
| +-- project.json # Per-project metadata mirror (id/name/root/remote)
+-- a1b2c3d4e5f6/ # 项目哈希(来自 git 远程 URL
| +-- project.json # 项目级元数据镜像ID/名称/根目录/远程地址)
| +-- observations.jsonl
| +-- observations.archive/
| +-- instincts/
| | +-- personal/ # Project-specific auto-learned
| | +-- inherited/ # Project-specific imported
| | +-- personal/ # 项目特定自动学习的
| | +-- inherited/ # 项目特定导入的
| +-- evolved/
| +-- skills/
| +-- commands/
| +-- agents/
+-- f6e5d4c3b2a1/ # Another project
+-- f6e5d4c3b2a1/ # 另一个项目
+-- ...
```

View File

@@ -102,35 +102,35 @@ origin: ECC
**X 版本:**
```
We just shipped [feature].
我们刚刚发布了 [feature]
[One specific thing it does that's impressive]
[它所实现的某个具体且令人印象深刻的功能]
[Link]
[链接]
```
**LinkedIn 版本:**
```
Excited to share: we just launched [feature] at [Company].
激动地宣布:我们刚刚在[Company]推出了[feature]。
Here's why it matters:
以下是其重要意义:
[2-3 short paragraphs with context]
[2-3段简短背景说明]
[Takeaway for the audience]
[对受众的核心启示]
[Link]
[链接]
```
**Threads 版本:**
```
just shipped something cool — [feature]
刚发布了一个很酷的东西 —— [feature]
[casual explanation of what it does]
[对这个功能是什么的随意解释]
link in bio
链接在简介里
```
### 源内容:技术见解
@@ -138,21 +138,21 @@ link in bio
**X 版本:**
```
TIL: [specific technical insight]
今天学到:[具体技术见解]
[Why it matters in one sentence]
[一句话说明其重要性]
```
**LinkedIn 版本:**
```
A pattern I've been using that's made a real difference:
我一直在使用的一种模式,它带来了真正的改变:
[Technical insight with professional framing]
[技术见解与专业框架]
[How it applies to teams/orgs]
[它如何适用于团队/组织]
#relevantHashtag
#相关标签
```
## API 集成

View File

@@ -101,34 +101,34 @@ for batch in chunks(items, size=5):
```
my-agent/
├── config.yaml # User customises this (keywords, filters, preferences)
├── config.yaml # 用户自定义此文件(关键词、过滤器、偏好设置)
├── profile/
│ └── context.md # User context the AI uses (resume, interests, criteria)
│ └── context.md # AI 使用的用户上下文(简历、兴趣、标准)
├── scraper/
│ ├── __init__.py
│ ├── main.py # Orchestrator: scrape → enrich → store
│ ├── filters.py # Rule-based pre-filter (fast, before AI)
│ ├── main.py # 协调器:抓取 → 丰富 → 存储
│ ├── filters.py # 基于规则的预过滤器(快速,在 AI 处理之前)
│ └── sources/
│ ├── __init__.py
│ └── source_name.py # One file per data source
│ └── source_name.py # 每个数据源一个文件
├── ai/
│ ├── __init__.py
│ ├── client.py # Gemini REST client with model fallback
│ ├── pipeline.py # Batch AI analysis
│ ├── jd_fetcher.py # Fetch full content from URLs (optional)
│ └── memory.py # Learn from user feedback
│ ├── client.py # Gemini REST 客户端,带模型回退
│ ├── pipeline.py # 批量 AI 分析
│ ├── jd_fetcher.py # 从 URL 获取完整内容(可选)
│ └── memory.py # 从用户反馈中学习
├── storage/
│ ├── __init__.py
│ └── notion_sync.py # Or sheets_sync.py / supabase_sync.py
│ └── notion_sync.py # sheets_sync.py / supabase_sync.py
├── data/
│ └── feedback.json # User decision history (auto-updated)
│ └── feedback.json # 用户决策历史(自动更新)
├── .env.example
├── setup.py # One-time DB/schema creation
├── enrich_existing.py # Backfill AI scores on old rows
├── setup.py # 一次性数据库/模式创建
├── enrich_existing.py # 对旧行进行 AI 分数回填
├── requirements.txt
└── .github/
└── workflows/
└── scraper.yml # GitHub Actions schedule
└── scraper.yml # GitHub Actions 计划任务
```
***
@@ -725,8 +725,8 @@ beautifulsoup4==4.12.3
lxml==5.1.0
python-dotenv==1.0.1
pyyaml==6.0.2
notion-client==2.2.1 # if using Notion
# playwright==1.40.0 # uncomment for JS-rendered sites
notion-client==2.2.1 # 如需使用 Notion
# playwright==1.40.0 # 针对 JS 渲染的站点,请取消注释
```
***
@@ -753,14 +753,14 @@ notion-client==2.2.1 # if using Notion
## 真实世界示例
```
"Build me an agent that monitors Hacker News for AI startup funding news"
"Scrape product prices from 3 e-commerce sites and alert when they drop"
"Track new GitHub repos tagged with 'llm' or 'agents' — summarise each one"
"Collect Chief of Staff job listings from LinkedIn and Cutshort into Notion"
"Monitor a subreddit for posts mentioning my company — classify sentiment"
"Scrape new academic papers from arXiv on a topic I care about daily"
"Track sports fixture results and keep a running table in Google Sheets"
"Build a real estate listing watcher — alert on new properties under ₹1 Cr"
"为我构建一个监控 Hacker News AI 初创公司融资新闻的智能体"
"从 3 家电商网站抓取产品价格并在降价时发出提醒"
"追踪标记有 'llm' 'agents' 的新 GitHub 仓库——并为每个仓库生成摘要"
" LinkedIn Cutshort 上的首席运营官职位列表收集到 Notion"
"监控一个提到我公司的 subreddit 帖子——并进行情感分类"
"每日从 arXiv 抓取我关注主题的新学术论文"
"追踪体育赛事结果并在 Google Sheets 中维护动态更新的表格"
"构建一个房地产房源监控器——在新房源价格低于 1 千万卢比时发出提醒"
```
***

View File

@@ -300,27 +300,27 @@ ALTER TABLE users DROP COLUMN IF EXISTS avatar_url;
```
Phase 1: EXPAND
- Add new column/table (nullable or with default)
- Deploy: app writes to BOTH old and new
- Backfill existing data
- 添加新列/表(可为空或带有默认值)
- 部署:应用同时写入旧数据和新数据
- 回填现有数据
Phase 2: MIGRATE
- Deploy: app reads from NEW, writes to BOTH
- Verify data consistency
- 部署:应用读取新数据,同时写入新旧数据
- 验证数据一致性
Phase 3: CONTRACT
- Deploy: app only uses NEW
- Drop old column/table in separate migration
- 部署:应用仅使用新数据
- 在单独迁移中删除旧列/表
```
### 时间线示例
```
Day 1: Migration adds new_status column (nullable)
Day 1: Deploy app v2 — writes to both status and new_status
Day 2: Run backfill migration for existing rows
Day 3: Deploy app v3 — reads from new_status only
Day 7: Migration drops old status column
Day 1:迁移添加新的 `new_status` 列(可空)
Day 1:部署应用 v2 —— 同时写入 `status` 和 `new_status`
Day 2:运行针对现有行的回填迁移
Day 3:部署应用 v3 —— 仅从 `new_status` 读取
Day 7:迁移删除旧的 `status` 列
```
## 反模式

View File

@@ -60,8 +60,8 @@ firecrawl_search(query: "<sub-question keywords>", limit: 8)
**使用 exa**
```
web_search_exa(query: "<sub-question keywords>", numResults: 8)
web_search_advanced_exa(query: "<keywords>", numResults: 5, startPublishedDate: "2025-01-01")
web_search_exa(query: "<子问题关键词>", numResults: 8)
web_search_advanced_exa(query: "<关键词>", numResults: 5, startPublishedDate: "2025-01-01")
```
**搜索策略:**
@@ -135,10 +135,10 @@ crawling_exa(url: "<url>", tokensNum: 5000)
对于广泛的主题,使用 Claude Code 的 Task 工具进行并行处理:
```
Launch 3 research agents in parallel:
1. Agent 1: Research sub-questions 1-2
2. Agent 2: Research sub-questions 3-4
3. Agent 3: Research sub-question 5 + cross-cutting themes
并行启动3个研究代理
1. 代理1研究子问题1-2
2. 代理2研究子问题3-4
3. 代理3研究子问题5 + 交叉主题
```
每个代理负责搜索、阅读来源并返回发现结果。主会话将其综合成最终报告。
@@ -155,9 +155,9 @@ Launch 3 research agents in parallel:
## 示例
```
"Research the current state of nuclear fusion energy"
"Deep dive into Rust vs Go for backend services in 2026"
"Research the best strategies for bootstrapping a SaaS business"
"What's happening with the US housing market right now?"
"Investigate the competitive landscape for AI code editors"
"研究核聚变能源的当前现状"
"深入探讨 2026 年 Rust Go 在后端服务中的对比"
"研究自举 SaaS 业务的最佳策略"
"美国房地产市场目前情况如何?"
"调查 AI 代码编辑器的竞争格局"
```

View File

@@ -24,17 +24,17 @@ origin: ECC
逐步替换实例——在发布过程中,新旧版本同时运行。
```
Instance 1: v1 → v2 (update first)
Instance 2: v1 (still running v1)
Instance 3: v1 (still running v1)
实例 1: v1 → v2 (首次更新)
实例 2: v1 (仍在运行 v1)
实例 3: v1 (仍在运行 v1)
Instance 1: v2
Instance 2: v1 → v2 (update second)
Instance 3: v1
实例 1: v2
实例 2: v1 → v2 (第二次更新)
实例 3: v1
Instance 1: v2
Instance 2: v2
Instance 3: v1 → v2 (update last)
实例 1: v2
实例 2: v2
实例 3: v1 → v2 (最后更新)
```
**优点:** 零停机时间,渐进式发布
@@ -46,12 +46,12 @@ Instance 3: v1 → v2 (update last)
运行两个相同的环境。原子化地切换流量。
```
Blue (v1) ← traffic
Green (v2) idle, running new version
Blue (v1) ← 流量
Green (v2) 空闲,运行新版本
# After verification:
Blue (v1) idle (becomes standby)
Green (v2) ← traffic
# 验证后:
Blue (v1) 空闲(转为备用状态)
Green (v2) ← 流量
```
**优点:** 即时回滚(切换回蓝色环境),切换干净利落
@@ -63,15 +63,15 @@ Green (v2) ← traffic
首先将一小部分流量路由到新版本。
```
v1: 95% of traffic
v2: 5% of traffic (canary)
v195% 的流量
v25% 的流量(金丝雀)
# If metrics look good:
v1: 50% of traffic
v2: 50% of traffic
# 如果指标表现良好:
v150% 的流量
v250% 的流量
# Final:
v2: 100% of traffic
# 最终:
v2100% 的流量
```
**优点:** 在全量发布前,通过真实流量发现问题
@@ -168,21 +168,21 @@ CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000", "--workers
### Docker 最佳实践
```
# GOOD practices
- Use specific version tags (node:22-alpine, not node:latest)
- Multi-stage builds to minimize image size
- Run as non-root user
- Copy dependency files first (layer caching)
- Use .dockerignore to exclude node_modules, .git, tests
- Add HEALTHCHECK instruction
- Set resource limits in docker-compose or k8s
# 良好实践
- 使用特定版本标签(node:22-alpine,而非 node:latest
- 采用多阶段构建以最小化镜像体积
- 以非 root 用户身份运行
- 优先复制依赖文件(利用分层缓存)
- 使用 .dockerignore 排除 node_modules.gittests 等文件
- 添加 HEALTHCHECK 指令
- docker-compose k8s 中设置资源限制
# BAD practices
- Running as root
- Using :latest tags
- Copying entire repo in one COPY layer
- Installing dev dependencies in production image
- Storing secrets in image (use env vars or secrets manager)
# 不良实践
- 以 root 身份运行
- 使用 :latest 标签
- 在单个 COPY 层中复制整个仓库
- 在生产镜像中安装开发依赖
- 在镜像中存储密钥(应使用环境变量或密钥管理器)
```
## CI/CD 流水线
@@ -254,11 +254,11 @@ jobs:
### 流水线阶段
```
PR opened:
lint → typecheck → unit tests → integration tests → preview deploy
PR 已开启:
lint → typecheck → 单元测试 → 集成测试 → 预览部署
Merged to main:
lint → typecheck → unit tests → integration tests → build image → deploy staging → smoke tests → deploy production
合并到 main
lint → typecheck → 单元测试 → 集成测试 → 构建镜像 → 部署到 staging → 冒烟测试 → 部署到 production
```
## 健康检查

View File

@@ -26,10 +26,10 @@ myproject/
│ ├── __init__.py
│ ├── settings/
│ │ ├── __init__.py
│ │ ├── base.py # Base settings
│ │ ├── development.py # Dev settings
│ │ ├── production.py # Production settings
│ │ └── test.py # Test settings
│ │ ├── base.py # 基础设置
│ │ ├── development.py # 开发环境设置
│ │ ├── production.py # 生产环境设置
│ │ └── test.py # 测试环境设置
│ ├── urls.py
│ ├── wsgi.py
│ └── asgi.py

View File

@@ -289,86 +289,86 @@ git diff | grep "import pdb" # Debugger
## 输出模板
```
DJANGO VERIFICATION REPORT
DJANGO 验证报告
==========================
Phase 1: Environment Check
阶段 1环境检查
✓ Python 3.11.5
Virtual environment active
All environment variables set
虚拟环境已激活
所有环境变量已设置
Phase 2: Code Quality
✓ mypy: No type errors
✗ ruff: 3 issues found (auto-fixed)
✓ black: No formatting issues
✓ isort: Imports properly sorted
✓ manage.py check: No issues
阶段 2代码质量
✓ mypy: 无类型错误
✗ ruff: 发现 3 个问题(已自动修复)
✓ black: 无格式问题
✓ isort: 导入已正确排序
✓ manage.py check: 无问题
Phase 3: Migrations
No unapplied migrations
No migration conflicts
All models have migrations
阶段 3数据库迁移
无未应用的迁移
无迁移冲突
所有模型均有对应的迁移文件
Phase 4: Tests + Coverage
Tests: 247 passed, 0 failed, 5 skipped
Coverage:
Overall: 87%
阶段 4测试与覆盖率
测试247 通过0 失败5 跳过
覆盖率:
总计:87%
users: 92%
products: 89%
orders: 85%
payments: 91%
Phase 5: Security Scan
✗ pip-audit: 2 vulnerabilities found (fix required)
✓ safety check: No issues
✓ bandit: No security issues
No secrets detected
阶段 5安全扫描
✗ pip-audit: 发现 2 个漏洞(需要修复)
✓ safety check: 无问题
✓ bandit: 无安全问题
未检测到密钥泄露
✓ DEBUG = False
Phase 6: Django Commands
✓ collectstatic completed
Database integrity OK
Cache backend reachable
阶段 6Django 命令
✓ collectstatic 完成
数据库完整性正常
缓存后端可访问
Phase 7: Performance
No N+1 queries detected
Database indexes configured
Query count acceptable
阶段 7性能
未检测到 N+1 查询
数据库索引已配置
查询数量可接受
Phase 8: Static Assets
✓ npm audit: No vulnerabilities
Assets built successfully
Static files collected
阶段 8静态资源
✓ npm audit: 无漏洞
资源构建成功
静态文件已收集
Phase 9: Configuration
阶段 9配置
✓ DEBUG = False
✓ SECRET_KEY configured
✓ ALLOWED_HOSTS set
✓ HTTPS enabled
✓ HSTS enabled
Database configured
✓ SECRET_KEY 已配置
✓ ALLOWED_HOSTS 已设置
✓ HTTPS 已启用
✓ HSTS 已启用
数据库已配置
Phase 10: Logging
Logging configured
Log files writable
阶段 10日志
日志配置完成
日志文件可写入
Phase 11: API Documentation
Schema generated
✓ Swagger UI accessible
阶段 11API 文档
架构已生成
✓ Swagger UI 可访问
Phase 12: Diff Review
Files changed: 12
+450, -120 lines
No debug statements
No hardcoded secrets
Migrations included
阶段 12差异审查
文件变更:12
行数变化:+450, -120
无调试语句
无硬编码密钥
包含迁移文件
RECOMMENDATION: ⚠️ Fix pip-audit vulnerabilities before deploying
建议:⚠️ 部署前修复 pip-audit 发现的漏洞
NEXT STEPS:
1. Update vulnerable dependencies
2. Re-run security scan
3. Deploy to staging for final testing
后续步骤:
1. 更新存在漏洞的依赖项
2. 重新运行安全扫描
3. 部署到预发布环境进行最终测试
```
## 预部署检查清单

View File

@@ -47,14 +47,14 @@ dmux
将研究和实现拆分为并行轨道:
```
Pane 1 (Research): "Research best practices for rate limiting in Node.js.
Check current libraries, compare approaches, and write findings to
Pane 1 (Research): "研究 Node.js 中速率限制的最佳实践。
检查当前可用的库,比较不同方法,并将研究结果写入
/tmp/rate-limit-research.md"
Pane 2 (Implement): "Implement rate limiting middleware for our Express API.
Start with a basic token bucket, we'll refine after research completes."
Pane 2 (Implement): "为我们的 Express API 实现速率限制中间件。
先从基本的令牌桶算法开始,研究完成后我们将进一步优化。"
# After Pane 1 completes, merge findings into Pane 2's context
# Pane 1 完成后,将研究结果合并到 Pane 2 的上下文中
```
### 模式 2多文件功能
@@ -62,11 +62,11 @@ Pane 2 (Implement): "Implement rate limiting middleware for our Express API.
在独立文件间并行工作:
```
Pane 1: "Create the database schema and migrations for the billing feature"
Pane 2: "Build the billing API endpoints in src/api/billing/"
Pane 3: "Create the billing dashboard UI components"
Pane 1: "创建计费功能的数据库模式和迁移"
Pane 2: " src/api/billing/ 中构建计费 API 端点"
Pane 3: "创建计费仪表板 UI 组件"
# Merge all, then do integration in main pane
# 合并所有内容,然后在主面板中进行集成
```
### 模式 3测试 + 修复循环
@@ -74,10 +74,10 @@ Pane 3: "Create the billing dashboard UI components"
在一个窗格中运行测试,在另一个窗格中修复:
```
Pane 1 (Watcher): "Run the test suite in watch mode. When tests fail,
summarize the failures."
窗格 1观察者“在监视模式下运行测试套件。当测试失败时
总结失败原因。”
Pane 2 (Fixer): "Fix failing tests based on the error output from pane 1"
窗格 2修复者“根据窗格 1 的错误输出修复失败的测试”
```
### 模式 4跨套件
@@ -95,11 +95,11 @@ Pane 3 (Claude Code): "Write E2E tests for the checkout flow"
并行审查视角:
```
Pane 1: "Review src/api/ for security vulnerabilities"
Pane 2: "Review src/api/ for performance issues"
Pane 3: "Review src/api/ for test coverage gaps"
Pane 1: "审查 src/api/ 中的安全漏洞"
Pane 2: "审查 src/api/ 中的性能问题"
Pane 3: "审查 src/api/ 中的测试覆盖缺口"
# Merge all reviews into a single report
# 将所有审查合并为一份报告
```
## 最佳实践

View File

@@ -156,9 +156,9 @@ docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d
同一 Compose 网络中的服务可通过服务名解析:
```
# From "app" container:
postgres://postgres:postgres@db:5432/app_dev # "db" resolves to the db container
redis://redis:6379/0 # "redis" resolves to the redis container
# "app" 容器:
postgres://postgres:postgres@db:5432/app_dev # "db" 解析到 db 容器
redis://redis:6379/0 # "redis" 解析到 redis 容器
```
### 自定义网络
@@ -345,21 +345,21 @@ docker network inspect <project>_default
## 反模式
```
# BAD: Using docker compose in production without orchestration
# Use Kubernetes, ECS, or Docker Swarm for production multi-container workloads
# 错误做法:在生产环境中使用 docker compose 而不进行编排
# 生产环境多容器工作负载应使用 KubernetesECS Docker Swarm
# BAD: Storing data in containers without volumes
# Containers are ephemeral -- all data lost on restart without volumes
# 错误做法:在容器内存储数据而不使用卷
# 容器是临时性的——不使用卷时,重启会导致所有数据丢失
# BAD: Running as root
# Always create and use a non-root user
# 错误做法:以 root 用户身份运行
# 始终创建并使用非 root 用户
# BAD: Using :latest tag
# Pin to specific versions for reproducible builds
# 错误做法:使用 :latest 标签
# 固定到特定版本以实现可复现的构建
# BAD: One giant container with all services
# Separate concerns: one process per container
# 错误做法:将所有服务放入一个巨型容器
# 关注点分离:每个容器运行一个进程
# BAD: Putting secrets in docker-compose.yml
# Use .env files (gitignored) or Docker secrets
# 错误做法:将密钥放入 docker-compose.yml
# 使用 .env 文件(在 git 中忽略)或 Docker secrets
```

View File

@@ -208,7 +208,7 @@ npm test -- --testPathPattern="existing"
### 实施后
```
/eval report feature-name
/eval 报告 功能名称
```
生成完整的评估报告
@@ -220,9 +220,9 @@ npm test -- --testPathPattern="existing"
```
.claude/
evals/
feature-xyz.md # Eval definition
feature-xyz.log # Eval run history
baseline.json # Regression baselines
feature-xyz.md # Eval定义
feature-xyz.log # Eval运行历史
baseline.json # 回归基线
```
## 最佳实践

View File

@@ -40,7 +40,7 @@ origin: ECC
用于当前信息、新闻或事实的通用网页搜索。
```
web_search_exa(query: "latest AI developments 2026", numResults: 5)
web_search_exa(query: "2026年最新人工智能发展", numResults: 5)
```
**参数:**
@@ -73,27 +73,27 @@ get_code_context_exa(query: "Python asyncio patterns", tokensNum: 3000)
### 快速查找
```
web_search_exa(query: "Node.js 22 new features", numResults: 3)
web_search_exa(query: "Node.js 22 新功能", numResults: 3)
```
### 代码研究
```
get_code_context_exa(query: "Rust error handling patterns Result type", tokensNum: 3000)
get_code_context_exa(query: "Rust错误处理模式Result类型", tokensNum: 3000)
```
### 公司或人物研究
```
web_search_exa(query: "Vercel funding valuation 2026", numResults: 3, category: "company")
web_search_exa(query: "site:linkedin.com/in AI safety researchers Anthropic", numResults: 5)
web_search_exa(query: "Vercel 2026年融资估值", numResults: 3, category: "company")
web_search_exa(query: "site:linkedin.com/in Anthropic AI安全研究员", numResults: 5)
```
### 技术深度研究
```
web_search_exa(query: "WebAssembly component model status and adoption", numResults: 5)
get_code_context_exa(query: "WebAssembly component model examples", tokensNum: 4000)
web_search_exa(query: "WebAssembly 组件模型状态与采用情况", numResults: 5)
get_code_context_exa(query: "WebAssembly 组件模型示例", tokensNum: 4000)
```
## 提示

View File

@@ -56,7 +56,7 @@ fal.ai MCP 提供以下工具:
generate(
app_id: "fal-ai/nano-banana-2",
input_data: {
"prompt": "a futuristic cityscape at sunset, cyberpunk style",
"prompt": "未来主义日落城市景观,赛博朋克风格",
"image_size": "landscape_16_9",
"num_images": 1,
"seed": 42
@@ -72,7 +72,7 @@ generate(
generate(
app_id: "fal-ai/nano-banana-pro",
input_data: {
"prompt": "professional product photo of wireless headphones on marble surface, studio lighting",
"prompt": "专业产品照片,无线耳机置于大理石表面,影棚灯光",
"image_size": "square",
"num_images": 1,
"guidance_scale": 7.5
@@ -95,10 +95,10 @@ generate(
使用 Nano Banana 2 并输入图像进行修复、扩展或风格迁移:
```
# First upload the source image
# 首先上传源图像
upload(file_path: "/path/to/image.png")
# Then generate with image input
# 然后使用图像输入进行生成
generate(
app_id: "fal-ai/nano-banana-2",
input_data: {
@@ -137,7 +137,7 @@ generate(
generate(
app_id: "fal-ai/kling-video/v3/pro",
input_data: {
"prompt": "ocean waves crashing on a rocky coast, dramatic clouds",
"prompt": "海浪拍打着岩石海岸,乌云密布",
"duration": "5s",
"aspect_ratio": "16:9"
}
@@ -152,7 +152,7 @@ generate(
generate(
app_id: "fal-ai/veo-3",
input_data: {
"prompt": "a bustling Tokyo street market at night, neon signs, crowd noise",
"prompt": "夜晚熙熙攘攘的东京街头市场,霓虹灯招牌,人群喧嚣",
"aspect_ratio": "16:9"
}
)

View File

@@ -17,9 +17,9 @@
### 黄金法则
```text
Each slide = exactly one viewport height.
Too much content = split into more slides.
Never scroll inside a slide.
每个幻灯片 = 恰好一个视口高度。
内容过多 = 分割成更多幻灯片。
切勿在幻灯片内部滚动。
```
### 内容密度限制

View File

@@ -369,17 +369,17 @@ func WriteAndFlush(w io.Writer, data []byte) error {
myproject/
├── cmd/
│ └── myapp/
│ └── main.go # Entry point
│ └── main.go # 入口点
├── internal/
│ ├── handler/ # HTTP handlers
│ ├── service/ # Business logic
│ ├── repository/ # Data access
│ └── config/ # Configuration
│ ├── handler/ # HTTP 处理器
│ ├── service/ # 业务逻辑
│ ├── repository/ # 数据访问
│ └── config/ # 配置
├── pkg/
│ └── client/ # Public API client
│ └── client/ # 公共 API 客户端
├── api/
│ └── v1/ # API definitions (proto, OpenAPI)
├── testdata/ # Test fixtures
│ └── v1/ # API 定义(proto, OpenAPI
├── testdata/ # 测试夹具
├── go.mod
├── go.sum
└── Makefile

View File

@@ -21,10 +21,10 @@ origin: ECC
### 红-绿-重构循环
```
RED → Write a failing test first
GREEN → Write minimal code to pass the test
REFACTOR → Improve code while keeping tests green
REPEAT → Continue with next requirement
RED → 首先编写一个失败的测试
GREEN → 编写最少的代码来通过测试
REFACTOR → 改进代码,同时保持测试通过
REPEAT → 继续处理下一个需求
```
### Go 中的分步 TDD

View File

@@ -38,15 +38,15 @@ origin: ECC
┌─────────────────────────────────────────────┐
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ DISPATCH │─────▶│ EVALUATE │ │
│ │ 调度 │─────▶│ 评估 │ │
│ └──────────┘ └──────────┘ │
│ ▲ │ │
│ │ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │ LOOP │◀─────│ REFINE │ │
│ │ 循环 │◀─────│ 优化 │ │
│ └──────────┘ └──────────┘ │
│ │
Max 3 cycles, then proceed
最多3次循环然后继续
└─────────────────────────────────────────────┘
```
@@ -148,42 +148,42 @@ async function iterativeRetrieve(task, maxCycles = 3) {
### 示例 1错误修复上下文
```
Task: "Fix the authentication token expiry bug"
任务:"修复身份验证令牌过期错误"
Cycle 1:
DISPATCH: Search for "token", "auth", "expiry" in src/**
EVALUATE: Found auth.ts (0.9), tokens.ts (0.8), user.ts (0.3)
REFINE: Add "refresh", "jwt" keywords; exclude user.ts
循环 1:
分发:在 src/** 中搜索 "token""auth""expiry"
评估:找到 auth.ts (0.9)tokens.ts (0.8)user.ts (0.3)
优化:添加 "refresh""jwt" 关键词;排除 user.ts
Cycle 2:
DISPATCH: Search refined terms
EVALUATE: Found session-manager.ts (0.95), jwt-utils.ts (0.85)
REFINE: Sufficient context (2 high-relevance files)
循环 2:
分发:搜索优化后的关键词
评估:找到 session-manager.ts (0.95)jwt-utils.ts (0.85)
优化上下文已充分2 个高相关文件)
Result: auth.ts, tokens.ts, session-manager.ts, jwt-utils.ts
结果:auth.tstokens.tssession-manager.tsjwt-utils.ts
```
### 示例 2功能实现
```
Task: "Add rate limiting to API endpoints"
任务:"为API端点添加速率限制"
Cycle 1:
DISPATCH: Search "rate", "limit", "api" in routes/**
EVALUATE: No matches - codebase uses "throttle" terminology
REFINE: Add "throttle", "middleware" keywords
周期 1
分发:在 routes/** 中搜索 "rate""limit""api"
评估:无匹配项 - 代码库使用 "throttle" 术语
优化:添加 "throttle""middleware" 关键词
Cycle 2:
DISPATCH: Search refined terms
EVALUATE: Found throttle.ts (0.9), middleware/index.ts (0.7)
REFINE: Need router patterns
周期 2
分发:搜索优化后的术语
评估:找到 throttle.ts (0.9)middleware/index.ts (0.7)
优化:需要路由模式
Cycle 3:
DISPATCH: Search "router", "express" patterns
EVALUATE: Found router-setup.ts (0.8)
REFINE: Sufficient context
周期 3
分发:搜索 "router""express" 模式
评估:找到 router-setup.ts (0.8)
优化:上下文已足够
Result: throttle.ts, middleware/index.ts, router-setup.ts
结果:throttle.tsmiddleware/index.tsrouter-setup.ts
```
## 与智能体集成

View File

@@ -23,9 +23,9 @@ origin: ECC
```
Application
└── viewModelScope (ViewModel)
└── coroutineScope { } (structured child)
├── async { } (concurrent task)
└── async { } (concurrent task)
└── coroutineScope { } (结构化子作用域)
├── async { } (并发任务)
└── async { } (并发任务)
```
始终使用结构化并发——绝不使用 `GlobalScope`

View File

@@ -24,28 +24,28 @@ origin: ECC
```text
src/main/kotlin/
├── com/example/
│ ├── Application.kt # Entry point, module configuration
│ ├── Application.kt # 入口点,模块配置
│ ├── plugins/
│ │ ├── Routing.kt # Route definitions
│ │ ├── Serialization.kt # Content negotiation setup
│ │ ├── Authentication.kt # Auth configuration
│ │ ├── StatusPages.kt # Error handling
│ │ └── CORS.kt # CORS configuration
│ │ ├── Routing.kt # 路由定义
│ │ ├── Serialization.kt # 内容协商设置
│ │ ├── Authentication.kt # 认证配置
│ │ ├── StatusPages.kt # 错误处理
│ │ └── CORS.kt # CORS 配置
│ ├── routes/
│ │ ├── UserRoutes.kt # /users endpoints
│ │ ├── AuthRoutes.kt # /auth endpoints
│ │ └── HealthRoutes.kt # /health endpoints
│ │ ├── UserRoutes.kt # /users 端点
│ │ ├── AuthRoutes.kt # /auth 端点
│ │ └── HealthRoutes.kt # /health 端点
│ ├── models/
│ │ ├── User.kt # Domain models
│ │ └── ApiResponse.kt # Response envelopes
│ │ ├── User.kt # 领域模型
│ │ └── ApiResponse.kt # 响应封装
│ ├── services/
│ │ ├── UserService.kt # Business logic
│ │ └── AuthService.kt # Auth logic
│ │ ├── UserService.kt # 业务逻辑
│ │ └── AuthService.kt # 认证逻辑
│ ├── repositories/
│ │ ├── UserRepository.kt # Data access interface
│ │ ├── UserRepository.kt # 数据访问接口
│ │ └── ExposedUserRepository.kt
│ └── di/
│ └── AppModule.kt # Koin modules
│ └── AppModule.kt # Koin 模块
src/test/kotlin/
├── com/example/
│ ├── routes/

View File

@@ -43,10 +43,10 @@ origin: ECC
#### RED-GREEN-REFACTOR 周期
```
RED -> Write a failing test first
GREEN -> Write minimal code to pass the test
REFACTOR -> Improve code while keeping tests green
REPEAT -> Continue with next requirement
RED -> 首先编写一个失败的测试
GREEN -> 编写最少的代码使测试通过
REFACTOR -> 改进代码同时保持测试通过
REPEAT -> 继续下一个需求
```
#### Kotlin 中逐步进行 TDD

View File

@@ -34,20 +34,20 @@ origin: ECC
```
app/
├── Actions/ # Single-purpose use cases
├── Actions/ # 单一用途的用例
├── Console/
├── Events/
├── Exceptions/
├── Http/
│ ├── Controllers/
│ ├── Middleware/
│ ├── Requests/ # Form request validation
│ └── Resources/ # API resources
│ ├── Requests/ # 表单请求验证
│ └── Resources/ # API 资源
├── Jobs/
├── Models/
├── Policies/
├── Providers/
├── Services/ # Coordinating domain services
├── Services/ # 协调领域服务
└── Support/
config/
database/

View File

@@ -372,19 +372,19 @@ for my $child (path('src')->children(qr/\.pl$/)) {
MyApp/
├── lib/
│ └── MyApp/
│ ├── App.pm # Main module
│ ├── Config.pm # Configuration
│ ├── DB.pm # Database layer
│ └── Util.pm # Utilities
│ ├── App.pm # 主模块
│ ├── Config.pm # 配置
│ ├── DB.pm # 数据库层
│ └── Util.pm # 工具集
├── bin/
│ └── myapp # Entry-point script
│ └── myapp # 入口脚本
├── t/
│ ├── 00-load.t # Compilation tests
│ ├── unit/ # Unit tests
│ └── integration/ # Integration tests
├── cpanfile # Dependencies
├── Makefile.PL # Build system
└── .perlcriticrc # Linting config
│ ├── 00-load.t # 编译测试
│ ├── unit/ # 单元测试
│ └── integration/ # 集成测试
├── cpanfile # 依赖项
├── Makefile.PL # 构建系统
└── .perlcriticrc # 代码检查配置
```
### 导出器模式
@@ -407,12 +407,12 @@ sub trim($str) { $str =~ s/^\s+|\s+$//gr }
### perltidy 配置 (.perltidyrc)
```text
-i=4 # 4-space indent
-l=100 # 100-char line length
-ci=4 # continuation indent
-ce # cuddled else
-bar # opening brace on same line
-nolq # don't outdent long quoted strings
-i=4 # 4 空格缩进
-l=100 # 100 字符行宽
-ci=4 # 续行缩进
-ce # else 与右花括号同行
-bar # 左花括号与语句同行
-nolq # 不对长引用字符串进行反向缩进
```
### perlcritic 配置 (.perlcriticrc)

Some files were not shown because too many files have changed in this diff Show More