Token导航 LogoToken导航TokenDH.com
研究检索执行命令github未标认证来源可访问clear审计通过

ccw-loop-b逆时针循环 b

Agent Skill

ccw-loop-b 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

24

周安装

1

GitHub Stars

1,937

下载量

8
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:ccw-loop-b(逆时针循环 b)
来源仓库:https://github.com/catlog22/claude-code-workflow
仓库路径:skills/ccw-loop-b
安装命令:
npx skills add https://github.com/catlog22/claude-code-workflow --skill ccw-loop-b
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/catlog22/claude-code-workflow --skill ccw-loop-b

简介

ccw-loop-b 是混合协调器模式,结合主调度器与专用 worker agent 实现迭代开发,适合在 Codex、Claude、Cursor、Gemini CLI 中执行复杂任务流水线时使用。

  • 它支持交互式、自动与并行三种执行模式,每个 action 由独立 worker 完成,协调器负责状态汇聚。
  • 架构分为 Develop、Debug、Validate 三类 worker,适用于代码实现、问题诊断与测试验证全流程。
  • 使用前应明确任务边界与 worker 职责划分,避免资源竞争或状态冲突。
  • ccw-loop-b 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

CCW Loop-B - Hybrid Orchestrator Pattern

协调器 + 专用 worker 的迭代开发工作流。支持三种执行模式(Interactive / Auto / Parallel),每个 action 由独立 worker agent 执行,协调器负责调度、状态管理和结果汇聚。

Architecture Overview

+------------------------------------------------------------+
|                    Main Coordinator                         |
|  职责: 状态管理 + worker 调度 + 结果汇聚 + 用户交互        |
+------------------------------------------------------------+
          |                    |                    |
          v                    v                    v
+----------------+   +----------------+   +----------------+
| Worker-Develop |   | Worker-Debug   |   | Worker-Validate|
| 专注: 代码实现 |   | 专注: 问题诊断 |   | 专注: 测试验证 |
+----------------+   +----------------+   +----------------+
          |                    |                    |
          v                    v                    v
   .workers/              .workers/             .workers/
   develop.output.json    debug.output.json     validate.output.json

Subagent API

API作用注意事项
spawn_agent({message})创建 worker,返回 agent_id首条 message 加载角色
wait({ids, timeout_ms})等待结果唯一取结果入口,非 close
send_input({id, message})继续交互/追问interrupt=true 慎用
close_agent({id})关闭回收不可逆,确认不再交互后才关闭

Key Design Principles

  1. 协调器保持轻量: 只做调度和状态管理,具体工作交给 worker
  2. Worker 职责单一: 每个 worker 专注一个领域(develop/debug/validate)
  3. 角色路径传递: Worker 自己读取角色文件,主流程不传递内容
  4. 延迟 close_agent: 确认不再需要交互后才关闭 worker
  5. 两阶段工作流: 复杂任务先澄清后执行,减少返工
  6. 批量等待优化: 并行模式用 wait({ids: [...]}) 批量等待
  7. 结果标准化: Worker 输出遵循统一 WORKER_RESULT 格式
  8. 灵活模式切换: 根据任务复杂度选择 interactive/auto/parallel

Arguments

ArgRequiredDescription
TASKOne of TASK or --loop-idTask description (for new loop)
--loop-idOne of TASK or --loop-idExisting loop ID to continue
--modeNointeractive (default) / auto / parallel

Execution Modes

Mode: Interactive (default)

协调器展示菜单,用户选择 action,spawn 对应 worker 执行。

Coordinator -> Show menu -> User selects -> spawn worker -> wait -> Display result -> Loop

Mode: Auto

自动按预设顺序执行,worker 完成后协调器决定下一步。

Init -> Develop -> [if issues] Debug -> Validate -> [if fail] Loop back -> Complete

Mode: Parallel

并行 spawn 多个 worker,batch wait 汇聚结果,协调器综合决策。

