3.1 skill-writer#

该模式用于维护 Agent Skills 本身，限制编辑范围到 .roo/skills* 相关目录。它的作用相当于“Agent 能力包维护模式”，负责 skill 的规范化编写与审计。

3.2 ctf-executor#

ctf-executor 是执行态模式，强调：

• 只做已明确边界的子目标
• 高密度调用工具、命令、脚本
• 保留硬证据与产物路径
• 对失败路径给出结构化回传

它的职责更像“战术执行器”，不负责长期全局规划，而负责把一轮操作做透。

3.3 ctf-commander#

ctf-commander 是编排态模式，负责：

• 识别题型
• 选择主路径与备选路径
• 选择主 skill
• 设定子任务边界
• 管理失败回退与模式切换

它更像“战术指挥层”，负责决定下一轮应该做什么，而不是直接把所有技术细节亲自跑完。

3.4 模式层的设计意义#

当前模式层已经体现出明显的双层分工：

• Commander 负责“路线正确”
• Executor 负责“执行做透”

这种拆分解决了单一模式同时负责规划与执行时容易出现的三个问题：

1. 编排容易被局部技术细节打断
2. 执行失败后没有上层负责换路
3. 证据、产物、writeup 难以纳入统一协议

4.1 环境契约文件： .roo/env-contract.md#

.roo/env-contract.md 是一个“统一环境声明文件”，其定位不是临时侦察记录，而是赛前维护的固定契约。

它主要定义了：

• Windows 层、WSL Bash 层、Sage 层三种运行层的职责边界
• 必须先读环境契约、再读机器可读配置的读取顺序
• 固定入口与最小一致性验证方法
• Windows 路径到 WSL 路径的映射规则
• 各题型默认推荐的执行分层方式

关键设计点包括：

1. 明确要求先读 env-contract.md，再读 settings.json。
2. 禁止赛时重新猜测工具位置，例如 WSL_SAGE 等入口必须直接引用。
3. 把 Crypto/Web/Reverse/Pwn/Forensics 的运行层拆成“采样 / 求解 / 回放”或等价分层。
4. 明确跨层共享产物必须落回工作区文件，而不是留在临时环境中。

这说明项目已经把“环境管理”从隐式经验提升为显式协议，这对 CTF 场景尤其重要，因为很多失败并不是题目本身问题，而是运行层混用导致的。

4.2 机器可读环境配置： .roo/settings.json#

.roo/settings.json 主要由两部分组成：

• env
• permissions

4.3 MCP 配置： .roo/mcp.json#

.roo/mcp.json 当前配置了两个 MCP 服务：

• ida-pro-mcp
• brave-search

4.4 配置层结论#

.roo 当前已经形成三种互补配置：

1. env-contract.md 负责“解释与约束”
2. settings.json 负责“机器可读入口与权限”
3. mcp.json 负责“MCP 服务接入”

这种拆分很合理：文档负责语义与流程，JSON 负责自动化消费，MCP 负责外部能力注入。

5.1 通用 CTF Skills： .roo/skills/#

.roo/skills/ 下包含大量通用技能包，例如：

• ctf-solve
• ctf-web-methodology
• ctf-web-recon
• ctf-crypto
• ctf-reverse
• ctf-pwn
• ctf-source-audit
• ctf-flag-verification
• playwright-cli

这些 skill 是题型方法论层，解决的是“遇到某一类目标时，应该按什么方法推进”。

5.2 Commander 专属 Skills： .roo/skills-ctf-commander/#

该目录负责编排层增强，当前至少包括：

• commander-task-routing
• commander-failure-replanning
• commander-blocker-analysis

其中 commander-task-routing 明确要求：

• 先判输入，再判题型
• 首轮即选择主 skill
• 输出固定格式的结构化计划
• 对 Web 目标追加 playwright-cli 判定
• 主路径连续失败后自动换路

这说明 Commander 层不是“自由发挥的分析”，而是被 skill 协议化了。

5.3 Executor 专属 Skills： .roo/skills-ctf-executor/#

该目录负责执行层增强，当前至少包括：

• executor-web-tool-selection
• executor-evidence-packaging
• executor-artifact-triage
• executor-exploit-attempts
• executor-writeup-handoff

6.1 题目目录#

仓库中当前已有题目目录：

• crypto/
• misc/
• pwn/
• reverse/
• web/

这些目录承载历史或当前题目的脚本、附件、writeup 与输出。例如：

• crypto/FMS
• misc/Sat
• pwn/hardoverflow_artifacts
• web/SuperStudentManager

这说明项目已经不只是保留最终答案，而是在用真实题目目录沉淀脚本、分析痕迹和 writeup，反向验证 Agent 目录规范是否可落地。

6.2 通用工具目录：tools/#

tools/ 中集中放置仓库级通用工具，包括：

• sqlmap-master
• dirsearch-master
• Fenjing-main
• phpggc-master
• RsaCtfTool-master

这些工具并不是孤立存在；根据 executor-exploit-attempts 与 executor-artifact-triage 的规则，它们已经被纳入标准调用协议，要求记录：

• 工具路径
• 用途
• 关键参数
• 输出文件

因此 tools/ 可以视为 Agent 的“可复用武器库”。

6.3 规划文档目录：plans/#

plans/ 目前已有多份架构与改造文档，例如：

• plans/ctf-agent-progress-report.md
• plans/ctf-agent-updated-workflow-analysis.md
• plans/ctf-agent-rules-upgrade.md
• plans/roocode-dual-mode-implementation-plan.md

这些文档的作用不是题目 writeup，而是 Agent 自身的设计演进记录。

也就是说，这个仓库同时维护两类知识：

1. 题目知识
2. Agent 架构知识

这是一个很鲜明的工程化特征。

8.1 优势#

当前项目结构的主要优势有：

1. 职责清晰：ctf-commander 与 ctf-executor 分工明确。
2. 环境显式化：env-contract.md 与 settings.json 把运行层问题前置处理。
3. 方法论模块化：通用 skill 与 mode-specific skill 分层组织，可持续扩展。
4. 工具可复用：tools/ 中工具已被执行协议正式吸纳。
5. 证据可复盘：目录结构、日志、payload、writeup 都有统一落点。
6. 适配混合题型：既能处理 Web 动态交互，也能调用 WSL/Sage/IDA 等强能力工具链。

8.2 限制#

当前结构也反映出一些阶段性限制：

1. 仍以 prompt / skill 协议为主，尚不是带状态机与任务图调度器的完整 runtime。
2. 当前规划文档较多，但自动化验证与回归测试体系还不明显。
3. 题目目录结构在历史题中已部分出现，但尚未看到所有存量目录完全统一到最新规范。
4. mode-specific skill 已经成型，但 Reverse / Pwn / Crypto 的执行模板还可以继续细分。