to-issues

name	to-issues
description	Break a plan or feature into vertical-slice GitHub issues. Each issue is a tracer bullet: independently deliverable, testable, and mergeable. Use when decomposing work from ROADMAP.md, a PRD, or a conversation.

Plan to Issues

Turn the current plan into a set of vertical-slice GitHub issues ready for implementation.

Workflow

1. Understand the Plan

If the plan is vague, interview the user briefly (max 3 questions) to clarify scope and boundaries. Check ROADMAP.md and existing issues for overlap.

2. Slice Vertically

Each issue must be a tracer bullet: a thin vertical slice that:

• Touches all necessary layers (domain → application → infrastructure → entry point)
• Is independently testable and mergeable
• Delivers observable value (even if small)

Anti-pattern: Horizontal slices like "add all domain entities", "add all tests", "wire DI for everything". These delay feedback.

3. Order by Dependencies

Number issues in implementation order. Earlier issues should unblock later ones. First issue should be the thinnest possible end-to-end path (the tracer bullet).

4. Format Each Issue

## Title

feat(scope): concise description

## Description

What this slice delivers and why it matters independently.

## Acceptance Criteria

- [ ] Criterion using Should/When language
- [ ] Tests pass: `{test command}`
- [ ] Lint passes: `{lint command}`

## Technical Notes

- Affected files/modules
- Key design decisions (reference ADRs if applicable)
- Dependencies on other issues (if any)

5. Present for Approval

Show the full issue list as a numbered table before creating anything:

| # | Title | Scope | Depends On |
|---|-------|-------|------------|
| 1 | feat(sdk-dotnet): add ISecretProvider port | Domain | n/a |
| 2 | feat(sdk-dotnet): implement AWS SSM provider | Infra | #1 |

Wait for user confirmation. Then create issues via gh issue create.

Rules

• Max 8 issues per plan: if more are needed, split into phases
• Each issue ≤ 1 day of work: if larger, slice thinner
• Use Conventional Commit format for titles
• Reference ADRs in technical notes when relevant
• Label issues with needs-triage unless user specifies otherwise