issue-execute
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseIssue Execute (Codex Version)
Issue 执行(Codex版本)
Core Principle
核心原则
Serial Execution: Execute solutions ONE BY ONE from the issue queue via . For each solution, complete all tasks sequentially (implement → test → verify), then commit once per solution with formatted summary. Continue autonomously until queue is empty.
ccw issue next串行执行:通过从问题队列中逐个执行解决方案。对于每个解决方案,依次完成所有任务(实现→测试→验证),然后为每个解决方案进行一次格式化摘要的提交。自主持续执行,直到队列为空。
ccw issue nextProject Context (MANDATORY FIRST STEPS)
项目上下文(必须执行的第一步)
Before starting execution, load project context:
- Read project tech stack:
.workflow/project-tech.json - Read project guidelines:
.workflow/project-guidelines.json - Read solution schema:
~/.ccw/workflows/cli-templates/schemas/solution-schema.json
This ensures execution follows project conventions and patterns.
在开始执行前,加载项目上下文:
- 读取项目技术栈:
.workflow/project-tech.json - 读取项目指南:
.workflow/project-guidelines.json - 读取解决方案 schema:
~/.ccw/workflows/cli-templates/schemas/solution-schema.json
这确保执行遵循项目约定和模式。
Parameters
参数
- : Queue ID to execute (REQUIRED)
--queue=<id> - : Worktree path or 'new' for creating new worktree
--worktree=<path|new> - : Skip test execution during solution implementation
--skip-tests - : Skip build step
--skip-build - : Preview execution without making changes
--dry-run
- :要执行的队列ID(必填)
--queue=<id> - :工作树路径,或使用'new'创建新工作树
--worktree=<path|new> - :在解决方案实现过程中跳过测试执行
--skip-tests - :跳过构建步骤
--skip-build - :预览执行过程,不进行实际修改
--dry-run
Queue ID Requirement (MANDATORY)
队列ID要求(必填)
--queue <queue-id>--queue <queue-id>When Queue ID Not Provided
未提供队列ID时
List queues → Output options → Stop and wait for userActions:
- - Fetch queue list
ccw issue queue list --brief --json - Filter active/pending status, output formatted list
- Stop execution, prompt user to rerun with
codex -p "@.codex/prompts/issue-execute.md --queue QUE-xxx"
No auto-selection - User MUST explicitly specify queue-id
列出队列 → 输出选项 → 停止并等待用户输入操作:
- - 获取队列列表
ccw issue queue list --brief --json - 筛选活跃/待处理状态的队列,输出格式化列表
- 停止执行,提示用户使用重新运行
codex -p "@.codex/prompts/issue-execute.md --queue QUE-xxx"
不支持自动选择 - 用户必须明确指定队列ID
Worktree Mode (Recommended for Parallel Execution)
工作树模式(推荐用于并行执行)
When is specified, create or use a git worktree to isolate work.
--worktreeUsage:
- - Create a new worktree with timestamp-based name
--worktree - - Resume in an existing worktree (for recovery/continuation)
--worktree <existing-path>
Note: commands auto-detect worktree and redirect to main repo automatically.
ccw issuebash
undefined当指定时,创建或使用git工作树来隔离工作。
--worktree用法:
- - 创建一个基于时间戳命名的新工作树
--worktree - - 在现有工作树中恢复执行(用于恢复/继续中断的任务)
--worktree <existing-path>
注意:命令会自动检测工作树,并自动重定向到主仓库。
ccw issuebash
undefinedStep 0: Setup worktree before starting (run from MAIN REPO)
Step 0: Setup worktree before starting (run from MAIN REPO)
Use absolute paths to avoid issues when running from subdirectories
Use absolute paths to avoid issues when running from subdirectories
REPO_ROOT=$(git rev-parse --show-toplevel)
WORKTREE_BASE="${REPO_ROOT}/.ccw/worktrees"
REPO_ROOT=$(git rev-parse --show-toplevel)
WORKTREE_BASE="${REPO_ROOT}/.ccw/worktrees"
Check if existing worktree path was provided
Check if existing worktree path was provided
EXISTING_WORKTREE="${1:-}" # Pass as argument or empty
if [[ -n "${EXISTING_WORKTREE}" && -d "${EXISTING_WORKTREE}" ]]; then
Resume mode: Use existing worktree
WORKTREE_PATH="${EXISTING_WORKTREE}"
WORKTREE_NAME=$(basename "${WORKTREE_PATH}")
Verify it's a valid git worktree
if ! git -C "${WORKTREE_PATH}" rev-parse --is-inside-work-tree &>/dev/null; then
echo "Error: ${EXISTING_WORKTREE} is not a valid git worktree"
exit 1
fi
echo "Resuming in existing worktree: ${WORKTREE_PATH}"
else
Create mode: New worktree with timestamp
WORKTREE_NAME="issue-exec-$(date +%Y%m%d-%H%M%S)"
WORKTREE_PATH="${WORKTREE_BASE}/${WORKTREE_NAME}"
Ensure worktree base directory exists (gitignored)
mkdir -p "${WORKTREE_BASE}"
Prune stale worktrees from previous interrupted executions
git worktree prune
Create worktree from current branch
git worktree add "${WORKTREE_PATH}" -b "${WORKTREE_NAME}"
echo "Created new worktree: ${WORKTREE_PATH}"
fi
EXISTING_WORKTREE="${1:-}" # Pass as argument or empty
if [[ -n "${EXISTING_WORKTREE}" && -d "${EXISTING_WORKTREE}" ]]; then
Resume mode: Use existing worktree
WORKTREE_PATH="${EXISTING_WORKTREE}"
WORKTREE_NAME=$(basename "${WORKTREE_PATH}")
Verify it's a valid git worktree
if ! git -C "${WORKTREE_PATH}" rev-parse --is-inside-work-tree &>/dev/null; then
echo "Error: ${EXISTING_WORKTREE} is not a valid git worktree"
exit 1
fi
echo "Resuming in existing worktree: ${WORKTREE_PATH}"
else
Create mode: New worktree with timestamp
WORKTREE_NAME="issue-exec-$(date +%Y%m%d-%H%M%S)"
WORKTREE_PATH="${WORKTREE_BASE}/${WORKTREE_NAME}"
Ensure worktree base directory exists (gitignored)
mkdir -p "${WORKTREE_BASE}"
Prune stale worktrees from previous interrupted executions
git worktree prune
Create worktree from current branch
git worktree add "${WORKTREE_PATH}" -b "${WORKTREE_NAME}"
echo "Created new worktree: ${WORKTREE_PATH}"
fi
Setup cleanup trap for graceful failure handling
Setup cleanup trap for graceful failure handling
cleanup_worktree() {
echo "Cleaning up worktree due to interruption..."
cd "${REPO_ROOT}" 2>/dev/null || true
git worktree remove "${WORKTREE_PATH}" --force 2>/dev/null || true
Keep branch for debugging failed executions
echo "Worktree removed. Branch '${WORKTREE_NAME}' kept for inspection."
}
trap cleanup_worktree EXIT INT TERM
cleanup_worktree() {
echo "Cleaning up worktree due to interruption..."
cd "${REPO_ROOT}" 2>/dev/null || true
git worktree remove "${WORKTREE_PATH}" --force 2>/dev/null || true
Keep branch for debugging failed executions
echo "Worktree removed. Branch '${WORKTREE_NAME}' kept for inspection."
}
trap cleanup_worktree EXIT INT TERM
Change to worktree directory
Change to worktree directory
cd "${WORKTREE_PATH}"
cd "${WORKTREE_PATH}"
ccw issue commands auto-detect worktree and use main repo's .workflow/
ccw issue commands auto-detect worktree and use main repo's .workflow/
So you can run ccw issue next/done directly from worktree
So you can run ccw issue next/done directly from worktree
**Worktree Execution Pattern**:- [MAIN REPO] Validate queue ID (--queue required, or prompt user to select)
- [WORKTREE] ccw issue next --queue <queue-id> → auto-redirects to main repo's .workflow/
- [WORKTREE] Implement all tasks, run tests, git commit
- [WORKTREE] ccw issue done <item_id> → auto-redirects to main repo
- Repeat from step 1
**Note**: Add `.ccw/worktrees/` to `.gitignore` to prevent tracking worktree contents.
**Benefits:**
- Parallel executors don't conflict with each other
- Main working directory stays clean
- Easy cleanup after execution
- **Resume support**: Pass existing worktree path to continue interrupted executions
**Resume Examples:**
```bash
**工作树执行模式**:- [主仓库] 验证队列ID(--queue为必填项,或提示用户选择)
- [工作树] ccw issue next --queue <queue-id> → 自动重定向到主仓库的.workflow/
- [工作树] 实现所有任务,运行测试,进行git提交
- [工作树] ccw issue done <item_id> → 自动重定向到主仓库
- 从步骤1重复执行
**注意**: 将`.ccw/worktrees/`添加到`.gitignore`中,防止跟踪工作树内容。
**优势**:
- 并行执行器之间不会相互冲突
- 主工作目录保持干净
- 执行后易于清理
- **恢复支持**: 传入现有工作树路径以继续中断的执行
**恢复示例**:
```bashList existing worktrees to find interrupted execution
列出现有工作树以找到中断的执行
git worktree list
git worktree list
Resume in existing worktree (pass path as argument)
在现有工作树中恢复执行(传入路径作为参数)
The worktree path will be used instead of creating a new one
将使用工作树路径而非创建新路径
codex -p "@.codex/prompts/issue-execute.md --worktree /path/to/existing/worktree"
**Completion - User Choice:**
When all solutions are complete, output options and wait for user to specify:
All solutions completed in worktree. Choose next action:
- Merge to main - Merge worktree branch into main and cleanup
- Create PR - Push branch and create pull request (Recommended for parallel execution)
- Keep branch - Keep branch for manual handling, cleanup worktree only
Please respond with: 1, 2, or 3
**Based on user response:**
```bashcodex -p "@.codex/prompts/issue-execute.md --worktree /path/to/existing/worktree"
**完成 - 用户选择**:
当所有解决方案完成后,输出选项并等待用户指定:
工作树中的所有解决方案已完成。选择下一步操作:
- 合并到主分支 - 将工作树分支合并到主分支并清理
- 创建PR - 推送分支并创建拉取请求(推荐用于并行执行)
- 保留分支 - 保留分支以便手动处理,仅清理工作树
请回复:1、2或3
**根据用户响应执行**:
```bashDisable cleanup trap before intentional cleanup
在有意清理前禁用清理陷阱
trap - EXIT INT TERM
trap - EXIT INT TERM
Return to main repo first (use REPO_ROOT from setup)
先返回主仓库(使用设置中的REPO_ROOT)
cd "${REPO_ROOT}"
cd "${REPO_ROOT}"
Validate main repo state before merge (prevents conflicts)
合并前验证主仓库状态(防止冲突)
validate_main_clean() {
if [[ -n $(git status --porcelain) ]]; then
echo "⚠️ Warning: Main repo has uncommitted changes."
echo "Cannot auto-merge. Falling back to 'Create PR' option."
return 1
fi
return 0
}
validate_main_clean() {
if [[ -n $(git status --porcelain) ]]; then
echo "⚠️ 警告:主仓库存在未提交的更改。"
echo "无法自动合并。回退到'创建PR'选项。"
return 1
fi
return 0
}
Option 1: Merge to main (only if main is clean)
选项1:合并到主分支(仅当主仓库干净时)
if validate_main_clean; then
git merge "${WORKTREE_NAME}" --no-ff -m "Merge issue queue execution: ${WORKTREE_NAME}"
git worktree remove "${WORKTREE_PATH}"
git branch -d "${WORKTREE_NAME}"
else
Fallback to PR if main is dirty
git push -u origin "${WORKTREE_NAME}"
gh pr create --title "Issue Queue: ${WORKTREE_NAME}" --body "Automated issue queue execution (main had uncommitted changes)"
git worktree remove "${WORKTREE_PATH}"
fi
if validate_main_clean; then
git merge "${WORKTREE_NAME}" --no-ff -m "Merge issue queue execution: ${WORKTREE_NAME}"
git worktree remove "${WORKTREE_PATH}"
git branch -d "${WORKTREE_NAME}"
else
如果主仓库有未提交内容,回退到创建PR
git push -u origin "${WORKTREE_NAME}"
gh pr create --title "Issue Queue: ${WORKTREE_NAME}" --body "Automated issue queue execution (main had uncommitted changes)"
git worktree remove "${WORKTREE_PATH}"
fi
Option 2: Create PR (Recommended for parallel execution)
选项2:创建PR(推荐用于并行执行)
git push -u origin "${WORKTREE_NAME}"
gh pr create --title "Issue Queue: ${WORKTREE_NAME}" --body "Automated issue queue execution"
git worktree remove "${WORKTREE_PATH}"
git push -u origin "${WORKTREE_NAME}"
gh pr create --title "Issue Queue: ${WORKTREE_NAME}" --body "Automated issue queue execution"
git worktree remove "${WORKTREE_PATH}"
Branch kept on remote
分支保留在远程仓库
Option 3: Keep branch
选项3:保留分支
git worktree remove "${WORKTREE_PATH}"
git worktree remove "${WORKTREE_PATH}"
Branch kept locally for manual handling
分支保留在本地以便手动处理
echo "Branch '${WORKTREE_NAME}' kept. Merge manually when ready."
**Parallel Execution Safety**: For parallel executors, "Create PR" is the safest option as it avoids race conditions during merge. Multiple PRs can be reviewed and merged sequentially.echo "Branch '${WORKTREE_NAME}' kept. Merge manually when ready."
**并行执行安全性**: 对于并行执行器,“创建PR”是最安全的选项,可避免合并时的竞争条件。多个PR可依次进行审核和合并。Execution Flow
执行流程
STEP 0: Validate queue ID (--queue required, or prompt user to select)
INIT: Fetch first solution via ccw issue next --queue <queue-id>
WHILE solution exists:
1. Receive solution JSON from ccw issue next --queue <queue-id>
2. Execute all tasks in solution.tasks sequentially:
FOR each task:
- IMPLEMENT: Follow task.implementation steps
- TEST: Run task.test commands
- VERIFY: Check task.acceptance criteria
3. COMMIT: Stage all files, commit once with formatted summary
4. Report completion via ccw issue done <item_id>
5. Fetch next solution via ccw issue next --queue <queue-id>
WHEN queue empty:
Output final summary步骤0:验证队列ID(--queue为必填项,或提示用户选择)
初始化:通过ccw issue next --queue <queue-id>获取第一个解决方案
当存在解决方案时:
1. 从ccw issue next --queue <queue-id>接收解决方案JSON
2. 依次执行solution.tasks中的所有任务:
对于每个任务:
- 实现:遵循task.implementation步骤
- 测试:运行task.test命令
- 验证:检查task.acceptance标准
3. 提交:暂存所有文件,使用格式化摘要进行一次提交
4. 通过ccw issue done <item_id>报告完成
5. 通过ccw issue next --queue <queue-id>获取下一个解决方案
当队列为空时:
输出最终摘要Step 1: Fetch First Solution
步骤1:获取第一个解决方案
Prerequisite: Queue ID must be determined (either from argument or user selection in Step 0).
--queueRun this command to get your first solution:
javascript
// ccw auto-detects worktree and uses main repo's .workflow/
// QUEUE_ID is required - obtained from --queue argument or user selection
const result = shell_command({ command: `ccw issue next --queue ${QUEUE_ID}` })This returns JSON with the full solution definition:
- : Solution identifier in queue (e.g., "S-1")
item_id - : Parent issue ID (e.g., "ISS-20251227-001")
issue_id - : Solution ID (e.g., "SOL-ISS-20251227-001-1")
solution_id - : Full solution with all tasks
solution - : Timing and executor hints
execution_hints
If response contains , all solutions are complete - skip to final summary.
{ "status": "empty" }前提条件: 必须确定队列ID(来自参数或步骤0中的用户选择)。
--queue运行以下命令获取第一个解决方案:
javascript
// ccw auto-detects worktree and uses main repo's .workflow/
// QUEUE_ID is required - obtained from --queue argument or user selection
const result = shell_command({ command: `ccw issue next --queue ${QUEUE_ID}` })该命令返回包含完整解决方案定义的JSON:
- : 队列中的解决方案标识符(例如:"S-1")
item_id - : 父问题ID(例如:"ISS-20251227-001")
issue_id - : 解决方案ID(例如:"SOL-ISS-20251227-001-1")
solution_id - : 包含所有任务的完整解决方案
solution - : 时间和执行器提示
execution_hints
如果响应包含,则所有解决方案已完成 - 跳转到最终摘要。
{ "status": "empty" }Step 2: Parse Solution Response
步骤2:解析解决方案响应
Expected solution structure:
json
{
"item_id": "S-1",
"issue_id": "ISS-20251227-001",
"solution_id": "SOL-ISS-20251227-001-1",
"status": "pending",
"solution": {
"id": "SOL-ISS-20251227-001-1",
"description": "Description of solution approach",
"tasks": [
{
"id": "T1",
"title": "Task title",
"scope": "src/module/",
"action": "Create|Modify|Fix|Refactor|Add",
"description": "What to do",
"modification_points": [
{ "file": "path/to/file.ts", "target": "function name", "change": "description" }
],
"implementation": [
"Step 1: Do this",
"Step 2: Do that"
],
"test": {
"commands": ["npm test -- --filter=xxx"],
"unit": ["Unit test requirement 1", "Unit test requirement 2"]
},
"regression": ["Verify existing tests still pass"],
"acceptance": {
"criteria": ["Criterion 1: Must pass", "Criterion 2: Must verify"],
"verification": ["Run test command", "Manual verification step"]
},
"commit": {
"type": "feat|fix|test|refactor",
"scope": "module",
"message_template": "feat(scope): description"
},
"depends_on": [],
"estimated_minutes": 30,
"priority": 1
}
],
"exploration_context": {
"relevant_files": ["path/to/reference.ts"],
"patterns": "Follow existing pattern in xxx",
"integration_points": "Used by other modules"
},
"analysis": {
"risk": "low|medium|high",
"impact": "low|medium|high",
"complexity": "low|medium|high"
},
"score": 0.95,
"is_bound": true
},
"execution_hints": {
"executor": "codex",
"estimated_minutes": 180
}
}预期的解决方案结构:
json
{
"item_id": "S-1",
"issue_id": "ISS-20251227-001",
"solution_id": "SOL-ISS-20251227-001-1",
"status": "pending",
"solution": {
"id": "SOL-ISS-20251227-001-1",
"description": "Description of solution approach",
"tasks": [
{
"id": "T1",
"title": "Task title",
"scope": "src/module/",
"action": "Create|Modify|Fix|Refactor|Add",
"description": "What to do",
"modification_points": [
{ "file": "path/to/file.ts", "target": "function name", "change": "description" }
],
"implementation": [
"Step 1: Do this",
"Step 2: Do that"
],
"test": {
"commands": ["npm test -- --filter=xxx"],
"unit": ["Unit test requirement 1", "Unit test requirement 2"]
},
"regression": ["Verify existing tests still pass"],
"acceptance": {
"criteria": ["Criterion 1: Must pass", "Criterion 2: Must verify"],
"verification": ["Run test command", "Manual verification step"]
},
"commit": {
"type": "feat|fix|test|refactor",
"scope": "module",
"message_template": "feat(scope): description"
},
"depends_on": [],
"estimated_minutes": 30,
"priority": 1
}
],
"exploration_context": {
"relevant_files": ["path/to/reference.ts"],
"patterns": "Follow existing pattern in xxx",
"integration_points": "Used by other modules"
},
"analysis": {
"risk": "low|medium|high",
"impact": "low|medium|high",
"complexity": "low|medium|high"
},
"score": 0.95,
"is_bound": true
},
"execution_hints": {
"executor": "codex",
"estimated_minutes": 180
}
}Step 2.1: Determine Execution Strategy
步骤2.1:确定执行策略
After parsing the solution, analyze the issue type and task actions to determine the appropriate execution strategy. The strategy defines additional verification steps and quality gates beyond the basic implement-test-verify cycle.
解析解决方案后,分析问题类型和任务操作以确定合适的执行策略。该策略定义了除基本的实现-测试-验证周期外的额外验证步骤和质量关卡。
Strategy Auto-Matching
策略自动匹配
Matching Priority:
- Explicit if provided
solution.strategy_type - Infer from keywords (Debug, Fix, Feature, Refactor, Test, etc.)
task.action - Infer from and
solution.descriptioncontenttask.title - Default to "standard" if no clear match
Strategy Types and Matching Keywords:
| Strategy Type | Match Keywords | Description |
|---|---|---|
| Debug, Diagnose, Trace, Investigate | Bug diagnosis with logging and debugging |
| Fix, Patch, Resolve, Correct | Bug fixing with root cause analysis |
| Feature, Add, Implement, Create, Build | New feature development with full testing |
| Refactor, Restructure, Optimize, Cleanup | Code restructuring with behavior preservation |
| Test, Coverage, E2E, Integration | Test implementation with coverage checks |
| Performance, Optimize, Speed, Memory | Performance optimization with benchmarking |
| Security, Vulnerability, CVE, Audit | Security fixes with vulnerability checks |
| Hotfix, Urgent, Critical, Emergency | Urgent fixes with minimal changes |
| Documentation, Docs, Comment, README | Documentation updates with example validation |
| Chore, Dependency, Config, Maintenance | Maintenance tasks with compatibility checks |
| (default) | Standard implementation without extra steps |
匹配优先级:
- 如果提供了明确的
solution.strategy_type - 从关键字推断(Debug、Fix、Feature、Refactor、Test等)
task.action - 从和
solution.description内容推断task.title - 如果没有明确匹配,默认使用"standard"
策略类型和匹配关键字:
| 策略类型 | 匹配关键字 | 描述 |
|---|---|---|
| Debug, Diagnose, Trace, Investigate | 带有日志记录和调试的问题诊断 |
| Fix, Patch, Resolve, Correct | 带有根本原因分析的问题修复 |
| Feature, Add, Implement, Create, Build | 带有完整测试的新功能开发 |
| Refactor, Restructure, Optimize, Cleanup | 不改变行为的代码重构 |
| Test, Coverage, E2E, Integration | 带有覆盖率检查的测试实现 |
| Performance, Optimize, Speed, Memory | 带有基准测试的性能优化 |
| Security, Vulnerability, CVE, Audit | 带有漏洞检查的安全修复 |
| Hotfix, Urgent, Critical, Emergency | 最小变更的紧急修复 |
| Documentation, Docs, Comment, README | 带有示例验证的文档更新 |
| Chore, Dependency, Config, Maintenance | 带有兼容性检查的维护任务 |
| (默认) | 无额外步骤的标准实现 |
Strategy-Specific Execution Phases
特定策略的执行阶段
Each strategy extends the basic cycle with additional quality gates:
每个策略在基本周期基础上扩展了额外的质量关卡:
1. Debug → Reproduce → Instrument → Diagnose → Implement → Test → Verify → Cleanup
1. 调试 → 复现 → 插桩 → 诊断 → 实现 → 测试 → 验证 → 清理
REPRODUCE → INSTRUMENT → DIAGNOSE → IMPLEMENT → TEST → VERIFY → CLEANUP复现 → 插桩 → 诊断 → 实现 → 测试 → 验证 → 清理2. Bugfix → Root Cause → Implement → Test → Edge Cases → Regression → Verify
2. 问题修复 → 根本原因 → 实现 → 测试 → 边缘情况 → 回归 → 验证
ROOT_CAUSE → IMPLEMENT → TEST → EDGE_CASES → REGRESSION → VERIFY根本原因分析 → 实现 → 测试 → 边缘情况测试 → 回归测试 → 验证3. Feature → Design Review → Unit Tests → Implement → Integration Tests → Code Review → Docs → Verify
3. 功能开发 → 设计评审 → 单元测试 → 实现 → 集成测试 → 代码评审 → 文档 → 验证
DESIGN_REVIEW → UNIT_TESTS → IMPLEMENT → INTEGRATION_TESTS → TEST → CODE_REVIEW → DOCS → VERIFY设计评审 → 单元测试 → 实现 → 集成测试 → 测试 → 代码评审 → 文档 → 验证4. Refactor → Baseline Tests → Implement → Test → Behavior Check → Performance Compare → Verify
4. 代码重构 → 基线测试 → 实现 → 测试 → 行为检查 → 性能对比 → 验证
BASELINE_TESTS → IMPLEMENT → TEST → BEHAVIOR_PRESERVATION → PERFORMANCE_CMP → VERIFY基线测试 → 实现 → 测试 → 行为一致性检查 → 性能对比 → 验证5. Test → Coverage Baseline → Test Design → Implement → Coverage Check → Verify
5. 测试实现 → 覆盖率基线 → 测试设计 → 实现 → 覆盖率检查 → 验证
COVERAGE_BASELINE → TEST_DESIGN → IMPLEMENT → COVERAGE_CHECK → VERIFY覆盖率基线 → 测试设计 → 实现 → 覆盖率检查 → 验证6. Performance → Profiling → Bottleneck → Implement → Benchmark → Test → Verify
6. 性能优化 → 性能分析 → 瓶颈定位 → 实现 → 基准测试 → 测试 → 验证
PROFILING → BOTTLENECK → IMPLEMENT → BENCHMARK → TEST → VERIFY性能分析 → 瓶颈定位 → 实现 → 基准测试 → 测试 → 验证7. Security → Vulnerability Scan → Implement → Security Test → Penetration Test → Verify
7. 安全修复 → 漏洞扫描 → 实现 → 安全测试 → 渗透测试 → 验证
VULNERABILITY_SCAN → IMPLEMENT → SECURITY_TEST → PENETRATION_TEST → VERIFY漏洞扫描 → 实现 → 安全测试 → 渗透测试 → 验证8. Hotfix → Impact Assessment → Implement → Test → Quick Verify → Verify
8. 紧急修复 → 影响评估 → 实现 → 测试 → 快速验证 → 验证
IMPACT_ASSESSMENT → IMPLEMENT → TEST → QUICK_VERIFY → VERIFY影响评估 → 实现 → 测试 → 快速验证 → 验证9. Documentation → Implement → Example Validation → Format Check → Link Validation → Verify
9. 文档更新 → 实现 → 示例验证 → 格式检查 → 链接验证 → 验证
IMPLEMENT → EXAMPLE_VALIDATION → FORMAT_CHECK → LINK_VALIDATION → VERIFY实现 → 示例验证 → 格式检查 → 链接验证 → 验证10. Chore → Implement → Compatibility Check → Test → Changelog → Verify
10. 维护任务 → 实现 → 兼容性检查 → 测试 → 更新变更日志 → 验证
IMPLEMENT → COMPATIBILITY_CHECK → TEST → CHANGELOG → VERIFY实现 → 兼容性检查 → 测试 → 更新变更日志 → 验证11. Standard → Implement → Test → Verify
11. 标准流程 → 实现 → 测试 → 验证
IMPLEMENT → TEST → VERIFY实现 → 测试 → 验证Strategy Selection Implementation
策略选择实现
Pseudo-code for strategy matching:
javascript
function determineStrategy(solution) {
// Priority 1: Explicit strategy type
if (solution.strategy_type) {
return solution.strategy_type
}
// Priority 2: Infer from task actions
const actions = solution.tasks.map(t => t.action.toLowerCase())
const titles = solution.tasks.map(t => t.title.toLowerCase())
const description = solution.description.toLowerCase()
const allText = [...actions, ...titles, description].join(' ')
// Match keywords (order matters - more specific first)
if (/hotfix|urgent|critical|emergency/.test(allText)) return 'hotfix'
if (/debug|diagnose|trace|investigate/.test(allText)) return 'debug'
if (/security|vulnerability|cve|audit/.test(allText)) return 'security'
if (/performance|optimize|speed|memory|benchmark/.test(allText)) return 'performance'
if (/refactor|restructure|cleanup/.test(allText)) return 'refactor'
if (/test|coverage|e2e|integration/.test(allText)) return 'test'
if (/documentation|docs|comment|readme/.test(allText)) return 'documentation'
if (/chore|dependency|config|maintenance/.test(allText)) return 'chore'
if (/fix|patch|resolve|correct/.test(allText)) return 'bugfix'
if (/feature|add|implement|create|build/.test(allText)) return 'feature'
// Default
return 'standard'
}Usage in execution flow:
javascript
// After parsing solution (Step 2)
const strategy = determineStrategy(solution)
console.log(`Strategy selected: ${strategy}`)
// During task execution (Step 3), follow strategy-specific phases
for (const task of solution.tasks) {
executeTaskWithStrategy(task, strategy)
}策略匹配伪代码:
javascript
function determineStrategy(solution) {
// 优先级1:明确的策略类型
if (solution.strategy_type) {
return solution.strategy_type
}
// 优先级2:从任务操作推断
const actions = solution.tasks.map(t => t.action.toLowerCase())
const titles = solution.tasks.map(t => t.title.toLowerCase())
const description = solution.description.toLowerCase()
const allText = [...actions, ...titles, description].join(' ')
// 匹配关键字(顺序重要 - 更具体的优先)
if (/hotfix|urgent|critical|emergency/.test(allText)) return 'hotfix'
if (/debug|diagnose|trace|investigate/.test(allText)) return 'debug'
if (/security|vulnerability|cve|audit/.test(allText)) return 'security'
if (/performance|optimize|speed|memory|benchmark/.test(allText)) return 'performance'
if (/refactor|restructure|cleanup/.test(allText)) return 'refactor'
if (/test|coverage|e2e|integration/.test(allText)) return 'test'
if (/documentation|docs|comment|readme/.test(allText)) return 'documentation'
if (/chore|dependency|config|maintenance/.test(allText)) return 'chore'
if (/fix|patch|resolve|correct/.test(allText)) return 'bugfix'
if (/feature|add|implement|create|build/.test(allText)) return 'feature'
// 默认
return 'standard'
}在执行流程中的用法:
javascript
// 解析解决方案后(步骤2)
const strategy = determineStrategy(solution)
console.log(`Strategy selected: ${strategy}`)
// 在任务执行期间(步骤3),遵循特定策略的阶段
for (const task of solution.tasks) {
executeTaskWithStrategy(task, strategy)
}Step 2.5: Initialize Task Tracking
步骤2.5:初始化任务跟踪
After parsing solution and determining strategy, use to track each task:
update_planjavascript
// Initialize plan with all tasks from solution
update_plan({
explanation: `Starting solution ${item_id}`,
plan: solution.tasks.map(task => ({
step: `${task.id}: ${task.title}`,
status: "pending"
}))
})Note: Codex uses tool for task tracking (not TodoWrite).
update_plan解析解决方案并确定策略后,使用跟踪每个任务:
update_planjavascript
// 使用解决方案中的所有任务初始化计划
update_plan({
explanation: `Starting solution ${item_id}`,
plan: solution.tasks.map(task => ({
step: `${task.id}: ${task.title}`,
status: "pending"
}))
})注意: Codex使用工具进行任务跟踪(而非TodoWrite)。
update_planStep 3: Execute Tasks Sequentially
步骤3:依次执行任务
Iterate through array and execute each task.
solution.tasksBefore starting each task, mark it as in_progress:
javascript
// Update current task status
update_plan({
explanation: `Working on ${task.id}: ${task.title}`,
plan: tasks.map(t => ({
step: `${t.id}: ${t.title}`,
status: t.id === task.id ? "in_progress" : (t.completed ? "completed" : "pending")
}))
})After completing each task (verification passed), mark it as completed:
javascript
// Mark task as completed (commit happens at solution level)
update_plan({
explanation: `Completed ${task.id}: ${task.title}`,
plan: tasks.map(t => ({
step: `${t.id}: ${t.title}`,
status: t.id === task.id ? "completed" : t.status
}))
})遍历数组并执行每个任务。
solution.tasks在开始每个任务前,将其标记为in_progress:
javascript
// 更新当前任务状态
update_plan({
explanation: `Working on ${task.id}: ${task.title}`,
plan: tasks.map(t => ({
step: `${t.id}: ${t.title}`,
status: t.id === task.id ? "in_progress" : (t.completed ? "completed" : "pending")
}))
})完成每个任务后(验证通过),将其标记为completed:
javascript
// 标记任务为已完成(提交在解决方案级别进行)
update_plan({
explanation: `Completed ${task.id}: ${task.title}`,
plan: tasks.map(t => ({
step: `${t.id}: ${t.title}`,
status: t.id === task.id ? "completed" : t.status
}))
})Phase A: IMPLEMENT
阶段A:实现
- Read context files in parallel using :
multi_tool_use.parallel
javascript
// Read all relevant files in parallel for context
multi_tool_use.parallel({
tool_uses: solution.exploration_context.relevant_files.map(file => ({
recipient_name: "functions.read_file",
parameters: { path: file }
}))
})- Follow steps in order
task.implementation - Apply changes to files
task.modification_points - Follow for code style consistency
solution.exploration_context.patterns - Run checks if specified to ensure no breakage
task.regression
Output format:
undefined- 使用并行读取上下文文件:
multi_tool_use.parallel
javascript
// 并行读取所有相关文件以获取上下文
multi_tool_use.parallel({
tool_uses: solution.exploration_context.relevant_files.map(file => ({
recipient_name: "functions.read_file",
parameters: { path: file }
}))
})- 按顺序遵循步骤
task.implementation - 对中的文件进行修改
task.modification_points - 遵循保证代码风格一致性
solution.exploration_context.patterns - 如果指定了,运行检查确保没有破坏现有功能
task.regression
输出格式:
undefinedImplementing: [task.title] (Task [N]/[Total])
正在实现:[task.title](第[N]/[总任务数]个任务)
Scope: [task.scope]
Action: [task.action]
Steps:
- ✓ [implementation step 1]
- ✓ [implementation step 2] ...
Files Modified:
- path/to/file1.ts
- path/to/file2.ts
undefined范围: [task.scope]
操作: [task.action]
步骤:
- ✓ [实现步骤1]
- ✓ [实现步骤2] ...
修改的文件:
- path/to/file1.ts
- path/to/file2.ts
undefinedPhase B: TEST
阶段B:测试
- Run all commands in
task.test.commands - Verify unit tests pass ()
task.test.unit - Run integration tests if specified ()
task.test.integration
If tests fail: Fix the code and re-run. Do NOT proceed until tests pass.
Output format:
undefined- 运行中的所有命令
task.test.commands - 验证单元测试通过()
task.test.unit - 如果指定了集成测试,运行集成测试()
task.test.integration
如果测试失败: 修复代码并重新运行。在测试通过前不得继续。
输出格式:
undefinedTesting: [task.title]
正在测试:[task.title]
Test Results:
- Unit tests: PASSED
- Integration tests: PASSED (or N/A)
undefined测试结果:
- 单元测试:通过
- 集成测试:通过(或不适用)
undefinedPhase C: VERIFY
阶段C:验证
Check all are met using steps:
task.acceptance.criteriatask.acceptance.verificationundefined检查所有是否通过步骤满足:
task.acceptance.criteriatask.acceptance.verificationundefinedVerifying: [task.title]
正在验证:[task.title]
Acceptance Criteria:
- Criterion 1: Verified
- Criterion 2: Verified ...
Verification Steps:
- Run test command
- Manual verification step
All criteria met: YES
**If any criterion fails**: Go back to IMPLEMENT phase and fix.验收标准:
- 标准1:已验证
- 标准2:已验证 ...
验证步骤:
- 运行测试命令
- 手动验证步骤
所有标准均满足:是
**如果任何标准不满足**: 返回实现阶段进行修复。Repeat for Next Task
重复执行下一个任务
Continue to next task in array until all tasks are complete.
solution.tasksNote: Do NOT commit after each task. Commits happen at solution level after all tasks pass.
继续执行数组中的下一个任务,直到所有任务完成。
solution.tasks注意: 不要在每个任务后提交。提交在所有任务通过后的解决方案级别进行。
Step 3.5: Commit Solution
步骤3.5:提交解决方案
After ALL tasks in the solution pass implementation, testing, and verification, commit once for the entire solution:
bash
undefined在解决方案的所有任务都通过实现、测试和验证后,为整个解决方案进行一次提交:
bash
undefinedStage all modified files from all tasks
暂存所有任务中的修改文件
git add path/to/file1.ts path/to/file2.ts ...
git add path/to/file1.ts path/to/file2.ts ...
Commit with clean, standard format (NO solution metadata)
使用清晰的标准格式提交(不包含解决方案元数据)
git commit -m "commit_type: [brief description of changes]"
git commit -m "commit_type: [brief description of changes]"
Example commits:
提交示例:
feat(auth): add token refresh mechanism
feat(auth): add token refresh mechanism
fix(payment): resolve timeout handling in checkout flow
fix(payment): resolve timeout handling in checkout flow
refactor(api): simplify error handling logic
refactor(api): simplify error handling logic
**Commit Type Selection**:
- `feat`: New feature or capability
- `fix`: Bug fix
- `refactor`: Code restructuring without behavior change
- `test`: Adding or updating tests
- `docs`: Documentation changes
- `chore`: Maintenance tasks
**Commit Language**:
- Use **Chinese** commit summary if project's `CLAUDE.md` specifies Chinese response guidelines or user explicitly requests Chinese
- Use **English** commit summary by default or when project targets international collaboration
- Check project's existing commit history for language convention consistency
**Output format:**
**提交类型选择**:
- `feat`: 新功能或能力
- `fix`: 问题修复
- `refactor`: 代码重构,不改变行为
</think_never_used_51bce0c785ca2f68081bfa7d91973934></think_never_used_51bce0c785ca2f68081bfa7d91973934></think_never_used_51bce0c785ca2f68081bfa7d91973934></think_never_used_51bce0c785ca2f68081bfa7d91973934>
- `test`: 添加或更新测试
- `docs`: 文档变更
- `chore`: 维护任务
**提交语言**:
- 如果项目的`CLAUDE.md`指定了中文响应指南,或用户明确要求中文,则使用**中文**提交摘要
- 默认或项目面向国际协作时,使用**英文**提交摘要
- 检查项目现有提交历史,保持语言约定一致
**输出格式**:Solution Committed: [solution_id]
解决方案已提交:[solution_id]
Commit: [commit hash]
Type: commit_type
Changes:
- [Feature/Fix/Improvement]: [What functionality was added/fixed/improved]
- [Specific change 1]
- [Specific change 2]
Files Modified:
- path/to/file1.ts - [Brief description of changes]
- path/to/file2.ts - [Brief description of changes]
- path/to/file3.ts - [Brief description of changes]
Solution: [solution_id] ([N] tasks completed)
undefined提交: [commit hash]
类型: commit_type
变更:
- [具体变更1]
- [具体变更2]
修改的文件:
- path/to/file1.ts - [变更简要描述]
- path/to/file2.ts - [变更简要描述]
- path/to/file3.ts - [变更简要描述]
解决方案: [solution_id](完成了[N]个任务)
undefinedStep 4: Report Completion
步骤4:报告完成
After ALL tasks in the solution are complete and committed, report to queue system with full solution metadata:
javascript
// ccw auto-detects worktree and uses main repo's .workflow/
// Record ALL solution context here (NOT in git commit)
shell_command({
command: `ccw issue done ${item_id} --result '${JSON.stringify({
solution_id: solution.id,
issue_id: issue_id,
commit: {
hash: commit_hash,
type: commit_type,
scope: commit_scope,
message: commit_message
},
analysis: {
risk: solution.analysis.risk,
impact: solution.analysis.impact,
complexity: solution.analysis.complexity
},
tasks_completed: solution.tasks.map(t => ({
id: t.id,
title: t.title,
action: t.action,
scope: t.scope
})),
files_modified: ["path1", "path2", ...],
tests_passed: true,
verification: {
all_tests_passed: true,
acceptance_criteria_met: true,
regression_checked: true
},
summary: "[What was accomplished - brief description]"
})}'`
})Complete Example:
javascript
shell_command({
command: `ccw issue done S-1 --result '${JSON.stringify({
solution_id: "SOL-ISS-20251227-001-1",
issue_id: "ISS-20251227-001",
commit: {
hash: "a1b2c3d4",
type: "feat",
scope: "auth",
message: "feat(auth): add token refresh mechanism"
},
analysis: {
risk: "low",
impact: "medium",
complexity: "medium"
},
tasks_completed: [
{ id: "T1", title: "Implement refresh token endpoint", action: "Add", scope: "src/auth/" },
{ id: "T2", title: "Add token rotation logic", action: "Create", scope: "src/auth/services/" }
],
files_modified: [
"src/auth/routes/token.ts",
"src/auth/services/refresh.ts",
"src/auth/middleware/validate.ts"
],
tests_passed: true,
verification: {
all_tests_passed: true,
acceptance_criteria_met: true,
regression_checked: true
},
summary: "Implemented token refresh mechanism with automatic rotation"
})}'`
})If solution failed:
javascript
shell_command({
command: `ccw issue done ${item_id} --fail --reason '${JSON.stringify({
task_id: "TX",
error_type: "test_failure",
message: "Integration tests failed: timeout in token validation",
files_attempted: ["path1", "path2"],
commit: null
})}'`
})在解决方案的所有任务完成并提交后,向队列系统报告完整的解决方案元数据:
javascript
// ccw auto-detects worktree and uses main repo's .workflow/
// 在此处记录所有解决方案上下文(不要放在git提交中)
shell_command({
command: `ccw issue done ${item_id} --result '${JSON.stringify({
solution_id: solution.id,
issue_id: issue_id,
commit: {
hash: commit_hash,
type: commit_type,
scope: commit_scope,
message: commit_message
},
analysis: {
risk: solution.analysis.risk,
impact: solution.analysis.impact,
complexity: solution.analysis.complexity
},
tasks_completed: solution.tasks.map(t => ({
id: t.id,
title: t.title,
action: t.action,
scope: t.scope
})),
files_modified: ["path1", "path2", ...],
tests_passed: true,
verification: {
all_tests_passed: true,
acceptance_criteria_met: true,
regression_checked: true
},
summary: "[完成的工作 - 简要描述]"
})}'`
})完整示例:
javascript
shell_command({
command: `ccw issue done S-1 --result '${JSON.stringify({
solution_id: "SOL-ISS-20251227-001-1",
issue_id: "ISS-20251227-001",
commit: {
hash: "a1b2c3d4",
type: "feat",
scope: "auth",
message: "feat(auth): add token refresh mechanism"
},
analysis: {
risk: "low",
impact: "medium",
complexity: "medium"
},
tasks_completed: [
{ id: "T1", title: "Implement refresh token endpoint", action: "Add", scope: "src/auth/" },
{ id: "T2", title: "Add token rotation logic", action: "Create", scope: "src/auth/services/" }
],
files_modified: [
"src/auth/routes/token.ts",
"src/auth/services/refresh.ts",
"src/auth/middleware/validate.ts"
],
tests_passed: true,
verification: {
all_tests_passed: true,
acceptance_criteria_met: true,
regression_checked: true
},
summary: "Implemented token refresh mechanism with automatic rotation"
})}'`
})如果解决方案失败:
javascript
shell_command({
command: `ccw issue done ${item_id} --fail --reason '${JSON.stringify({
task_id: "TX",
error_type: "test_failure",
message: "Integration tests failed: timeout in token validation",
files_attempted: ["path1", "path2"],
commit: null
})}'`
})Step 5: Continue to Next Solution
步骤5:继续执行下一个解决方案
Fetch next solution (using same QUEUE_ID from Step 0/1):
javascript
// ccw auto-detects worktree
// Continue using the same QUEUE_ID throughout execution
const result = shell_command({ command: `ccw issue next --queue ${QUEUE_ID}` })Output progress:
✓ [N/M] Completed: [item_id] - [solution.description]
Commit: [commit_hash] ([commit_type])
Tasks: [task_count] completed
→ Fetching next solution...DO NOT STOP. Return to Step 2 and continue until queue is empty.
获取下一个解决方案(使用步骤0/1中的同一个QUEUE_ID):
javascript
// ccw auto-detects worktree
// 在整个执行过程中使用同一个QUEUE_ID
const result = shell_command({ command: `ccw issue next --queue ${QUEUE_ID}` })输出进度:
✓ [N/M] 已完成: [item_id] - [solution.description]
提交: [commit_hash] ([commit_type])
任务: [task_count]个已完成
→ 获取下一个解决方案...不要停止。返回步骤2继续执行,直到队列为空。
Final Summary
最终摘要
When returns :
ccw issue next{ "status": "empty" }If running in worktree mode: Prompt user for merge/PR/keep choice (see "Completion - User Choice" above) before outputting summary.
markdown
undefined当返回时:
ccw issue next{ "status": "empty" }如果在工作树模式下运行: 在输出摘要前,提示用户选择合并/创建PR/保留分支(见上文“完成 - 用户选择”)。
markdown
undefinedIssue Queue Execution Complete
问题队列执行完成
Total Solutions Executed: N
Total Tasks Executed: M
Total Commits: N (one per solution)
Solution Commits:
| # | Solution | Tasks | Commit | Type |
|---|---|---|---|---|
| 1 | SOL-xxx-1 | T1, T2 | abc123 | feat |
| 2 | SOL-xxx-2 | T1 | def456 | fix |
| 3 | SOL-yyy-1 | T1, T2, T3 | ghi789 | refactor |
Files Modified:
- path/to/file1.ts
- path/to/file2.ts
Summary:
[Overall what was accomplished]
undefined已执行解决方案总数: N
已执行任务总数: M
提交总数: N(每个解决方案一次提交)
解决方案提交:
| # | 解决方案 | 任务 | 提交 | 类型 |
|---|---|---|---|---|
| 1 | SOL-xxx-1 | T1, T2 | abc123 | feat |
| 2 | SOL-xxx-2 | T1 | def456 | fix |
| 3 | SOL-yyy-1 | T1, T2, T3 | ghi789 | refactor |
修改的文件:
- path/to/file1.ts
- path/to/file2.ts
摘要:
[整体完成的工作内容]
undefinedExecution Rules
执行规则
- Never stop mid-queue - Continue until queue is empty
- One solution at a time - Fully complete (all tasks + commit + report) before moving on
- Sequential within solution - Complete each task's implement/test/verify before next task
- Tests MUST pass - Do not proceed if any task's tests fail
- One commit per solution - All tasks share a single commit with formatted summary
- Self-verify - All acceptance criteria must pass before solution commit
- Report accurately - Use after each solution
ccw issue done - Handle failures gracefully - If a solution fails, report via and continue to next
ccw issue done --fail - Track with update_plan - Use update_plan tool for task progress tracking
- Worktree auto-detect - commands auto-redirect to main repo from worktree
ccw issue
- 不要在队列中途停止 - 持续执行直到队列为空
- 一次处理一个解决方案 - 完全完成(所有任务+提交+报告)后再处理下一个
- 解决方案内串行执行 - 完成每个任务的实现/测试/验证后再执行下一个任务
- 测试必须通过 - 如果任何任务的测试失败,不得继续
- 每个解决方案一次提交 - 所有任务共享一个带有格式化摘要的提交
- 自我验证 - 在解决方案提交前,所有验收标准必须通过
- 准确报告 - 每个解决方案完成后使用
ccw issue done - 优雅处理失败 - 如果解决方案失败,通过报告,然后继续处理下一个
ccw issue done --fail - 使用update_plan跟踪 - 使用update_plan工具跟踪任务进度
- 工作树自动检测 - 命令从工作树中自动重定向到主仓库
ccw issue
Error Handling
错误处理
| Situation | Action |
|---|---|
| All done - output final summary |
| Tests fail | Fix code, re-run tests |
| Verification fails | Go back to implement phase |
| Solution commit fails | Check staging, retry commit |
| Log error, continue to next solution |
| Any task unrecoverable | Call |
| 情况 | 操作 |
|---|---|
| 全部完成 - 输出最终摘要 |
| 测试失败 | 修复代码,重新运行测试 |
| 验证失败 | 返回实现阶段 |
| 解决方案提交失败 | 检查暂存状态,重试提交 |
| 记录错误,继续处理下一个解决方案 |
| 任何任务无法恢复 | 调用 |
CLI Command Reference
CLI命令参考
| Command | Purpose |
|---|---|
| List all queues (for queue selection) |
| Fetch next solution from specified queue (--queue required) |
| Mark solution complete with result (auto-detects queue) |
| Mark solution failed with structured reason |
| Reset failed items in specific queue |
| 命令 | 用途 |
|---|---|
| 列出所有队列(用于队列选择) |
| 从指定队列获取下一个解决方案(--queue为必填项) |
| 标记解决方案完成并提交结果(自动检测队列) |
| 标记解决方案失败并提交结构化原因 |
| 重置指定队列中的失败项 |
Start Execution
开始执行
Step 0: Validate Queue ID
If was NOT provided in the command arguments:
--queue- Run
ccw issue queue list --brief --json - Filter and display active/pending queues to user
- Stop execution, prompt user to rerun with
--queue QUE-xxx
Step 1: Fetch First Solution
Once queue ID is confirmed, begin by running:
bash
ccw issue next --queue <queue-id>Then follow the solution lifecycle for each solution until queue is empty.
步骤0:验证队列ID
如果命令参数中未提供:
--queue- 运行
ccw issue queue list --brief --json - 筛选并显示活跃/待处理队列给用户
- 停止执行,提示用户使用重新运行
--queue QUE-xxx
步骤1:获取第一个解决方案
一旦确认队列ID,通过运行以下命令开始:
bash
ccw issue next --queue <queue-id>然后为每个解决方案遵循生命周期流程,直到队列为空。
",