flow-develop

主机：Codex CLI — 此技能最初为 Claude Code 设计，后改编供 Codex 使用。 交叉引用命令在 Codex 中使用已安装的技能名称，而不是 /octo:* 斜杠命令。 使用当前 Codex shell 和子 Agent 工具。在当前会话未提供相应能力前，不要声称某个提供方、模型或主机子 Agent 可用。 主机工具的对应项请参阅 skills/blocks/codex-host-adapter.md。

{{PREAMBLE}}

从已安装的插件中加载 skills/blocks/engineering-method-selection.md， 并仅应用与此任务相关的方法。保留此入口点的执行约定和输出格式。将引用的技能作为指令阅读； 不要递归调用当前命令，也不要从某个席位发起提供方调用。

可移植功能边界

实现前，选择现有功能并运行其边界适配器：

OCTO_ROOT="${CLAUDE_PLUGIN_ROOT:-${HOME}/.claude-octopus/plugin}"
bash "$OCTO_ROOT/scripts/helpers/feature-workflow.sh" boundary develop "${OCTOPUS_FEATURE:-}"

读取已绑定的项目策略、相对源文件和摘要。通过可用的原生主机提问工具，一次性询问返回的标记批次。将跳过或非交互式的决定保持为待定。报告未决项数量，并仅推迟当前约定取决于某个已命名且未获答复的决定的任务。运行时会在实际任务分派前重复这些检查。

两个或更多规范／计划／任务产物会自动触发确定性分析。检查通过时无需额外的模型席位。未解决的发现最多可触发一个独立且有界的席位；对于该产物版本，主机与运行时共用此席位。语义审查不可用或失败时，发出警告并继续。分析会报告精确的源文引述，且不会重写产物。

存在稳定任务 ID 和元数据时，应予以使用。父级会在每个波次重新解析路径、依赖关系和当前 Git 状态。提示不能授予并发权限，也不能允许覆盖用户更改。旧版输入保留其现有规划器和执行路径。

开发前：状态检查

开始开发前：

1. 阅读 .octo/STATE.md，确认 Define 阶段已完成
2. 更新 STATE.md：
   • current_phase: 3
   • phase_position: "Development"
   • status: "in_progress"

# Verify Define phase is complete
if [[ -f ".octo/STATE.md" ]]; then
  define_status=$("${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" get_phase_status 2)
  if [[ "$define_status" != "complete" ]]; then
    echo "⚠️ Warning: Define phase not marked complete. Consider running definition first."
  fi
fi

# Update state for Development phase
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
  --phase 3 \
  --position "Development" \
  --status "in_progress"

⚠️ 执行约定（强制——不可跳过）

此技能使用强制执行模式。必须严格遵循以下顺序。

第 1 步：检测工作上下文（强制）

分析用户提示和项目，以确定上下文：

知识类上下文指标：

• 交付物相关词语：“PRD”、“提案”、“演示文稿”、“报告”、“战略文档”、“商业案例”
• 商业相关词语：“市场进入”、“竞争分析”、“利益相关方”、“执行摘要”

开发类上下文指标：

• 技术相关词语：“API”、“端点”、“函数”、“模块”、“服务”、“组件”
• 操作相关词语：“实现”、“编码”、“构建”、“创建”、“开发” + 技术名词

同时检查：项目是否包含 package.json、Cargo.toml 等文件？（这表明可能属于开发类上下文）

记录 context_type = "Dev" 或 "Knowledge"

步骤 1b：检测开发子类型（如果是开发上下文）

当 context_type 为 Dev 时，确定子类型，以便在发送给提供方的提示词中注入适合该领域的质量指导。将匹配的补充文本追加到用户提示词之后。

