القائمة
把计划、规格说明或当前对话拆解为一组示踪子弹（tracer-bullet）工单，每个工单声明其阻塞边，发布到配置好的追踪器——阻塞边可以是本地文件中的文本，也可以是真实追踪器上的原生阻塞链接。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | to-tickets |
| description | 把计划、规格说明或当前对话拆解为一组示踪子弹（tracer-bullet）工单，每个工单声明其阻塞边，发布到配置好的追踪器——阻塞边可以是本地文件中的文本，也可以是真实追踪器上的原生阻塞链接。 |
| disable-model-invocation | true |
Break a plan, spec, or conversation into a set of tickets — tracer-bullet vertical slices, each declaring the tickets that block it.
The issue tracker and triage label vocabulary should have been provided to you — run /setup-matt-pocock-skills if not.
Work from whatever is already in the conversation context. If the user passes a reference (a spec path, an issue number or URL) as an argument, fetch it and read its full body and comments.
If you have not already explored the codebase, do so to understand the current state of the code. Ticket titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy, then make the easy change."
Break the work into tracer bullet tickets.
Give each ticket its blocking edges — the other tickets that must complete before it can start. A ticket with no blockers can start immediately.
Wide refactors are the exception to vertical slicing. A wide refactor is one mechanical change — rename a column, retype a shared symbol — whose blast radius fans across the whole codebase, so a single edit breaks thousands of call sites at once and no vertical slice can land green. Don't force it into a tracer bullet; sequence it as expand–contract. First expand: add the new form beside the old so nothing breaks. Then migrate the call sites over in batches sized by blast radius (per package, per directory), each batch its own ticket blocked by the expand, keeping CI green batch to batch because the old form still exists. Finally contract: delete the old form once no caller remains, in a ticket blocked by every migrate batch. When even the batches can't stay green alone, keep the sequence but let them share an integration branch that all block a final integrate-and-verify ticket — green is promised only there.
Present the proposed breakdown as a numbered list. For each ticket, show:
Ask the user:
Iterate until the user approves the breakdown.
Publish the approved tickets. How depends on the tracker /setup-matt-pocock-skills configured — the tickets are the same either way, only the shape of the blocking edges changes:
.scratch/<feature-slug>/issues/<NN>-<slug>.md, numbered from 01 in dependency order (blockers first). Each file's "Blocked by" lists the numbers/titles it depends on. Use the per-ticket file template below — one ticket per file, never a single combined file.ready-for-agent triage label unless instructed otherwise — the tickets are agent-grabbable by construction.Work the frontier: any ticket whose blockers are all done. For a purely linear chain that means top to bottom.
Do NOT close or modify any parent issue.
What to build: the end-to-end behaviour this ticket makes work, from the user's perspective — not a layer-by-layer implementation list.
Blocked by: the numbers/titles of the tickets that gate this one, or "None — can start immediately".
Status: ready-for-agent
A reference to the parent issue on the tracker (if the source was an existing issue, otherwise omit this section).
The end-to-end behaviour this ticket makes work, from the user's perspective — not layer-by-layer implementation.
In either form, avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
Work the frontier one ticket at a time with /implement, clearing context between tickets.
提供使用 CameraX 进行 Android 相机开发的技术指导。当实现相机功能、处理异步录制生命周期、使用 CameraX 进行底层硬件互操作，或集成 ML Kit 或 Media3 特效时使用。
提供基于 Android Credential Manager API 实现已验证邮箱获取的完整工作流。使用此 skill 向 Android 应用集成安全、免 OTP 的邮箱验证流程。该 skill 利用来自 Google 等可信提供商的加密验证凭证，解决注册流程摩擦过大的问题。
提供让应用 UI 适配不同 Android 设备（手机、平板、折叠屏、笔记本、桌面、TV、Auto 和 XR）的说明。涵盖使用 Compose MediaQuery API 处理不同窗口尺寸、指针设备（如鼠标）和文本输入设备（如键盘）；使用 Navigation3 Scenes 实现多窗格布局；使用 Compose Grid 和 FlexBox API 实现随目标尺寸变化的自适应 UI 组件（如按钮）和自适应布局（含导航区——nav rails 和 nav bars）。
提供将 Android XML View 迁移到 Jetpack Compose 的结构化工作流。该 skill 详述从规划和依赖设置，到主题和布局迁移、验证及 XML 清理的分步流程。当需要在 Android 项目中把 XML View 迁移到 Jetpack Compose 时使用。它解决将旧版 XML View 的 UI 转换为现代声明式 Compose 组件、同时保持互操作性的问题。
使用此 skill 将 Jetpack Compose Styles API 集成到 Android 项目。引导你升级依赖、设置组件主题、让自定义组件可样式化，以及将现有布局属性迁移到统一样式。迁移自定义设计系统组件、用 Style 属性替换硬编码参数、使用 Modifier.styleable 处理交互状态。
学习如何安装并迁移到 Jetpack Navigation 3，以及如何实现 deep links、多个 backstack、scenes（对话框、底部表、list-detail、two-pane、supporting pane）、条件导航（如已登录导航 vs 匿名导航）、从流程返回结果、与 Hilt/ViewModel/Kotlin/View 互操作集成等功能和模式。