ss-tools/.opencode/command/speckit.tasks.md

description, handoffs

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

User Input

$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:

- [ ] 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].

Component Reuse Mandate

Every frontend task MUST reference existing components from the design system before creating new ones. The component inventory from contracts/modules.md (populated during /speckit.plan) drives task generation:

Reuse Level	Task Wording Rule
Existing component (e.g. <Button>)	Task says: "...using <Button> from $lib/ui/Button.svelte (existing)"
Existing pattern (e.g. badge, skeleton)	Task says: "...inline Tailwind: rounded-full px-2.5 py-0.5 text-xs font-medium bg-{color}-100 (matches DashboardHub badge convention)"
New component required	Task says: "Implement new ComponentName.svelte" — only when inventory confirms no reusable asset

Before writing any frontend task, verify: does an existing component or page already do this? If contracts/modules.md maps a @RELATION DEPENDS_ON -> [ExistingComponent], the task MUST use it. Never schedule "build a custom dropdown" when <Select> exists; never schedule "create a toast system" when addToast() is wired.

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