子类型	触发关键词	质量补充内容
frontend-ui	"page"、"widget"、"component"、"UI"、"HTML"、"CSS"、"form"、"dashboard"、"layout"	请参阅下方的 frontend-ui 增强内容。
cli-tool	"CLI"、"command-line"、"terminal"、"script"、"flag"、"argument"	通过 --help 标志提供帮助文本。使用有意义的退出代码（0 表示成功，1 表示用户错误，2 表示系统错误）。正确使用 stdin/stdout/stderr。验证参数并提供清晰的错误消息。
api-service	"API"、"endpoint"、"REST"、"GraphQL"、"gRPC"、"server"、"route"	在边界处验证输入。使用一致的错误响应格式。为每个端点配置身份验证/授权。考虑速率限制。提供 OpenAPI/schema 文档。
infra	"deploy"、"terraform"、"docker"、"CI"、"pipeline"、"Kubernetes"、"helm"	操作应具备幂等性。切勿将密钥硬编码。记录回滚路径。包含健康检查。
data	"ETL"、"pipeline"、"migration"、"schema"、"database"、"SQL"	迁移应具备幂等性。制定备份/回滚策略。在数据摄取时验证数据。
general	未匹配任何子类型时的默认值	不添加补充内容——仅使用基础实现者角色。

frontend-ui 增强内容

检测到 frontend-ui 子类型时，请执行以下两项操作：

A. 在提示词中注入质量补充内容： 优先使用自包含文件。无障碍：ARIA 标签、键盘导航、44px 触控目标（WCAG 2.5.5）。安全 DOM：优先使用 createElement，而非 innerHTML。渐进增强：通过功能检测识别 API（navigator.share、localStorage），并提供回退方案。通过 localStorage 保存用户偏好设置。

B. 从 BM25 获取设计智能信息（如果可用）：

调用 orchestrate.sh 之前，请检查设计智能引擎是否存在，并查询相关设计上下文：

SEARCH_PY="${HOME}/.claude-octopus/plugin/vendors/ui-ux-pro-max-skill/src/ui-ux-pro-max/scripts/search.py"
if [[ -f "$SEARCH_PY" ]]; then
    # Detect relevant domains from the prompt
    design_context=""
    # Style query — what visual style fits this task?
    style_hit=$(python3 "$SEARCH_PY" "<user's task description>" --domain style --top 1 2>/dev/null || true)
    [[ -n "$style_hit" ]] && design_context+="Design style suggestion: $style_hit\n"
    # UX query — relevant UX patterns
    ux_hit=$(python3 "$SEARCH_PY" "<user's task description>" --domain ux --top 1 2>/dev/null || true)
    [[ -n "$ux_hit" ]] && design_context+="UX pattern: $ux_hit\n"
    # Append to prompt if hits found
    if [[ -n "$design_context" ]]; then
        # Append design intelligence to the orchestrate.sh prompt
        prompt="${prompt}\n\nDesign intelligence (from BM25 search):\n${design_context}"
    fi
fi

这样可为提供方提供具体的设计指导（风格方向、UX 模式），无需用户单独运行 /octo:design-ui-ux。如果未安装搜索引擎，则仅使用质量补充内容继续实施。

**应用方式：**在步骤 4 中调用 orchestrate.sh 时，将质量补充内容（以及可用的设计智能信息）追加到提示词中：

orchestrate.sh develop "<user prompt>\n\nQuality requirements for this deliverable:\n<supplement text>\n<design intelligence if found>"

**在确定上下文之前，不要继续执行步骤 2。**上下文类型（Dev 或 Knowledge）和开发子类型决定了要注入哪些质量补充内容和设计智能信息——上下文错误会导致提供方将额度浪费在无关分析上。

步骤 2：显示视觉指示器（强制 - 阻塞）

强制要求：在显示横幅之前，必须使用原生命令行工具运行此提供方检查。不得跳过。不得假定提供方可用。

bash "${HOME}/.claude-octopus/plugin/scripts/helpers/check-providers.sh"

请使用以下实际结果。禁止：只显示“🔵 Claude: Available ✓”，而不列出所有提供方。

如果设置了 OCTO_ALLOWED_PROVIDERS，则将其视为允许参与的提供方的唯一依据。允许列表筛除的提供方会被有意报告为不可用；请勿在工作流中调用或推荐这些提供方。

在执行 orchestrate.sh 之前显示此横幅：

