ask-gabriel

Ask Gabriel

此技能包的地图。推荐下一个技能，或指向展示完整路径的旅程。保持轻量：只有在选定路径后，才加载其他技能的正文。

阅读时机

• 起步时什么都不用读。请勿在此路由中加载 code-quality.md 和 code-structure.md 中的规则：它们本来就适用，而且下一个技能会加载它们。
• 准备好回复了吗？请查看 writing-style.md 中的简洁语言和 Unslop 部分。跳过它们，推荐内容就会像技能包术语一样晦涩。
• 不确定完整路径是什么样？请查看下方对应的旅程。跳过它，就可能第一步走对，第三步却走错。

旅程

每段旅程都通过技能和规则，一步步跟进一项工作；每个阶段都会说明要打开的规则以及下一步行动。它们共用一个示例领域（计费），并彼此衔接。旅程中的路径和结构优于应用现有代码，因为现有代码通常杂乱无章。只有在应用中的同类实现符合示例时，才会复制它（引用同类实现）。

工作内容	旅程
从工单到发布，基于坚实基础构建新 Feature	new-feature.md
后续改动适配现有接缝，即新变体可接入的命名扩展点（“添加 PayPal”）	follow-up-fits-the-seam.md
后续改动需要先建立接缝（先重构，再实现 Feature）	follow-up-needs-a-seam.md
从调查到修复，处理 Bug 报告	bug.md
随手记下一条以后要用的笔记	quick-note.md

了解一条规则在代码中的具体含义（前后对比、模式的目录树）：code-quality-examples.md 和 code-structure-examples.md。

入门路线

情况	从这里开始
将 main 合并到分支、更新分支，或以其他方式同步 Git，且不要求更改行为	仅同步 Git：Git 安全、冲突和合并；干净同步后即停止
明确的工单，包含 Gabriel 的工作者自我审查和主 Agent 检查循环	/gabriel-mode
不确定该用哪个技能	留在这里，查看下方说明
某项功能的工作原理、操作演练、所有权或分层结构	/how
为什么采用这种实现方式，或设计依据	/why
模糊的想法／构建前的研究	/analyze
需要先调查、尚未有人要求修复的 Bug	/analyze → /task-with-tests（可构建时）
修复 Bug	/task-with-tests
审查或评估现有代码或整个仓库，不产生差异	/analyze
持续构建，直到满足 X	/task-with-tests（默认构建方式；用户可以拒绝所有测试）
完全不编写测试地构建	/task
编码风格／这个差异是否整洁？	/review（它会应用 code-quality.md；示例见 code-quality-examples.md）。指导原则列表是 principles.md，不是技能
结构／文件夹／服务／数据形状	/analyze，然后 /task-with-tests（两者都会应用 code-structure.md；形状示例见 code-structure-examples.md）
需要一份最终可直接实施的 Linear/GitHub 工单	/write-ticket
发布分支或拉取请求	shipping.md
Linear 工单 → 构建	使用该工单运行 /task-with-tests。按照相同规则发布
对决策、方向或结构提出质疑	/grill-me
审查本地分支与 main 的差异，或审查已打开的 GitHub PR	/review
持续关注 PR，直到检查／审查发生变化	/babysit-pr，由父级负责监控并报告最新的 HEAD
在有限预算内重复审查和授权修复	/review-loop
根据当前意图评估或恢复旧 PR	/takeover-pr
选择浏览器或其他工具	优先使用 Harness 进行发现
构建屏幕／前端，或更新应用 UX 的事实来源	/task-with-tests（它会应用 user-experience.md 和 docs/design.md）
明确调用有界的审查与改进循环，优化 UI 使用路径或慢速路径	/hillclimb，仅在用户点名时使用；它会根据目标选择 UI 或性能变体。常规 UI 或提速工作沿用现有流程
用测试锁定复杂行为	/task-with-tests 会在深入讨论后提出测试，你可以拒绝所有测试。可以直接要求编写测试，或在 /review 建议锁定时表示同意。无论哪种情况，Agent 都会遵循 testing.md
验证已更改的行为，或明确要求运行所有现有测试并对正在运行的应用、迁移、端点或任务进行 QA	/verification，范围由行为和风险决定；明确要求完整验证时，会运行所有已配置的测试套件
审计、删减或清理现有测试	/test-audit（报告证据，并在删除前等待批准；活动模式涵盖整个子系统）
从 skills.sh 安装此技能包	/setup-gabriel-skills（询问技能和 AGENTS.md 的放置位置；仅在安装失败时手动复制）

构建时优先使用 /analyze，然后使用 /task-with-tests。/how 和 /why 会在说明机制或依据后停止。只推荐此映射中的技能名称；嵌套式还是一次性调用，由该技能的 SKILL.md 决定。

仅同步 Git 不会启动构建、审查或验证流程。对冲突作出实质性解决后，必须检查受影响的行为；选择这些检查并不意味着获准扩大任务范围。仓库要求的检查和用户明确提出的验证要求仍然适用。 /task 会拆分工作，并自行完成每个部分。只有用户提出要求，或接受了 /task 的行为锁定说明或 /review 的建议时，才会编写测试（testing.md）。常规编辑不编写测试。

流程

用户询问应运行哪个技能

1. 如果需求不明确，请用一句话询问用户的意图。
2. 推荐一个下一步技能，并说明接下来一两步。若有匹配的流程指南，请附上链接。
3. 只有用户明确同意（或说了“直接选一个开始”）后，才运行该技能。
4. 使用通俗易懂的语言，并展开缩写。不要使用聊天机器人式的结束语或浮夸措辞。
5. 推荐 /task、/task-with-tests、/analyze、/how 或 /why 时，说明这些技能会应用 code-quality.md 和 code-structure.md。

Agent 在工作过程中不确定

1. 将工作与某个流程指南匹配，并打开它。
2. 找到当前所处步骤，并按其指示操作：要运行的技能、要打开的规则，以及下一步行动。
3. 如果没有匹配的流程指南，请使用入门路径表，然后查看 AGENTS.md 中的技能表。如果仍不确定，请向用户问一个问题，并给出建议答案。

反面模式

• 在不使用这些供应商的应用中照搬计费供应商名称