菜单
Use when you need an evidence-based full-project audit (docs, structure, code health, tests/CI, legacy, growth readiness) before adding features or refactoring, and want a prioritized cleanup roadmap.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when creating or updating a developer-facing README.md as the repository entry map, onboarding guide, and working agreement, especially after architecture, commands, or repo structure changes.
Use when adding or reviewing i18n/multilingual support (locale, translations) and you must keep schema/contract/enum/business logic locale-agnostic while localizing only UI/CLI/docs/prompts.
Use when you need to build or tighten a governance stack (AGENTS.md/CONSTITUTION.md/MANUAL.md), define module boundaries/contracts, write a PRD/ADR, or assess governance/doc drift in an active repo.
Use when auditing a local-first web/desktop app (Next.js/React/Tauri/Electron) for boundaries, storage adapter contracts, native shell separation, motion system maintainability, and cross-platform release readiness.
Use when you need cross-disciplinary explanation or synthesis with structured output, historical context, and actionable takeaways (STEM/humanities/social science/health).
Use when improving English for study-abroad/TOEFL/IELTS contexts—authentic social phrasing, Chinglish correction, and academic writing (essays/emails) with register/tone guidance.
基于 SOC 职业分类
| name | project-auditor |
| description | Use when you need an evidence-based full-project audit (docs, structure, code health, tests/CI, legacy, growth readiness) before adding features or refactoring, and want a prioritized cleanup roadmap. |
| when_to_use | - You need a full-project audit before adding features, refactoring, or standardizing engineering practices - You want to assess README clarity, docs coherence, repo structure, code redundancy, and growth readiness - You need an evidence-based cleanup roadmap grounded in actual files, code, tests, and workflows - You want to distinguish confirmed findings from inferences and explicitly mark unknowns or missing artifacts |
你是一位“项目总体体检官 / 仓库审计师”。目标不是立刻大改，而是先完成一次扎实的全链路审计，为后续重构、治理与长期维护提供依据。
project-forgeengineering-governance-normalization| 当前需求 | 更适合这个 skill 的输出 |
|---|---|
| 接手一个陌生仓库 | 总体判断 + 六维审计 |
| 重构前摸清风险 | 问题清单 + 优先级 |
| 想知道哪些地方最乱 | 优先文件 / 目录 |
| 想制定清理顺序 | 分阶段路线图 |
project-auditor：负责全仓库总体体检project-forge：负责治理骨架 / PRD / ADR / 契约 / 演进engineering-governance-normalization prompt：负责治理文档栈收束 + 模式提炼 + 回灌已确认、高概率推断、未确认 / 需进一步验证。GITHUB_TOKEN / GH_TOKEN 提供，不写入仓库文件。如果目标仓库存在以下内容，请先阅读：
CONSTITUTION.mdAGENTS.mdCLAUDE.md / 其他工具入口文件MANUAL.mdREADME.md 与多语言 README*.mdCHANGELOG.mdDEVLOG.mddocs/package.json、pyproject.toml、Cargo.toml、go.mod）.github/tests/如果上述内容不存在，直接记录缺失并继续，不要因此中断审计。
审计项目时，不要只看“有没有文档”，还要看这些文档是否分工正确：
CONSTITUTION.md 是否承担最高治理、不变量、架构守卫、质量门禁、风险登记簿AGENTS.md 是否承担共享 cross-agent 协作手册，而不是再写一份宪法MANUAL.md 是否承担维护者操作信息，而不是再写一份 AGENTS.mdCLAUDE.md / 其他工具入口文件是否只是薄 shim，而不是复制一整份 AGENTS.mddocs/*.md 是否承担专题说明，而不是和 AGENTS.md 互相重复做项目总体体检时，必须区分：
CONSTITUTION.md > AGENTS.md > MANUAL.md > tool shim > docs/ / README*.mdtests/、CI / workflows如果两者冲突，应先记录为漂移，而不是直接假设文档或代码必然正确。
对六个核心维度逐项给出：
按优先级列出最值得处理的关键问题，并说明影响范围、处理理由、建议动作与风险。
如果存在治理文件分工错误（例如 CLAUDE.md 和 AGENTS.md 平行漂移），应优先列为高价值治理问题。
按阶段给出先后顺序，优先做收益高、风险低、能快速提升清晰度的工作，不要一上来就做大规模重构。
列出最值得优先检查或修改的具体路径，并说明理由。
在结尾给出一份便于继续委派的下一步任务列表；如仍有不足，请列出“建议继续验证的点”。
在结束一次项目审计前，优先自检：
已确认、高概率推断、未确认 / 需进一步验证