autonomous-fixes

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Dynamic Context

动态上下文

Args: $ARGUMENTS
Branch: !
```
git branch --show-current
```

Config: !

test -f .claude/autonomous-tests.json && echo "YES" || echo "NO — requires autonomous-tests config"

Pending fixes: !

find docs/_autonomous/pending-fixes -name '*.md' 2>/dev/null | wc -l | tr -d ' '

Fix results: !

find docs/_autonomous/fix-results -name '*.md' 2>/dev/null | wc -l | tr -d ' '

Test results: !

find docs/_autonomous/test-results -name '*.md' 2>/dev/null | wc -l | tr -d ' '

Agent Teams: !

python3 -c "import json;s=json.load(open('$HOME/.claude/settings.json'));print('ENABLED' if s.get('env',{}).get('CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS')=='1' else 'DISABLED')" 2>/dev/null || echo "DISABLED — settings not found"

参数：$ARGUMENTS
分支：!
```
git branch --show-current
```

配置：!

test -f .claude/autonomous-tests.json && echo "YES" || echo "NO — requires autonomous-tests config"

待修复项：!

find docs/_autonomous/pending-fixes -name '*.md' 2>/dev/null | wc -l | tr -d ' '

修复结果：!

find docs/_autonomous/fix-results -name '*.md' 2>/dev/null | wc -l | tr -d ' '

测试结果：!

find docs/_autonomous/test-results -name '*.md' 2>/dev/null | wc -l | tr -d ' '

Agent团队：!

python3 -c "import json;s=json.load(open('$HOME/.claude/settings.json'));print('ENABLED' if s.get('env',{}).get('CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS')=='1' else 'DISABLED')" 2>/dev/null || echo "DISABLED — settings not found"

Role

角色

Project-agnostic autonomous fix runner. Reads findings from

autonomous-tests

output, lets the user select items to fix, plans and executes fixes via Agent Teams, verifies results, and updates documentation to enable re-testing — creating a bidirectional test-fix loop.

不绑定具体项目的自动修复执行器。读取

autonomous-tests

输出的检测结果，让用户选择要修复的条目，通过Agent团队规划并执行修复，验证结果，更新文档以支持重测，形成双向测试-修复循环。

Arguments: $ARGUMENTS

参数：$ARGUMENTS

Arg	Meaning
(empty)	Default: interactive selection via AskUserQuestion
`all`	Select all fixable items (V, F, T prefixes)
`critical`	Pre-select items with Severity = Critical
`high`	Pre-select items with Severity = Critical or High
`vulnerability`	Pre-select all security/vulnerability items (V-prefix)
`file:<path>`	Target a specific pending-fixes or test-results file

Print resolved scope, then proceed without waiting.

参数	含义
(空)	默认：通过AskUserQuestion进行交互选择
`all`	选择所有可修复项（V、F、T前缀的条目）
`critical`	预选择严重级别为Critical的条目
`high`	预选择严重级别为Critical或High的条目
`vulnerability`	预选择所有安全/漏洞类条目（V前缀）
`file:<路径>`	指向特定的待修复文件或测试结果文件

输出确定的修复范围后，直接继续执行无需等待。

Phase 0 — Configuration

阶段0 - 配置

Step 0: Prerequisites Check

Read

~/.claude/settings.json

and check two things:

Agent teams feature flag: verify
```
env.CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS
```
is
```
"1"
```
. If missing or not
```
"1"
```
, STOP and tell the user:
Agent teams are required for this skill but not enabled. Run:
```
bash <skill-dir>/scripts/setup-hook.sh
```
This enables the
```
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS
```
flag and the required hooks in your settings. Do not proceed until the flag is confirmed enabled.
Hooks (informational): if the
```
PreToolUse
```
→
```
ExitPlanMode
```
or
```
AskUserQuestion
```
hooks are not present in global settings, inform the user:
This skill includes ExitPlanMode and AskUserQuestion as skill-scoped hooks, so they work automatically during
```
/autonomous-fixes
```
runs. To also enable them globally, run the setup script above. Then continue — do not block on this.

Step 1: Config Validation

This skill reuses

.claude/autonomous-tests.json

