从组织审计到任务创建
手动完成这项工作需要半天时间：阅读一份冗长的审计报告，决定哪些内容应该归为一组，为每个任务编写优先级和完成定义，然后将其输入到跟踪系统中。本技能负责读取和输入工作。决策权仍然在您手中。
步骤 1：先询问再行动
在一则消息中询问并等待回复：
- 哪个组织（CLI 别名）？确认不是客户的生产组织，除非约定允许在那里进行只读扫描。
- 任务放在哪里？ClickUp（哪个列表）或 GitHub（哪个仓库）。检查对应的 MCP 服务器是否已连接；如果未连接，则停止并说明如何连接。
- 任务由谁负责？指定负责人姓名，或者保持未分配。
- 有什么要排除的？有些发现是已知且已接受的。现在说明可以避免后续的噪音。
步骤 2：审计
node audit.js --org <别名> --out ./out
生成 out/findings.md 和 out/findings.json。只读操作：每个调用都是查询或列表。
步骤 3：构建任务
node to-tasks.js out/findings.json
生成 out/tasks.json：每种发现类型和严重程度对应一个任务，每个受影响的组件作为一个检查项，长组拆分为每批 25 个，包含优先级、工作量、标签和验收标准。
步骤 4：与用户一起审查
以表格形式显示任务列表：键、标题、优先级、工作量、检查项数量。然后应用脚本无法判断的逻辑：
- 合并或拆分，如果分组方式与团队的工作方式不匹配。
- 删除用户在步骤 1 中说要排除的发现。
- 将看似微小但实际上并非如此的问题标记为重要（例如，一个拥有“修改所有数据”权限的集成用户既是安全发现，也是变更控制发现）。
- 在团队有自己的完成定义时重写验收标准。
在用户确认列表正确之前，不要创建任何内容。
步骤 5：创建
通过已连接的 MCP 服务器创建每个已审批的任务，或者对于 GitHub 使用 node create-issues.js --repo owner/name（先使用 --dry-run 预览），包含标题、描述、优先级、标签、检查列表（ClickUp 检查列表或 GitHub 正文中的任务列表）和验收标准。将每个已创建的任务 URL 记录回 out/tasks.json 的 url 字段下。
然后报告：创建了多少个任务，在哪里创建的，以及从步骤 2 到最后一个任务创建所花费的时间。
规则
- 审计绝不会写入组织。
- 未经列表批准，不得创建任何任务。
- 没有任何客户名称会离开组织文件夹。
- 如果任务系统调用失败，停止，报告哪些任务已创建、哪些未创建，并且不要盲目重试。