Minion

Minion Skills

给 Agent 一套可控执行系统。覆盖 7 个核心技能，让 Agent 从"黑盒执行"变成"有边界、有记录、有闭环"的执行系统。

minion-core minion-bot minion-prd-issues minion-fullstack minion-tests minion-git-commit minion-release
↓ 向下滚动
01 / SYSTEM

系统定位与工作方式

Agent 执行约束系统，人类按现场灵活调整，Agent 必须按规则执行。

🎯 定位

这是一套 Agent 执行约束系统，不是人类流程管控系统。人类可按现场灵活调整；Agent 必须按规则执行。当人类明确授权走捷径，Agent 执行并记录偏离原因。

⚡ 基础原则

安全优先：先遵守 minion-bot 红线。
交付优先：流程与交付冲突时，优先完成任务，再补最小记录。
分级流程：小任务走轻流程，复杂任务走标准闭环。

👤 关键决策归人类

目标确认、范围取舍、上线批准、风险接受。人类不需要被流程束缚，但上述节点建议始终保留。

💡 核心价值

提高交付确定性（不是只追求速度）
保证过程可审计、可回滚、可接力
让 Agent 负责执行，人类在关键阶段做审核与决策

⚠️ 优先级关系
1minion-bot（红线）
2领域技能（prd-issues / fullstack / tests / git-commit / release）
3minion-core（入口与阅读顺序）
02 / SKILLS

七个技能的职责边界

每个技能有明确的职责范围，协同工作形成完整的研发闭环。

Skill 核心职责 典型输出 不负责
minion-core 定义读取顺序与冲突裁决 统一执行入口 业务细节实现
minion-bot 定义安全边界与行为红线 风险可控执行 产品需求决策
minion-prd-issues 把模糊需求结构化 PRD、术语表、Issue、`issue-meta` 代码实现
minion-fullstack 研发实现与上下文回写 代码变更、`dev/bug` 字段补全 需求评审、测试判定
minion-tests 多通道验证与缺陷回流 测试报告、失败证据、Bug 回流 业务修复代码
minion-git-commit 标准化提交动作 commit/push/可选 PR 部署发布执行
minion-release 标准化发布与上线执行 发布证据、健康检查、回滚记录 业务开发与需求拆解
03 / COMBOS

研发组合总览 A-G

七种组合按场景切换，适用于不同的任务类型和复杂度。

组合 B（直做 + 最小验证）是推荐默认选项，在速度与质量之间取得平衡。小任务用 A/B；复杂任务用 C/D；故障用 E；巡检用 F；上线用 G。

A

极速直做

小改动、目标清晰、当天闭环
fullstack → git-commit
成本
低
速度
最高
追溯
低
B

直做 + 最小验证

中小改动，需要基本质量兜底
fullstack → tests(P0) → git-commit
成本
低-中
速度
高
追溯
中
C

轻需求拆解

需求略模糊，但规模不大
prd-issues(轻) → fullstack → tests → git-commit
成本
中
速度
中高
追溯
中高
D

标准功能闭环

跨人协作、跨端开发、需完整审计
prd-issues(全) → fullstack → tests → git-commit
成本
中-高
速度
中
追溯
高
E

缺陷快修闭环

线上故障、测试失败、回归破坏
tests/人工报错 → fullstack(bug) → tests(复测) → git-commit
成本
中
速度
高
追溯
中高
F

无人值守回归

CI、夜间巡检、定时质量监控
tests(unattended) → 缺陷回流 → E
成本
中
速度
高(人工低)
追溯
中高
G

发布上线闭环

需要实际部署/发版（Web/移动端/小程序）
A/B/C/D/E → minion-release
成本
中
速度
中高
追溯
高

4.1 组合 A：极速直做

需求明确、改动小、无跨团队依赖时的轻量组合。

📋 触发条件

  • 需求明确
  • 改动小
  • 无跨团队依赖

🔄 步骤

  • 人类确认目标与完成标准
  • minion-fullstack 直接实现
  • minion-git-commit 提交

👤 关键审核点

  • 是否允许跳过测试
  • 是否允许直接推送

⚠️ 风险与控制

  • 风险：遗漏隐性回归
  • 控制：提交前人工快速自测关键路径

4.2 组合 B：直做 + 最小验证 ★ 推荐默认

功能改动不大，但有用户影响，需要基础质量保证。

📋 触发条件

  • 功能改动不大，但有用户影响
  • 需要基础质量保证

🔄 步骤

  • minion-fullstack 开发
  • minion-tests 执行 P0 核心场景
  • minion-git-commit 提交

👤 关键审核点

  • 确认 P0 场景是否覆盖业务核心
  • 确认是否可上线或继续补测

⚠️ 风险与控制

  • 风险：P1/P2 问题未覆盖
  • 控制：高风险变更时升级到 C 或 D

4.3 组合 C：轻需求拆解

需求描述不够清晰，任务规模中等。

📋 触发条件

  • 需求描述不够清晰
  • 任务规模中等