— no separate config file.

Run

test -f .claude/autonomous-tests.json && echo "CONFIG_EXISTS" || echo "CONFIG_MISSING"

in Bash.

If
```
CONFIG_MISSING
```
, STOP: "No autonomous-tests config found. Run
```
/autonomous-tests
```
first to set up your project and generate test findings."
Read the config. Validate
```
version
```
equals
```
4
```
.
Verify config trust: compute SHA-256 hash (same method as autonomous-tests) and check against
```
~/.claude/trusted-configs/
```
. If untrusted, show config for confirmation (redact
```
testCredentials
```
values).

Ensure
documentation.fixResults
: if missing, add

"fixResults": "docs/_autonomous/fix-results"

to the config and save.

Step 2: Findings Scan

Scan the configured

_autonomous/

directories:

```
documentation.pendingFixes
```
→ pending-fixes documents
```
documentation.testResults
```
→ test-results documents
```
documentation.fixResults
```
→ prior fix-results (for context)

If no pending-fixes and no test-results with

### Requires Fix

### Vulnerabilities

entries exist, STOP: "No findings to fix. Run

/autonomous-tests

first to generate test results."

步骤0：前置条件检查

读取

~/.claude/settings.json

并检查两项内容：

Agent团队功能开关：验证
```
env.CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS
```
为
```
"1"
```
。如果不存在或不为
```
"1"
```
，停止执行并告知用户：
本技能需要Agent teams功能，但该功能未启用。请执行：
```
bash <skill-dir>/scripts/setup-hook.sh
```
该命令会启用
```
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS
```
开关以及配置中所需的钩子。在确认开关启用前不要继续执行。
钩子（仅告知）：如果全局配置中不存在
```
PreToolUse
```
→
```
ExitPlanMode
```
或
```
AskUserQuestion
```
钩子，告知用户：
本技能包含技能作用域的ExitPlanMode和AskUserQuestion钩子，因此在
```
/autonomous-fixes
```
运行期间会自动生效。如果需要全局启用这两个钩子，请执行上述安装脚本。然后继续执行，不要因为该问题阻塞流程。

步骤1：配置校验

本技能复用

.claude/autonomous-tests.json

，无需单独的配置文件。

在Bash中执行

test -f .claude/autonomous-tests.json && echo "CONFIG_EXISTS" || echo "CONFIG_MISSING"

。

如果返回
```
CONFIG_MISSING
```
，停止执行："未找到autonomous-tests配置。请先运行
```
/autonomous-tests
```
完成项目配置并生成测试结果。"
读取配置，验证
```
version
```
等于
```
4
```
。
验证配置信任状态：计算SHA-256哈希（与autonomous-tests使用相同方法），并与
```
~/.claude/trusted-configs/
```
中的记录比对。如果未受信任，展示配置供用户确认（脱敏
```
testCredentials
```
字段值）。

确保存在
documentation.fixResults
配置：如果缺失，在配置中添加

"fixResults": "docs/_autonomous/fix-results"

并保存。

步骤2：检测结果扫描

扫描配置的

_autonomous/

```
documentation.pendingFixes
```
→ 待修复文档
```
documentation.testResults
```
→ 测试结果文档
```
documentation.fixResults
```
→ 历史修复结果（用作上下文参考）

如果没有待修复项，也没有包含

### Requires Fix

或

### Vulnerabilities

章节的测试结果，停止执行："没有可修复的检测结果。请先运行

/autonomous-tests

生成测试结果。"

Phase 1 — Finding Presentation (User Selection Gate)

阶段1 - 检测结果展示（用户选择关卡）

Parse all

_autonomous/

documents following the rules in

references/finding-parser.md

. Build a structured summary with four categories:

Vulnerabilities (V-prefix): Items with Category =
```
Security Gap
```
,
```
Data Leak
```
,
```
Privacy Violation
```
, or from
```
### Vulnerabilities
```
/
```
### API Response Security
```
subsections. Each shows:
- OWASP category
- Severity
- Regulatory impact (LGPD/GDPR/CCPA/HIPAA)
- Exploitability assessment
- Compliance risk level
Bugs (F-prefix): From pending-fixes, non-security categories.
Failed Tests (T-prefix): From test-results
```
### Requires Fix
```
.
Informational: Guided tests (G), autonomous tests (A) — counts only, not selectable.

