matt相关skill改造工作流：to-ticket

• 弃用spec-kit相关流程，太重了
  • 会有很多文件生成
    且有时候spec边界如果确认不清楚，到plan会有很多偏差，
    改造去除了task，但是流程还是太重了

使用ticket，分步骤实施，单个实施后单个验收，不耦合全部实施。

• 命令
  • npx skills add https://github.com/mattpocock/skills

个人实践

创建提示词

实施提示词

/implement 根据@plan/01-搭建.md 的## 4-首页是本次改动的计划
实施 @.scratch/home-dashboard/issues/04-home-echarts-charts.md
与上述要求一样优先参考老项目 @ecms-front-end/ ，并复用功能，不单独建轮子

原文

grilling skill，可以用来逐步追问、压测 spec 或修改边界。实际效果可以做到你说的“逐步确认修改边界”。

推荐工作流是：

Spec → Plan → Ticket → 实施 → 验收 Ticket

1. Spec
   目标是确认“做什么 / 不做什么 / 怎么验收”，不要急着讲实现。
   重点确认：

   • 页面入口、菜单入口、路由边界
   • 是否接接口，接口字段以谁为准
   • 权限、状态、异常分支
   • 明确不做项，比如本轮不做 Tab、不做动态菜单、不做占位页
   • 验收标准和命令

2. Plan
   目标是把 spec 翻译成技术方案。
   包括：

   • 影响模块
   • 采用现有哪套模式
   • 文件结构怎么放
   • 实现顺序
   • 风险点和回滚成本

3. Ticket
   目标是拆成可独立实施的垂直切片。
   每个 ticket 要能单独验证，并标清 Blocked by。这一步适合用 to-tickets。

4. 实施
   按 frontier 做，也就是先做没有 blocker 的 ticket。
   当前这种线性链路就是 01 → 02 → 03 → 04。

5. 验收 Ticket
   可以有两种做法：

   • 小需求：每个 ticket 自带验收项即可。
   • 像“静态路由与菜单”这种影响路由/壳层的需求：保留一个最终回归 ticket，比如现在的 04-static-route-menu-regression.md，统一验证登录、路由、菜单、构建命令。

我的建议是：
这个工作流作为“中等以上前端业务改造”的默认流程可行；但很小的 bug 不必走全套，直接“定位 → 修复 → 验证”更高效。

如果你想用逐步确认边界的方式，下一次可以这样下指令：

用 grilling 的方式帮我确认这个 spec 的修改边界，不要直接实施。

或者：

先 grill 这个 plan，重点追问不实施项、验收口径和依赖顺序。

这样我会先连续追问边界，等确认后再进入 plan 或 to-tickets。

其他小bug修复

很小的 bug 不必走全套，直接“定位 → 修复 → 验证”更高效。

最适合的是 diagnosing-bugs。

它本身就是“定位 → 修复 → 验证”的完整闭环，只是更严格，流程是：

建立反馈环路 → 复现并最小化 → 假设 → 定向探针 → 修复 + 回归测试 → 清理 + 复盘

对应你说的三段：

• 定位：diagnosing-bugs
  先建立能复现问题的命令、测试或脚本，再缩小触发条件，避免靠猜。
• 修复：diagnosing-bugs + 必要时 tdd
  如果有合适测试缝隙，就先写回归测试，再最小修复。
• 验证：diagnosing-bugs + code-review
  重新跑原始复现命令、回归测试、类型检查/构建，再 review 变更风险。

推荐用法：

用 .agents\skills\diagnosing-bugs 定位并修复这个问题：……

如果你希望更轻量一点，可以这样约定：

按“定位 → 修复 → 验证”处理，不走完整 hard bug 流程。

所以你的轻量 bug 工作流可以是：

diagnosing-bugs → tdd（可选）→ 修复 → 验证命令 → code-review（可选）

如果是很小的前端问题，比如“菜单高亮不对”，我建议不用全量 diagnosing-bugs 的六阶段，可以采用它的核心要求：先做一个可复现信号，再改，再用同一个信号验绿。

附录

几个相关 skill 的定位：

• diagnosing-bugs：最适合 bug、报错、行为异常、性能退化。
• tdd：适合你明确要测试先行，或 bug 有稳定测试缝隙。
• implement：适合已经有 spec/ticket，要直接实施，不是专门定位问题。
• code-review：适合修完后审 diff，找回归风险和遗漏。
• triage：适合 issue 进入开发前，判断是否信息足够、是否 ready-for-agent。