141 lines
4.8 KiB
Markdown
141 lines
4.8 KiB
Markdown
---
|
|
description: Generate an actionable, dependency-ordered tasks.md for the active Rust MCP feature.
|
|
handoffs:
|
|
- label: Analyze For Consistency
|
|
agent: speckit.analyze
|
|
prompt: Run a cross-artifact consistency analysis for the Rust MCP feature
|
|
send: true
|
|
- label: Implement Project
|
|
agent: speckit.implement
|
|
prompt: Start implementation in phases for the Rust MCP 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, tool payloads, runtime evidence, 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
|
|
|
|
### Rust / MCP Pathing
|
|
|
|
Prefer real repository paths such as:
|
|
|
|
- `src/server/*.rs`
|
|
- `src/services/**/*.rs`
|
|
- `src/models/*.rs`
|
|
- `src/semantics/*.rs`
|
|
- `tests/*.rs`
|
|
- `docs/adr/*.md`
|
|
- `specs/<feature>/contracts/*.md`
|
|
|
|
Do **not** generate default tasks for:
|
|
|
|
- `backend/` or `frontend/`
|
|
- `*.py`
|
|
- `.svelte`
|
|
- `__tests__/`
|
|
|
|
### Verification Discipline
|
|
|
|
Each story phase must end with:
|
|
|
|
- a verification task against `ux_reference.md` interpreted as the caller/operator interaction contract
|
|
- a semantic audit / verification task tied to repository validators and touched contracts
|
|
|
|
Typical verification tasks may include:
|
|
|
|
- focused `cargo test` commands
|
|
- `cargo test --all-targets --all-features -- --nocapture`
|
|
- `cargo clippy --all-targets --all-features -- -D warnings`
|
|
- `python3 scripts/static_verify.py`
|
|
|
|
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 deterministic tool envelope mapping in src/server/tools.rs (RATIONALE: preserve task-shaped MCP parity; REJECTED: ad-hoc per-tool response shapes)`
|
|
- `- [ ] T033 [US2] Add runtime evidence verification in tests/server_protocol.rs (RATIONALE: C4/C5 flows must expose belief markers; REJECTED: relying on manual log inspection only)`
|
|
|
|
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 MCP tools/resources
|
|
- new query/mutation flows
|
|
- 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 Rust crate structure
|
|
- at least one explicit verification task protects against rejected-path regression
|