Argument-based pre-selection:

```
all
```
→ select all V, F, T items
```
critical
```
→ select items with Severity = Critical
```
high
```
→ select items with Severity = Critical or High
```
vulnerability
```
→ select all V-prefix items
```
file:<path>
```
→ select items from the specified file only

If no argument pre-selects items (empty args or default), present findings via

AskUserQuestion

(forced by hook — works even in dontAsk/bypass mode). Let the user choose which items to fix.

CRITICAL: Do NOT read any source code during this phase. No file reads, no grepping, no code exploration. Only parse

_autonomous/

documents. Source code reading happens in Phase 2 after the user has selected items.

遵循

references/finding-parser.md

中的规则解析所有

_autonomous/

文档，构建包含四类条目的结构化摘要：

漏洞（V前缀）：类别为
```
Security Gap
```
、
```
Data Leak
```
、
```
Privacy Violation
```
的条目，或者来自
```
### Vulnerabilities
```
/
```
### API Response Security
```
子章节的条目。每个条目展示：
- OWASP类别
- 严重级别
- 监管影响（LGPD/GDPR/CCPA/HIPAA）
- 可利用性评估
- 合规风险等级
Bug（F前缀）：来自待修复项的非安全类条目。
测试失败（T前缀）：来自测试结果中
```
### Requires Fix
```
章节的条目。
信息类：引导测试（G）、自动测试（A）——仅统计数量，不可选择。

基于参数的预选择：

```
all
```
→ 选择所有V、F、T类条目
```
critical
```
→ 选择严重级别为Critical的条目
```
high
```
→ 选择严重级别为Critical或High的条目
```
vulnerability
```
→ 选择所有V前缀的条目
```
file:<路径>
```
→ 仅选择指定文件中的条目

如果没有参数预选择条目（空参数或默认情况），通过

AskUserQuestion

展示检测结果（由钩子强制触发，即使在dontAsk/bypass模式下也会生效），让用户选择要修复的条目。

重要提示：本阶段不要读取任何源代码，不要读取文件、不要执行grep、不要探索代码，仅解析

_autonomous/

目录下的文档。源代码读取将在用户选择条目后的阶段2执行。

Phase 2 — Plan Mode

阶段2 - 计划模式

Enter plan mode (Use /plan). The plan MUST start with a "Context Reload" section as Step 0 containing:

Instruction to re-read this skill file (the SKILL.md that launched this session)
Instruction to read the config:
```
.claude/autonomous-tests.json
```
Instruction to read the templates: the
```
references/templates.md
```
file from this skill
The resolved scope arguments:
```
$ARGUMENTS
```
The current branch name
The selected items (IDs, titles, sources)
Key context from the finding documents

This ensures that when context is cleared after plan approval, the executing agent can fully reconstruct the session state.

For each selected item, read the relevant source code and build a Fix Context Document:

Read the files referenced in the finding (endpoint files, model files, test files)
Trace the code path: input → processing → output
Identify the root cause (not just the symptom)
Design the fix

Vulnerability items (V-prefix) get enhanced context:

Trace full input → processing → output path for the affected endpoint/handler
Identify ALL user-controlled inputs reaching the vulnerable code
Check for related vulnerability patterns in same file/module (e.g., if SQL injection found, check all query construction in the file)
Assess regulatory exposure (which data protection laws apply to the exposed data)
Security-aware remediation design: fixes must address root causes, not mask symptoms — enforce proper serialization/DTO filtering, add validation/sanitization layers, introduce rate limiting or protective guards where needed

Dependency analysis: Determine which items can be fixed independently vs. which form dependent chains:

Independent: Items that affect different files, modules, DB collections, or endpoints with no overlap
Dependent: Items that share files, modify the same function, or where one fix might affect another

Execution strategy:

Independent groups → parallel (one agent per group via Agent Teams)
Dependent chains → sequential (single agent handles the chain in order)
Always use
```
model: "opus"
```
for agents

Wait for user approval.

