القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام 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 | 质量门（仅大层级） |
关键设计： 审查者从未编写其审查的代码。这消除了作者偏见 —— 自我审查中最常见的漏检来源。
质量管道完成后，单元进入合并队列：
单元分支
│
├─ 变基到主分支
│ └─ 冲突？→ 驱逐（捕获冲突上下文）
│
├─ 运行构建 + 测试
│ └─ 失败？→ 驱逐（捕获测试输出）
│
└─ 通过 → 快进主分支，推送，删除分支