AI agent skill · by @chujianyun
Agent Md Advisor
AGENTS.md / CLAUDE.md 最佳实践顾问。用于用户询问 agents markdown、AGENTS.md、CLAUDE.md、Claude Code memory、AI coding agent 指令文件的格式、结构、最佳实践;也用于审查、诊断、重写、优化或从零创建 AGENTS.md、CLAUDE.md、CLAUDE.local.md、.claude/rules 等 agent 指令文件。不适用于通用 README 写作,除非目标是给 AI coding agent 提供项目上下文。
Archived 2026-10-23 · Source updated 2026-10-09. Check the original repository for the latest version.
SKILL.md instructions
# Agent Markdown Advisor 帮助用户回答、审查、优化和创建 AI coding agent 指令文件,重点覆盖 `AGENTS.md` 与 `CLAUDE.md`。 ## 设计模式 本 skill 主要采用: - **Advisor**:回答格式、结构、放什么/不放什么等最佳实践问题 - **Reviewer**:诊断已有 `AGENTS.md` / `CLAUDE.md` 是否违反最佳实践 - **Generator**:根据项目和用户描述创建新的指令文件 - **Editor**:用户明确要求执行优化时,直接修改相关文件 ## Gotchas - 不要把 `AGENTS.md` / `CLAUDE.md` 写成项目百科、README 复制品或完整 API 文档 - 不要把 `AGENTS.md` / `CLAUDE.md` 写成人设说明书、口号墙或愿望清单;它应该像给资深工程师的技术简报 - 不要把 linter、formatter、类型检查器能确定执行的规则改写成大量自然语言 - 不要写实际密钥、token、生产连接串、客户数据或内部安全细节;只写密钥位置和访问方式 - 不要凭空发明命令;先看 `package.json`、`pyproject.toml`、`Makefile`、CI workflow、README 等可验证来源 - 不要默认建议复杂 `.claude/agents`、hooks、MCP、skills;先判断项目是否真的需要 - 如果用户只要求诊断,不要直接改文件;如果用户说“优化、重写、创建、执行”,可以落地修改 - 保持文件短而可执行:`AGENTS.md` 理想上 150 行以内,`CLAUDE.md` 优先压到 80-120 行,超过 200 行要强烈考虑拆分 ## 工作模式 先判断用户需求属于哪一类: 1. **问答模式**:解释格式、章节、层级、AGENTS.md 和 CLAUDE.md 区别、最佳实践。 2. **诊断模式**:用户已有文件,希望指出问题、违反的实践和改进建议。 3. **优化模式**:用户明确要求修改、重写、压缩、整理或“执行优化”。 4. **创建模式**:用户还没有文件,或希望根据描述生成 `AGENTS.md` / `CLAUDE.md`。 ## 使用流程 复制此清单并跟踪进度: ```text 处理进度: - [ ] 步骤 1:识别模式和目标文件 - [ ] 步骤 2:读取必要参考资料 - [ ] 步骤 3:读取项目上下文或用户提供内容 - [ ] 步骤 4:给出诊断、方案或草稿 - [ ] 步骤 5:如用户要求落地,修改文件并验证 ``` ### Step 1: 识别模式和目标文件 优先判断目标: - 跨工具、Codex、Copilot、Cursor、通用 AI coding agent:优先 `AGENTS.md` - Claude Code 项目记忆、Claude 专属规则:优先 `CLAUDE.md` - 每个项目都会重复的工作偏好:优先放 global/user 级配置 - 当前项目、技术栈、架构和命令:优先放 repo 内 `AGENTS.md` / `CLAUDE.md` - 个人本地偏好:优先 `CLAUDE.local.md` 或用户级 memory,不要提交到团队共享文件 - Monorepo 或多技术栈:考虑根目录文件 + 子目录嵌套文件 如果用户没有指定文件名: - 想要通用标准:建议 `AGENTS.md` - 主要使用 Claude Code:建议 `CLAUDE.md` - 同时使用多种工具:建议以 `AGENTS.md` 为主,并视工具支持情况用 `CLAUDE.md` 或符号链接兼容 ### Step 2: 读取必要参考 - 回答最佳实践问题:读 [references/best-practices.md](references/best-practices.md) - 审查或评分已有文件:读 [references/review-rubric.md](references/review-rubric.md) - 创建或重写文件:读 [references/templates.md](references/templates.md) - 需要追溯资料依据时:读 [references/source-notes.md](references/source-notes.md) ### Step 3: 读取项目上下文 诊断或创建文件前,先读取最小必要上下文: - 目标文件:`AGENTS.md`、`CLAUDE.md`、`CLAUDE.local.md` - 项目概览:`README.md` - 技术栈和命令:`package.json`、`pyproject.toml`、`Makefile`、`justfile`、`Taskfile.yml`、`pnpm-workspace.yaml` - 测试和 CI:`.github/workflows/`、`pytest.ini`、`vitest.config.*`、`tsconfig.json` - 现有 AI 配置:`.claude/`、`.cursor/rules/`、`.github/copilot-instructions.md` 只读与判断有关的文件。不要为了写指令文件而扫描整个仓库。 ### Step 4: 输出方式 #### 问答模式 用简洁中文回答,并给出可操作判断: ```markdown 结论:... 推荐结构: - ... 注意事项: - ... ``` #### 诊断模式 必须明确给结论和优先级: ```markdown # Agent 指令文件诊断 结论:优秀 / 基本可用 / 需要重构 / 风险较高 成熟度:L0-L6 中的某一级 ## 主要问题 1. [P1] ... 2. [P2] ... ## 做得好的地方 - ... ## 优化建议 1. ... 2. ... ## 建议改法 - 保留:... - 删除:... - 拆分:... - 新增:... ``` 如果能定位具体行,引用文件路径和行号。问题要围绕“会不会让 agent 更可靠”判断,不要只做文字润色。 #### 优化模式 先快速诊断,再直接编辑。编辑原则: - 保留真实、稳定、全局适用的信息 - 删除空泛、重复、过期、过细、容易从代码推断的信息 - 把长 SOP、API 文档、风格指南改成“Read when”引用 - 把命令改成可复制的真实命令 - 把硬规则压缩成能阻止具体错误的清单,`MUST` / `MUST NOT` 只留给少数关键约束 - 把安全边界和高风险操作写清楚 完成后说明改了什么,并建议用户实际跑一次常见任务来验证。 #### 创建模式 根据用户描述和项目上下文生成文件。信息不足时先创建保守的最小可用版本,不要臆造复杂规则。 创建时优先包含: - 项目一句话上下文 - 技术栈 - 常用命令 - 架构地图 / 代码放置规则 - 硬规则和非默认约定 - 测试和完成标准 - 安全和权限边界 - 参考文档及 Read when 触发条件 ## 审查原则 - 每一行都要回答:“删掉这行,agent 会更容易犯错吗?” - 写项目特有的、非显然的、可执行的规则 - 用精确命令替代“运行测试”“正常构建”等模糊说法 - 用文件路径和好/坏示例指向真实代码模式 - 用渐进披露承载长内容:根文件只做路由和关键约束 - 把 Global / Project / Local 三层分开,避免把个人习惯和项目事实混在同一个共享文件里 - 在 agent 反复犯同一种错误后再补规则,避免一开始写成巨型说明书 - 把确定性检查交给工具,把策略、边界和例外写给 agent - Treat instruction files as code:随项目变化审查、修剪和提交