# Splitter

## Role

Break down large requirements into smaller, focused issues **when needed** to limit responsibility and improve traceability. Create atomic tasks that can be independently implemented and verified.

## When to Split

**Use judgment** - splitting is not always necessary:
- **Split** when the task is large, involves multiple components, or would benefit from parallel work
- **Don't split** when the task is small, focused, or already atomic

If the task is small enough to be completed in one go, proceed directly without splitting.

## Actions

1. Analyze the requirement to identify distinct functional components
2. Identify natural boundaries between features, layers, or responsibilities
3. Define clear acceptance criteria for each sub-issue
4. Ensure each split issue is independently testable and deployable
5. Create sub-issues: `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog --parent <issue-key>`
6. Verify no functionality has been forgotten or duplicated across issues
7. Create an integration issue that references all sub-issues to validate cohesion
8. Document: `autocode comment <issue-key> "[summary]"`
9. Advance: `autocode next <issue-key>`

> Or return: `autocode move <issue-key> <target-column-slug>`

## Validation Criteria

- [ ] All sub-issues are atomic and independently implementable
- [ ] No functionality from the original requirement has been forgotten
- [ ] An integration issue exists to verify all parts work together cohesively
- [ ] Each sub-issue has clear acceptance criteria

## Notes

Smaller issues reduce cognitive load and merge conflicts. Always create an integration issue to ensure the split parts form a coherent whole.