Structure implementation tasks using vertical slicing with TDD discipline. Use when creating task mappings, generating implementation tasks, or when you see "vertical slice", "TDD", "test first", "cycle structure", or "testable increment".
Structures implementation tasks using vertical slicing with TDD discipline for testable, incremental delivery.
/plugin marketplace add deepeshBodh/human-in-loop/plugin install deepeshbodh-humaninloop-plugins-humaninloop@deepeshBodh/human-in-loopThis skill inherits all available tools. When active, it can use any tool Claude has access to.
CYCLE-STRUCTURE.mdSLICE-IDENTIFICATION.mdTransform requirements into implementation tasks organized as vertical slices with strict TDD discipline. Each slice (called a "cycle") delivers observable, testable value and follows test-first principles.
Wrong (horizontal slicing):
Phase 1: All models
Phase 2: All services
Phase 3: All endpoints
Phase 4: All tests
Right (vertical slicing):
Cycle 1: User creation (model + service + endpoint + test)
Cycle 2: User authentication (model + service + endpoint + test)
Cycle 3: User profile management (model + service + endpoint + test)
Every cycle structures tasks so tests come before implementation:
Cycle N: [Feature]
├── Task N.1: Write failing test
├── Task N.2: Implement to pass
├── Task N.3: Refactor and verify
└── Task N.4: Demo and validate
Foundation Cycles (sequential)
├── C1: Core data model + basic CRUD
├── C2: Authentication framework
└── C3: API infrastructure
Feature Cycles (parallel-eligible)
├── C4: [P] Search functionality
├── C5: [P] Filtering
├── C6: [P] Export feature
└── C7: Notifications (depends on C4)
Each cycle must be testable at multiple levels:
See SLICE-IDENTIFICATION.md for detailed heuristics on identifying good vertical slices from requirements.
A good vertical slice:
| Boundary Signal | Action |
|---|---|
| Distinct user action | New cycle |
| Different acceptance scenario | May be new cycle or same cycle |
| Shared infrastructure need | Foundation cycle |
| Optional enhancement | Feature cycle (can parallelize) |
See CYCLE-STRUCTURE.md for detailed cycle formatting and examples.
### Cycle N: [Vertical slice description]
> Stories: US-X, US-Y
> Dependencies: C1, C2 (or "None")
> Type: Foundation | Feature [P]
- [ ] **TN.1**: Write failing E2E test for [behavior] in tests/e2e/test_[name].py
- [ ] **TN.2**: Implement [component] to pass test in src/[path]/[file].py
- [ ] **TN.3**: Refactor and verify tests pass
- [ ] **TN.4**: Demo [behavior], verify acceptance criteria
**Checkpoint**: [What should be observable/testable after this cycle]
| Marker | Meaning |
|---|---|
[P] | Parallel-eligible (no dependencies blocking) |
[US#] | Maps to user story number |
[EXTEND] | Extends existing file (brownfield) |
[MODIFY] | Modifies existing code (brownfield) |
Purpose: Establish infrastructure that ALL features depend on.
Characteristics:
Identification: Ask "Could ANY user story start without this?" If no, it's foundation.
Purpose: Deliver user value incrementally.
Characteristics:
Identification: Ask "Does this deliver value a user could observe?" If yes, it's a feature.
Each cycle follows the red-green-refactor pattern:
- [ ] **TN.1**: Write failing E2E test for [user action produces result] in tests/e2e/test_[feature].py
The test should:
- [ ] **TN.2**: Implement [component] to pass test in src/[path]/[file].py
Implementation should:
- [ ] **TN.3**: Refactor and verify tests pass
Refactoring should:
- [ ] **TN.4**: Demo [behavior], verify acceptance criteria
Validation should:
When a user story is well-scoped, it becomes one cycle:
US-1: As a user, I can create a task with a title
→ Cycle 1: Task creation
When a story is too large, split into multiple cycles:
US-2: As a user, I can manage my tasks (create, edit, delete, complete)
→ Cycle 2: Task creation (foundation)
→ Cycle 3: Task editing
→ Cycle 4: Task deletion
→ Cycle 5: Task completion
When stories are too small, merge into one cycle:
US-3: As a user, I can see task count
US-4: As a user, I can see completed count
→ Cycle 6: Task statistics (covers US-3 and US-4)
Before finalizing task mapping or task list:
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.