Coordinator -> spawn [develop, debug, validate] in parallel -> wait({ ids: all }) -> Merge -> Decide

Execution Flow

Input Parsing:
   └─ Parse arguments (TASK | --loop-id + --mode)
   └─ Convert to structured context (loopId, state, mode)

Phase 1: Session Initialization
   └─ Ref: phases/01-session-init.md
      ├─ Create new loop OR resume existing loop
      ├─ Initialize state file and directory structure
      └─ Output: loopId, state, progressDir, mode

Phase 2: Orchestration Loop
   └─ Ref: phases/02-orchestration-loop.md
      ├─ Mode dispatch: interactive / auto / parallel
      ├─ Worker spawn with structured prompt (Goal/Scope/Context/Deliverables)
      ├─ Wait + timeout handling + result parsing
      ├─ State update per iteration
      └─ close_agent on loop exit

Phase Reference Documents (read on-demand when phase executes):

PhaseDocumentPurpose
1phases/01-session-init.mdArgument parsing, state creation/resume, directory init
2phases/02-orchestration-loop.md3-mode orchestration, worker spawn, batch wait, result merge

Data Flow

User Input (TASK | --loop-id + --mode)
    ↓
[Parse Arguments]
    ↓ loopId, state, mode

Phase 1: Session Initialization
    ↓ loopId, state (initialized/resumed), progressDir

Phase 2: Orchestration Loop
    ↓
    ┌─── Interactive Mode ──────────────────────────────────┐
    │ showMenu → user selects → spawn worker → wait →       │
    │ parseResult → updateState → close worker → loop       │
    └───────────────────────────────────────────────────────┘
    ┌─── Auto Mode ─────────────────────────────────────────┐
    │ selectNext → spawn worker → wait → parseResult →      │
    │ updateState → close worker → [loop_back?] → next      │
    └───────────────────────────────────────────────────────┘
    ┌─── Parallel Mode ─────────────────────────────────────┐
    │ spawn [develop, debug, validate] → batch wait →       │
    │ mergeOutputs → coordinator decides → close all        │
    └───────────────────────────────────────────────────────┘
    ↓
return finalState

Session Structure

{projectRoot}/.workflow/.loop/
├── {loopId}.json                    # Master state (API + Skill shared)
├── {loopId}.workers/                # Worker structured outputs
│   ├── init.output.json
│   ├── develop.output.json
│   ├── debug.output.json
│   ├── validate.output.json
│   └── complete.output.json
└── {loopId}.progress/               # Human-readable progress
    ├── develop.md
    ├── debug.md
    ├── validate.md
    └── summary.md

State Management

Master state file: {projectRoot}/.workflow/.loop/{loopId}.json

{
  "loop_id": "loop-b-20260122-abc123",
  "title": "Task title",
  "description": "Full task description",
  "mode": "interactive | auto | parallel",
  "status": "running | paused | completed | failed",
  "current_iteration": 0,
  "max_iterations": 10,
  "created_at": "ISO8601",
  "updated_at": "ISO8601",

  "skill_state": {
    "phase": "init | develop | debug | validate | complete",
    "action_index": 0,
    "workers_completed": [],
    "parallel_results": null,
    "pending_tasks": [],
    "completed_tasks": [],
    "findings": []
  }
}

Control Signal Checking: 协调器在每次 spawn worker 前检查 state.status:

  • running → continue
  • paused → exit gracefully, wait for resume
  • failed → terminate

