aaione
aaione/everything-claude-code-zh
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/aaione/everything-claude-code-zh --skill autonomous-loops命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Kubernetes 工作负载模式、资源管理、RBAC、probes、autoscaling、ConfigMap/Secret 处理，以及面向生产级部署的 kubectl 调试。
完成任何非平凡任务后使用。智能体按 5 个维度自评输出——准确性、完整性、清晰度、可执行性、简洁性——每项都给出具体证据。生成结构化 1-5 评分卡和具体改进建议。
在 competitive-platform-analysis 产出分层竞品集合后使用。按九个加权维度（定位、声音、视觉工艺、offer packaging、证据、enterprise-readiness、thought leadership、定价、客户 strategic tension）为每个竞品评分，使用明确 1–5 rubrics 和 tension-plot。位于 competitive-report-structure 之前。
基于 SOC 职业分类
正在显示 SKILL.md
| name | autonomous-loops |
| description | 自主 Claude Code 循环的模式和架构 —— 从简单的顺序管道到 RFC 驱动的多代理 DAG 系统。 |
| origin | ECC |
兼容性说明 (v1.8.0)：
autonomous-loops保留一个版本。 规范的技能名称现在是continuous-agent-loop。新的循环指导 应该在那里编写，而此技能仍然可用以避免 破坏现有工作流。
用于自主运行 Claude Code 的模式、架构和参考实现。涵盖从简单的 claude -p 管道到完整的 RFC 驱动多代理 DAG 编排的所有内容。
从最简单到最复杂：
| 模式 | 复杂度 | 最适合 |
|---|---|---|
| 顺序管道 | 低 | 日常开发步骤、脚本化工作流 |
| NanoClaw REPL | 低 | 交互式持久会话 |
| 无限代理循环 | 中 | 并行内容生成、规范驱动工作 |
| 连续 Claude PR 循环 | 中 | 具有 CI 门控的多天迭代项目 |
| 去反 slop 模式 | 附加 | 任何实现者步骤后的质量清理 |
| Ralphinho / RFC 驱动 DAG | 高 | 大型功能、具有合并队列的多单元并行工作 |
claude -p）最简单的循环。 将日常开发分解为一系列非交互式 claude -p 调用。每个调用都是具有明确提示的聚焦步骤。
如果你不能弄清楚这样的循环，这意味着你甚至无法驱动 LLM 在交互模式下修复你的代码。
claude -p 标志以提示非交互式运行 Claude Code，完成后退出。链式调用以构建管道：
#!/bin/bash
# daily-dev.sh — 功能分支的顺序管道
set -e
# 步骤 1：实现功能
claude -p "阅读 docs/auth-spec.md 中的规范。在 src/auth/ 中实现 OAuth2 登录。首先编写测试（TDD）。不要创建任何新的文档文件。"
# 步骤 2：去反 slop（清理传递）
claude -p "审查上次提交更改的所有文件。删除任何不必要的类型测试、过度防御性检查或语言功能测试（例如，测试 TypeScript 泛型是否工作）。保留真正的业务逻辑测试。清理后运行测试套件。"
# 步骤 3：验证
claude -p "运行完整构建、lint、类型检查和测试套件。修复任何故障。不要添加新功能。"
# 步骤 4：提交
claude -p "为所有暂存更改创建约定式提交。使用 'feat: add OAuth2 login flow' 作为消息。"
claude -p 调用都有新的上下文窗口，意味着步骤之间没有上下文泄漏。set -e 在失败时停止管道。ECC 的内置持久循环。 一个会话感知的 REPL，以完整对话历史同步调用 claude -p。
# 启动默认会话
node scripts/claw.js
# 带技能上下文的命名会话
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js
~/.claude/claw/{session}.md 加载对话历史claude -p双提示系统，编排用于规范驱动生成的并行子代理。由 disler 开发（致谢：@disler）。
提示 1（编排器） 提示 2（子代理）
┌─────────────────────┐ ┌──────────────────────┐
│ 解析规范文件 │ │ 接收完整上下文 │
│ 扫描输出目录 │ deploys │ 阅读分配的编号 │
│ 规划迭代 │────────────│ 严格遵循规范 │
│ 分配创意方向 │ N agents │ 生成唯一输出 │
│ 管理波次 │ │ 保存到输出目录 │
└─────────────────────┘ └──────────────────────┘
生产级 shell 脚本，在连续循环中运行 Claude Code，创建 PR、等待 CI 并自动合并。由 AnandChowdhary 创建（致谢：@AnandChowdhary）。
┌─────────────────────────────────────────────────────┐
│ 连续 CLAUDE 迭代 │
│ │
│ 1. 创建分支 (continuous-claude/iteration-N) │
│ 2. 使用增强提示运行 claude -p │
│ 3.（可选）审查者传递 — 单独的 claude -p │
│ 4. 提交更改（claude 生成消息） │
│ 5. 推送 + 创建 PR (gh pr create) │
│ 6. 等待 CI 检查（poll gh pr checks） │
│ 7. CI 故障？→ 自动修复传递 (claude -p) │
│ 8. 合并 PR（squash/merge/rebase） │
│ 9. 返回主分支 → 重复 │
│ │
│ 限制：--max-runs N | --max-cost $X │
│ --max-duration 2h | 完成信号 │
└─────────────────────────────────────────────────────┘
任何循环的附加模式。 在每个实现者步骤之后添加专用的清理/重构步骤。
当您要求 LLM 使用 TDD 实现时，它会过于字面地理解"编写测试"：
typeof x === 'string'）不要限制实现者，让它彻底。然后添加一个专注的清理代理：
# 步骤 1：实现（让它彻底）
claude -p "使用完整 TDD 实现功能。彻底测试。"
# 步骤 2：去反 slop（单独上下文、专注清理）
claude -p "审查工作树中的所有更改。删除：
- 验证语言/框架行为而不是业务逻辑的测试
- 类型系统已经强制执行的冗余类型检查
- 针对不可能状态的过度防御性错误处理
- Console.log 语句
- 注释掉的代码
保留所有业务逻辑测试。清理后运行测试套件以确保没有任何损坏。"
最复杂的模式。 RFC 驱动的多代理管道，将规范分解为依赖 DAG，通过分层质量管道运行每个单元，并通过代理驱动的合并队列进行落地。由 enitrat 创建（致谢：@enitrat）。
RFC/PRD 文档
│
▼
分解（AI）
将 RFC 分解为具有依赖 DAG 的工作单元
│
▼
┌──────────────────────────────────────────────────────┐
│ RALPH 循环（最多 3 遍） │
│ │
│ 对于每个 DAG 层（按依赖顺序）： │
│ │
│ ┌── 质量管道（每个单元并行）──────────────────────┐ │
│ │ 每个单元在自己的工作树中： │ │
│ │ 研究 → 计划 → 实现 → 测试 → 审查 │ │
│ │ （深度因复杂性层而异） │ │
│ └──────────────────────────────────────────────────┘ │
│ │
│ ┌── 合并队列─────────────────────────────────────┐ │
│ │ 变基到主分支 → 运行测试 → 落地或驱逐 │ │
│ │ 驱逐的单元带着冲突上下文重新进入 │ │
│ └──────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────┘
不同层级获得不同的管道深度：
| 层级 | 管道阶段 |
|---|---|
| trivial | implement → test |
| small | implement → test → code-review |
| medium | research → plan → implement → test → PRD-review + code-review → review-fix |
| large | research → plan → implement → test → PRD-review + code-review → review-fix → final-review |
任务是单个专注的更改吗？
├─ 是 → 顺序管道或 NanoClaw
└─ 否 → 是否有书面规范/RFC？
├─ 是 → 需要并行实现吗？
│ ├─ 是 → Ralphinho（DAG 编排）
│ └─ 否 → Continuous Claude（迭代 PR 循环）
└─ 否 → 需要同一事物的许多变体吗？
├─ 是 → 无限代理循环（规范驱动生成）
└─ 否 → 带去反 slop 的顺序管道
兼容性说明 (v1.8.0)：
autonomous-loops保留一个版本。 规范的技能名称现在是continuous-agent-loop。新的循环指导 应该在那里编写，而此技能仍然可用以避免 破坏现有工作流。
用于自主运行 Claude Code 的模式、架构和参考实现。涵盖从简单的 claude -p 管道到完整的 RFC 驱动多代理 DAG 编排的所有内容。
从最简单到最复杂：
| 模式 | 复杂度 | 最适合 |
|---|---|---|
| 顺序管道 | 低 | 日常开发步骤、脚本化工作流 |
| NanoClaw REPL | 低 | 交互式持久会话 |
| 无限代理循环 | 中 | 并行内容生成、规范驱动工作 |
| 连续 Claude PR 循环 | 中 | 具有 CI 门控的多天迭代项目 |
| 去反 slop 模式 | 附加 | 任何实现者步骤后的质量清理 |
| Ralphinho / RFC 驱动 DAG | 高 | 大型功能、具有合并队列的多单元并行工作 |
claude -p）最简单的循环。 将日常开发分解为一系列非交互式 claude -p 调用。每个调用都是具有明确提示的聚焦步骤。
如果你不能弄清楚这样的循环，这意味着你甚至无法驱动 LLM 在交互模式下修复你的代码。
claude -p 标志以提示非交互式运行 Claude Code，完成后退出。链式调用以构建管道：
#!/bin/bash
# daily-dev.sh — 功能分支的顺序管道
set -e
# 步骤 1：实现功能
claude -p "阅读 docs/auth-spec.md 中的规范。在 src/auth/ 中实现 OAuth2 登录。首先编写测试（TDD）。不要创建任何新的文档文件。"
# 步骤 2：去反 slop（清理传递）
claude -p "审查上次提交更改的所有文件。删除任何不必要的类型测试、过度防御性检查或语言功能测试（例如，测试 TypeScript 泛型是否工作）。保留真正的业务逻辑测试。清理后运行测试套件。"
# 步骤 3：验证
claude -p "运行完整构建、lint、类型检查和测试套件。修复任何故障。不要添加新功能。"
# 步骤 4：提交
claude -p "为所有暂存更改创建约定式提交。使用 'feat: add OAuth2 login flow' 作为消息。"
claude -p 调用都有新的上下文窗口，意味着步骤之间没有上下文泄漏。set -e 在失败时停止管道。ECC 的内置持久循环。 一个会话感知的 REPL，以完整对话历史同步调用 claude -p。
# 启动默认会话
node scripts/claw.js
# 带技能上下文的命名会话
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js
~/.claude/claw/{session}.md 加载对话历史claude -p双提示系统，编排用于规范驱动生成的并行子代理。由 disler 开发（致谢：@disler）。
提示 1（编排器） 提示 2（子代理）
┌─────────────────────┐ ┌──────────────────────┐
│ 解析规范文件 │ │ 接收完整上下文 │
│ 扫描输出目录 │ deploys │ 阅读分配的编号 │
│ 规划迭代 │────────────│ 严格遵循规范 │
│ 分配创意方向 │ N agents │ 生成唯一输出 │
│ 管理波次 │ │ 保存到输出目录 │
└─────────────────────┘ └──────────────────────┘
生产级 shell 脚本，在连续循环中运行 Claude Code，创建 PR、等待 CI 并自动合并。由 AnandChowdhary 创建（致谢：@AnandChowdhary）。
┌─────────────────────────────────────────────────────┐
│ 连续 CLAUDE 迭代 │
│ │
│ 1. 创建分支 (continuous-claude/iteration-N) │
│ 2. 使用增强提示运行 claude -p │
│ 3.（可选）审查者传递 — 单独的 claude -p │
│ 4. 提交更改（claude 生成消息） │
│ 5. 推送 + 创建 PR (gh pr create) │
│ 6. 等待 CI 检查（poll gh pr checks） │
│ 7. CI 故障？→ 自动修复传递 (claude -p) │
│ 8. 合并 PR（squash/merge/rebase） │
│ 9. 返回主分支 → 重复 │
│ │
│ 限制：--max-runs N | --max-cost $X │
│ --max-duration 2h | 完成信号 │
└─────────────────────────────────────────────────────┘
任何循环的附加模式。 在每个实现者步骤之后添加专用的清理/重构步骤。
当您要求 LLM 使用 TDD 实现时，它会过于字面地理解"编写测试"：
typeof x === 'string'）不要限制实现者，让它彻底。然后添加一个专注的清理代理：
# 步骤 1：实现（让它彻底）
claude -p "使用完整 TDD 实现功能。彻底测试。"
# 步骤 2：去反 slop（单独上下文、专注清理）
claude -p "审查工作树中的所有更改。删除：
- 验证语言/框架行为而不是业务逻辑的测试
- 类型系统已经强制执行的冗余类型检查
- 针对不可能状态的过度防御性错误处理
- Console.log 语句
- 注释掉的代码
保留所有业务逻辑测试。清理后运行测试套件以确保没有任何损坏。"
最复杂的模式。 RFC 驱动的多代理管道，将规范分解为依赖 DAG，通过分层质量管道运行每个单元，并通过代理驱动的合并队列进行落地。由 enitrat 创建（致谢：@enitrat）。
RFC/PRD 文档
│
▼
分解（AI）
将 RFC 分解为具有依赖 DAG 的工作单元
│
▼
┌──────────────────────────────────────────────────────┐
│ RALPH 循环（最多 3 遍） │
│ │
│ 对于每个 DAG 层（按依赖顺序）： │
│ │
│ ┌── 质量管道（每个单元并行）──────────────────────┐ │
│ │ 每个单元在自己的工作树中： │ │
│ │ 研究 → 计划 → 实现 → 测试 → 审查 │ │
│ │ （深度因复杂性层而异） │ │
│ └──────────────────────────────────────────────────┘ │
│ │
│ ┌── 合并队列─────────────────────────────────────┐ │
│ │ 变基到主分支 → 运行测试 → 落地或驱逐 │ │
│ │ 驱逐的单元带着冲突上下文重新进入 │ │
│ └──────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────┘
不同层级获得不同的管道深度：
| 层级 | 管道阶段 |
|---|---|
| trivial | implement → test |
| small | implement → test → code-review |
| medium | research → plan → implement → test → PRD-review + code-review → review-fix |
| large | research → plan → implement → test → PRD-review + code-review → review-fix → final-review |
这可以在简单更改上避免昂贵操作，同时确保架构更改获得彻底审查。
每个阶段在自己的代理进程中以自己的上下文窗口运行：
| 阶段 | 模型 | 目的 |
|---|---|---|
| Research | Sonnet | 阅读代码库 + RFC，生成上下文文档 |
| Plan | Opus | 设计实现步骤 |
| Implement | Codex | 按照计划编写代码 |
| Test | Sonnet | 运行构建 + 测试套件 |
| PRD Review | Sonnet | 规范合规性检查 |
| Code Review | Opus | 质量 + 安全检查 |
| Review Fix | Codex | 解决审查问题 |
| Final Review | Opus | 质量门（仅大层级） |
关键设计： 审查者从未编写其审查的代码。这消除了作者偏见 —— 自我审查中最常见的漏检来源。
质量管道完成后，单元进入合并队列：
单元分支
│
├─ 变基到主分支
│ └─ 冲突？→ 驱逐（捕获冲突上下文）
│
├─ 运行构建 + 测试
│ └─ 失败？→ 驱逐（捕获测试输出）
│
└─ 通过 → 快进主分支，推送，删除分支