원클릭으로
to-issues
Quebra um plano ou PRD em issues independentes com tracer-bullet vertical slices.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Quebra um plano ou PRD em issues independentes com tracer-bullet vertical slices.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use this skill whenever the user is building or scaffolding a new Flutter or Dart mobile app, adding any Flutter feature, screen, page, view model, use case, repository, or API/backend call, setting up Flutter push notifications or deep links, or mapping/refactoring an existing Flutter project toward a layered clean architecture — EVEN WHEN the user never names the architecture, rx_notifier, MVVM, clean architecture, get_it, dio, drift, or go_router. It applies the moment the work touches Flutter app structure: a request like "add a login screen", "fetch data from this endpoint", "create a settings feature", "wire up FCM", "open this screen from a notification", or "clean up my Flutter project" is in scope. This skill is THE way to produce Flutter code in this codebase shape: rx_notifier Controller view models, AbstractUseCase with Either<AppError,T> error handling, I*Repository interface/impl pairs, a tiered dio gateway, get_it dependency injection, drift TTL cache, and go_router navigation. Prefer it over a
Knowledge graph semântico da codebase via MCP. Mapeia arquitetura, analisa blast-radius de mudanças e faz code review com até 8x menos tokens. Usa Tree-sitter (24 linguagens) + SQLite.
Mantém uma knowledge base persistente no Obsidian seguindo o pattern Karpathy LLM Wiki — ingest de sources, query sobre wiki compilado, lint de saúde. Dispara quando o usuário pede "ingest", "alimenta o wiki", "atualiza wiki", "consulta wiki", "lint wiki", "/wiki-ingest", "/wiki-query", "/wiki-lint", "que sabemos sobre X", "compila X no wiki", "adiciona ao wiki", ou ao salvar uma nova source em References/.
Analisa projetos Stitch e sintetiza design system semântico em arquivos DESIGN.md.
Transforma ideias vagas de UI em prompts polidos e otimizados para Stitch.
Design system e style guide configurável para projetos frontend. Use SEMPRE que criar componentes, páginas ou UI em React/Next/Angular/Vue.
| name | to-issues |
| description | Quebra um plano ou PRD em issues independentes com tracer-bullet vertical slices. |
| source | vendored |
| upstream | https://github.com/mattpocock/skills |
| license | MIT |
| added | "2026-05-16T00:00:00.000Z" |
| vendored | "2026-06-05T00:00:00.000Z" |
Break a plan into independently-grabbable issues using vertical slices (tracer bullets).
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 an issue reference (issue number, URL, or path) as an argument, fetch it from the issue tracker 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. Issue titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
Break the plan into tracer bullet issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
Slices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.
- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests) - A completed slice is demoable or verifiable on its own - Prefer many thin slices over few thick onesPresent the proposed breakdown as a numbered list. For each slice, show:
Ask the user:
Iterate until the user approves the breakdown.
For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. These issues are considered ready for AFK agents, so publish them with the correct triage label unless instructed otherwise.
Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
## ParentA reference to the parent issue on the issue tracker (if the source was an existing issue, otherwise omit this section).
A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
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 here and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
Or "None - can start immediately" if no blockers.
Do NOT close or modify any parent issue.