进入计划模式（使用/plan）。 计划必须以"上下文重载"章节作为步骤0，包含以下内容：

重新读取本技能文件（启动本次会话的SKILL.md）的指令
读取配置
```
.claude/autonomous-tests.json
```
的指令
读取模板文件：本技能的
```
references/templates.md
```
文件的指令
确定的范围参数：
```
$ARGUMENTS
```
当前分支名称
选中的条目（ID、标题、来源）
检测结果文档中的关键上下文

这可以确保计划通过后上下文被清空时，执行的Agent可以完整重建会话状态。

针对每个选中的条目，读取相关源代码并构建修复上下文文档：

读取检测结果中引用的文件（接口文件、模型文件、测试文件）
追踪代码路径：输入 → 处理 → 输出
定位根因（而非仅表面症状）
设计修复方案

漏洞类条目（V前缀）需要补充额外上下文：

追踪受影响接口/处理器的完整输入 → 处理 → 输出路径
识别所有到达漏洞代码的用户可控输入
检查同一文件/模块中的相关漏洞模式（例如发现SQL注入时，检查文件中所有查询构造逻辑）
评估监管暴露面（暴露的数据适用哪些数据保护法律）
安全感知的修复设计：修复必须解决根因，而非掩盖症状——强制使用正确的序列化/DTO过滤，添加校验/消毒层，必要时引入限流或防护机制

依赖分析：判断哪些条目可以独立修复，哪些属于依赖链：

独立项：影响不同文件、模块、DB集合或接口，没有重叠的条目
依赖项：共享文件、修改同一函数、或者一个修复可能影响另一个的条目

执行策略：

独立分组 → 并行执行（通过Agent团队为每个分组分配一个Agent）
依赖链 → 顺序执行（单个Agent按顺序处理整个依赖链）
Agent始终使用
```
model: "opus"
```

等待用户审批。

Phase 3 — Execution

阶段3 - 执行

Use

TeamCreate

to create a fix team. Spawn

general-purpose

agents as teammates with

model: "opus"

Standard fix agent instructions (all items):

Read the Fix Context Document for your assigned items
Re-read the source files to confirm current state
Implement the fix addressing the root cause
Run existing unit tests if configured (
```
testing.unitTestCommand
```
from config)
Verify the fix with targeted checks (API calls, DB queries, log inspection)
Report results (RESOLVED/PARTIAL/UNABLE with details)

Vulnerability fix agent instructions (V-prefix items — in addition to standard):

Remove or redact sensitive data from API responses (enforce DTO/serializer filtering)
Add input validation and sanitization at the boundary
Implement rate limiting, file size validation, content-type validation where applicable
Add circuit breakers for external service interactions
Harden error responses (no stack traces, internal metadata, or debug info in responses)
Verify the fix doesn't introduce new attack vectors
Check for the same vulnerability pattern in related files/endpoints
Test with variant attack payloads (not just the original vector)

Execution flow:

Create tasks for each item/group via
```
TaskCreate
```
— include: Fix Context Document, source file paths, fix instructions, verification steps
Assign tasks to agents via
```
TaskUpdate
```
with
```
owner
```
Independent groups run in parallel; dependent chains run sequentially through a single agent
Never fix in the main conversation — always delegate to agents
After all agents complete, shut down teammates via
```
SendMessage
```
with
```
type: "shutdown_request"
```

使用

TeamCreate

创建修复团队，生成

general-purpose

类型的Agent作为团队成员，使用

model: "opus"

。

标准修复Agent指令（所有条目适用）：

读取分配给你的条目的修复上下文文档
重新读取源文件确认当前状态
实现针对根因的修复
如果配置了单元测试，执行现有单元测试（配置中的
```
testing.unitTestCommand
```
）
通过定向检查验证修复（API调用、DB查询、日志检查）
上报结果（RESOLVED/PARTIAL/UNABLE，附带详情）

漏洞修复Agent额外指令（V前缀条目适用，在标准指令基础上补充）：

