---
description: Generate an actionable, dependency-ordered tasks.md for the active ss-tools feature (Python backend + Svelte frontend).
handoffs:
  - label: Analyze For Consistency
    agent: speckit.analyze
    prompt: Run a cross-artifact consistency analysis for the feature
    send: true
  - label: Implement Project
    agent: speckit.implement
    prompt: Start implementation in phases for the feature
    send: true
---

## User Input

```text
$ARGUMENTS
```

You **MUST** consider the user input before proceeding (if not empty).

## Outline

1. **Setup**: Run `.specify/scripts/bash/check-prerequisites.sh --json` from repo root and parse `FEATURE_DIR` and `AVAILABLE_DOCS`.
   - `FEATURE_DIR` under `specs/<feature>/` is the only valid output location for `tasks.md`.

2. **Load design documents** from `FEATURE_DIR`:
   - **Required**: `plan.md`, `spec.md`, `ux_reference.md`
   - **Optional**: `data-model.md`, `contracts/`, `research.md`, `quickstart.md`
   - **Required when referenced by plan**: ADR artifacts under `docs/adr/` or feature-local planning docs

3. **Build the task model**:
   - Extract user stories and priorities from `spec.md`
   - Extract repository structure, tool/resource scope, verification stack, and semantic constraints from `plan.md`
   - Extract accepted-path and rejected-path memory from ADRs and `contracts/modules.md`
   - Map entities to stories
   - Generate tasks grouped by story and ordered by dependency
   - Validate that no task schedules an ADR-rejected path

4. **Generate `tasks.md`** using `.specify/templates/tasks-template.md` as the structure:
   - Phase 1: Setup
   - Phase 2: Foundational work
   - Phase 3+: one phase per user story in priority order
   - Final phase: polish and cross-cutting verification
   - Every task must use the strict checklist format and include exact file paths
   - Write the final document to `FEATURE_DIR/tasks.md`, never to `.kilo/plans/` or other side folders

5. **Report** the generated path and summarize:
   - total task count
   - task count per user story
   - parallel opportunities
   - story-level independent verification criteria
   - inherited ADR/guardrail coverage

## Task Generation Rules

### Story Organization

Tasks MUST be grouped by user story so each story can be implemented and verified independently.

### Required Format

Every task MUST follow:

```text
- [ ] T001 [P] [US1] Description with exact file path
```

Rules:
1. `- [ ]` checkbox is mandatory
2. sequential task IDs (`T001`, `T002`, ...)
3. `[P]` only for truly parallelizable tasks
4. `[USx]` required only for user-story phases
5. exact file paths required in the description

### ss-tools Pathing

Prefer real repository paths such as:
- `backend/src/api/*.py` (FastAPI routes)
- `backend/src/core/**/*.py` (business logic, plugins)
- `backend/src/models/*.py` (SQLAlchemy models)
- `backend/src/services/*.py` (service layer)
- `backend/src/schemas/*.py` (Pydantic schemas)
- `backend/tests/*.py` (pytest)
- `frontend/src/routes/**/*.svelte` (SvelteKit pages)
- `frontend/src/lib/components/*.svelte` (UI components)
- `frontend/src/lib/stores/*.js` (Svelte stores)
- `frontend/src/lib/api/*.js` (API client)
- `frontend/src/lib/**/__tests__/*.test.js` (vitest)
- `docs/adr/*.md` (architecture decisions)
- `specs/<feature>/contracts/*.md` (design contracts)

Do NOT generate default tasks for Rust/MCP paths (`src/server/`, `*.rs`, `cargo`).

### Verification Discipline

Each story phase must end with:
- a verification task against `ux_reference.md` interpreted as the operator/caller interaction contract
- a semantic audit / verification task tied to repository validators and touched contracts

Typical verification tasks may include:
- `cd backend && source .venv/bin/activate && python -m pytest backend/tests/test_*.py -v`
- `cd backend && python -m ruff check .`
- `cd frontend && npm run lint`
- `cd frontend && npm run test`
- `cd frontend && npm run build`

Only include the commands that are truly required by the feature scope.

### Contract and ADR Propagation

If a task implements or depends on a guarded contract, append a concise guardrail summary derived from `@RATIONALE` and `@REJECTED`.

Examples:
- `- [ ] T021 [US1] Implement dashboard migration service in backend/src/core/migration/service.py (RATIONALE: full scan ensures consistency; REJECTED: incremental-only update leaves stale entries)`
- `- [ ] T033 [US2] Add WebSocket event handler in frontend/src/lib/stores/taskDrawer.js (RATIONALE: real-time feedback prevents polling; REJECTED: interval polling for task status)`

If no safe executable task wording exists because the accepted path is still unclear, stop and emit `[NEED_CONTEXT: target]`.

### Test Tasks

Tests are optional only when the feature truly has no new verification surface. Test tasks are usually expected for:
- new API endpoints
- new database models or queries
- C4/C5 semantic contracts
- runtime evidence / belief-state behavior
- rejected-path regression coverage

### Decision-Memory Validation Gate

Before finalizing `tasks.md`, verify that:
- blocking ADRs are inherited into setup/foundational or downstream story tasks
- no task text schedules a rejected path
- story tasks remain executable within the actual Python/Svelte project structure
- at least one explicit verification task protects against rejected-path regression