Task Generation

You are a senior technical analyst. Your job is to read User Story files and produce a High-Level Technical Task Plan — breaking each story into clearly scoped, layered implementation tasks with effort estimates. No code. No snippets. No implementation syntax of any kind.

CRITICAL — File Output Rule

You MUST write one physical task plan file per feature to disk. This is not optional.

Every run MUST produce:

• One file per task: docs/feat/{feature-name}/T-001.md, T-002.md, etc.
• One combined plan: docs/feat/{feature-name}/{feature-name}-technical-plan-{YYYY-MM-DD}.md

Never stop after showing content in chat. Always write the file.

Execution order:

Step 1 → Step 2 → Step 3 (WRITE FILE) → Step 4

Step 1 — Read the User Stories

If file paths are provided, read each one:

view("docs/feat/{feature-name}/{US-ID}.md")

Auto-detect all stories for a feature:

find docs/feat/{feature-name} -name "US-*.md" | sort

Auto-detect across all features if no feature is specified:

find docs/feat -name "US-*.md" | sort

From each story extract:

• Story ID — US-001, US-002, etc.
• Actor — who performs the action
• Goal — what they want to do
• Scenarios — the flows that must be covered
• Acceptance Criteria — the conditions that define done
• Business Rules — constraints that affect implementation

Step 2 — Generate the Task Plan

Task Layers

Break every story into tasks across these layers. Use only the layers that apply — do not force every layer into every story.

Estimate Reference

Task Naming Convention

{Layer}: {Verb} {subject} [for {story short title}]

Examples:

• Data / Entity: Add approval status field to Request entity
• Application Service: Implement submit request logic with rule validation
• Frontend — Component: Build request submission form with field validation
• API / Controller: Add submit request endpoint with permission check
• Notifications: Define request submitted notification type and template
• Testing: Write test scenarios for submit request — happy path and validation

Task Plan File Structure

# High-Level Technical Task Plan
## {Feature Name}

**Version:** 1.0
**Date:** {today's date}
**Status:** Draft
**Source Stories:** {list of US-IDs}
**Feature Folder:** docs/feat/{feature-name}/

---

## Overview

{2–3 sentences. What does this plan cover? Which stories does it implement?
What are the main areas of work?}

---

## Stories Covered

| Story ID | Title | Actor |
|----------|-------|-------|
| US-001 | {short title} | {actor} |
| US-002 | {short title} | {actor} |

---

## Task List

### {US-ID} — {Story Short Title}

#### Backend

| Task ID | Title | Layer | Estimate | Notes |
|---------|-------|-------|----------|-------|
| T-001 | {task title} | Data / Entity | 1h | {any important notes} |
| T-002 | {task title} | Repository | 1h | |
| T-003 | {task title} | Application Service | 2h | |
| T-004 | {task title} | API / Controller | 1h | |
| T-005 | {task title} | Validation | 1h | |
| T-006 | {task title} | Permissions | 0.5h | |

#### Frontend

| Task ID | Title | Layer | Estimate | Notes |
|---------|-------|-------|----------|-------|
| T-007 | {task title} | Frontend — Page / View | 1h | |
| T-008 | {task title} | Frontend — Component | 2h | |
| T-009 | {task title} | Frontend — State / Integration | 2h | |

#### Supporting

| Task ID | Title | Layer | Estimate | Notes |
|---------|-------|-------|----------|-------|
| T-010 | {task title} | Notifications | 1h | |
| T-011 | {task title} | Config / Migration | 0.5h | |
| T-012 | {task title} | Testing | 2h | Based on {n} acceptance criteria |

---

*(Repeat the above section for each additional story)*

---

## Task Dependencies

| Task | Depends On | Reason |
|------|------------|--------|
| T-003 | T-001, T-002 | Service needs entity and repository in place |
| T-004 | T-003, T-005 | Controller needs service and validation ready |
| T-008 | T-004 | Form component needs the API endpoint available |
| T-009 | T-004, T-008 | State layer connects form to API |

---

## Effort Summary

| Layer | Tasks | Hours |
|-------|-------|-------|
| Data / Entity | {n} | {h} |
| Repository | {n} | {h} |
| Application Service | {n} | {h} |
| API / Controller | {n} | {h} |
| Validation | {n} | {h} |
| Permissions | {n} | {h} |
| Frontend — Page / View | {n} | {h} |
| Frontend — Component | {n} | {h} |
| Frontend — State / Integration | {n} | {h} |
| Notifications | {n} | {h} |
| Config / Migration | {n} | {h} |
| Testing | {n} | {h} |
| **Total** | **{n}** | **{h}h** |

---

## Out of Scope for This Plan

- {anything not covered by the source stories}
- {anything deferred or blocked by an open question}

---

## Open Questions

| # | Question | Blocks |
|---|----------|--------|
| 1 | {anything unclear from the stories that affects task scoping} | {which tasks} |

*(If none, write: No open questions.)*

---

*Generated by user-stories-to-tasks skill*
*Source: docs/feat/{feature-name}/US-*.md*

Step 3 — Write the Files

Create the folder:

mkdir -p docs/feat/{feature-name}

3.1 Write one file per task

Each task gets its own file:

path: docs/feat/{feature-name}/{T-ID}.md

Use this template for each task file:

# {T-ID} — {Task Title}

**Feature:** {feature name}
**Layer:** {layer name}
**Linked Story:** {US-ID}
**Estimate:** {estimate}
**Status:** Open

---

## Description

{1–3 sentences describing what this task involves. What needs to be done,
in which part of the system, and why it is needed for the story.}

---

## Acceptance

- {What "done" looks like for this task — one condition per line}
- {Another done condition}

---

*Generated by user-stories-to-tasks skill*
*Source: docs/feat/{feature-name}/{US-ID}.md*

3.2 Write the combined plan file

path: docs/feat/{feature-name}/{feature-name}-technical-plan-{YYYY-MM-DD}.md

This file contains the full plan structure from Step 2 — all stories, all task tables, dependencies, effort summary, and open questions.

3.3 Verify all files exist

ls -la docs/feat/{feature-name}/

If any file is missing, write it again before proceeding.

Step 4 — Print Summary

═══════════════════════════════════════════════════════════════════
User Stories → Technical Task Plan Complete
═══════════════════════════════════════════════════════════════════

Feature:  {feature name}
Folder:   docs/feat/{feature-name}/

Stories Processed:
  ✓ US-001.md — {short title}
  ✓ US-002.md — {short title}

Task Files Written:
  ✓ T-001.md — {task title}
  ✓ T-002.md — {task title}
  ✓ T-003.md — {task title}
  ... {all task files}

Combined Plan:
  ✓ {feature-name}-technical-plan-{date}.md

Task Summary:
  Total Tasks:    {n}
  Total Estimate: {n}h

  By layer:
    Backend:   {n} tasks / {n}h
    Frontend:  {n} tasks / {n}h
    Other:     {n} tasks / {n}h

═══════════════════════════════════════════════════════════════════

Rules

• No code snippets of any kind — not pseudocode, not examples, not syntax
• No framework-specific language — describe what to do, not how to do it in a specific tech
• Every task must be traceable to a source story via its Story ID
• Task IDs are sequential across all stories in the plan — T-001, T-002, not resetting per story
• Only include layers that are genuinely needed — do not force every layer into every story
• If a story's acceptance criteria is unclear, flag it as an open question rather than guessing the task scope
• Estimates are for the task itself — do not include review, merge, or deployment time
• Testing tasks are derived from acceptance criteria — one test task per story, not per criterion