移除或脱敏API响应中的敏感数据（强制DTO/序列化器过滤）
在边界层添加输入校验和消毒
必要时实现限流、文件大小校验、内容类型校验
为外部服务交互添加熔断机制
加固错误响应（响应中不包含堆栈跟踪、内部元数据或调试信息）
验证修复不会引入新的攻击面
检查相关文件/接口中是否存在相同的漏洞模式
使用变种攻击payload测试（不局限于原始攻击向量）

执行流程：

通过
```
TaskCreate
```
为每个条目/分组创建任务——包含：修复上下文文档、源文件路径、修复指令、验证步骤
通过
```
TaskUpdate
```
的
```
owner
```
字段为Agent分配任务
独立分组并行运行；依赖链通过单个Agent顺序执行
不要在主会话中执行修复，始终委托给Agent
所有Agent执行完成后，通过
```
SendMessage
```
发送
```
type: "shutdown_request"
```
关闭团队成员

Phase 4 — Verification

阶段4 - 验证

After all agents report, verify results:

Standard verification (all items):

Confirm files were modified as expected
Run unit tests if configured
Check that the original issue is resolved (re-execute the failing scenario)

Security-specific verification (V-prefix items):

Re-test the original attack vector (must be blocked)
Test variant payloads (different injection strings, encoding bypasses, alternative file types)
Verify no auth bypass or privilege escalation introduced
Verify error responses are hardened (no internal metadata leakage)
Verify sensitive data removal from API responses
Check rate limiting is enforced (if added)

Mark each item as: RESOLVED (fix works, verified), PARTIAL (partially addressed, needs more work), or UNABLE (cannot fix autonomously, needs human intervention).

所有Agent上报结果后，验证修复结果：

标准验证（所有条目适用）：

确认文件按预期修改
如果配置了单元测试则执行单元测试
确认原始问题已解决（重新执行失败场景）

安全专项验证（V前缀条目适用）：

重新测试原始攻击向量（必须被拦截）
测试变种payload（不同注入字符串、编码绕过、替代文件类型）
验证没有引入鉴权绕过或权限提升漏洞
验证错误响应已加固（无内部元数据泄漏）
验证API响应中的敏感数据已移除
验证限流已生效（如果添加了限流）

将每个条目标记为：RESOLVED（修复生效，已验证）、PARTIAL（部分解决，需要更多工作）或UNABLE（无法自动修复，需要人工介入）。

Phase 5 — Documentation Update

阶段5 - 文档更新

Generate docs in dirs from config (create dirs if needed). Get filename timestamp by running

date -u +"%Y-%m-%d-%H-%M-%S"

in Bash (never guess the time). Read
references/templates.md
for the exact output structure before writing.

Fix-results document: Always generated. Write to

documentation.fixResults

path. Contains Fix Cycle Metadata, per-item results, and next steps.

Resolution blocks: For each item sourced from pending-fixes, append a

### Resolution

block to the corresponding fix entry in the original pending-fixes document.

Test-results updates: For each T-prefix item, append a fix-applied status line to the corresponding entry in the test-results document.

V-prefix items get a
### Security Impact
subsection in the fix-results document containing:

OWASP category
Attack vector (realistic exploitation scenario)
Regulatory/compliance impact (which laws, what penalties)
Mitigation description (what the fix does and why it works)
Related patterns checked (other files/endpoints verified)
Residual risk (if any)

在配置的目录中生成文档（如果目录不存在则创建）。通过Bash执行

date -u +"%Y-%m-%d-%H-%M-%S"

获取文件名时间戳（不要猜测时间）。写入前务必阅读
references/templates.md
了解准确的输出结构。

修复结果文档：始终生成，写入

documentation.fixResults

路径，包含修复周期元数据、每个条目的结果、后续步骤。

解决记录块：针对每个来自待修复项的条目，在原始待修复文档的对应修复条目后追加

### Resolution

块。

测试结果更新：针对每个T前缀的条目，在测试结果文档的对应条目后追加修复已应用的状态行。

V前缀条目需要在修复结果文档中新增
### Security Impact
子章节，包含：

OWASP类别
攻击向量（真实的利用场景）
监管/合规影响（适用哪些法律、对应处罚）
缓解措施说明（修复的内容以及生效原理）
检查的相关模式（验证过的其他文件/接口）
残留风险（如果有）