对于 Dev 上下文：

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Dev] Develop Phase: [Brief description of what you're building]

Provider Availability:
🔴 Codex CLI: ${codex_status} - Code generation and patterns
🟡 Antigravity CLI: ${agy_status} - Alternative approaches
🧭 Antigravity CLI: ${agy_status} - Additional external-model challenge
🔵 Claude: Available ✓ - Integration and quality gates

💰 Estimated Cost: 0.02-0.10 USD
⏱️  Estimated Time: 3-7 minutes

对于 Knowledge 上下文：

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Knowledge] Develop Phase: [Brief description of deliverable]

Provider Availability:
🔴 Codex CLI: ${codex_status} - Structure and framework application
🟡 Antigravity CLI: ${agy_status} - Content and narrative development
🧭 Antigravity CLI: ${agy_status} - Additional external-model challenge
🔵 Claude: Available ✓ - Integration and quality review

💰 Estimated Cost: 0.02-0.10 USD
⏱️  Estimated Time: 3-7 minutes

**显示横幅之前，不要继续执行步骤 3。**横幅会向用户显示哪些提供方将运行以及他们会产生哪些费用——在用户看不到这些信息时启动 API 调用，违反了费用透明原则。

STEP 3：读取先前状态（强制 — 状态管理）

执行工作流前，读取任何先前的上下文：

# Initialize state if needed
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" init_state

# Set current workflow
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" set_current_workflow "flow-develop" "develop"

# Get prior decisions (critical for implementation)
prior_decisions=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_decisions "all")

# Get context from discover and define phases
discover_context=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_context "discover")
define_context=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_context "define")

# Display what you found (if any)
if [[ "$discover_context" != "null" ]]; then
  echo "📋 Discovery phase findings:"
  echo "  $discover_context"
fi

if [[ "$define_context" != "null" ]]; then
  echo "📋 Definition phase scope:"
  echo "  $define_context"
fi

if [[ "$prior_decisions" != "[]" && "$prior_decisions" != "null" ]]; then
  echo "📋 Implementing with decisions:"
  echo "$prior_decisions" | jq -r '.[] | "  - \(.decision) (\(.phase)): \(.rationale)"'
fi

这会提供实施所需的关键信息：

• 已决定的技术栈和模式
• 已定义的范围和要求
• 为实施提供参考的研究发现
• 如果已安装 claude-mem，则可以使用其 MCP 工具（search、timeline、get_observations）检查相关的过往实施模式

读取状态前，禁止继续执行 STEP 4。

STEP 4：执行 orchestrate.sh develop（强制 — 使用 Bash 工具）

你必须通过原生 shell 命令工具执行此命令：

