用途：为 git 仓库生成一份面向 LLM 阅读的项目档案，写入 docs/{project-name}.md。它不是代码库目录地图或 diff 示意图，而是架构判断类文档，包含设计取舍、使用模式以及不适用场景，让后续 LLM 能快速回答四个核心问题：核心抽象是什么、实现功能 X 改哪些模块、最大风险或技术债是什么、何时该用或不该用。
主要能力：按阶段执行。阶段 0 预检确定目标目录与项目名（依次从 package.json、pyproject.toml、Cargo.toml、go.mod 提取，否则用目录名），运行扫描脚本 uv run {SKILL_DIR}/scripts/scan-project.py {TARGET_DIR} --format summary，采集 git 元数据（最近提交、贡献者、版本标签、首次提交日期），检查是否已存在 docs/CODEBASE_MAP.md，并根据总 token 数选择执行模式。阶段 1 通过 gh api 获取 GitHub stars/forks/issues，尝试获取 npm 或 PyPI 下载量、许可证，并评估成熟度（experimental、growing、stable、mature）。阶段 2 使用子代理并行探索源码。阶段 3 依据扫描结果与子代理报告检测条件章节。阶段 4 合并报告、生成 Mermaid 架构拓扑图与数据流图、结构化模块依赖，并填充输出模板。阶段 5 质量门禁：禁止使用“优雅、完美、强大、直观”等主观词，审计数字来源，校验结构，执行核心问题与证据核查。
使用方式：以技能形式调用，指定目标 git 仓库目录。执行模式依据总 token 数选择：不超过 80k 时 Opus 直接读取全部文件分析；80k 至 200k 使用 2 个代理；200k 至 400k 与超过 400k 使用 3 个代理。所有子代理须在同一条消息中并行启动。
适用场景：为开源或内部仓库生成 LLM 可读的架构说明书，支持 monorepo 工作区分组。
限制：需要 git 仓库与可用脚本环境；GitHub 统计、扩展包下载量在不可用或非 GitHub 仓库时记为 N/A；成熟度采用最低匹配档位的保守估计；输出为 Markdown 文档，具体安装步骤、价格与效果资料暂未提供。