agent-sort

原文涵盖的主题

• 技能分类
• 何时使用
• 不可协商的规则
• 输出
• 分类模型
• 证据来源
• 并行审查轮次
• 核心工作流

当仓库需要项目特定的 ECC 表面而非默认完整安装时，使用此技能。 目标不是猜测"什么感觉有用"。目标是根据实际代码库中的证据对 ECC 组件进行分类。 项目只需要 ECC 的子集，完整安装过于嘈杂 仓库技术栈明确，但无人希望逐个手动筛选技能 团队希望获得基于 grep 证据而非主观意见的可重复安装决策 需要将始终加载的日常工作流表面与可搜索的库/参考表面分离 仓库已偏离至错误的语言、规则或钩子集，需要清理 以当前仓库为事实来源，而非通用偏好 每个 DAILY 决策必须引用具体的仓库证据 LIBRARY 并不意味着"删除"；它意味着"保持可访问但不默认加载" 不要安装当前仓库无法使用的钩子、规则或脚本 优先使用 ECC 原生表面；不要引入第二个安装系统 按顺序生成以下工件： 1. DAILY 清单 2. LIBRARY 清单 3. 安装计划 4. 验证报告 5. 可选的路由器（如果项目需要） 仅使用两个分类： DAILY 应为该仓库的每个会话加载 与仓库的语言、框架、工作流或操作者表面强匹配 LIBRARY 保留有用，但不值得默认加载 应通过搜索、路由器技能或选择性手动使用保持可访问 在进行任何分类之前，使用仓库本地证据： 文件扩展名 包管理器和锁文件 框架配置 CI 和钩子配置 构建/测试脚本 导入和依赖清单 明确描述技术栈的仓库文档 有用的命令包括： 如果并行子代理可用，将审查分为以下轮次： 1. 代理 分类 agents/ 2. 技能 分类 skills/ 3. 命令 分类 commands/ 4. 规则 分类 rules/ 5. 钩子和脚本 分类钩子表面、MCP 健康检查、辅助脚本和操作系统兼容性 6. 额外项 分类上下文、示例、MCP 配置、模板和指导文档 如果子代理不可用，则按顺序运行相同的轮次。 在分类任何内容之前，确定实际技术栈： 使用的语言 使用的框架 主要包管理器 测试技术栈 代码检查/格式化技术栈 部署/运行时表面 已存在的操作者集成 对于每个候选表面，记录： 组件路径 组件类型 建议的分类 仓库证据 简短理由 使用此格式： 提升至 DAILY 当： 仓库明确使用匹配的技术栈 组件足够通用，有助于每个会话 仓库已依赖相应的运行时或工作流 降级至 LIBRARY 当： 组件与技术栈不匹配 仓库可能以后需要，但不是每天 它增加了上下文开销而无直接相关性 将分类转化为行动： DAILY 技能 -> 安装或保留在 .claude/skills/ DAILY 命令 -> 仅当仍然有用时保留为显式 shim DAILY 规则 -> 仅安装匹配的语言集 DAILY 钩子/脚本 -> 仅保留兼容的 LIBRARY 表面 -> 通过搜索或 skill-library 保持可访问 如果仓库已使用选择性安装，则更新该计划而非创建另一个系统。 如果项目需要可搜

这里只展示节选，请以完整原文和当前要求为准。