Files
ss-tools/.opencode/command/speckit.tasks.md
2026-05-08 18:01:49 +03:00

157 lines
6.0 KiB
Markdown

---
description: Generate an actionable, dependency-ordered tasks.md for the active Python/Svelte feature.
handoffs:
- label: Analyze For Consistency
agent: speckit.analyze
prompt: Run a cross-artifact consistency analysis for the Python/Svelte feature
send: true
- label: Implement Project
agent: speckit.implement
prompt: Start implementation in phases for the Python/Svelte 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, backend/frontend scope, verification stack, and semantic constraints from `plan.md`
- Extract accepted-path and rejected-path memory from ADRs and `contracts/modules.md`
- Map entities, API payloads, UI components, and verification scenarios 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
### Python / Svelte Pathing
Prefer real repository paths such as:
**Backend (Python):**
- `backend/src/api/*.py` (FastAPI routes)
- `backend/src/core/**/*.py` (core services, task manager, auth, migration, plugins)
- `backend/src/models/*.py` (SQLAlchemy models)
- `backend/src/services/*.py` (business logic)
- `backend/src/schemas/*.py` (Pydantic schemas)
- `backend/tests/*.py` (pytest tests)
**Frontend (Svelte):**
- `frontend/src/routes/**/*.svelte` (SvelteKit pages)
- `frontend/src/lib/components/**/*.svelte` (reusable Svelte 5 components)
- `frontend/src/lib/stores/*.svelte.js` (Svelte rune stores)
- `frontend/src/lib/api/*.js` (API client modules)
- `frontend/tests/**/*.test.js` (vitest tests)
**Shared/Infrastructure:**
- `docs/adr/*.md`
- `docker/*`
- `specs/<feature>/contracts/*.md`
Do **not** generate default tasks for:
- `src/**/*.rs` or `tests/*.rs`
- `Cargo.toml`
- `cargo` commands
- MCP server/tool/resource syntax unless the feature actually introduces them
### Verification Discipline
Each story phase must end with:
- a verification task against `ux_reference.md` interpreted as the API caller, CLI operator, or Svelte UX interaction contract
- a semantic audit / verification task tied to repository validators and touched contracts
Typical verification tasks may include:
- focused `pytest backend/tests/test_<module>.py` commands
- `cd backend && pytest` (full backend suite)
- `cd frontend && npm run test` (vitest suite)
- `ruff check backend/` (Python lint)
- `cd frontend && npm run build` (Svelte build validation)
- `python3 scripts/static_verify.py` (semantic static verification)
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 report generation endpoint in backend/src/api/reports.py (RATIONALE: unified report envelope preserves task-shaped parity; REJECTED: ad-hoc per-endpoint response shapes)`
- `- [ ] T033 [US2] Add WebSocket logging handler in backend/src/core/task_manager/ws_handler.py (RATIONALE: C4/C5 flows must expose real-time log streaming; REJECTED: polling-based log retrieval)`
- `- [ ] T040 [US3] Create DashboardCard component in frontend/src/lib/components/DashboardCard.svelte (RATIONALE: @UX_STATE must cover Idle/Loading/Error/Empty; REJECTED: single-state inline rendering without recovery)`
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. In this repository, test tasks are usually expected for:
- new FastAPI endpoints / WebSocket handlers
- new plugin or service modules
- new Svelte components with `@UX_STATE` contracts
- 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 repository structure
- at least one explicit verification task protects against rejected-path regression