🔄 步骤

  • minion-prd-issues 轻澄清
  • 形成简版任务上下文
  • minion-fullstack 实现
  • minion-tests 验证
  • minion-git-commit 收口

👤 关键审核点

  • 确认"做什么/不做什么"
  • 确认验收标准

⚠️ 风险与控制

  • 风险：边界仍有歧义
  • 控制：保留 1 个 Gate

4.4 组合 D：标准功能闭环

跨端（server/cms/app）或多人接力，需要明确追溯与审计。

📋 触发条件

  • 跨端或多人接力
  • 需要明确追溯与审计

🔄 步骤

  • minion-prd-issues 全流程
  • minion-fullstack 按任务开发
  • minion-tests 回归
  • minion-git-commit 提交并按需创建 PR

👤 关键审核点

  • Gate 1：PRD 是否定稿
  • Gate 2：Issue 拆分是否可执行
  • 发布前：是否接受残余风险

⚠️ 风险与控制

  • 风险：流程成本上升
  • 控制：仅在复杂任务启用

4.5 组合 E：缺陷快修闭环

线上故障、回归失败、用户投诉可复现问题。

📋 触发条件

  • 线上故障
  • 回归失败
  • 用户投诉可复现问题

🔄 步骤

  • 从 minion-tests FAIL 或人工反馈进入
  • 建立 bug 上下文
  • minion-fullstack 最小修复
  • minion-tests 复测
  • minion-git-commit 提交

👤 关键审核点

  • 是否先止血再完善
  • 是否需要热修复路径

⚠️ 风险与控制

  • 风险：只修表象未修根因
  • 控制：要求回写 root_cause 与 fix_scope

4.6 组合 F：无人值守回归

需要持续质量监控，团队希望降低人工巡检成本。

📋 触发条件

  • 需要持续质量监控
  • 团队希望降低人工巡检成本

🔄 步骤

  • minion-tests 按计划 unattended 执行
  • 自动产出报告并回流缺陷
  • 人类按优先级将问题拉入 E 处理

👤 关键审核点

  • 设定告警阈值与处理 SLA
  • 决定哪些 FAIL 立即处理

⚠️ 风险与控制

  • 风险：告警噪音过高
  • 控制：分级过滤 P0/P1 立即处理

4.7 组合 G：发布上线闭环 ✨ 新增

已完成功能开发并确认可发布，需要真实执行部署、上架或小程序提审。

📋 触发条件

  • 已完成功能开发并确认可发布
  • 需要真实执行部署、上架或小程序提审

🔄 步骤

  • 先完成 A/B/C/D/E 任一研发闭环
  • minion-release 执行目标平台发布
  • 产出发布证据、健康检查结果与回滚目标
  • 若发布失败，按回滚清单执行并记录

👤 关键审核点

  • production 环境是否批准继续执行
  • 是否接受当前残余风险并正式对外

⚠️ 风险与控制

  • 风险：发布参数缺失或环境差异导致失败
  • 控制：Preflight + 一次性补齐变量 + 明确回滚目标
04 / DECISION

如何选择组合

按顺序判断，快速匹配最适合的研发组合。

🎯 决策规则
1是否是故障修复？→E
2是否定时/无人值守巡检？→F
3是否需要实际部署/发版？→+G
4是否跨端、跨人、需完整追溯？→D
5需求是否模糊？→C
6是否需要最小质量兜底？→B
7其余小任务→A
↕ 降级与升级规则

降级：人类要求"先做完"时
D → C → B → A

升级：风险提升时
A/B → C/D（影响面变大、需求变更频繁）

进入上线窗口：可追加 G
A/B/C/D/E → +G

Gate 与 issue-meta 启用策略

组合Gate 策略
A / B / E默认无 Gate，口头确认即可
C建议 1 个 Gate（验收标准确认）
D建议 2 个 Gate（PRD 确认 + Issue 清单确认）
F无 Gate，按阈值与告警策略执行
Gproduction 建议 1 个 Gate（发布前继续确认）

📋 issue-meta 字段责任

domain.* + 部分 dev.*

补全 dev.author/dev.sql/dev.platform；bug 修复补 bug.*

写 test.scenarios；失败生成 bug 块

不依赖 issue-meta；发布参数以发布指令与项目配置为准

05 / HUMAN

关键阶段的人类职责

人类不需要被流程束缚，但以下节点建议始终保留。

🎯

目标确认

要解决什么问题，成功标准是什么

⚖️

范围取舍

现在做什么，不做什么

⚠️

风险接受

是否接受已知残余问题

🚀

上线批准

是否允许发布

📋

优先级判断

FAIL/bug 的处理顺序

✨ 总结

这套 SKILL 的核心价值是：把 Agent 从"黑盒执行"变成"有边界、有记录、有闭环"的执行系统。流程不是一条路，而是 A-G 组合按场景切换；人类在关键阶段审核和决策，确保从研发到发布都可控且可交付。

B（速度与质量平衡）

A / B

C / D

E

F

G

周度复盘只看三项：按期交付率、回归稳定性、修复时长