aihero.dev的工程技能，完全可以跟着你手上现有的材料选：需求还没捋清楚的时候用 grill-with-docs，方案定下来了用 to-spec 整理规格，已经有完整规格、准备排开发的时候，就用 to-tickets 拆工单。用之前先装好对应技能，再在目标仓库里配好工单跟踪器和文档存放位置就行。
需求没定时该用哪个技能？
直接用 grill-with-docs 就行。它把需求追问和领域建模整合到一起，刚好适合核对现有规则、同步记录相关术语。
举个例子，你现在手里只有一句模糊的要求：「给待办列表加归档」。先让助手查当前现有任务的状态、列表过滤规则，再挨个确认：归档之后是不是默认隐藏、要不要保留历史记录、支不支持恢复。直接在已经装了对应技能的项目会话里输入指令：「用 Grill with Docs 帮我讨论归档规则，先核对现有行为」。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
这一阶段跑完，输出的结果就是所有已经达成共识的约定，以及还没定下来的待确认问题。如果有项目专属术语或者长期决策需要留存，再按照项目文档的现有布局更新术语表或者决策记录就行。
示例：先找规则，再问影响实现的问题
用 grill-with-docs 检查当前项目如何区分已完成和已归档。先找现有规则，再逐个问我默认列表、历史查看和恢复的约定。
结束这个阶段之前，先确认助手能完整复述所有已经敲定的规则。比如最后大家只同意隐藏归档任务，还没定历史入口的方案，就把历史入口放到未决项里留着后续讨论。
什么时候用 to-spec 整理规格？
需求全部确认完，就可以用 to-spec 把之前讨论好的结论整理成规格，存到你之前配置好的跟踪器里。要是还有业务规则没定，先回去把需求讨论完再说。
比如「归档后默认隐藏，历史仍可查看，这一版不支持恢复」这些点全部达成共识之后，就可以让 to-spec 结合之前的讨论记录和现有代码整理规格。它会自动归纳所有已经确认的结论，要是你发现需求还有没覆盖到的空白，先把空白点问清楚再让它生成内容。
审阅规格的时候，重点查清楚待解决的问题、用户能直接感知到的结果、功能范围和验证点。别只看到规格写了「支持归档」就过，还要确认里面有没有明确默认列表和历史视图的差异。
规格要能判断范围
你可以请 to-spec 把已经确认的内容拆成三类：用户目标、行为约束、本轮版本不做的内容。交接的时候，直接拿着这份规格去问另一位开发者怎么验收，看他会不会把「从列表隐藏」误理解成删除。
我之前做的课程管理项目里，直接删除和转换为草稿两个操作，也特意分开确认过各自的业务边界。
什么时候用 to-tickets 拆工单？
手里已经有明确规格、需要排期开发的时候，就用 to-tickets 切出每张都能独立验证的工单。保存之前先核对每张工单的交付标准，还有工单之间的阻塞关系对不对。
已经有过审的规格之后，直接把规格路径传给 to-tickets，让它先列好所有工单、每张的交付结果和阻塞项。比如可以先交付「归档单条任务并从默认列表隐藏」，再做「归档视图展示历史任务」。审阅的时候逐张核对，每张工单能不能演示出一个完整用户行为，对应的依赖项是不是真的会阻塞后续开发。
要是某张工单既要改归档逻辑、又要做列表展示、还要加恢复功能，直接要求按本轮的迭代范围重新切分。每张工单至少要能明确说清一个用户动作，以及一个可直接观察的运行结果。
