repo-recon

用途

repo-recon 是一个智能体技能，用于在改动代码之前系统地梳理一个不熟悉的代码库。它把勘察定义为一段简短、有边界的流程——几分钟而非几小时——用于提前建立理解，避免之后在构建失败、PR 被拒和重写上付出代价。它是每一次安全编辑的“前置”环节。

核心观点：勘察便宜，猜测昂贵。在改动任何一行代码之前，先花几分钟回答五个问题：这个仓库是什么、如何布局？如何构建、测试和运行？一个真实流程位于何处、端到端如何运作？我的代码必须遵循哪些约定？我把这些记在哪里？

主要能力

该技能定义了一个五步勘察流程，每步都有明确的书面产出：

阅读地图：先读 README、ARCHITECTURE、docs/ 和 ADR；列出顶层目录树并识别入口点（main、index、server、CLI、worker、App 组件等）；浏览清单文件（package.json、pyproject.toml、go.mod、Cargo.toml、composer.json、Gemfile、pom.xml 等）以了解真实依赖和脚本；记录仓库“不是什么”（无测试？无文档？monorepo？库还是应用？）。产出：一段话的心智模型。
学习命令：查看 README/CONTRIBUTING、Makefile、Justfile、Taskfile 和清单脚本块，找出确切的安装、构建、测试、lint 和运行/开发命令；至少端到端验证一条命令（通常是测试套件，若测试慢则用构建）。产出：一份带工作目录的已验证命令速查表。
追踪一条流程：挑选一个有代表性的流程（面向用户的功能、请求生命周期、任务），从入口点一路跟到输出、数据库或副作用；用搜索在调用点与定义之间跳转，阅读真实代码；记录每一步的 file:line 锚点。一条流程足矣，不要追踪三条。产出：一份书面追踪记录。
记录约定并遵循：识别本地风格并遵循它，即使你自己会写得不同。关注命名方式、结构（错误处理位置、类型/schema 位置）、测试风格、错误处理与日志模式、提交/PR 风格。产出：一份将在每次编辑中有意识匹配的约定清单。
写下来：把勘察结果写入持久笔记而非记忆。可在仓库根目录写 RECON.md（或加入 .gitignore）供团队/其他智能体复用，私有的一次性仓库可保留会话笔记。内容包括地图段落、已验证命令、流程追踪、约定清单和未解问题。如发现 TODO 或地雷，记录在此，暂不修复。产出：下次可跳过此步的笔记文件。

使用方式

该技能通过技能描述触发使用，资料未提供具体安装命令或调用方式。用户需在智能体技能平台（如 skills.sh）上使用该技能。

适用场景

首次在某个仓库中工作
长期未接触后重返某仓库（记忆已过时）
代码库庞大、老旧或没有文档
需要做跨越模块边界的改动（新功能、重构、迁移或原因不明的 bug）
审阅或扩展他人写的代码
需要为另一个智能体或同事提供快速准确的定位说明

不适用场景：改动是自包含脚本中的一行——地图就是文件本身；已持有近期勘察笔记中的地图、命令和约定（勘察要新鲜，而非仪式）。

常设规则

先搜索再假设：不要假设某个辅助函数、模式或文件存在——先用 grep 确认。
先验证再相信：读 README 不等于理解代码，要对实际源码和真实命令运行进行确认。
勘察期间不改代码：不做顺手修复、不做重构、不做“快速改进”；代码只读，唯一产出是勘察笔记。
匹配而非强加：本地约定与个人偏好冲突时，约定优先。
完整阅读即将修改的文件，而不只是编辑点附近的片段。
地图与现实矛盾时提问：文档说 X 而代码做 Y，则信任代码、标记偏差，并询问预期行为是 X 还是 Y。

完成标准

能够回答上述五个问题且答案已写入磁盘时，勘察即完成：一段话的地图、已验证的安装/构建/测试/运行命令、一条带 file:line 锚点的端到端流程、一份编辑将遵循的约定清单、写入磁盘的勘察笔记（或一次性仓库的会话笔记）、勘察期间零源码改动。

常见错误

跳过地图直接扎进随机文件；猜测命令而不读清单或 Makefile；追踪太多流程；在勘察期间“修复”发现的问题；信任对类似仓库的过时记忆；把勘察只留在脑子里。

限制

资料未提供该技能的收费、价格、平台依赖或具体安装步骤。

技能介绍

用途