busya/ss-tools
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

tasks ready

Browse Source
This commit is contained in:
busya
2026-05-08 18:01:49 +03:00
parent d8df1fff59
commit bdd376595c
32 changed files with 3243 additions and 229 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
.opencode/command/speckit.specify.md
View File

@@ -1,9 +1,9 @@
---
description: Create or update the feature specification from a natural-language feature description for the Rust MCP repository.
description: Create or update the feature specification from a natural-language feature description for the Python/Svelte repository.
handoffs:
- label: Build Technical Plan
agent: speckit.plan
prompt: Create a Rust MCP implementation plan for the active feature
prompt: Create a Python/Svelte implementation plan for the active feature
- label: Clarify Spec Requirements
agent: speckit.clarify
prompt: Clarify specification requirements
@@ -39,38 +39,41 @@ The feature description is the text passed to `/speckit.specify`.
- `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.
5. Generate `ux_reference.md` as an **interaction reference** for API callers, CLI/operator flows, Svelte UX states, result envelopes, warnings, and recovery behavior.
6. Write `spec.md` focused on **what** the user/operator needs and **why**, not how the Python/FastAPI backend or Svelte frontend 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 domain language appropriate for this repository: API callers (REST/WebSocket), CLI operators, Svelte UI users, task runners, data migration operators, Git integration users.
- Avoid leaking implementation details such as FastAPI route names, SQLAlchemy models, Svelte component names, or exact file-level refactors.
- 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.
- The default project structure is a web application with `backend/src/` (Python) and `frontend/src/` (Svelte). Assume this unless the feature explicitly changes it.
- Do not assume Rust, MCP server, cargo, or `src/*.rs` conventions 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.
- `ux_reference.md` is mandatory. For this repository it covers both:
- **API/interaction reference** for backend callers (REST endpoints, WebSocket messages, CLI commands)
- **Svelte UX reference** for frontend flows (when the feature has a UI component)
- Capture:
- caller/operator persona
- happy-path invocation flow
- result envelope expectations
- caller/operator/end-user persona
- happy-path invocation flow (API requests, CLI commands, or UI interactions)
- result envelope expectations (JSON response shapes, CLI output, UI feedback)
- warning/degraded states
- failure recovery guidance
- canonical terminology
- Only include UI-specific `@UX_*` guidance when the feature truly has a user interface component.
- Include `@UX_STATE`, `@UX_FEEDBACK`, `@UX_RECOVERY`, `@UX_REACTIVITY` guidance when the feature introduces Svelte components.
## 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
- no stale Rust/MCP assumptions unless the feature explicitly needs them
- compatibility with the Python/FastAPI backend and Svelte frontend surface
- measurable success criteria
- explicit edge cases and recovery paths
- decision-memory readiness for downstream planning