Initial commit
This commit is contained in:
Zhongwei Li
305
commands/cmd.task.md.deprecated
Normal file
305
commands/cmd.task.md.deprecated
Normal file
@@ -0,0 +1,305 @@
|
||||
---
|
||||
description: Generate atomic implementation tasks from high-level plans, providing coding agents with clear, actionable work items.
|
||||
---
|
||||
|
||||
# Interactive Implementation Task Generator
|
||||
|
||||
Decompose technical plans into atomic, executable tasks following Test-Driven Development.
|
||||
|
||||
# Stage 1: Load Context
|
||||
|
||||
**Actions**:
|
||||
1. Run `git rev-parse --abbrev-ref HEAD` to get current branch
|
||||
2. Verify `.specimin/plans/{branch}/` exists. If not: `Error: Specimin not initialized. Run /init first.`
|
||||
3. Read `.specimin/plans/{branch}/plan.md` (high-level plan)
|
||||
4. Read `.specimin/plans/{branch}/spec.md` (feature specification)
|
||||
|
||||
**Context Extraction Goals**:
|
||||
- Component/module names and boundaries
|
||||
- Data structures and models
|
||||
- Integration points with existing code
|
||||
- Technical decisions (libraries, patterns, architectures)
|
||||
- Key function responsibilities
|
||||
|
||||
**Error Handling**: If plan.md missing: `Error: No plan.md found for branch '{branch}'. Run /feature.plan first.`
|
||||
|
||||
# Stage 2: Analyze Plan Structure
|
||||
|
||||
Identify blocking ambiguities that prevent concrete task generation:
|
||||
- **Dependencies**: Unclear integration points?
|
||||
- **Technical choices**: Multiple valid approaches without clear direction?
|
||||
- **Error handling**: Unaddressed edge cases or failure modes?
|
||||
- **Data flow**: Unclear inputs/outputs between components?
|
||||
|
||||
**Identify 0-5 critical ambiguities only**. Do NOT ask about:
|
||||
- Coding style, naming conventions, or trivial details
|
||||
- Implementation details you can reasonably infer
|
||||
- Non-blocking uncertainties
|
||||
|
||||
**Vague Plan Detection**: If plan lacks component structure, data flow, or function-level detail:
|
||||
```
|
||||
Warning: Plan too vague to generate atomic tasks.
|
||||
Missing: Component breakdown, data structures, integration points, function responsibilities.
|
||||
Add detail to plan.md, then rerun /cmd.implement.
|
||||
```
|
||||
|
||||
**Checkpoint**: Verify you understand all technical decisions and component boundaries before proceeding.
|
||||
|
||||
# Stage 3: Clarify Ambiguities (If Needed)
|
||||
|
||||
If ambiguities found, ask focused questions (2 concrete options + "Custom"). Maximum 0-5 questions (prefer fewer). Focus on plan-level decisions, not code details. Wait for user response.
|
||||
|
||||
If no ambiguities, skip to Stage 4.
|
||||
|
||||
# Stage 4: Generate Atomic Tasks
|
||||
|
||||
Decompose plan into **function-level atomic tasks** following TDD.
|
||||
|
||||
## Atomicity Definition
|
||||
|
||||
**Atomic task = one file or one clear unit of work**, aligned with code structures:
|
||||
- **Sequence**: One file/module (schema, controller, service, migration)
|
||||
- **Branch**: Decision logic (validation, error handling, conditional flows)
|
||||
- **Loop**: Iteration logic (batch processing, collection operations)
|
||||
|
||||
**Examples**:
|
||||
- ✅ Good: "Create User schema in lib/app/accounts/user.ex"
|
||||
- ❌ Too broad: "Implement authentication" → Split into specific files
|
||||
- ❌ Too granular: "Add variable for user ID" → Implementation detail
|
||||
|
||||
## Task Format
|
||||
|
||||
```markdown
|
||||
- [ ] T{XXX} [P?] {Verb + what + exact file path} (R{XX})
|
||||
```
|
||||
|
||||
**Elements**:
|
||||
- `- [ ]`: Checkbox for completion tracking
|
||||
- `T001, T002...`: Sequential task ID across all phases
|
||||
- `[P]`: Optional parallel marker (different files, no dependencies)
|
||||
- `Verb`: Create, Write, Implement, Verify, Add, Update
|
||||
- `(R01)`: Spec requirement mapping
|
||||
|
||||
## TDD Task Pattern (MANDATORY)
|
||||
|
||||
**Use for every feature/function**:
|
||||
```markdown
|
||||
- [ ] TXXX Write test for [capability] expecting [specific behavior] in test/[path]_test.exs (RXX)
|
||||
- [ ] TXXX Run test and confirm RED (fails with expected error message)
|
||||
- [ ] TXXX Implement [function] with minimal code to pass in lib/[path].ex (RXX)
|
||||
- [ ] TXXX Run test and confirm GREEN (passes)
|
||||
```
|
||||
|
||||
**Rules**:
|
||||
1. Test task always precedes implementation task
|
||||
2. Explicit verification tasks for RED and GREEN phases
|
||||
3. No exceptions - this is a constitution mandate
|
||||
|
||||
## Complete TDD Examples
|
||||
|
||||
**Example 1: Simple CRUD Feature (User Creation)**
|
||||
```markdown
|
||||
## Phase 1: Foundation
|
||||
- [ ] T001 Create migration for users table in priv/repo/migrations/20250106_create_users.exs (R01)
|
||||
- [ ] T002 [P] Create User schema in lib/app/accounts/user.ex (R01)
|
||||
- [ ] T003 Write test for user creation expecting {:ok, %User{}} in test/app/accounts_test.exs (R02)
|
||||
- [ ] T004 Run test and confirm RED (Accounts.create_user/1 undefined)
|
||||
- [ ] T005 Implement create_user/1 in lib/app/accounts.ex (R02)
|
||||
- [ ] T006 Run test and confirm GREEN
|
||||
|
||||
## Phase 2: Validation
|
||||
- [ ] T007 Write test for email validation expecting {:error, changeset} in test/app/accounts_test.exs (R03)
|
||||
- [ ] T008 Run test and confirm RED (validation not enforced)
|
||||
- [ ] T009 Add email validation to User changeset in lib/app/accounts/user.ex (R03)
|
||||
- [ ] T010 Run test and confirm GREEN
|
||||
```
|
||||
|
||||
**Example 2: Complex Integration (Payment Processing)**
|
||||
```markdown
|
||||
## Phase 1: External Service Setup
|
||||
- [ ] T001 [P] Create Stripe client module in lib/app/payments/stripe_client.ex (R01)
|
||||
- [ ] T002 [P] Add Stripe configuration to config/config.exs (R01)
|
||||
- [ ] T003 Write test for charge creation expecting {:ok, %Charge{}} in test/app/payments_test.exs (R02)
|
||||
- [ ] T004 Run test and confirm RED (Payments.create_charge/2 undefined)
|
||||
- [ ] T005 Implement create_charge/2 with Stripe API call in lib/app/payments.ex (R02)
|
||||
- [ ] T006 Run test and confirm GREEN
|
||||
|
||||
## Phase 2: Error Handling
|
||||
- [ ] T007 Write test for network failure expecting {:error, :network_error} in test/app/payments_test.exs (R03)
|
||||
- [ ] T008 Run test and confirm RED (error not caught)
|
||||
- [ ] T009 Add retry logic with exponential backoff in lib/app/payments.ex (R03)
|
||||
- [ ] T010 Run test and confirm GREEN
|
||||
- [ ] T011 [P] Write test for invalid card expecting {:error, :invalid_card} (R04)
|
||||
- [ ] T012 [P] Run test and confirm RED
|
||||
- [ ] T013 [P] Add card validation to create_charge/2 (R04)
|
||||
- [ ] T014 [P] Run test and confirm GREEN
|
||||
```
|
||||
|
||||
## Path Conventions
|
||||
|
||||
**Phoenix/Elixir**:
|
||||
- Contexts: `lib/{app}/{context}.ex`
|
||||
- Schemas: `lib/{app}/{context}/{schema}.ex`
|
||||
- LiveViews: `lib/{app}_web/live/{feature}_live.ex`
|
||||
- Controllers: `lib/{app}_web/controllers/{name}_controller.ex`
|
||||
- Tests: `test/{app}/{context}_test.exs`
|
||||
- Migrations: `priv/repo/migrations/{timestamp}_{desc}.exs`
|
||||
|
||||
**For other projects**: Use conventions from plan.md.
|
||||
|
||||
## Phase Organization
|
||||
|
||||
Group tasks into phases from plan.md. Standard phases:
|
||||
1. **Foundation**: Migrations, schemas, contexts, core tests
|
||||
2. **Integration**: External services, APIs, third-party libraries
|
||||
3. **Interface**: LiveViews, controllers, user-facing components
|
||||
4. **Polish**: Validation, edge cases, error handling
|
||||
|
||||
**Dependency rules**: migrations → schemas → contexts → interfaces
|
||||
|
||||
**Parallel opportunities**: Mark `[P]` when tasks touch different files and have no dependencies.
|
||||
|
||||
**Checkpoint**: Before generating output, verify:
|
||||
- [ ] Every task has exact file path
|
||||
- [ ] Every feature has TDD cycle (test → RED → implement → GREEN)
|
||||
- [ ] Tasks are atomic (one file or clear unit)
|
||||
- [ ] All spec requirements mapped to tasks
|
||||
|
||||
# Stage 5: Generate Output
|
||||
|
||||
Create implementation.md with this structure:
|
||||
|
||||
```markdown
|
||||
# Implementation Tasks: {Feature Name}
|
||||
|
||||
**Overview**: {1-2 sentence summary}
|
||||
**Total Tasks**: {N} | **Phases**: {M} | **Estimated Completion**: {Time estimate}
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: {Name}
|
||||
**Dependencies**: None
|
||||
**Parallel Opportunities**: {Count of [P] tasks}
|
||||
|
||||
- [ ] T001 {Task description with file path} (R01)
|
||||
[All phase 1 tasks following TDD pattern]
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: {Name}
|
||||
**Dependencies**: Phase 1 complete
|
||||
**Parallel Opportunities**: {Count}
|
||||
|
||||
- [ ] T007 {Task description with file path} (R04)
|
||||
[All phase 2 tasks]
|
||||
|
||||
---
|
||||
|
||||
## Spec Requirement Mapping
|
||||
- R01: Tasks T001, T002
|
||||
- R02: Tasks T003-T006
|
||||
[Complete mapping]
|
||||
|
||||
---
|
||||
|
||||
## Critical Dependencies
|
||||
{Sequential dependencies that block other work}
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
{Integration points, assumptions, clarifications}
|
||||
```
|
||||
|
||||
Present draft: `I've generated {N} tasks in {M} phases. Reply "Approved" to save, or provide feedback.`
|
||||
|
||||
Wait for approval. Support iteration. Never merge test and implementation tasks during revision.
|
||||
|
||||
# Stage 6: Save Tasks
|
||||
|
||||
Once approved:
|
||||
1. Run `git rev-parse --abbrev-ref HEAD`
|
||||
2. Save to `.specimin/plans/{branch}/implementation.md`
|
||||
3. Confirm: `Implementation tasks saved to .specimin/plans/{branch}/implementation.md`
|
||||
4. **Proceed immediately to Stage 7**
|
||||
|
||||
Only save after explicit approval.
|
||||
|
||||
# Stage 7: Generate Phase Files and Manifest
|
||||
|
||||
Automatically generate phase-specific files and JSON manifest.
|
||||
|
||||
## Step 1: Create Directory
|
||||
```bash
|
||||
mkdir -p .specimin/plans/{branch}/tasks/
|
||||
```
|
||||
|
||||
## Step 2: Parse Implementation.md
|
||||
|
||||
1. Read `.specimin/plans/{branch}/implementation.md`
|
||||
2. Identify phase boundaries: `## Phase N:` headers
|
||||
3. Extract for each phase:
|
||||
- Phase number and name
|
||||
- Dependencies and parallel opportunities
|
||||
- All task lines (`- [ ] TXXX ...`)
|
||||
4. For each task capture:
|
||||
- Task ID (T001, T002...)
|
||||
- Full description
|
||||
- Phase number
|
||||
- Parallel marker ([P] present?)
|
||||
|
||||
## Step 3: Generate Phase Files
|
||||
|
||||
For each phase, create `phase_N.md`:
|
||||
|
||||
**File**: `.specimin/plans/{branch}/tasks/phase_1.md`
|
||||
**Content**:
|
||||
```markdown
|
||||
# Phase N: {Phase Name}
|
||||
|
||||
**Dependencies**: {From implementation.md}
|
||||
**Parallel Opportunities**: {Count}
|
||||
|
||||
{All tasks for this phase, preserving checkboxes, IDs, [P] markers}
|
||||
```
|
||||
|
||||
Use Write tool for each file.
|
||||
|
||||
## Step 4: Generate JSON Manifest
|
||||
|
||||
**Schema** (4 fields per task):
|
||||
```json
|
||||
[
|
||||
{
|
||||
"id": "T001",
|
||||
"description": "Create User schema in lib/app/accounts/user.ex (R01)",
|
||||
"phase": 1,
|
||||
"status": "pending"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
**Escaping**: `"` → `\"`, `\` → `\\`, `\n` → `\\n`, `\t` → `\\t`
|
||||
|
||||
Save to `.specimin/plans/{branch}/tasks/manifest.json`
|
||||
|
||||
## Step 5: Edge Cases
|
||||
|
||||
- **Single phase**: Still create `phase_1.md` (not `phase.md`)
|
||||
- **Empty phases**: Skip file creation, note in confirmation
|
||||
- **No phases**: Display error: `Error: Could not detect phases. Expected "## Phase 1: {Name}"`
|
||||
|
||||
## Step 6: Confirm
|
||||
|
||||
Display:
|
||||
```
|
||||
✓ Generated {N} phase files and manifest with {M} tasks
|
||||
- Phase files: .specimin/plans/{branch}/tasks/phase_1.md through phase_{N}.md
|
||||
- Manifest: .specimin/plans/{branch}/tasks/manifest.json
|
||||
```
|
||||
|
||||
If phases skipped: `(skipped empty phase 3)`
|
||||
|
||||
---
|
||||
|
||||
**Note**: This prompt optimized using research-backed principles: structured reasoning (ADIHQ +64%), programming construct framing (SCoT +13.79%), TDD verification (Reflexion 91%), token efficiency (-39%), and explicit checkpoints for quality.
|
||||
Reference in New Issue
Block a user