Initial commit

templates/checklist-template.md

@@ -0,0 +1,13 @@
+# Quality Checklist: {{FEATURE}}
+
+*Created: {{DATE}}*
+
+Reviewer-owned quality gate for the written requirements — these boxes judge
+the spec text, not the implementation. Check an item only after actually
+reviewing it; add domain-specific items freely.
+
+- [ ] Every user story has at least one concrete acceptance scenario
+- [ ] Each requirement is verifiable (a test could pass or fail it)
+- [ ] Success criteria are measurable without naming technologies
+- [ ] All clarification markers are resolved or consciously accepted
+- [ ] Assumptions state the chosen default AND what was ruled out

templates/commands/speckit.implement.md

@@ -0,0 +1,13 @@
+# /speckit.implement — execute the task list
+
+Gate: tasks.md exists for the current feature (run `python3 speckit.py status`
+to confirm); if it is missing, stop and run /speckit.tasks first.
+
+1. Read spec.md, plan.md and tasks.md of the current feature.
+2. Work through tasks.md strictly top to bottom, phase by phase: implement
+   each task test-first, and flip its checkbox to `- [x]` only after its
+   verification actually passed.
+3. Never renumber or delete tasks; append newly discovered work as new
+   checkboxes at the end of the fitting phase.
+4. When all boxes are checked, run `python3 speckit.py check` and report the
+   result to the user together with how to run the built feature.

templates/commands/speckit.plan.md

@@ -0,0 +1,13 @@
+# /speckit.plan — create the implementation plan
+
+Gate: the current feature must already have a completed spec.md — read it
+first; if it is missing or full of unresolved markers, stop and say so.
+
+1. Run `python3 speckit.py plan` — it seeds `plan.md` next to the spec
+   (the command refuses to run while spec.md is missing).
+2. Fill plan.md from the spec: the concrete stack in ## Technical Context,
+   the intended source layout in ## Structure, and each significant choice
+   with rationale and rejected alternative in ## Decisions.
+3. Check every decision against memory/constitution.md; justify or simplify
+   anything that violates an article.
+4. Run `python3 speckit.py status` to confirm the phase is recorded.

templates/commands/speckit.specify.md

