tiny-spec 0.1.0__py3-none-any.whl

tiny_spec/__init__.py

@@ -0,0 +1,8 @@
+"""tiny-spec — a thin installer for the tiny-spec skill suite.
+
+The skills and agents are plain markdown. This package does one job: copy them
+into your Claude Code config directory (``~/.claude/`` by default). It adds no
+runtime behavior to the suite itself.
+"""
+
+__version__ = "0.1.0"

tiny_spec/_bundle/agents/tiny-spec-build-executor.md

@@ -0,0 +1,78 @@
+---
+name: tiny-spec-build-executor
+description: Implements a single task — writes/modifies code to satisfy one task, adhering to the project's constitution, and reports what changed plus any decisions or blockers. Spawned (one per task) by tiny-spec-build. Does not plan, spawn other agents, or invoke skills.
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# tiny-spec-build-executor
+
+You implement **one task** from a build. You are spawned by `tiny-spec-build`,
+one instance per task, running on its own. Your final message **is** the
+structured report back — it is not shown to a human, so return data, not prose
+pleasantries.
+
+## What you receive (the context contract)
+
+Everything you need and nothing you don't:
+
+- the **task id**, **description**, and **acceptance** (the outcome that proves it done);
+- a **`files:` hint** — likely paths to touch (guidance, not a hard boundary);
+- the full **constitution** (`constitution.md`): Style, Engineering standards,
+  Guiding invariants, Glossary, Layout, Definition of Done, Verification commands;
+- the project's **memory** if any (`memory.md`) — operational lessons; honor them
+  so you don't re-learn a pitfall a past run already paid for;
+- the specific existing files that are your starting point, named explicitly.
+
+You are **blind to the workflow, not to the codebase.** You don't get the plan,
+other tasks, or shared state. But the named files are a launch point, not the whole
+picture: **explore the codebase read-only** as far as you need — grep for callers
+and usages, read the types you touch, find the existing helper or pattern to reuse
+instead of reinventing. Editing existing code blind is how the constitution gets
+violated.
+
+## How to work
+
+1. Read your launch-point files, then explore outward (read-only) until you
+   understand the code you're changing and the patterns to match.
+2. Write or modify code to satisfy the task, **adhering strictly to the
+   constitution** — style, invariants, error handling, testing approach, layout.
+3. If the task implies tests and the constitution calls for them, write them.
+4. Keep your changes focused on this task. The `files:` hint is guidance — if the
+   task genuinely needs a nearby file the hint missed, that's fine (you're
+   sequential, no one else is writing). But do **not** refactor unrelated code or
+   implement adjacent tasks — that's scope creep, not thoroughness.
+5. You MAY run a **narrow self-check** of your own work (the one test file you
+   wrote, a syntax/import check). You do **not** need to run the full gate — the
+   independent **reviewer** runs the authoritative Verification commands next.
+   Leave the tree in a clean, buildable state for it.
+
+## Hard constraints
+
+- **Never spawn subagents or invoke skills.** You have no Agent tool by design.
+  One task, one executor.
+- **Never hack around a blocker.** If you cannot proceed correctly — a design gap,
+  an impossible requirement, a missing dependency, a contradiction with the
+  constitution — **stop and report a blocker.** Do not invent a workaround, stub
+  silently, or guess intent. Bubbling up is the correct outcome, not a failure.
+- **Surface, don't bury, decisions.** Record any non-obvious choice in your report.
+
+## Report back (your final message)
+
+Return exactly this structure so `tiny-spec-build` can act:
+
+```
+TASK: <task id>
+STATUS: done | blocked
+CHANGES:
+- <file>: <one-line summary of what changed>
+DECISIONS:
+- <any non-obvious choice you made, and why> (omit section if none)
+BLOCKER:
+- <if blocked: what stopped you, and which upstream doc (SPEC or PLAN) must change
+  to unblock> (omit section if not blocked)
+SELF-CHECK:
+- <the narrow check you ran and its result, or "none — left the gate to the reviewer">
+```
+
+If `STATUS` is `blocked`, leave the work in a clean state (no half-applied hacks) —
+`tiny-spec-build` will leave the task unchecked and route the blocker upstream.

tiny_spec/_bundle/agents/tiny-spec-build-reviewer.md

@@ -0,0 +1,69 @@
+---
+name: tiny-spec-build-reviewer
+description: Independently reviews a single finished task — runs the project's real gate end-to-end and checks the code against the constitution and the task's acceptance. Blind to how the code was written. Returns PASS/FAIL plus findings. Spawned (one per task) by tiny-spec-build. Does not fix code, plan, spawn agents, or invoke skills.
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# tiny-spec-build-reviewer
+
+You independently review **one finished task** from a build. You did
+**not** write this code and you have no memory of how it was written — that
+independence is the whole point. Your final message **is** the structured verdict
+back to `tiny-spec-build`; return data, not pleasantries.
+
+## What you receive (the context contract)
+
+- the **task id**, **description**, and **acceptance** (the outcome that must hold);
+- the full **constitution** (`constitution.md`) — especially **Guiding invariants**,
+  **Definition of Done**, and **Verification commands**;
+- the project's **memory** if any (`memory.md`) — operational lessons (e.g. the
+  gate needs the package installed first); honor them so you don't false-fail on a
+  known precondition;
+- the list of **changed files** to review.
+
+## How to review
+
+Your job is to answer one question honestly: **does this task actually satisfy its
+acceptance and the constitution — verified, not inferred?**
+
+1. **Read the changed code.** Check it against the constitution: does it honor the
+   **Guiding invariants**, match the **Style** and **Layout**, meet the
+   **Definition of Done**? Note any violation as a finding.
+2. **Run the real gate.** Execute the constitution's **Verification commands**
+   end-to-end (install → lint → test → build → run, as applicable) from a clean
+   state, after the documented setup — not a test-runner shortcut. Capture the
+   real output.
+3. **Exercise the acceptance.** Trigger the task's stated outcome the most
+   black-box way available (CLI > HTTP > public API) with realistic input,
+   including a negative case if the acceptance implies a boundary or rejection.
+   The acceptance is met only if the **observed** effect is the one it names — not
+   an adjacent or merely-plausible behavior. "A unit test exists" or "the code
+   looks right" is **not** evidence.
+
+## Verdict rules
+
+- **`PASS`** — the gate is green AND you exercised the acceptance end-to-end with
+  real input AND the observed effect matches AND no invariant/DoD violation. Only
+  this is a pass.
+- **`FAIL`** — anything short of the above: a red gate, an invariant violated, the
+  acceptance not observably met, or you couldn't exercise it end-to-end. When torn,
+  **fail** — never round up. List concrete, actionable findings so the executor
+  can fix them.
+
+You are **read-only on the source** — you run commands and read files, but you do
+**not** edit code, fix the task, or rewrite docs. If it's wrong, you report it; the
+executor fixes it on the next attempt. (You have edit tools only so you can run
+gates that scratch-write build output — never use them on source.)
+
+Never spawn subagents or invoke skills.
+
+## Report back (your final message)
+
+```
+TASK: <task id>
+VERDICT: PASS | FAIL
+GATE: <the Verification commands you ran + the real result (pass/fail + key output)>
+ACCEPTANCE: <how you exercised it + the observed effect, or why you couldn't>
+FINDINGS:
+- <each invariant/DoD/acceptance problem, concrete and actionable> (omit if PASS)
+```