${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh develop "<user's implementation request>"

重要：严禁：

• ❌ 未调用 orchestrate.sh 就直接实施 — 单模型实施会错过外部提供方通过独立分析发现的替代方案和边缘情况
• ❌ 不参考多个提供方的观点就编写代码
• ❌ 声称自己在“模拟”工作流
• ❌ 未运行此命令就继续执行步骤 4

你必须使用原生 shell 命令工具调用 orchestrate.sh。

执行期间用户看到的内容（v7.16.0+）

如果在 Claude Code v2.1.16+ 中运行，用户会在任务旋转指示器中看到实时进度指示：

阶段 1 — 外部提供方执行（并行）：

• 🔴 正在生成代码和模式（Codex）...
• 🟡 正在探索替代方案（Antigravity）...

阶段 2 — 综合（顺序执行）：

• 🔵 正在整合并应用质量关卡...

这些旋转指示器的状态描述会自动更新 — orchestrate.sh 会在每个 Agent 执行前调用 update_task_progress()。用户可以清楚看到哪个提供方正在工作以及正在执行什么任务。

**如果未在 Claude Code v2.1.16+ 中运行：**进度指示会静默跳过，不会显示错误。

STEP 5：验证执行（强制 — 验证关卡）

orchestrate.sh 完成后，验证其是否成功：

# Find the latest synthesis file (created within last 10 minutes)
SYNTHESIS_FILE=$(find ~/.claude-octopus/results -name "tangle-synthesis-*.md" -mmin -10 2>/dev/null | head -n1)

if [[ -z "$SYNTHESIS_FILE" ]]; then
  echo "❌ VALIDATION FAILED: No synthesis file found"
  echo "orchestrate.sh did not execute properly"
  exit 1
fi

echo "✅ VALIDATION PASSED: $SYNTHESIS_FILE"
cat "$SYNTHESIS_FILE"

如果验证失败：

1. 向用户报告错误
2. 显示 ~/.claude-octopus/logs/ 中的日志
3. 不要继续展示结果
4. 不要用直接实施来替代 — 回退到单模型实施会跳过多提供方综合，无法及早发现设计缺陷

STEP 6：更新状态（强制 — 执行后）

验证综合结果后，将实施详情记录到状态中：

# Extract key implementation decisions from synthesis
implementation_approach=$(head -50 "$SYNTHESIS_FILE" | grep -A 3 "## Implementation\|## Approach" | tail -3 | tr '\n' ' ')

# Record implementation decisions
decision_made=$(echo "$implementation_approach" | grep -o "implemented\|using [A-Za-z0-9 ]*\|chose to\|pattern:" | head -1)

if [[ -n "$decision_made" ]]; then
  "${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" write_decision \
    "develop" \
    "$decision_made" \
    "Multi-AI implementation consensus"
fi

# Update develop phase context
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" update_context \
  "develop" \
  "$implementation_approach"

# Update metrics
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" update_metrics "phases_completed" "1"

更新状态前，禁止继续执行 STEP 7。

STEP 7：展示实施计划（仅在完成步骤 1–6 后）

读取综合文件并展示：

• 推荐方案
• 实施步骤
• 所有可用观点中的代码概述
• 质量关卡结果
• 请求用户确认后再实施

用户确认后：使用 Write/Edit 工具实施解决方案

注明归属：

*Multi-AI Implementation powered by Claude Octopus*
*Providers: available external providers + 🔵 Claude*
*Full implementation plan: $SYNTHESIS_FILE*

开发工作流 — 开发阶段 🛠️

⚠️ 强制：上下文检测与视觉指示

执行任何工作流操作之前，你必须：

步骤 1：检测工作上下文

分析用户的提示词和项目，确定上下文：

知识上下文指标（在提示词中）：

• 交付物相关术语：“PRD”“提案”“演示文稿”“报告”“策略文档”“商业案例”
• 商业相关术语：“市场进入”“竞争分析”“利益相关方”“执行摘要”

开发上下文指标（在提示词中）：

• 技术相关术语：“API”“端点”“函数”“模块”“服务”“组件”
• 操作相关术语：“实施”“编写代码”“构建”“创建”“开发” + 技术名词

**还需检查：**项目是否包含 package.json、Cargo.toml 等文件？（这表明属于开发上下文）

步骤 1b：检测开发子类型 — 请参阅上文 EXECUTION CONTRACT 步骤 1b 中的子类型表和质量补充内容。调用 orchestrate.sh 前，将相应补充内容添加到提示词中。

第 2 步：输出上下文感知横幅

对于开发上下文：

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Dev] Develop Phase: [Brief description of what you're building]
📋 Session: ${CLAUDE_SESSION_ID}

Providers:
🔴 Codex CLI - Code generation and patterns
🟡 Antigravity CLI - Alternative approaches
🔵 Claude - Integration and quality gates

对于知识上下文：

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Knowledge] Develop Phase: [Brief description of deliverable]
📋 Session: ${CLAUDE_SESSION_ID}

Providers:
🔴 Codex CLI - Structure and framework application
🟡 Antigravity CLI - Content and narrative development
🔵 Claude - Integration and quality review

{{VISUAL_INDICATORS}}

双钻石流程的一部分：DEVELOP（发散思维）

       DEVELOP (tangle)

        \         /
         \   *   /
          \ * * /
           \   /
            \ /

       Diverge with
        solutions

此工作流的作用

develop 阶段使用外部 CLI 提供方生成多种实现方案：

1. 🔴 Codex CLI - 专注于实现、代码生成和技术模式
2. 🟡 Antigravity CLI - 提供替代方案、边缘情况和最佳实践
3. 🔵 Claude（你） - 负责整合、完善和最终实现

这是解决方案的发散阶段——在收敛到最佳方案之前，我们会探索不同的实现路径。

何时使用 Develop

在以下情况下使用 develop：

开发上下文示例