Phase 6 — Loop Signal

阶段6 - 循环信号

Summarize the fix cycle and signal readiness for re-testing:

undefined

总结修复周期，发出可重测的信号：

undefined

Fix Cycle Complete

修复周期完成

Items attempted: {N}
Resolved: {N}
Partial: {N}
Unable: {N}

Re-run autonomous-tests to verify:

/autonomous-tests


If `Ready for Re-test: YES` in the fix-results document, inform the user that autonomous-tests will prioritize re-testing these items on next run.

**Vulnerability warning**: If any V-prefix items remain PARTIAL or UNABLE, emit a prominent warning with security priority ranking:

⚠️ UNRESOLVED SECURITY FINDINGS

The following security items could not be fully resolved and require manual attention:

Priority order (highest risk first):

Data leaks — {list V-prefix items if any}
Credential exposure — {list V-prefix items if any}
Privilege escalation — {list V-prefix items if any}
Denial-of-service risks — {list V-prefix items if any}
Compliance violations — {list V-prefix items if any}

---

尝试修复条目数：{N}
已解决：{N}
部分解决：{N}
无法修复：{N}

重新运行autonomous-tests验证结果：

/autonomous-tests


如果修复结果文档中`Ready for Re-test: YES`，告知用户下次运行autonomous-tests时会优先重测这些条目。

**漏洞警告**：如果有V前缀条目仍为PARTIAL或UNABLE状态，输出醒目的安全优先级排名警告：

⚠️ 未解决的安全检测结果

以下安全条目未被完全修复，需要人工处理：

优先级排序（风险从高到低）：

数据泄漏 — {如果有V前缀条目则列出}
凭证暴露 — {如果有V前缀条目则列出}
权限提升 — {如果有V前缀条目则列出}
拒绝服务风险 — {如果有V前缀条目则列出}
合规违规 — {如果有V前缀条目则列出}

---

Rules

规则

Never modify production data or connect to production services
Never expose credentials, keys, or tokens in documentation output
Always enter plan mode before executing fixes (Phase 2)
Always delegate fixes to Agent Teams — never fix in main conversation
NEVER use the
Agent
tool directly for execution. ALWAYS use
TeamCreate
→
TaskCreate
→ spawn agents with
team_name
parameter →
TaskUpdate
→
SendMessage
. Plain
Agent
calls bypass team coordination and task tracking. The
Agent
tool without
team_name
is PROHIBITED during Phase 3.
Always spawn agents with
```
model: "opus"
```
for maximum reasoning capability
Always present findings for user selection before reading source code (Phase 1 before Phase 2)
AskUserQuestion hook ensures user selection even in dontAsk/bypass mode
Security fixes must address root causes — not mask symptoms
Use UTC timestamps everywhere — always obtain from
```
date -u
```
, never guess
Reuse
```
.claude/autonomous-tests.json
```
— never create a separate config
Never activate Docker MCPs where
```
safe: false
```
V-prefix items always get enhanced security context, verification, and documentation

永远不要修改生产数据或连接生产服务
永远不要在文档输出中暴露凭证、密钥或token
执行修复前必须进入计划模式（阶段2）
始终将修复任务委托给Agent团队，不要在主会话中执行修复
永远不要直接使用
Agent
工具执行任务。必须遵循
TeamCreate
→
TaskCreate
→ 生成带
team_name
参数的Agent →
TaskUpdate
→
SendMessage
的流程。纯
Agent
调用会绕过团队协调和任务跟踪。阶段3期间禁止使用不带
team_name
的
Agent
工具。
始终为Agent指定
```
model: "opus"
```
以获得最高的推理能力
读取源代码前必须先展示检测结果供用户选择（阶段1早于阶段2）
AskUserQuestion钩子确保即便是dontAsk/bypass模式下也会要求用户选择
安全修复必须解决根因，不能掩盖症状
所有地方使用UTC时间戳——始终从
```
date -u
```
获取，不要猜测
复用
```
.claude/autonomous-tests.json
```
，永远不要创建单独的配置
永远不要激活
```
safe: false
```
的Docker MCP
V前缀条目始终需要补充安全上下文、安全验证和安全相关文档