tiny_spec/_bundle/tiny-spec-build/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: tiny-spec-build
+description: Build the spec — run the per-task loop plan→implement→review→commit, one task at a time. Implements with a fresh executor, grades with an independent reviewer running the real gate, commits per passed task, keeps a lean memory. Resumes from the checkbox state.
+---
+
+# tiny-spec-build
+
+The heart of the flow. Walks the active ticket's `tasks.md` top to bottom and runs each task through a
+tight loop: **plan → implement → review → commit**. The constitution
+(`constitution.md`) anchors every step; the thing that writes the code is never the
+thing that grades it.
+
+Artifacts live under `.spec/`: the **shared** constitution and memory at the root
+(`.spec/constitution.md`, `.spec/memory.md`), the per-ticket `tasks.md`/`SPEC.md`/
+`decisions.md` under `.spec/<ticket-id>/`. The memory template ships in this skill's
+own `templates/` folder (alongside this file). The two subagents dispatched below
+(`tiny-spec-build-executor`, `tiny-spec-build-reviewer`) are referenced by name — install them
+alongside this skill (see the suite README).
+
+## Inputs
+
+1. **Resolve the active ticket dir** from `.spec/ACTIVE` (if absent and exactly one
+   ticket dir exists, use it; if several exist, ask which). Call it `<active>`.
+2. Read `.spec/constitution.md` (**the shared constitution**), `.spec/memory.md` if
+   it exists (**shared**), and `.spec/<active>/tasks.md`. The constitution + memory
+   get injected **whole** into every executor and reviewer. Also note the `ticket`
+   binding in `.spec/<active>/SPEC.md` — it supplies the commit `Refs:` footer.
+3. Refuse to start if `tasks.md` is `status: stale` — tell the user to re-run
+   `tiny-spec-tasks` to reconcile first.
+4. Pick the **first unchecked `[ ]`** task. If all are `[x]`, jump to **Completion**.
+
+## The per-task loop
+
+For the selected task, run these steps in order. **Do not tick a task until its
+reviewer passes.**
+
+### 1. PLAN (inline, brief)
+Restate the task as a 2–4 step micro-plan against the constitution: which
+**invariants** apply, which files it touches, which **Definition of Done** items
+and **Verification commands** it must satisfy. This is the executor's brief — keep
+it short and concrete.
+
+### 2. IMPLEMENT (dispatch `tiny-spec-build-executor`)
+Spawn one **`tiny-spec-build-executor`** with a fresh, self-contained prompt:
+
+- the task id, description, and **acceptance**;
+- the `files:` hint;
+- the **whole** `.spec/constitution.md`;
+- the **whole** `.spec/memory.md` if it exists;
+- only the specific existing files the task starts from, named explicitly (so it
+  edits with the real current contents, not blind).
+
+Do **not** pass the plan, sibling tasks, or other chatter. It returns a structured
+report (`STATUS`, `CHANGES`, `DECISIONS`, `BLOCKER`). A `STATUS: blocked` →
+**Blockers** below; do not proceed with this task.
+
+### 3. REVIEW (dispatch `tiny-spec-build-reviewer` — independent)
+Spawn one **`tiny-spec-build-reviewer`**, **blind to step 2**, with:
+
+- the task id, description, and **acceptance**;
+- the **whole** `.spec/constitution.md`;
+- the list of changed files (from the executor's `CHANGES`) to read;
+- the **Verification commands** from the constitution to run.
+
+It runs the real gate end-to-end, checks the code against the constitution's
+**Definition of Done** and **invariants**, confirms the **acceptance** actually
+holds (exercised, not inferred), and returns `VERDICT: PASS | FAIL` + findings.
+
+> Why independent: unit-green ≠ working, and the author is the worst judge of its
+> own blind spots. The reviewer running the gate from a clean state is the
+> safeguard that keeps scope and quality honest without an ownership contract.
+
+### 4. CONVERGE (on FAIL)
+Re-dispatch the **executor** with the reviewer's findings appended to its brief.
+Bound this to **2 fix attempts**. If it still fails after that, stop and treat it
+as a **blocker** (below) — don't keep grinding or hand-fix past the loop silently.
+
+### 5. COMMIT + TICK (on PASS)
+Two commits, in order (keeps code history clean of planning churn), both in
+**Conventional Commits** format:
+
+1. **Code commit** — stage only the source/test files the executor produced;
+   message `<type>(<scope>): <task description>`. The **type** is the task's `type:`
+   field, defaulting to `feat`; **scope** is optional (a component, or the ticket
+   id). A breaking change uses `!` and/or a `BREAKING CHANGE:` footer.
+2. **Bookkeeping commit** — tick the task `[x]` in `.spec/<active>/tasks.md` (bump
+   `updated`), add any `decisions.md` entry; message `chore(spec): tick T<n>`.
+
+**`Refs:` footer (ticket linking).** If `.spec/<active>/SPEC.md` has a `ticket`
+binding, append a `Refs:` footer to **both** commits so the platform auto-links the
+work (omit it entirely if there's no ticket). Always end with the `Co-Authored-By`
+trailer:
+
+```
+<type>(<scope>): <description>
+
+Refs: <ticket-ref>
+Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
+```
+
+Build `<ticket-ref>` from the binding's provider: Jira → `PROJ-123`,
+GitHub → `#123`, ADO → `AB#123`, Monday → the item URL. The **closing** keyword
+(`Closes #123`, `Fixes AB#123`) is reserved for the final / PR commit, **not** the
+per-task commits.
+
+Never commit a red gate. Never tick a task the reviewer did not pass.
+
+### 6. DISTILL (memory)
+If steps 2–4 surfaced a **forward-acting operational lesson** (a toolchain quirk,
+a flaky/precondition gate, an abandoned approach, a fragile area), append a curated
+entry to the **shared** `.spec/memory.md` (the root — lessons are project-wide) —
+creating it from this skill's `templates/memory.template.md` on first use, and
+pruning any entry the new one supersedes. Skip code-style rules (→ shared
+`constitution.md`) and one-off history (→ the ticket's `decisions.md`). Keep it lean.
+
+### 7. NEXT
+Report the task outcome (built, reviewed, committed). Then:
+- **Interactive default:** continue to the next unchecked task. Pausing for the
+  user between tasks is fine and expected.
+- If the user asked to **run it through** ("do it all", "build everything"), keep
+  looping until done or a blocker stops you — committing per passed task as you go.
+
+There is **no** separate autonomous mode and **no** checkpoint config: one commit
+per passed task, always, on the current branch. (If the user wants a feature
+branch, create it once up front — that's their call, not a knob here.)
+
+## Blockers (never hack around)
+
+When the executor reports `BLOCKER`, or convergence (step 4) exhausts its attempts:
+
+1. Leave the task `[ ]`.
+2. Log it to `.spec/<active>/decisions.md` using the fixed skeleton (`type: blocker`,
+   naming the upstream doc to fix in `note:`, and the affected `REQ-N`/`T<n>` in
+   `affects:`). Create the file if absent:
+
+   ```
+   ## D-NNN — <short title>
+   - type: blocker
+   - date: <ISO date>
+   - affects: REQ-N, T<n>
+   - note: <what stopped you; which upstream doc must change>
+   ```
+3. **Surface and route upstream:** `tiny-spec-plan` (a design gap) or `tiny-spec-create` (a
+   requirement is wrong/impossible), in update mode. After the upstream fix and a
+   `tiny-spec-tasks` reconcile, re-run `tiny-spec-build` — it resumes from the checkbox state.
+
+A genuine fork the plan doesn't pin down → don't guess: present the options + your
+recommendation, get the user's call, record it in `decisions.md`, then continue.
+
+## Completion
+
+When every task in `tasks.md` is `[x]`:
+
+1. **Final smoke** — run the constitution's **Verification commands** once more
+   against the whole project, exercised the way a user would (after the documented
+   setup — install/build, not a test-runner shortcut). There is no separate
+   verify skill — this final smoke confirms the requirements actually work end-to-end, not
+   just that tasks are ticked.
+2. **Report** — what was built, the commits made (with the branch), and any open
+   `decisions.md` items (blockers, tasks unchecked by a reconcile). If the final
+   smoke reveals a gap, it's a bug to fix now (new/edited task) or a blocker to
+   route upstream — not a pass.
+3. **Close the ticket (reference-only).** If a ticket is bound, this is where the
+   **closing** keyword belongs — on the final / PR commit, not the per-task ones:
+   GitHub `Closes #123`, ADO `Fixes AB#123`. Jira/Monday have no closing keyword,
+   so move the ticket's status manually (active auto-transitions are an opt-in layer
+   — see [INTEGRATIONS.md](INTEGRATIONS.md)). The suite makes **no API calls**.

tiny_spec/_bundle/tiny-spec-build/templates/memory.template.md

@@ -0,0 +1,17 @@
+# Memory — operational lessons
+
+> Curated, forward-acting lessons that should survive across runs so the blind
+> executor and reviewer don't re-learn them. **Project-wide** — lives at the
+> `.spec/` root and is shared across every ticket. NOT a changelog. Prune superseded
+> entries. Code-style rules belong in `constitution.md`; one-off history in the
+> ticket's `decisions.md`.
+
+<!-- Each entry:
+- type: environment | pitfall | tried-rejected | hotspot
+  lesson: <one line — the operational fact>
+  apply:  <one line — why it matters / what to do about it>
+-->
+
+- type: environment
+  lesson: <e.g. the test suite needs the package installed (`pip install -e .`) first>
+  apply:  <run the documented setup before the gate; a bare `pytest` gives a false red>

tiny_spec/_bundle/tiny-spec-create/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: tiny-spec-create
+description: Start or update a spec — capture intent and requirements into .spec/<slug>/SPEC.md, optionally bound to a ticket (or ad-hoc). On first run, scaffolds .spec/ and seeds the shared constitution (constitution.md) from a short interview. Re-run to update an existing spec in place.
+---
+
+# tiny-spec-create
+
+Captures **what** the user wants and **why**, as testable `REQ-N` requirements.
+This is the front door of the flow. A spec can be bound to a ticket or worked
+**ad-hoc** — both are first-class (see below).
+
+The suite works **one spec at a time**, namespaced per spec. Artifacts live
+under `.spec/` in the **project root** (the user's cwd) — never in this skill's
+directory. Two are **project-wide** and shared at the `.spec/` root
+(`constitution.md`, `memory.md`); the per-spec ones (`SPEC.md`, `PLAN.md`,
+`tasks.md`, `decisions.md`) live under `.spec/<slug>/`. Templates ship in this
+skill's own `templates/` folder (alongside this file); read them from there.
+
+## Pick the slug (resolve the active dir)
+
+Each spec lives in its own directory `.spec/<slug>/`. At the start of the interview,
+establish the slug. There are two paths — both are first-class:
+
+- **Bound to a ticket.** Ask for the **provider** (`jira | github | ado | monday`),
+  **id**, **url**, and optionally the current **status**. Derive the slug from the
+  platform key: verbatim when filesystem-safe (`PROJ-123`); otherwise normalize —
+  GitHub `#42`→`gh-42`, Monday item→`monday-<id>`, ADO `AB#77`→`ado-77`.
+- **Ad-hoc (no ticket).** Perfectly supported — just confirm there's no ticket and
+  use a short kebab-case slug of the feature name (e.g. `dark-mode`, `perf-pass`).
+  The SPEC omits the `ticket:` frontmatter block, and commits drop the `Refs:`
+  footer (everything else — namespacing, the constitution, the build loop — is
+  identical). You can bind a ticket later by adding the block to `SPEC.md`.
+
+Create `.spec/<slug>/` and write the slug as the single line of `.spec/ACTIVE` (the
+pointer every downstream skill reads to find the active spec).
+
+## First run — scaffold
+
+If `.spec/` does not exist:
+
+1. Create `.spec/` and the active ticket dir `.spec/<slug>/`, and write `.spec/ACTIVE`.
+2. **Short interview** (keep it short — earned ceremony):
+   - the ticket binding (above);
+   - the intent in one paragraph;
+   - the language/stack and where code lives;
+   - the must-have requirements (the capabilities, not the design).
+3. Seed the **shared constitution**: copy this skill's
+   `templates/constitution.template.md` to `.spec/constitution.md` (the **root**, not
+   the ticket dir — it is project-wide) and fill in what the interview already told
+   you (Style, Layout, Verification commands at minimum). Leave the rest for
+   `tiny-spec-plan` to harden — but never leave a section empty of intent. If
+   `constitution.md` already exists (a prior ticket created it), **reuse it** — do
+   not overwrite the project's constitution.
+
+## Write `SPEC.md`
+
+Copy this skill's `templates/SPEC.template.md` to `.spec/<slug>/SPEC.md` and fill
+it in:
+
+- the **ticket binding** frontmatter block (or omit it if there's no ticket);
+- a one-paragraph **intent**;
+- a `## Requirements` list — each `REQ-N` a single **user-observable, testable**
+  capability with **no implementation detail** ("the CLI accepts a `--json` flag
+  and prints valid JSON", not "add a json module");
+- the optional sections (`Context`, `Non-goals`, `Success criteria`,
+  `Open questions`, `Links`) where they add value — omit any that don't apply.
+
+Number requirements `REQ-1, REQ-2, …`. Keep each atomic — if a line has an "and"
+that hides two capabilities, split it.
+
+## Update mode (re-run on an existing spec)
+
+When the active ticket's `SPEC.md` already exists and the user wants a change to
+requirements (resolve the active dir from `.spec/ACTIVE`):
+
+1. Edit `.spec/<active>/SPEC.md` in place — add/alter/remove `REQ-N`, preserving
+   existing ids where the requirement still exists.
+2. Flip downstream **stale**: set `PLAN.md` and `tasks.md` frontmatter to
+   `status: stale` (if they exist).
+3. Log it: append a `decisions.md` entry to `.spec/<active>/decisions.md`, using the
+   fixed skeleton (`type: change`, the affected `REQ-N`). Create the file if absent:
+
+   ```
+   ## D-NNN — <short title>
+   - type: change
+   - date: <ISO date>
+   - affects: REQ-N
+   - note: <what changed + why>
+   ```
+
+Tell the user which downstream docs went stale and to re-run `tiny-spec-plan` to
+reconcile.
+
+> **New spec?** To start a different piece of work (a new ticket or an ad-hoc
+> change), re-run this skill — it creates a new `.spec/<slug>/` and repoints
+> `.spec/ACTIVE`. The shared `constitution.md` and `memory.md` carry over; the
+> previous spec's artifacts stay untouched on disk.
+
+## When done
+
+Report the requirements captured and point the user at `tiny-spec-plan`.

tiny_spec/_bundle/tiny-spec-create/templates/SPEC.template.md

@@ -0,0 +1,51 @@
+---
+status: current
+updated: <ISO date>
+# Ticket binding (reference-only). Omit this whole block if there is no ticket.
+ticket:
+  provider: jira | github | ado | monday
+  id: <PROJ-123 | #42 | AB#77 | item id>
+  url: <link to the ticket>
+  status: <optional manual mirror of the platform status, e.g. In Progress>
+---
+
+# <Project / feature name>
+
+<!-- optional: omit if N/A -->
+## Context
+
+<Why now — the background, the problem, what prompted this. No solution detail.>
+
+## Intent
+
+<One paragraph: what this is and why it exists. The "what" and "why", never the "how".>
+
+## Requirements
+
+<Each REQ is one user-observable, testable capability. No implementation detail.
+If a line hides two capabilities behind an "and", split it.>
+
+- REQ-1 — <capability>
+- REQ-2 — <capability>
+- REQ-3 — <capability>
+
+<!-- optional: omit if N/A -->
+## Non-goals
+
+<What this explicitly does NOT cover — scope boundaries that prevent creep.>
+
+<!-- optional: omit if N/A -->
+## Success criteria
+
+<How we'll know the whole spec succeeded, beyond the per-requirement acceptance —
+e.g. a metric, an end-to-end scenario, a stakeholder sign-off.>
+
+<!-- optional: omit if N/A -->
+## Open questions
+
+<Unresolved questions that may change requirements. Resolve before/while planning.>
+
+<!-- optional: omit if N/A -->
+## Links
+
+<Ticket, related specs, design docs, prior art.>

tiny_spec/_bundle/tiny-spec-create/templates/constitution.template.md

@@ -0,0 +1,34 @@
+# Constitution
+
+> This is the strongest, most persistent document in the project. It is
+> **project-wide** — it lives at the `.spec/` root and anchors *every* ticket, not
+> any one of them. Every task is implemented and reviewed against it. Keep it true;
+> keep it lean. Project-specific richness belongs here — not scattered across tasks.
+
+## Style
+<Formatting, naming, language idioms. The defaults a reader should assume.>
+
+## Engineering standards
+<Error handling, logging, testing approach, dependency policy, what "tested" means here.>
+
+## Guiding invariants
+<The non-negotiables. "Never X." "Always Y." The rules a reviewer can fail a task on.>
+
+## Glossary
+<Domain term — one-line definition. Keep the team speaking one language.>
+
+## Layout
+<Where things live. Directory map. Where new code of each kind goes.>
+
+## Definition of Done
+<The bar a task must clear to be checked off: e.g. code + tests + docs updated,
+gate green, no TODOs left, matches the invariants above.>
+
+## Verification commands
+<The exact gate. The reviewer runs these. Example:
+- install: `...`
+- lint:    `...`
+- test:    `...`
+- build:   `...`
+- run:     `...`
+>

tiny_spec/_bundle/tiny-spec-plan/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: tiny-spec-plan
+description: Turn the active ticket's SPEC.md into a technical design — produce PLAN.md and harden the shared constitution.md (the constitution). Re-run in update mode to reconcile after a SPEC change.
+---
+
+# tiny-spec-plan
+
+Decides **how** the requirements get built, and — just as important — hardens the
+**constitution** (`constitution.md`) that every task will be implemented and
+reviewed against.
+
+Artifacts live under `.spec/`: the **shared** constitution at the root
+(`.spec/constitution.md`), the per-ticket `SPEC.md`/`PLAN.md` under
+`.spec/<ticket-id>/`. **Resolve the active ticket dir** from `.spec/ACTIVE` (if it's
+absent and exactly one ticket dir exists, use it; if several exist, ask which). The
+template ships in this skill's own `templates/` folder (alongside this file).
+Requires `.spec/<active>/SPEC.md`.
+
+## Harden the constitution (`constitution.md`) — do this first
+
+The constitution is the spine of the whole flow and **project-wide** — it lives at
+`.spec/constitution.md` (the root, shared across every ticket), and is injected whole
+into every executor and reviewer. Make it strong and specific to *this* project, not
+generic boilerplate. Fill in / sharpen all seven sections:
+
+1. **Style** · 2. **Engineering standards** · 3. **Guiding invariants** ·
+4. **Glossary** · 5. **Layout** · 6. **Definition of Done** ·
+7. **Verification commands**.
+
+Two sections carry the most weight — get them right:
+- **Guiding invariants** — the non-negotiables a reviewer can *fail a task on*.
+  Be concrete ("all timestamps are UTC ISO-8601", "no network calls in unit
+  tests"), not aspirational ("write clean code").
+- **Verification commands** — the exact, runnable gate (install → lint → test →
+  build → run). The reviewer executes these literally, so they must actually work
+  from a clean checkout. If setup is needed (e.g. install the package first), say
+  so explicitly.
+
+## Write `PLAN.md`
+
+Copy this skill's `templates/PLAN.template.md` to
+`.spec/<active>/PLAN.md` and fill it in:
+
+- `## Approach` *(required)* — the design narrative: the shape of the solution, key
+  decisions, trade-offs. Detailed enough that `tiny-spec-tasks` can derive a task list
+  from it. Optional `### Phase` headings are allowed for readability only.
+- `## Requirement coverage` *(required)* — map **every** `REQ-N` to where it's
+  addressed. A requirement with no home is a gap: fix the approach or route back to
+  `tiny-spec-create`.
+- Optional sections (`Architecture`, `Risks & mitigations`, `Test strategy`,
+  `Open questions`) where they add value — omit any that don't apply.
+
+Keep it proportional: a small change is a few paragraphs, not a phased epic.
+
+## Update mode (SPEC changed → PLAN is stale)
+
+When `PLAN.md` is `status: stale`:
+
+1. Read the latest `.spec/<active>/decisions.md` change entry to see what moved.
+2. Reconcile `.spec/<active>/PLAN.md` and the shared `.spec/constitution.md` — adjust
+   only what the change requires; preserve the rest.
+3. Flip `.spec/<active>/tasks.md` to `status: stale` (if it exists) and extend the
+   `decisions.md` entry.
+4. Set `PLAN.md` `status: current`, bump `updated`.
+
+## When done
+
+Confirm the constitution is hardened and every `REQ-N` is covered, then point the
+user at `tiny-spec-tasks`.

tiny_spec/_bundle/tiny-spec-plan/templates/PLAN.template.md

@@ -0,0 +1,45 @@
+---
+status: current
+updated: <ISO date>
+---
+
+# Plan — <project / feature name>
+
+## Approach
+
+<The design narrative: how the requirements will be met. Key decisions, the shape
+of the solution, notable trade-offs. Enough that someone could derive the tasks
+from it. Optional `### Phase` headings are fine for readability — they do NOT
+parallelize or gate anything.>
+
+<!-- optional: omit if N/A -->
+## Architecture
+
+<The moving parts and how they fit: components, data flow, key interfaces or
+modules. A small diagram or bullet map is fine. Skip for changes too small to need it.>
+
+## Requirement coverage
+
+<Every REQ-N maps to where it's addressed. No requirement left unaddressed.>
+
+- REQ-1 — <where/how addressed>
+- REQ-2 — <where/how addressed>
+- REQ-3 — <where/how addressed>
+
+<!-- optional: omit if N/A -->
+## Risks & mitigations
+
+<What could go wrong (technical risk, unknowns, fragile areas) and how the plan
+de-risks it.>
+
+<!-- optional: omit if N/A -->
+## Test strategy
+
+<How the work will be verified beyond the constitution's gate — what to test, at
+what level, and any fixtures/data needed.>
+
+<!-- optional: omit if N/A -->
+## Open questions
+
+<Design questions still unresolved. A question that blocks tasks must be answered
+here or routed back to tiny-spec-create before tiny-spec-tasks runs.>

tiny_spec/_bundle/tiny-spec-tasks/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: tiny-spec-tasks
+description: Slice the active ticket's PLAN.md into tasks.md — a flat, ordered checklist of small tasks, each with an acceptance outcome. Executed sequentially by tiny-spec-build. Re-run in update mode to reconcile after a plan change.
+---
+
+# tiny-spec-tasks
+
+Turns the plan into `tasks.md`: a **flat, ordered checklist** of small, concrete
+tasks. No waves, no parallelism, no `owns:` contracts — tasks run one at a time,
+top to bottom.
+
+Artifacts live under `.spec/`; `PLAN.md` and `tasks.md` are per-ticket. **Resolve
+the active ticket dir** from `.spec/ACTIVE` (if absent and exactly one ticket dir
+exists, use it; if several exist, ask which). The template ships in this skill's own
+`templates/` folder (alongside this file). Requires `.spec/<active>/PLAN.md`.
+
+## Slice the plan into tasks
+
+Walk the `## Approach` in `PLAN.md` and break it into tasks. Each task is:
+
+- **Small and independently checkable** — one slice a single executor can finish
+  and a reviewer can grade in one pass. If you can't write a one-line acceptance
+  for it, it's too big — split it.
+- **Ordered so each builds on the last.** Tasks run sequentially, so a later task
+  may freely assume an earlier task's code already exists. Put foundational work
+  (types, schema, scaffolding) first. Order by dependency, not by guesswork.
+- **Right-sized, not fragmented.** Don't split a cohesive change into five files'
+  worth of micro-tasks just to look granular. Earned ceremony: fewer, meaningful
+  tasks beat many trivial ones.
+
+For each task, write:
+
+```
+- [ ] T<n> — <imperative description>
+  - acceptance: <one user-observable outcome that proves it's done>
+  - type: feat            # optional; Conventional Commit type (defaults to feat)
+  - req: REQ-n            # optional; the REQ-N this task delivers
+  - files: <comma-separated hint of files it will touch>
+```
+
+The **acceptance** is what the reviewer checks against — make it observable
+("`spec --version` prints the version and exits 0"), not internal ("version logic
+added"). **type** picks the Conventional Commit type `tiny-spec-build` uses for this
+task's code commit (`feat | fix | docs | refactor | test | chore | build | ci | perf | style`);
+set it when the task is clearly not a feature (e.g. `fix`, `docs`, `refactor`),
+otherwise omit and it defaults to `feat`. **req** ties the task to the requirement
+it satisfies (traceability). The **files** line is a hint to focus the executor and
+reviewer; it is not enforced, so approximate paths are fine.
+
+Cover **every** part of the approach — together the tasks must deliver all
+`REQ-N`. Don't leave a requirement with no task.
+
+## Write `tasks.md`
+
+Copy this skill's `templates/tasks.template.md` to
+`.spec/<active>/tasks.md`, fill in the `## Tasks` checklist with all tasks `[ ]`
+unchecked, set frontmatter `status: current`, `updated: <today>`.
+
+## Update mode (PLAN changed → tasks are stale)
+
+When `tasks.md` is `status: stale`:
+
+1. Read the latest `.spec/<active>/decisions.md` change entry.
+2. Reconcile — add/alter/remove tasks to match the new plan, preserving existing
+   `T<n>` ids where the task still exists; new tasks get the next free id.
+3. **Completed-work guardrail:** if a change touches a task already `[x]`,
+   **uncheck it** (`[ ]`) and record the unchecked ids in
+   `.spec/<active>/decisions.md` for human review, using the fixed skeleton. Never
+   assume built work survived.
+
+   ```
+   ## D-NNN — <short title>
+   - type: change
+   - date: <ISO date>
+   - affects: T<n>, T<m>
+   - note: <which tasks were unchecked and why>
+   ```
+4. Set `status: current`, bump `updated`.
+
+## When done
+
+Report the task count and point the user at `tiny-spec-build` (one task at a time) or
+note they can run it straight through.

tiny_spec/_bundle/tiny-spec-tasks/templates/tasks.template.md

@@ -0,0 +1,28 @@
+---
+status: current
+updated: <ISO date>
+---
+
+# Tasks — <project / feature name>
+
+> Executed top to bottom, one at a time. A checked `[x]` task is implemented AND
+> reviewed. `type:` and `req:` are optional; `files:` is a hint, not an ownership
+> contract.
+
+## Tasks
+
+- [ ] T1 — <one small, independently-checkable slice of work>
+  - acceptance: <one user-observable outcome that proves T1 is done>
+  - type: feat            # optional; Conventional Commit type for this task's commit (defaults to feat)
+  - req: REQ-1            # optional; the REQ-N this task delivers
+  - files: <path, path>
+
+- [ ] T2 — <next slice; assume T1's code exists>
+  - acceptance: <observable outcome>
+  - type: feat
+  - req: REQ-2
+  - files: <path, path>
+
+- [ ] T3 — <…>
+  - acceptance: <observable outcome>
+  - files: <path, path>

tiny_spec/cli.py

@@ -0,0 +1,124 @@
+"""tiny-spec installer CLI.
+
+Two commands, stdlib only:
+
+    tiny-spec install      copy skills + agents into ~/.claude
+    tiny-spec uninstall    remove the ones tiny-spec installed
+
+Re-running ``install`` overwrites in place, so it doubles as an update. Pass
+``--dir`` to target a Claude config dir other than ``~/.claude`` (handy for
+testing into a throwaway directory).
+
+What gets installed is declared in ``manifest.json`` — the single source of
+truth for the install set. Adding or renaming a skill/agent means editing the
+manifest (and the matching path in ``pyproject.toml``), nothing else here.
+"""
+
+from __future__ import annotations
+
+import argparse
+import json
+import shutil
+import sys
+from importlib.resources import as_file, files
+from pathlib import Path
+
+
+def _manifest() -> dict:
+    """The declared install set: ``{"skills": [...], "agents": [...]}``."""
+    return json.loads(files("tiny_spec").joinpath("manifest.json").read_text())
+
+
+def _default_dir() -> Path:
+    return Path.home() / ".claude"
+
+
+def install(claude_dir: Path) -> int:
+    """Copy the manifest's skills and agents into ``claude_dir``. Overwrites in place."""
+    manifest = _manifest()
+    skills_dst = claude_dir / "skills"
+    agents_dst = claude_dir / "agents"
+    skills_dst.mkdir(parents=True, exist_ok=True)
+    agents_dst.mkdir(parents=True, exist_ok=True)
+
+    with as_file(files("tiny_spec").joinpath("_bundle")) as bundle:
+        for skill in manifest["skills"]:
+            src = bundle / skill
+            if not src.is_dir():
+                raise SystemExit(f"manifest lists skill '{skill}' but it is not bundled")
+            dst = skills_dst / skill
+            if dst.exists():
+                shutil.rmtree(dst)
+            shutil.copytree(src, dst)
+            print(f"  skill   {dst}")
+        for agent in manifest["agents"]:
+            src = bundle / "agents" / agent
+            if not src.is_file():
+                raise SystemExit(f"manifest lists agent '{agent}' but it is not bundled")
+            dst = agents_dst / agent
+            shutil.copy2(src, dst)
+            print(f"  agent   {dst}")
+
+    print(f"\nInstalled tiny-spec into {claude_dir}. Restart Claude Code to load it.")
+    return 0
+
+
+def uninstall(claude_dir: Path) -> int:
+    """Remove only the manifest's skills and agents. Leaves the rest alone."""
+    manifest = _manifest()
+    removed = 0
+    for skill in manifest["skills"]:
+        dst = claude_dir / "skills" / skill
+        if dst.exists():
+            shutil.rmtree(dst)
+            print(f"  removed {dst}")
+            removed += 1
+    for agent in manifest["agents"]:
+        dst = claude_dir / "agents" / agent
+        if dst.exists():
+            dst.unlink()
+            print(f"  removed {dst}")
+            removed += 1
+
+    if removed:
+        print(f"\nRemoved {removed} item(s) from {claude_dir}.")
+    else:
+        print(f"Nothing to remove in {claude_dir}.")
+    return 0
+
+
+def build_parser() -> argparse.ArgumentParser:
+    parser = argparse.ArgumentParser(
+        prog="tiny-spec",
+        description="Install the tiny-spec skill suite into your Claude Code config.",
+    )
+    sub = parser.add_subparsers(dest="command", required=True)
+
+    for name, help_text in (
+        ("install", "copy skills and agents into ~/.claude (re-run to update)"),
+        ("uninstall", "remove the skills and agents tiny-spec installed"),
+    ):
+        p = sub.add_parser(name, help=help_text)
+        p.add_argument(
+            "--dir",
+            type=Path,
+            default=_default_dir(),
+            metavar="PATH",
+            help="Claude config directory (default: ~/.claude)",
+        )
+
+    return parser
+
+
+def main(argv=None) -> int:
+    args = build_parser().parse_args(argv)
+    claude_dir: Path = args.dir.expanduser()
+    if args.command == "install":
+        return install(claude_dir)
+    if args.command == "uninstall":
+        return uninstall(claude_dir)
+    return 1  # pragma: no cover — argparse guarantees a known command
+
+
+if __name__ == "__main__":  # pragma: no cover
+    sys.exit(main())

tiny_spec/manifest.json

@@ -0,0 +1,12 @@
+{
+  "skills": [
+    "tiny-spec-create",
+    "tiny-spec-plan",
+    "tiny-spec-tasks",
+    "tiny-spec-build"
+  ],
+  "agents": [
+    "tiny-spec-build-executor.md",
+    "tiny-spec-build-reviewer.md"
+  ]
+}

tiny_spec-0.1.0.dist-info/METADATA

@@ -0,0 +1,236 @@
+Metadata-Version: 2.4
+Name: tiny-spec
+Version: 0.1.0
+Summary: A tiny, opinionated take on spec-driven development.
+Project-URL: Homepage, https://github.com/GrayMa77er/tiny-spec
+Project-URL: Source, https://github.com/GrayMa77er/tiny-spec
+Project-URL: Issues, https://github.com/GrayMa77er/tiny-spec/issues
+Author: Snir Orlanczyk
+License: MIT License
+        
+        Copyright (c) 2026 Snir Orlanczyk
+        
+        Permission is hereby granted, free of charge, to any person obtaining a copy
+        of this software and associated documentation files (the "Software"), to deal
+        in the Software without restriction, including without limitation the rights
+        to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+        copies of the Software, and to permit persons to whom the Software is
+        furnished to do so, subject to the following conditions:
+        
+        The above copyright notice and this permission notice shall be included in all
+        copies or substantial portions of the Software.
+        
+        THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+        IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+        FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+        AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+        LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+        OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+        SOFTWARE.
+License-File: LICENSE
+Keywords: ai-agents,claude,claude-code,skills,spec-driven-development
+Classifier: Environment :: Console
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3
+Requires-Python: >=3.9
+Description-Content-Type: text/markdown
+
+<p align="center">
+  <img src="images/logo.png" alt="tiny-spec" width="200">
+</p>
+
+<h1 align="center">tiny-spec</h1>
+
+<p align="center">A tiny, opinionated take on spec-driven development.</p>
+
+<p align="center">
+  <a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-blue.svg" alt="License: MIT"></a>
+  <a href="https://docs.claude.com/en/docs/claude-code/overview"><img src="https://img.shields.io/badge/Claude%20Code-skills-d97757.svg" alt="Claude Code"></a>
+</p>
+
+tiny-spec is a four-step workflow for Claude Code that turns a ticket into shipped,
+reviewed code. You write the intent, it produces a design, a task list, and then
+builds the work one task at a time. Every task is implemented by one agent and
+graded by an independent reviewer that runs the real tests before anything is
+committed.
+
+It is four skills and two agents. No orchestrator, no config file, no build step.
+
+```
+tiny-spec-create  →  tiny-spec-plan  →  tiny-spec-tasks  →  tiny-spec-build
+   intent               design             tasks            per-task loop
+   SPEC.md              PLAN.md +          tasks.md         plan → implement → review → commit
+                        constitution
+```
+
+## New to spec-driven development?
+
+Spec-driven development (SDD) means writing down *what* you want and *why* before
+any code exists, then letting that spec drive the build. Instead of prompting an
+agent and hoping, you hand it a small, explicit contract — the intent, a design,
+and an ordered list of tasks — and it implements against that. The payoff: the
+agent stops guessing. It knows what "done" looks like, you can review the plan
+before a single line is written, and the result is checked against the spec
+rather than vibes. tiny-spec is one small take on that idea.
+
+## Quickstart
+
+Install the skills and agents into your Claude Code config with
+[uv](https://docs.astral.sh/uv/):
+
+```sh
+uvx tiny-spec install
+```
+
+Restart Claude Code so it picks up the new skills, then run the flow in your project:
+
+```
+/tiny-spec-create   # capture intent and requirements (binds a ticket, optional)
+/tiny-spec-plan     # turn the spec into a design and harden the constitution
+/tiny-spec-tasks    # slice the plan into an ordered checklist
+/tiny-spec-build    # build each task: implement, review, commit
+```
+
+Re-run `install` any time to update; `tiny-spec uninstall` removes only what it
+installed. Each skill is copied (not symlinked) so every install is
+self-contained.
+
+<details>
+<summary>Manual install (no uv)</summary>
+
+The skills and agents are plain markdown — copy them in by hand. Claude Code
+loads skills from `~/.claude/skills/` and agents from `~/.claude/agents/`:
+
+```sh
+git clone https://github.com/GrayMa77er/tiny-spec.git
+cd tiny-spec
+
+mkdir -p "$HOME/.claude/skills" "$HOME/.claude/agents"
+for s in tiny-spec-create tiny-spec-plan tiny-spec-tasks tiny-spec-build; do
+  cp -R "$s" "$HOME/.claude/skills/$s"
+done
+cp agents/*.md "$HOME/.claude/agents/"
+```
+
+If a skill name collides with one you already have, rename these before copying,
+or install one set at a time.
+
+</details>
+
+## How it works
+
+The constitution (`constitution.md`) is the spine. `tiny-spec-create` seeds it from a
+short interview, `tiny-spec-plan` hardens it with concrete engineering rules, and
+`tiny-spec-build` injects it whole into every task. It holds your style, standards,
+invariants, definition of done, and verification commands.
+
+`tiny-spec-build` walks the task list top to bottom. Each task runs through one loop:
+
+1. Plan the task against the constitution (inline, brief).
+2. Implement it with a fresh `tiny-spec-build-executor` agent.
+3. Review it with an independent `tiny-spec-build-reviewer` agent that runs the gate
+   end to end and grades against the constitution and the task's acceptance.
+4. On pass, commit the code plus a checklist tick. On fail, loop back to the
+   executor with the findings. After two failed attempts it becomes a blocker.
+
+```mermaid
+flowchart TB
+    SPEC[SPEC.md<br/>intent] --> PLAN[PLAN.md<br/>design] --> TASKS[tasks.md<br/>checklist]
+
+    TASKS --> P[Plan task]
+    P --> I[Implement<br/>executor]
+    I --> R[Review + run gate<br/>reviewer]
+    R -->|pass| C[Commit + tick]
+    C --> TASKS
+    R -->|fail| I
+    R -->|fail twice| B[Blocker logged to decisions.md]
+
+    CON([constitution.md]) -.-> P & I & R
+    MEM([memory.md]) -.-> I & R
+```
+
+Solid arrows are the flow. Dotted arrows show the persistent context injected into
+a step: the `constitution.md` goes into planning, implementation, and review, while
+`memory.md` is handed to the executor and reviewer.
+
+A small `memory.md` carries operational lessons between runs, so the executor and
+reviewer (which start fresh each time) don't relearn the same pitfalls.
+
+When a task can't pass because of a gap in the design or spec, the executor stops
+and logs a blocker instead of hacking around it. You fix the gap upstream in
+`tiny-spec-plan` or `tiny-spec-create`, then resume. Work runs one ticket at a time and
+resumes from the checklist state.
+
+## Why it's small
+
+Most spec frameworks are generous by default:
+many phases, many agents, many generated documents. tiny-spec makes the opposite
+bet. Keep one safeguard, drop the rest.
+
+A green unit test suite is not the same as working software, so the reviewer
+exercises acceptance criteria end to end and a final smoke test confirms the whole
+spec. That independent review is the safeguard — not the volume of planning
+artifacts. One task, one commit, an external reviewer. Nothing gets added unless
+it earns its place.
+
+The case for staying small:
+
+- **Documents are context, and context isn't free.** Generating large `spec.md`,
+  `plan.md`, `research.md`, and `data-model.md` files costs tokens to write, then
+  costs context to carry. Every paragraph the agent has to hold is room it no
+  longer has for your actual code. tiny-spec keeps the spine small — a
+  constitution and a short memory — and injects only what each task needs.
+- **Real work is a ticket inside a system, not a greenfield repo.** Bigger kits
+  assume you're bootstrapping a project from a blank page. Day to day, you pick up
+  a ticket and change part of a system that already exists. tiny-spec binds to a
+  ticket, works one at a time, and references your task platform instead of
+  re-describing the world.
+- **Rigid pipelines fight the user.** Mandatory phases and required sections
+  impose ceremony on work that doesn't need it. tiny-spec's extra structure is
+  optional by design — add shape where it pays, skip it where it doesn't.
+- **More moving parts is more to maintain.** Orchestrators, ownership contracts,
+  checkpoint matrices, and config files are themselves a system you have to learn
+  and keep in sync. Four skills and two agents are not.
+- **Generated docs can fake rigor.** A folder of polished planning artifacts looks
+  like progress, but it isn't proof. The proof is the reviewer running your real
+  tests before each commit.
+
+That's the whole trade: where larger kits add machinery, tiny-spec adds one
+independent reviewer and stops.
+
+## Project layout
+
+Each skill is self-contained. It carries its own templates and refers to them by
+relative path, with no absolute paths and no shared parent required at runtime, so
+a skill folder works wherever you drop it.
+
+tiny-spec creates a `.spec/` directory in your project root, never inside a skill.
+It is namespaced per ticket, with a shared spine at the root:
+
+```
+.spec/
+  ACTIVE                    the active ticket directory name (resolution pointer)
+  constitution.md           project-wide, shared across tickets
+  memory.md                 operational lessons, shared across tickets
+  <ticket-id>/              one directory per ticket (PROJ-123/, gh-42/, …)
+    SPEC.md  PLAN.md  tasks.md  decisions.md
+```
+
+`CONTRACTS.md` documents the formats for maintainers. The skills do not read it at
+runtime; each is self-sufficient.
+
+## Integrations
+
+tiny-spec binds to a task platform (Jira, GitHub Issues, Azure DevOps, Monday) by
+reference only: a `ticket` block in the spec and a `Refs:` footer on each
+[Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/), so the
+platform auto-links the work. No API calls or credentials are required.
+
+## Contributing
+
+Issues and pull requests are welcome. See [CONTRIBUTING.md](CONTRIBUTING.md), and
+read [AGENTS.md](AGENTS.md) before changing any skill or agent.
+
+## License
+
+[MIT](LICENSE)

tiny_spec-0.1.0.dist-info/RECORD

@@ -0,0 +1,19 @@
+tiny_spec/__init__.py,sha256=aX_g10wVFxMjQX30_QPW9Oq75k2nft828TESvcD-d3w,289
+tiny_spec/cli.py,sha256=iHy91HaBaclpboMGbQho7vTS4Iptasn0EUEjyMhuBl0,4074
+tiny_spec/manifest.json,sha256=W_hvaWKBiTLkJ3_lJWaLXTJSu5Xp1WtQDnUR84d41AM,201
+tiny_spec/_bundle/agents/tiny-spec-build-executor.md,sha256=BbK_i1Iqy6GZgotXORdipiVWketyyZDhnkEM0cNBtAs,3922
+tiny_spec/_bundle/agents/tiny-spec-build-reviewer.md,sha256=w8U2hHA1C-TO-sISEL_v11-zt4XnfLQkBuHQovMGt_U,3486
+tiny_spec/_bundle/tiny-spec-build/SKILL.md,sha256=xmwMYKH39LK7_19OEL4PfOLZLAkKUGo94ytMz6g4b1M,8501
+tiny_spec/_bundle/tiny-spec-build/templates/memory.template.md,sha256=UW3KP5JtlfBnGlXe1zTizJAN-Jga9W6sTHoo0BFBsBM,767
+tiny_spec/_bundle/tiny-spec-create/SKILL.md,sha256=o_aENHoSLynX0I_e53BiswnxxM7fO5qrLM7OXkg4axo,4908
+tiny_spec/_bundle/tiny-spec-create/templates/SPEC.template.md,sha256=MxZ1f8q1M9Ew9pUtyC6EIP-aurzD2HWTc4P-rJA7eEE,1361
+tiny_spec/_bundle/tiny-spec-create/templates/constitution.template.md,sha256=xQ6Nmgw06CuMe8NezstG-ptFLANsD2eifAc9GfL-R24,1151
+tiny_spec/_bundle/tiny-spec-plan/SKILL.md,sha256=K8_pqv7xwSZiK6lsuCGOIog2dMREFEMS2QWqohUX5no,3312
+tiny_spec/_bundle/tiny-spec-plan/templates/PLAN.template.md,sha256=mSnBQnH3o9xgYTSVlhKASjsvjxglHCvWYHE9hl5R0O0,1317
+tiny_spec/_bundle/tiny-spec-tasks/SKILL.md,sha256=KjR7p-Evg7JvAF_YxcP76GU-r7uyEKJf3se0SQHp8Fk,3778
+tiny_spec/_bundle/tiny-spec-tasks/templates/tasks.template.md,sha256=BPCRJ89DMoPTWEQGItKNDQhTudsszS5vVziL53_Uu_0,822
+tiny_spec-0.1.0.dist-info/METADATA,sha256=r5hoPE84WFT8dVxrTRWGGNivTIfCM2gScUm9iPsmr3c,10315
+tiny_spec-0.1.0.dist-info/WHEEL,sha256=mffPy8wBnZQn2VnJUU5jE99KsxaSfiyMHV9Yt0aLVxs,87
+tiny_spec-0.1.0.dist-info/entry_points.txt,sha256=hfwcYT04QqN82P4nPdPfacAnPO_k-2o_YFytPh2i7UM,49
+tiny_spec-0.1.0.dist-info/licenses/LICENSE,sha256=-DxXBwYgv2yn2RynYeoGy47kiIez2SHBfpZEf1SnUA0,1071
+tiny_spec-0.1.0.dist-info/RECORD,,

tiny_spec-0.1.0.dist-info/WHEEL

@@ -0,0 +1,4 @@
+Wheel-Version: 1.0
+Generator: hatchling 1.30.1
+Root-Is-Purelib: true
+Tag: py3-none-any

tiny_spec-0.1.0.dist-info/entry_points.txt

@@ -0,0 +1,2 @@
+[console_scripts]
+tiny-spec = tiny_spec.cli:main

tiny_spec-0.1.0.dist-info/licenses/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Snir Orlanczyk
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.