project-map-builder
生成或更新用户指定文件夹的 PROJECT_MAP.md。适用于用户要求目录地图/项目地图/代码仓概览/文件夹级说明/更新已有 PROJECT_MAP.md 的场景。必须先询问要扫描的文件夹范围，禁止默认全仓库扫描；支持单目录或多目录（合并或分别生成）。
Best use case
project-map-builder is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
生成或更新用户指定文件夹的 PROJECT_MAP.md。适用于用户要求目录地图/项目地图/代码仓概览/文件夹级说明/更新已有 PROJECT_MAP.md 的场景。必须先询问要扫描的文件夹范围，禁止默认全仓库扫描；支持单目录或多目录（合并或分别生成）。
Teams using project-map-builder should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/project-map-builder/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How project-map-builder Compares
| Feature / Agent | project-map-builder | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
生成或更新用户指定文件夹的 PROJECT_MAP.md。适用于用户要求目录地图/项目地图/代码仓概览/文件夹级说明/更新已有 PROJECT_MAP.md 的场景。必须先询问要扫描的文件夹范围，禁止默认全仓库扫描；支持单目录或多目录（合并或分别生成）。
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# 项目目录地图构建器 为指定目录范围生成或增量更新高信噪比的目录说明文档。 ## 核心规则 - 必须让用户指定要扫描的文件夹范围，禁止默认全仓库扫描。 - 若范围过大，提醒上下文风险并让用户确认或缩小范围。 - 输出语言必须与用户当前语言一致。 - 文档文件名固定：PROJECT_MAP.md。 - 若输出位置已存在 PROJECT_MAP.md，进入更新模式（仅增量更新）。 - 若不存在，进入主动引导模式（先确认范围再新建）。 ## 输出位置规则 - 单目录：将 PROJECT_MAP.md 写在该目录根。 - 多目录： - 先询问：生成一个合并文档，还是每个目录各生成一个。 - 合并：写到项目根目录。 - 分开：各目录根各写一份 PROJECT_MAP.md。 ## 最少需要询问用户的问题 - 要扫描哪些文件夹？ - 如果是多个文件夹：合并成一个文档，还是分别生成多个？ - 若范围大或不明确：是否确认范围？ ## 工作流 ### A) 主动引导模式（不存在 PROJECT_MAP.md） 1) 确认扫描范围与输出策略。 2) 快速列出指定目录的文件清单。 3) 识别入口与关键文件（如 manifest、主入口、服务线程、UI、配置、存储、测试、文档）。 4) 只打开“关键文件”用于解释职责与关系，避免全量读取。 5) 按结构模板生成 PROJECT_MAP.md。 6) 不确定处必须显式标注（如“假设”“未确认”）。 ### B) 更新模式（已存在 PROJECT_MAP.md） 1) 读取既有 PROJECT_MAP.md。 2) 仅重新扫描用户指定的目录范围。 3) 结合“当前对话上下文”与文件清单差异，定位需更新的段落。 4) 只做增量补丁更新，不进行全量重写。 5) 添加“本次更新”小节（日期 + 范围 + 变更点）。 ## 扫描规则 - 优先使用快速文件列表命令（如 `rg --files` 或 `Get-ChildItem`）。 - 不要打开所有文件，只读关键文件。 - 如需更深入的细节，先向用户确认要深入的子目录。 ## 文档结构模板（PROJECT_MAP.md） 可按需调整，但建议包含： 1) 项目概览（一句话） 2) 作用范围（本次扫描的文件夹列表） 3) 入口与运行链路（简化版） 4) 关键配置与存储键（如适用） 5) 目录与文件说明（按目录层级） 6) 关键模块关系/调用链 7) 风险/遗留/不确定点 8) 本次更新（仅更新模式） ## 多目录输出规则 - 合并文档：在“作用范围”列出每个目录，并为每个目录写独立小节。 - 分开文档：每个目录只描述自身范围，不做跨目录合并。 ## 更新模式规则（仅增量） - 尽量保留已有结构与表述。 - 只修改与新增/删除文件或新上下文相关的部分。 - 除非明确错误，否则不删除旧内容。 - “本次更新”记录日期、范围与变更摘要。 ## 安全与清晰性 - 无法确认的行为或规则必须标注为“假设/未确认”。 - 看似遗留的文件应标注为“可能遗留”，除非用户要求，否则不建议删除。
Related Skills
lesson-builder
帮助用户通过讨论完成课程大纲和课件。当用户说"备课"、"做课件"、"准备课程"时触发。
writing-assistant
写作助手 - 当用户说"我想写XX"、"帮我梳理选题"、"怎么形成框架"、"给我组织思路"时触发。根据观点清晰度自动选择最优路线：清晰观点走"框架→内容"，模糊观点走"挖掘→选题→框架→内容"。
weekly-report
帮助用户梳理周报，按照完整逻辑展示工作价值和边界。当用户说"写周报"、"周报"、"梳理周报"、"整理工作"时触发。
vision-exploration
终局愿景探索。用户抛出一个模糊 idea，AI 主导引导，通过"追问价值 → 挖掘动机 → 推导演化 → 画终局"的链路，帮用户看到未来最远的可能性。不设限，不收敛，纯发散。
version-planner
帮助用户把产品需求拆解成渐进式版本规划。当用户说"拆版本"、"版本规划"、"MVP怎么做"、"分阶段实现"时触发。
ui-design
UI 样式修改协作流程。当用户要求修改页面样式、调整布局、改 UI 细节时使用。通过"截图定位 → 现状描述 → 方案选择 → 改代码 → 微调"的结构化流程，减少沟通偏差，避免浪费 token。
thought-mining
思维挖掘助手 - 通过对话帮助用户把脑子里的零散想法倒出来、记录下来、整理成文章。覆盖从思维挖掘到成稿的完整流程。
thinking-partner
思考拍档 - 陪你从混沌中理清局面，锁定核心问题，拆解卡点，共创解法，落地行动
req-change-workflow
Standardize requirement/feature changes in an existing codebase (especially Chrome extensions) by turning "改需求/需求变更/调整交互/改功能/重构流程" into a repeatable loop: clarify acceptance criteria, confirm current behavior from code, assess impact/risk, design the new logic, implement with small diffs, run a fixed regression checklist, and update docs/decision log. Use when the user feels the change process is chaotic, when edits tend to sprawl across files, or when changes touch manifest/service worker/OAuth/storage/UI and need reliable verification + rollback planning.
product-naming
产品命名协作流程。当用户想给产品/项目/模块起名字时使用。通过"灵魂挖掘 → 约束提取 → 路线发散 → 方向选择 → 竞品验证 → 最终确认"的结构化流程，从模糊想法产出有品牌生命力的名字，避免拍脑袋起名。
priority-judge
优先级判断助手 - 帮用户从混沌的待办事项中判断优先级，确定现在该做什么。当用户说"我有很多事要做"、"帮我理一下"、"排个优先级"、"今天该做什么"时触发。
prd-doc-writer
Write and iteratively refine PRD/需求文档 with a story-driven structure and strict staged confirmations (journey map alignment, per-story single-point confirmation, final generation gate). Use when the user asks to 梳理/撰写/完善 PRD、需求文档、用户故事、验收标准，并希望用 ASCII 线框图与 Mermaid（流程图/状态图/时序图）来减少歧义、共同完成文档。