@@ -0,0 +1,18 @@
+# /speckit.specify — create a feature specification
+
+The user gives you a feature description. Turn it into a reviewable spec:
+
+1. Run `python3 speckit.py specify "<the description>"` from the project —
+   or, when the user provides the brief as a file, pass its path instead
+   (add `--name "<short feature name>"` when the file starts with metadata).
+   This creates `specs/NNN-slug/spec.md` and makes it the current feature.
+2. Open that spec.md and replace every placeholder section with real content:
+   prioritized user stories with acceptance scenarios (## User Stories),
+   verifiable numbered requirements and key entities (## Requirements),
+   measurable technology-agnostic outcomes (## Success Criteria), and the
+   defaults you chose for open points (## Assumptions).
+3. Where you truly cannot decide without the user, leave a marker of the form
+   NEEDS CLARIFICATION plus the question in square brackets — at most 3.
+4. Finish by running `python3 speckit.py check` and resolving any findings.
+
+Do not make technology choices here — the spec says what and why, never how.

templates/commands/speckit.tasks.md

@@ -0,0 +1,13 @@
+# /speckit.tasks — break the plan into executable tasks
+
+Gate: the current feature needs a filled plan.md — read spec.md and plan.md
+before writing anything; if plan.md is missing, stop and say so.
+
+1. Run `python3 speckit.py tasks` — it seeds `tasks.md` for the current
+   feature (refused while plan.md is missing).
+2. Replace the placeholder checkboxes with real tasks: dependency-ordered
+   phases under ## Phases, one checkbox per task, exact file paths in each
+   description, user-story order preserved (P1 first).
+3. Every task must be small enough to verify on its own; note which tasks
+   are independent enough to run in parallel.
+4. Run `python3 speckit.py status` to see the open-task count.

templates/constitution-template.md

@@ -0,0 +1,30 @@
+# {{PROJECT}} Constitution
+
+*Adopted: {{DATE}} — version 1.0.0*
+
+Standing principles every feature in this project must respect. Specs, plans
+and tasks are checked against these articles; a violation needs an explicit,
+written justification or the work does not proceed.
+
+## Article I — Simplicity
+
+The smallest design that satisfies the spec wins. New layers, wrappers or
+abstractions require a demonstrated need, not an anticipated one.
+
+## Article II — Tests Prove Behavior
+
+No behavior ships without a test that failed before the behavior existed.
+
+## Article III — Minimal Blast Radius
+
+Touch only what the feature requires. Leave unrelated code, files and
+interfaces unchanged.
+
+## Article IV — Honest Artifacts
+
+Specs record what is actually decided; open questions are marked, not hidden.
+Task checkboxes reflect verified reality, not intentions.
+
+## Amendments
+
+Record changes here with date, version bump and one-line rationale.

templates/plan-template.md

@@ -0,0 +1,33 @@
+# Implementation Plan: {{FEATURE}}
+
+*Created: {{DATE}}*
+
+Turn the spec into concrete technical decisions. Stay minimal: prefer the
+simplest structure that satisfies the spec, and justify anything that isn't.
+
+## Technical Context
+
+Language/runtime, dependencies, storage, testing approach, target platform,
+and any performance or scale constraints. Unknowns become research notes here
+— resolve them before writing tasks.
+
+- Language:
+- Dependencies:
+- Storage:
+- Testing:
+
+## Structure
+
+The intended source layout: directories, modules, and where new code lands.
+
+```
+(project tree sketch)
+```
+
+## Decisions
+
+Each significant choice with its one-line rationale and the alternative that
+was rejected. Anything that adds complexity needs a justification tied to a
+requirement.
+
+- D1: … — because …

templates/spec-template.md

@@ -0,0 +1,43 @@
+# Feature Specification: {{FEATURE}}
+
+*Created: {{DATE}}*
+
+> Original request: {{DESCRIPTION}}
+
+Anything genuinely undecided gets an inline marker: the words NEEDS CLARIFICATION
+plus the open question, wrapped in square brackets. Keep at most 3 of them — pick
+a sensible default for everything else and record it under Assumptions.
+
+## User Stories
+
+Describe who wants what and why. At least one story with priority P1; each story
+must be independently testable.
+
+### Story 1 — (P1)
+
+As a …, I want …, so that ….
+
+**Acceptance:** Given …, when …, then ….
+
+## Requirements
+
+Numbered, verifiable statements of what the feature must do. Name the key
+entities (data the feature reads or writes) at the end.
+
+- R1: The system must …
+
+**Entities:** …
+
+## Success Criteria
+
+Measurable, technology-agnostic outcomes that tell you the feature works
+(counts, durations, rates — things you can check without knowing the stack).
+
+- S1: …
+
+## Assumptions
+
+Defaults chosen for anything the request left open, plus explicit scope
+boundaries (what this feature deliberately does not cover).
+
+- A1: …

templates/tasks-template.md

@@ -0,0 +1,25 @@
+# Tasks: {{FEATURE}}
+
+*Created: {{DATE}}*
+
+Dependency-ordered, checkable work items derived from the spec and plan.
+Work top to bottom; a phase starts only when the one before it is done.
+Replace the placeholder tasks below with real ones — keep the checkbox format,
+one task per line, exact file paths in the description.
+
+## Phases
+
+### Setup
+
+- [ ] T1: Prepare project scaffolding and test harness
+- [ ] T2: Create data structures / entities from the spec
+
+### Implementation
+
+- [ ] T3: Implement Story 1 happy path (test first)
+- [ ] T4: Implement edge cases and error handling for Story 1
+- [ ] T5: Wire the feature into the existing entry points
+
+### Polish
+
+- [ ] T6: Documentation touch-ups and final full test run