Recovery: If state corrupted, rebuild from .progress/ markdown files and .workers/*.output.json.

Worker Catalog

WorkerRole FilePurposeOutput Files
initccw-loop-b-init.md会话初始化、任务解析init.output.json
developccw-loop-b-develop.md代码实现、重构develop.output.json, develop.md
debugccw-loop-b-debug.md问题诊断、假设验证debug.output.json, debug.md
validateccw-loop-b-validate.md测试执行、覆盖率validate.output.json, validate.md
completeccw-loop-b-complete.md总结收尾complete.output.json, summary.md

Worker Dependencies

WorkerDepends OnLeads To
init-develop (auto) / menu (interactive)
developinitvalidate / debug
debuginitdevelop / validate
validatedevelop or debugcomplete / develop (if fail)
complete-Terminal

Worker Sequences

Simple Task (Auto):     init → develop → validate → complete
Complex Task (Auto):    init → develop → validate (fail) → debug → develop → validate → complete
Bug Fix (Auto):         init → debug → develop → validate → complete
Analysis (Parallel):    init → [develop ‖ debug ‖ validate] → complete
Interactive:            init → menu → user selects → worker → menu → ...

Worker Prompt Protocol

Spawn Message Structure (§7.1)

function buildWorkerPrompt(action, loopId, state) {
  return `
## TASK ASSIGNMENT

### MANDATORY FIRST STEPS (Agent Execute)
1. **Read role definition**: ~/.codex/agents/ccw-loop-b-${action}.md (MUST read first)
2. Read: ${projectRoot}/.workflow/project-tech.json
3. Read: ${projectRoot}/.workflow/project-guidelines.json

---

Goal: ${goalForAction(action, state)}

Scope:
- 可做: ${allowedScope(action)}
- 不可做: ${forbiddenScope(action)}
- 目录限制: ${directoryScope(action, state)}

Context:
- Loop ID: ${loopId}
- State: ${projectRoot}/.workflow/.loop/${loopId}.json
- Output: ${projectRoot}/.workflow/.loop/${loopId}.workers/${action}.output.json
- Progress: ${projectRoot}/.workflow/.loop/${loopId}.progress/${action}.md

Deliverables:
- 按 WORKER_RESULT 格式输出
- 写入 output.json 和 progress.md

Quality bar:
- ${qualityCriteria(action)}
`
}

关键: 角色文件由 worker 自己读取,主流程只传递路径。不嵌入角色内容。

Worker Output Format (WORKER_RESULT)

WORKER_RESULT:
- action: {action_name}
- status: success | failed | needs_input
- summary: <brief summary>
- files_changed: [list]
- next_suggestion: <suggested next action>
- loop_back_to: <action name if needs loop back, or null>

DETAILED_OUTPUT:
<action-specific structured output>

Two-Phase Clarification (§5.2)

Worker 遇到模糊需求时采用两阶段模式:

阶段 1: Worker 输出 CLARIFICATION_NEEDED + Open questions
阶段 2: 协调器收集用户回答 → send_input → Worker 继续执行
// 解析 worker 是否需要澄清
if (output.includes('CLARIFICATION_NEEDED')) {
  const userAnswers = await collectUserAnswers(output)
  send_input({
    id: workerId,
    message: `## CLARIFICATION ANSWERS\n${userAnswers}\n\n## CONTINUE EXECUTION`
  })
  const finalResult = wait({ ids: [workerId], timeout_ms: 600000 })
}

Parallel Split Strategy (§6)

Strategy 1: 按职责域拆分(推荐)

Worker职责交付物禁止事项
develop定位入口、调用链、实现方案变更点清单不做测试
debug问题诊断、风险评估问题清单+修复建议不写代码
validate测试策略、覆盖分析测试结果+质量报告不改实现

Strategy 2: 按模块域拆分

Worker 1: src/auth/**     → 认证模块变更
Worker 2: src/api/**      → API 层变更
Worker 3: src/database/** → 数据层变更

拆分原则

  1. 文件隔离: 避免多个 worker 同时修改同一文件
  2. 职责单一: 每个 worker 只做一件事
  3. 边界清晰: 超出范围用 CLARIFICATION_NEEDED 请求确认
  4. 最小上下文: 只传递完成任务所需的最小信息

Result Merge (Parallel Mode)

function mergeWorkerOutputs(outputs) {
  return {
    develop: parseWorkerResult(outputs.develop),
    debug: parseWorkerResult(outputs.debug),
    validate: parseWorkerResult(outputs.validate),
    conflicts: detectConflicts(outputs),  // 检查 worker 间建议冲突
    merged_at: getUtc8ISOString()
  }
}

冲突检测: 当多个 worker 建议修改同一文件时,协调器标记冲突,由用户决定。

TodoWrite Pattern

Phase-Level Tracking (Attached)

[
  {"content": "Phase 1: Session Initialization", "status": "completed"},
  {"content": "Phase 2: Orchestration Loop (auto mode)", "status": "in_progress"},
  {"content": "  → Worker: init", "status": "completed"},
  {"content": "  → Worker: develop (task 2/5)", "status": "in_progress"},
  {"content": "  → Worker: validate", "status": "pending"},
  {"content": "  → Worker: complete", "status": "pending"}
]

Parallel Mode Tracking

[
  {"content": "Phase 1: Session Initialization", "status": "completed"},
  {"content": "Phase 2: Parallel Analysis", "status": "in_progress"},
  {"content": "  → Worker: develop (parallel)", "status": "in_progress"},
  {"content": "  → Worker: debug (parallel)", "status": "in_progress"},
  {"content": "  → Worker: validate (parallel)", "status": "in_progress"},
  {"content": "  → Merge results", "status": "pending"}
]

Core Rules

  1. Start Immediately: First action is TodoWrite initialization, then Phase 1 execution
  2. Progressive Phase Loading: Read phase docs ONLY when that phase is about to execute
  3. Parse Every Output: Extract WORKER_RESULT from worker output for next decision
  4. Worker 生命周期: spawn → wait → [send_input if needed] → close,不长期保留 worker
  5. 结果持久化: Worker 输出写入 {projectRoot}/.workflow/.loop/{loopId}.workers/
  6. 状态同步: 每次 worker 完成后更新 master state
  7. 超时处理: send_input 请求收敛,再超时则使用已有结果继续
  8. DO NOT STOP: Continuous execution until completed, paused, or max iterations

Error Handling

Error TypeRecovery
Worker timeoutsend_input 请求收敛 → 再超时则跳过
Worker failedLog error, 协调器决策是否重试
Batch wait partial timeout使用已完成结果继续
State corrupted从 progress 文件和 worker output 重建
Conflicting worker results标记冲突,由用户决定
Max iterations reached生成总结,记录未完成项

Coordinator Checklist

Before Each Phase

  • Read phase reference document
  • Check current state and control signals
  • Update TodoWrite with phase tasks

After Each Worker

  • Parse WORKER_RESULT from output
  • Persist output to .workers/{action}.output.json
  • Update master state file
  • close_agent (确认不再需要交互)
  • Determine next action (continue / loop back / complete)

Reference Documents

DocumentPurpose
workers/Worker 定义 (init, develop, debug, validate, complete)

Usage

# Interactive mode (default)
/ccw-loop-b TASK="Implement user authentication"

# Auto mode
/ccw-loop-b --mode=auto TASK="Fix login bug"

# Parallel analysis mode
/ccw-loop-b --mode=parallel TASK="Analyze and improve payment module"

# Resume existing loop
/ccw-loop-b --loop-id=loop-b-20260122-abc123

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

25.39%
按下载量换算2

windsurf

23.36%
按下载量换算2

OpenCode

17.97%
按下载量换算1

Cursor

12.1%
按下载量换算1

Codex

6.6%
按下载量换算1

Antigravity

3.01%
按下载量换算0

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

执行命令

安装流程涉及命令执行,可能通过 npx skills add https://github.com/catlog22/claude-code-workflow --skill ccw-loop-b;npx skills add catlog22/claude-code-workflow --skill "ccw-loop-b" 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

来源信息

继续浏览同类 Skills