split-spec

name	split-spec
description	Split this repository's SPEC.md into thin, ordered, TDD-ready Markdown task slices. Use when the user asks to split, slice, break down, or create implementation task files from SPEC.md for use with the tdd-task skill.

Split Spec

Turn SPEC.md into small implementation slices that can be executed with the tdd-task skill.

Inputs

• SPEC.md
• .agents/skills/tdd-task/SKILL.md
• .agents/skills/tdd-task/references/project.md

Stop and ask only when SPEC.md leaves behavior ambiguous enough that a slice would encode a guess.

Output

Create one Markdown file per slice:

slices/
  01-<slug>.md
  02-<slug>.md

Each slice file must be self-contained and use this shape:

# Slice NN: <name>

## Goal
...

## User Story Slices
- US-NB: ...
- US-NF: ...

## Scope
- ...

## Acceptance Criteria
- ...

## TDD Notes
- Red: ...
- Green: ...
- Verify: ...

## Dependencies
- ...

Slicing Rules

• Prefer thin vertical slices that deliver behavior a user or test can observe.
• Keep each slice small enough for one focused TDD pass.
• Do not create layer-only slices unless the slice is a necessary, testable platform increment.
• Put schema, backend, frontend, and tests in the same slice when that is the smallest useful behavior.
• Preserve every user story from SPEC.md as one or more implementation story slices.
• Split stories by implementation ownership when needed, especially backend/API/database versus frontend/UI behavior.
• Use stable suffixes for split story IDs, such as US-5B for backend, US-5F for frontend, and US-23D for detail/history UI when one frontend story spans multiple surfaces.
• Do not duplicate the same split story ID across files.
• Keep each split story phrased as an outcome for that slice, not as a copy of the parent story.
• Keep dependencies minimal and explicit.
• Write German user-facing text with Umlaute.
• Describe the intended workflow only; do not mention replaced approaches or migration history.

TDD Fit

Every slice must tell the executor where the first failing test should live and which verification command from tdd-task/references/project.md is relevant.

Use these defaults unless the codebase suggests a narrower command:

• Backend or database behavior: ./mvnw -Dtest=<TestClass> test, then ./mvnw test when risk justifies it.
• Frontend behavior: add or use a frontend test harness before claiming automated frontend coverage, then run npm run build from frontend/.
• Cross-cutting verification: ./mvnw verify once backend, frontend tests, and frontend build are wired together.

Final Check

Before finishing:

• Confirm every parent US-* from SPEC.md is represented by at least one split story ID.
• Confirm every split story ID appears in exactly one slice file.
• Confirm each slice has observable acceptance criteria.
• Confirm no slice depends on future behavior without listing that dependency.