90 lines
3.8 KiB
Markdown
90 lines
3.8 KiB
Markdown
---
|
|
description: Create or update the feature specification from a natural-language feature description for the Rust MCP repository.
|
|
handoffs:
|
|
- label: Build Technical Plan
|
|
agent: speckit.plan
|
|
prompt: Create a Rust MCP implementation plan for the active feature
|
|
- label: Clarify Spec Requirements
|
|
agent: speckit.clarify
|
|
prompt: Clarify specification requirements
|
|
send: true
|
|
---
|
|
|
|
## User Input
|
|
|
|
```text
|
|
$ARGUMENTS
|
|
```
|
|
|
|
You **MUST** consider the user input before proceeding (if not empty).
|
|
|
|
## Outline
|
|
|
|
The feature description is the text passed to `/speckit.specify`.
|
|
|
|
1. Generate a concise short name (2-4 words) for the feature branch.
|
|
2. Check existing branches/spec directories and run `.specify/scripts/bash/create-new-feature.sh --json ...` exactly once.
|
|
- This step is the source of truth for the feature lifecycle.
|
|
- It MUST create and checkout the git branch `NNN-short-name` when git is available.
|
|
- It MUST create `specs/NNN-short-name/` and initialize `spec.md` there.
|
|
- Treat the returned `SPEC_FILE` path as authoritative and derive `FEATURE_DIR` from it.
|
|
3. Load these sources before writing the spec:
|
|
- `.specify/templates/spec-template.md`
|
|
- `.specify/templates/ux-reference-template.md`
|
|
- `.specify/memory/constitution.md`
|
|
- `README.md`
|
|
- `docs/SEMANTIC_PROTOCOL_COMPLIANCE.md`
|
|
- relevant `docs/adr/*` when the feature clearly touches an existing architectural lane
|
|
4. Create or update the following artifacts inside `FEATURE_DIR` only:
|
|
- `spec.md`
|
|
- `ux_reference.md`
|
|
- `checklists/requirements.md`
|
|
5. Generate `ux_reference.md` as an **interaction reference** for MCP callers, CLI/operator flows, result envelopes, warnings, and recovery behavior.
|
|
6. Write `spec.md` focused on **what** the user/operator needs and **why**, not how the Rust crate will implement it.
|
|
7. Validate the spec against a requirements-quality checklist and iterate until major issues are resolved.
|
|
|
|
## Specification Rules
|
|
|
|
- Use domain language appropriate for this repository: MCP callers, tools, resources, runtime evidence, workspace flows, operator recovery, semantic contracts.
|
|
- Avoid leaking implementation details such as module names, crates, file-level refactors, or exact Rust APIs.
|
|
- Use `[NEEDS CLARIFICATION: ...]` only for truly blocking product ambiguities. Maximum 3 markers.
|
|
- Prefer informed defaults grounded in repository context over unnecessary clarification.
|
|
- Do not assume web-app, backend/frontend, or Svelte UI flows unless the feature actually introduces them.
|
|
- Do not write feature outputs to `.kilo/plans/`, `.kilo/reports/`, or any path outside `specs/<feature>/...`.
|
|
|
|
## UX / Interaction Reference Rules
|
|
|
|
- `ux_reference.md` is mandatory, but for this repository it is usually an interaction-reference artifact rather than a screen-design artifact.
|
|
- Capture:
|
|
- caller/operator persona
|
|
- happy-path invocation flow
|
|
- result envelope expectations
|
|
- warning/degraded states
|
|
- failure recovery guidance
|
|
- canonical terminology
|
|
- Only include UI-specific `@UX_*` guidance when the feature truly has a user interface component.
|
|
|
|
## Quality Validation
|
|
|
|
Generate `FEATURE_DIR/checklists/requirements.md` and ensure it validates:
|
|
|
|
- no implementation leakage into `spec.md`
|
|
- no stale Python/Svelte assumptions unless the feature explicitly needs them
|
|
- compatibility with the Rust MCP/task-shaped tool surface
|
|
- measurable success criteria
|
|
- explicit edge cases and recovery paths
|
|
- decision-memory readiness for downstream planning
|
|
|
|
If unresolved clarification markers remain, present them in a compact, high-impact format and stop for user input.
|
|
|
|
## Completion Report
|
|
|
|
Report:
|
|
|
|
- branch name
|
|
- feature directory under `specs/`
|
|
- `spec.md` path
|
|
- `ux_reference.md` path
|
|
- checklist path and status
|
|
- readiness for `/speckit.clarify` or `/speckit.plan`
|