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

description, handoffs

description	handoffs
Create or update the feature specification from a natural-language feature description for the Rust MCP repository.	label agent prompt Build Technical Plan speckit.plan Create a Rust MCP implementation plan for the active feature label agent prompt send Clarify Spec Requirements speckit.clarify Clarify specification requirements true

User Input

$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