• 功能实现：“构建一个用户身份验证系统”
• 代码生成：“创建一个用于用户注册的 API 端点”
• 复杂构建：“使用 Redis 实现缓存层”
• 架构实现：“创建一个用于支付处理的微服务”
• 集成工作：“集成 Stripe 支付处理”

知识上下文示例

• PRD 创建：“为移动端引导功能编写 PRD”
• 战略文档：“制定面向亚太地区的市场进入战略”
• 商业案例：“为迁移到云端编写商业案例”
• 演示文稿：“制作关于 Q2 业绩的高管演示文稿”
• 研究报告：“编写竞争分析报告”

不要将 develop 用于：

• 简单的单行代码更改（使用 Edit 工具）
• Bug 修复（使用调试技能）
• 代码审查任务（使用 deliver-workflow 或审查技能）
• 阅读或探索代码（使用 Read 工具）
• 简单的文档编辑（使用 Write 工具）

视觉指示

执行前，你会看到：

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation
🛠️ Develop Phase: Building and developing solutions

Providers:
🔴 Codex CLI - Code generation and patterns
🟡 Antigravity CLI - Alternative approaches
🔵 Claude - Integration and refinement

工作原理

第 1 步：调用 Tangle 阶段

${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh develop "<user's implementation request>"

第 2 步：多提供方实现

orchestrate.sh 脚本将：

1. 使用实现任务调用 Codex CLI
2. 使用实现任务调用 Antigravity CLI
3. 由你（Claude）贡献实现分析
4. 综合各方案并推荐最佳路径

第 3 步：检查质量门禁

tangle 阶段包含自动质量验证：

• 代码质量检查
• 安全扫描
• 最佳实践验证
• 实现完整性检查

第 3b 步：处理 Agent 续接（v9.5 / CC v2.1.77+）

当 orchestrate.sh 输出包含 AGENT_TEAMS_RESUME:${agent_id}:${task_id}:${role}:${phase} 时：

1. 使用 SendMessage({to: "${agent_id}", message: "<iteration prompt>"}) 向现有 Agent 发送消息——此操作会自动恢复已停止的 Agent（CC v2.1.77+）
2. 从恢复指令 JSON 中读取迭代提示词，文件路径为 ~/.claude-octopus/agent-teams/${task_id}.json
3. 如果 SendMessage 返回错误（Agent 已被垃圾回收或未找到），则使用指令文件中的完整提示词创建新 Agent
4. Agent 回复后，通过以下方式在桥接账本中存储其 agentId：bridge_store_agent_id(task_id, agent_id)

注意：CC v2.1.77 中已移除 Agent(resume: ...) 参数。继续 Agent 时始终使用 SendMessage。

第 4 步：读取结果

结果保存至：

~/.claude-octopus/results/${SESSION_ID}/tangle-synthesis-<timestamp>.md

第 5 步：实现解决方案

审阅所有观点后，使用 Write/Edit 工具实现最终解决方案。

实施说明

调用此技能时，请严格遵循上文的执行约定。该约定包括：

1. 阻塞步骤 1：检测工作上下文（开发或知识）
2. 阻塞步骤 2：检查提供方并显示可视化指示
3. 阻塞步骤 3：通过原生 shell 命令工具执行 orchestrate.sh develop
4. 阻塞步骤 4：确认综合文件存在
5. 步骤 5：提供实施计划并征求用户确认
6. 确认后：使用 Write/Edit 工具实施解决方案

每个步骤都必须执行且具有阻塞性——只有当前步骤成功完成后，才能继续下一步。

任务管理集成

创建任务以跟踪执行进度：

// At start of skill execution
TaskCreate({
  subject: "Execute develop workflow with multi-AI providers",
  description: "Run orchestrate.sh develop for implementation",
  activeForm: "Running multi-AI develop workflow"
})

// Mark in_progress when calling orchestrate.sh
TaskUpdate({taskId: "...", status: "in_progress"})

// Mark completed ONLY after implementation finished
TaskUpdate({taskId: "...", status: "completed"})

错误处理

如果任何步骤失败：

• 步骤 1（上下文）：如果无法确定，则默认为开发上下文
• 步骤 2（提供方）：如果所有外部提供方都不可用，请建议使用 /octo:setup 并停止
• 步骤 3（orchestrate.sh）：显示 bash 错误、检查日志并向用户报告
• 步骤 4（验证）：如果综合文件缺失，请显示 orchestrate.sh 日志；不要用直接实施来替代

如果 orchestrate.sh 执行失败，绝不要退而采用直接实施。请报告失败情况，并让用户决定如何继续。

实施计划格式

成功执行后，按以下格式提供实施计划：

# Implementation Plan: <task>

## Recommended Approach
[Your strategic recommendation based on all perspectives]

## Implementation Steps
1. [Step-by-step implementation plan]
2. ...

## Code Overview

### Codex Approach
[Key implementation details from Codex]

### Antigravity Approach
[Alternative considerations from Antigravity]

### Final Implementation
[Your integrated solution]

## Quality Gates
- [ ] Security validation: PASSED/FAILED
- [ ] Best practices: PASSED/FAILED
- [ ] Code quality: PASSED/FAILED

Would you like me to proceed with implementation?

6. 实施解决方案 用户确认后，使用 Write/Edit 工具创建实施内容：
   • 创建必要的文件
   • 根据综合方案编写代码
   • 视情况添加测试
   • 编写实施文档

使用示例

示例 1：构建身份验证系统

User: Build a user authentication system with JWT

Claude:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ Develop Phase: Building authentication system

[Executes: ${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh develop "Build a user authentication system with JWT"]

[After completion, reads synthesis and presents:]

# Implementation Plan: User Authentication System

## Recommended Approach

Based on multi-provider analysis, I recommend a layered approach:
1. Auth middleware for JWT validation
2. Login/register endpoints
3. Token refresh mechanism
4. Secure password hashing (bcrypt)

## Implementation Steps

1. Create `src/auth/middleware.ts` - JWT validation middleware
2. Create `src/auth/controller.ts` - Login/register endpoints
3. Create `src/auth/service.ts` - Business logic
4. Create `src/auth/utils.ts` - Token generation/validation
5. Update `src/routes.ts` - Register auth routes

## Code Overview

### Codex Approach
- Modern TypeScript with strict types
- Express middleware pattern
- Redis for token blacklisting
- Comprehensive error handling

### Antigravity Approach
- Passport.js integration suggestion
- Rate limiting on auth endpoints
- Multi-factor auth consideration
- Session management alternatives

### Final Implementation
- Hybrid: Modern TypeScript + Express patterns
- JWT with refresh tokens
- bcrypt password hashing
- Rate limiting included
- Optional MFA hooks for future

## Quality Gates
- ✅ Security validation: PASSED (bcrypt, secure tokens)
- ✅ Best practices: PASSED (TypeScript, error handling)
- ⚠️  Code quality: WARNING (consider adding request validation)

Would you like me to proceed with implementation?

[User: Yes, proceed]

[Claude creates files and implements the solution]

示例 2：创建 API 端点

User: Create an API endpoint for fetching user notifications

Claude:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ Develop Phase: Creating API endpoint

[Executes tangle workflow]

[Presents implementation plan with multi-provider perspectives]
[Implements the endpoint after user confirmation]

质量门集成

tangle 阶段会通过 .claude/hooks/quality-gate.sh 自动运行质量检查：

# Triggered after tangle execution (PostToolUse hook)
./hooks/quality-gate.sh

{{QUALITY_GATES}}

与其他工作流的集成

Tangle 是双钻石流程的第三阶段：

PROBE (Discover) → GRASP (Define) → TANGLE (Develop) → INK (Deliver)

Tangle 完成后，你可以继续：

• Ink：验证并交付实施成果

也可以将其单独用于实施任务。

实施前检查清单

编写代码前，请确保：

• 所有提供方都已返回实施方案
• 已评估质量门（安全性、最佳实践、代码质量）
• 用户已确认实施计划
• 文件结构和架构清晰明确
• 已确认依赖项且可用
• 已规划测试（如适用）

实施后：自动代码审查与端到端验证（必须执行）

实施完成后、向用户展示结果之前，必须并行启动两个验证 Agent。 不要跳过此步骤，也不要询问用户是否运行——此步骤会自动执行。

同时启动两个 Agent：

Agent 1 — 代码审查（Sonnet）：

Agent(
  model: "sonnet",
  subagent_type: "feature-dev:code-reviewer",
  background execution: true,
  description: "Code review: post-develop",
  prompt: "Review the code changes from this development session. Focus on:
1. Bugs, logic errors, security vulnerabilities
2. Hidden dependencies or coupling issues
3. Whether error handling covers failure modes
4. Adherence to project conventions (check CLAUDE.md)

Check git diff for the changed files. Report only high-confidence issues."
)

Agent 2 — 端到端验证（Sonnet）：

Agent(
  model: "sonnet",
  background execution: true,
  description: "E2E test: post-develop",
  prompt: "Run end-to-end verification of the development changes:
1. Run the project's test suite (detect from package.json scripts, Makefile, or pyproject.toml)
2. Verify no regressions in existing tests
3. Check that new files are properly integrated (imported, registered, sourced)
4. Verify the implementation matches the original task requirements

Report: tests passed/failed, any integration issues found."
)

两个 Agent 完成后：

• 将它们的发现作为结果的一部分呈现给用户
• 如果代码审查员发现高置信度问题，请醒目地标出
• 如果测试失败，请在询问“接下来做什么？”之前标出
• 不要因审查而阻塞；应将发现与结果一并呈现

原因：用户不应在开发工作完成后还需要手动请求代码审查。由不同模型（Sonnet 与 Opus）进行独立审查，可以发现实施者容易忽略的问题。自动运行测试，则能在用户发现回归问题之前将其捕获。

实现后检查清单

编写代码后，请确保：

• 已创建/更新所有文件
• 代码遵循综合分析得出的推荐模式
• 代码遵循项目现有的注释规范（除非用户要求或项目风格要求，否则不要添加注释）
• 已处理安全问题
• 已实现错误处理
• 已编写测试（如适用）
• 已运行 lint/typecheck 命令（从 package.json、pyproject.toml、Cargo.toml、Makefile 中识别；如果未找到，请询问用户）
• 如果发现了 lint/test 命令，但未在 CLAUDE.md 中记录，请建议将其添加进去
• 已完成自动代码审查（Sonnet Agent）
• 已完成端到端验证（Sonnet Agent）
• 已告知用户工作已完成，并提供审查结果
• 建议运行 ink-workflow 进行验证

成本注意事项

外部 API 使用情况：

• 🔴 Codex CLI 使用你的 OPENAI_API_KEY（会产生费用）
• 🟡 Antigravity CLI 使用你的 AGY_AUTH_TOKEN（会产生费用）
• 🔵 Claude 分析已包含在 Claude Code 中

Tangle 工作流通常每项任务的费用为 0.02-0.10 USD，具体取决于复杂程度和代码长度。

开发后：检查点

开发完成后：

1. 通过 skill-verification-gate 对变更行为运行新的定向测试；如果测试失败，请停止。
2. 创建检查点：git tag octo-checkpoint-post-develop-$(date +%Y%m%d-%H%M%S)
3. 更新 .octo/STATE.md，记录完成情况，并添加一条包含已修改文件的历史记录。

# Enter this block only after fresh targeted tests pass.
checkpoint_tag="octo-checkpoint-post-develop-$(date +%Y%m%d-%H%M%S)"
git tag "$checkpoint_tag" -m "Post-develop checkpoint from embrace workflow"
echo "📌 Created checkpoint: $checkpoint_tag"

# Update state only after verification and checkpoint creation succeed.
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
  --status "complete" \
  --history "Develop phase completed"

# Record files modified in this phase
modified_files=$(git diff --name-only HEAD~1 2>/dev/null || echo "See git log")
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
  --history "Files modified: $modified_files"

终端状态

只有在实现已完成、已创建开发后检查点标签且定向测试已全新通过（参见 skill-verification-gate）后，Develop 阶段才算完成。 然后调用 flow-deliver 进行验证。不要在此处宣布工作已完成——完成声明应在审查后的 Deliver 阶段作出。

准备开始构建！ 此技能仅在用户明确调用并请求实现或构建功能后使用。