@cerebriline/core 4.100.240 → 4.100.241

package/assets/skills/sdd-status/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: sdd-status
+description: >-
+  Reports where spec-driven work stands, without changing anything, from the
+  sdd tool: the
+  milestone and its slices, the slice in progress and its tasks, requirement
+  coverage, open blockers and questions, checks waiting for a person, and the
+  next step. Use when the user asks for status, progress, what is done, what
+  is left, or what is next in a project that has a .sdd folder.
+disabled: true
+---
+
+# Skill: Status
+
+Read-only. Says where the project stands. It changes nothing, runs nothing that changes anything, and does not start the next step.
+
+Part of the spec-driven set: `sdd-wizard` (where am I, what is next), `sdd-discuss`, `sdd-plan`, `sdd-execute`, `sdd-verify`, `sdd-quick`, `sdd-status`. Each works when the others are off; where this skill hands over to one that is not enabled, do that step directly by the rules given here.
+
+## The `sdd` tool
+
+The plan is kept in a database in the project (`.sdd/sdd.db`), and you reach it only through the **`sdd` tool**. The database is the truth: what is wanted, the milestones, their slices and tasks, what was proved, and which step is due.
+
+- **`sdd` with action `next`** answers with the one step that is due and everything that step needs. Call it when you start and whenever you are unsure. Do not work out the next step yourself, and do not rely on what was said earlier in a conversation.
+- Every other action records one thing and answers with the next step. An action out of turn is **refused**, with the reason and what to do instead. Do what it says; do not look for a way round it.
+- The markdown under `.sdd/` (`PROJECT.md`, `REQUIREMENTS.md`, `DECISIONS.md`, `KNOWLEDGE.md`, `STATE.md`, and a folder per milestone with its roadmap, plans and summaries) is **written by the tool** from the database, for people to read and review. Read it when it helps. **Never edit it**: an edit is overwritten, and the plan does not change.
+- The tool gives the ids: `M001` (milestone), `S01` (slice), `T01` (task), `R001` (requirement), `D001` (decision).
+- A **milestone** is a deliverable someone could ship. A **slice** is a vertical piece of it that can be demonstrated on its own. A **task** is one unit of work small enough to do, verify and describe in one sitting.
+- Only you, the lead, call `sdd`. An agent or a teammate given a task works on the code and reports; it does not record anything.
+
+If you do not have a tool called `sdd`, this skill cannot run. Say so: the tool is offered when a task starts with a spec-driven skill turned on, so the user starts a new task. Do not imitate the tool by writing the files yourself.
+
+## Ask
+
+Call `sdd` with action `status`, and then with action `next`. These two change nothing. Call no other action from this skill.
+
+If `status` says spec-driven development has not been started in this project, say that, and that `sdd-wizard` starts it. Nothing else.
+
+## Check what the tool cannot see
+
+The tool knows the plan. It does not know git. If the project is a git repository, look at `git worktree list` and report:
+
+- a worktree under `.sdd/worktrees/` for a slice that is already done;
+- a done slice whose branch (`sdd/M001-S01`) was never merged;
+- a file under `.sdd/` that was edited by hand (`git status` shows it changed although no step ran): it will be overwritten by the next step.
+
+Report these as inconsistencies. Do not repair them here.
+
+## Report
+
+Short, most important first. Start from what `status` printed:
+
+```
+M001 <title>: 2 of 5 slices done
+  [x] S01 <title>
+  [x] S02 <title>
+  [ ] S03 <title>: 1 of 4 tasks done     <- now
+  [ ] S04 <title>                        (after S03)
+  [ ] S05 <title>
+
+Next: <the step from next, in plain words, and the skill that does it>
+
+Requirements: 6 validated, 5 active, 2 deferred
+Waiting on you: <an approval, acceptance checks marked for a person, a missing credential>
+Blocked: <what, or "no">
+Isolation: <the slice's worktree and branch, and whether it has unmerged commits; or "none">
+Inconsistencies: <what was found, or "none">
+```
+
+Add the last verification in one line (what was run, and how it ended; it is in the newest task summary under `.sdd/milestones/`), and anything a summary lists as a known issue that the user should not be surprised by.
+
+If the user asks about one thing (a slice, a requirement, a decision), answer it from the files under `.sdd/` and name the file it is in.
+
+## Credits
+
+Adapted from [Get Shit Done (GSD 2)](https://getshitdone.help/), source at [gsd-build/GSD-2](https://github.com/gsd-build/GSD-2). The milestone, slice and task hierarchy, the order of the phases, and keeping the plan in a database that says which step is due are GSD's. These skills use their own engine and their own folder (`.sdd/`), and are not compatible with a `.gsd/` folder.

package/assets/skills/sdd-verify/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: sdd-verify
+description: >-
+  Verifies spec-driven work at the level that is due: closes a finished slice
+  by running its verification and its acceptance checks, recording its
+  summary and reassessing the rest of the roadmap; or
+  audits a finished milestone against its success criteria and requirements
+  and completes it only when everything is proved. Use when every task of a
+  slice is done, when every slice of a milestone is done, when sdd-wizard says
+  verification is next, or when the user asks to verify, validate or accept
+  the work.
+disabled: true
+---
+
+# Skill: Verify
+
+Checks that what was built is what was promised. Tasks passing one by one does not show that the slice works, and slices passing does not show that the milestone delivers; this skill is where the assembled thing is tested against the plan and the result recorded.
+
+Part of the spec-driven set: `sdd-wizard` (where am I, what is next), `sdd-discuss`, `sdd-plan`, `sdd-execute`, `sdd-verify`, `sdd-quick`, `sdd-status`. Each works when the others are off; where this skill hands over to one that is not enabled, do that step directly by the rules given here.
+
+## The `sdd` tool
+
+The plan is kept in a database in the project (`.sdd/sdd.db`), and you reach it only through the **`sdd` tool**. The database is the truth: what is wanted, the milestones, their slices and tasks, what was proved, and which step is due.
+
+- **`sdd` with action `next`** answers with the one step that is due and everything that step needs. Call it when you start and whenever you are unsure. Do not work out the next step yourself, and do not rely on what was said earlier in a conversation.
+- Every other action records one thing and answers with the next step. An action out of turn is **refused**, with the reason and what to do instead. Do what it says; do not look for a way round it.
+- The markdown under `.sdd/` (`PROJECT.md`, `REQUIREMENTS.md`, `DECISIONS.md`, `KNOWLEDGE.md`, `STATE.md`, and a folder per milestone with its roadmap, plans and summaries) is **written by the tool** from the database, for people to read and review. Read it when it helps. **Never edit it**: an edit is overwritten, and the plan does not change.
+- The tool gives the ids: `M001` (milestone), `S01` (slice), `T01` (task), `R001` (requirement), `D001` (decision).
+- A **milestone** is a deliverable someone could ship. A **slice** is a vertical piece of it that can be demonstrated on its own. A **task** is one unit of work small enough to do, verify and describe in one sitting.
+- Only you, the lead, call `sdd`. An agent or a teammate given a task works on the code and reports; it does not record anything.
+
+If you do not have a tool called `sdd`, this skill cannot run. Say so: the tool is offered when a task starts with a spec-driven skill turned on, so the user starts a new task. Do not imitate the tool by writing the files yourself.
+
+## Which verification is due
+
+Call `sdd` with action `next`:
+
+- `close_slice` → **Part A**.
+- `validate_milestone` → **Part B**.
+- `complete_milestone` → **Part C**.
+
+## The three levels of proof
+
+- **Contract:** unit tests, types, lint. Each piece does what it says, alone.
+- **Integration:** the pieces work together across their boundaries.
+- **Operational:** it builds, starts, and the flow a user follows works end to end.
+
+Passing one level says nothing about the next. A slice is closed on the first two; a milestone needs all three.
+
+## Evidence, not opinion
+
+Every check is recorded with what was run and what was seen. For each, choose the lightest thing that honestly proves it: a command and its exit code, a file's content, a request and its response, the running app. Verdicts are **PASS**, **FAIL** or **NEEDS-HUMAN**. What only a person can judge (how it looks, how it feels, whether the wording is right) is marked NEEDS-HUMAN with everything prepared for them; never invent a pass for it.
+
+## Part A: Close a slice
+
+1. **Run the slice's verification**, all of it, in the workspace (in the slice's worktree, if it was built in one; see "Merging an isolated slice" below): the project's tests, and each task's `Verify` command again now that they are all in. If a check fails, fix it and run again; a fix here is small and within the slice. If it cannot be fixed within the slice's plan, stop: the slice is not done, and it is replanned (`sdd-plan`).
+2. **Check the goal, not the tasks:** is the slice's goal now true, end to end? Is each requirement it owns demonstrably met?
+3. **Run the acceptance checks.** Write the cases for this slice, specific to what it built: each with its preconditions, its steps and the expected result, starting from the slice's demo. Run each, and note how it was checked and what was observed. Each ends as `pass`, `fail` or `needs_human`.
+4. **Close it** with `sdd` action **`complete_slice`**:
+   - `summary`: one line saying what a user can now do; what was delivered; the requirements met, with the evidence; and **forward intelligence** for the slices after this one — what is fragile, where the result differs from what the roadmap assumed, and what a later slice will trip over;
+   - `uat`: one entry per acceptance check, `{check, result, note}`.
+
+   The tool refuses to close a slice with a task not done, with no acceptance checks, or with a check that failed. A failed check means new tasks: `replan_slice`, execute them, and close again. A `needs_human` check does not stop the slice; tell the user exactly what to try, and how.
+
+   Closing the slice marks the requirements it owns as validated.
+5. **Record what was learned:** decisions with `add_decision`, lessons with `add_knowledge`, only where they would save a later step real work.
+6. **Reassess the roadmap.** Read the summary just recorded against the slices still to be built:
+
+   - did this slice settle the risk it was meant to?
+   - did a new risk appear that should change the order?
+   - are the boundaries between slices still what the roadmap says?
+
+   The usual answer is that the roadmap stands, and one line saying so is the right output. Change it only on evidence, and only with the user's agreement: `add_slices` for new ones, `remove_slice` for one that is no longer needed and has no work in it. Completed slices are never changed.
+
+### Merging an isolated slice
+
+When the slice was built in a worktree (`.sdd/worktrees/M001-S01/`, branch `sdd/M001-S01`), steps 1 to 3 are run there. After the slice is closed:
+
+1. Make sure everything in the worktree is committed on its branch.
+2. In the main checkout, on the branch the user was on, check `git status --porcelain`: if they have uncommitted changes outside `.sdd/`, stop and ask before merging.
+3. The first time, ask whether to merge verified slices without asking again, and record the answer under "Isolation" in the working agreements (`sdd` action `set_project`). Then:
+
+```
+git merge --squash sdd/M001-S01
+git commit -m "<the slice summary's first line>"
+```
+
+4. **If the merge conflicts, stop.** Show the conflicting files and what each side changed. Do not resolve by taking one side wholesale, and do not abort the user's own work. Resolve with the user, or leave the slice unmerged, say so, and keep it with `sdd` action `capture` so it is not forgotten.
+5. If the user's branch had moved since the worktree was created, run the slice verification once more on the merged result. A failure here is fixed before going on.
+6. Only when the merge commit exists: `git worktree remove .sdd/worktrees/M001-S01` and `git branch -D sdd/M001-S01`. If the removal is refused because something is uncommitted there, look at what it is; do not force it.
+
+Slices that ran side by side are merged one after another, each verified on the result of the one before. Never push.
+
+With sub-agents, steps 1 and 3 can each be given to an agent with a fresh context, which is a better witness than whoever built the slice. With a slice reviewer teammate, ask it for its findings before step 2.
+
+## Part B: Validate the milestone
+
+An audit, not a rerun. `next` lists the requirements the milestone promised. Read the roadmap, every slice summary and acceptance result (under `.sdd/milestones/M###/`), the requirements and the decisions, and check:
+
+1. **Success criteria:** for each one in the milestone's context, the evidence that it is met, from summaries, acceptance results or by running it now. No evidence means not met.
+2. **Slice delivery:** for each slice, does its summary show what its demo promised?
+3. **Integration:** do the boundaries line up? What one slice produces, the next actually consumes?
+4. **Requirements:** every requirement of the milestone is validated, or explicitly deferred with a reason.
+5. **Operational proof:** build it, start it, and walk the main flow end to end, now.
+6. **Real change:** the milestone produced code, not only a plan.
+
+Record it with `sdd` action **`validate_milestone`**: `findings` (the checklist, each slice against its claim, the integration findings, the requirement coverage) and a `verdict`:
+
+- **`pass`:** everything is proved. Small gaps that do not block are listed in the findings and carried into the summary.
+- **`needs_remediation`:** something promised is not delivered. Give `remediation`: the slices that fix it, in the form of a roadmap's slices. They are added to the roadmap, the next step is planning them (`sdd-plan`), and the audit runs again when they are done. Tell the user.
+
+## Part C: Complete the milestone
+
+Only with a passing audit; the tool refuses otherwise, and there is no override. If no code was changed, the milestone is **not** complete: say exactly that, and stop.
+
+Call `sdd` action **`complete_milestone`** with `summary`: one line; what was built; each success criterion with its evidence; the requirements validated, deferred and changed; the key decisions and whether each still looks right; the key files; the lessons; the follow-ups.
+
+Then tell the user what they now have and how to try it. Commit only if the working agreements say to. Never push, tag or publish without their explicit yes.
+
+## Credits
+
+Adapted from [Get Shit Done (GSD 2)](https://getshitdone.help/), source at [gsd-build/GSD-2](https://github.com/gsd-build/GSD-2). The milestone, slice and task hierarchy, the order of the phases, and keeping the plan in a database that says which step is due are GSD's. These skills use their own engine and their own folder (`.sdd/`), and are not compatible with a `.gsd/` folder.

package/assets/skills/sdd-wizard/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: sdd-wizard
+description: >-
+  The front door of spec-driven development: asks the sdd tool where the
+  work stands, says so, and runs the next step, whether that is
+  discussing a new project or milestone, planning a slice, executing a task or
+  verifying. Runs one step at a time by default, or keeps going until the
+  milestone is done or blocked when asked for auto mode. Use when the user
+  wants to start or continue spec-driven development, says "what's next" or
+  "continue", or asks to build something larger than a quick change in a
+  planned, verified way.
+disabled: true
+---
+
+# Skill: Spec-Driven Development
+
+Builds software from an agreed specification, in verified steps: **discuss** what is wanted, **plan** it as a roadmap of slices, and for each slice **plan** its tasks, **execute** them one at a time and **verify** the result, then validate the whole milestone. Every step records what it decided and what it proved, so the next one starts from the record and not from memory.
+
+This skill is the entry point. It asks where the project stands and does the next step.
+
+Part of the spec-driven set: `sdd-wizard` (where am I, what is next), `sdd-discuss`, `sdd-plan`, `sdd-execute`, `sdd-verify`, `sdd-quick`, `sdd-status`. Each works when the others are off; where this skill hands over to one that is not enabled, do that step directly by the rules given here.
+
+## The `sdd` tool
+
+The plan is kept in a database in the project (`.sdd/sdd.db`), and you reach it only through the **`sdd` tool**. The database is the truth: what is wanted, the milestones, their slices and tasks, what was proved, and which step is due.
+
+- **`sdd` with action `next`** answers with the one step that is due and everything that step needs. Call it when you start and whenever you are unsure. Do not work out the next step yourself, and do not rely on what was said earlier in a conversation.
+- Every other action records one thing and answers with the next step. An action out of turn is **refused**, with the reason and what to do instead. Do what it says; do not look for a way round it.
+- The markdown under `.sdd/` (`PROJECT.md`, `REQUIREMENTS.md`, `DECISIONS.md`, `KNOWLEDGE.md`, `STATE.md`, and a folder per milestone with its roadmap, plans and summaries) is **written by the tool** from the database, for people to read and review. Read it when it helps. **Never edit it**: an edit is overwritten, and the plan does not change.
+- The tool gives the ids: `M001` (milestone), `S01` (slice), `T01` (task), `R001` (requirement), `D001` (decision).
+- A **milestone** is a deliverable someone could ship. A **slice** is a vertical piece of it that can be demonstrated on its own. A **task** is one unit of work small enough to do, verify and describe in one sitting.
+- Only you, the lead, call `sdd`. An agent or a teammate given a task works on the code and reports; it does not record anything.
+
+If you do not have a tool called `sdd`, this skill cannot run. Say so: the tool is offered when a task starts with a spec-driven skill turned on, so the user starts a new task. Do not imitate the tool by writing the files yourself.
+
+## Step 1: Ask what is due
+
+Call `sdd` with action `next`. The answer names the step:
+
+| `next` says | What it is | Skill |
+|---|---|---|
+| `discuss_project` | nothing is recorded yet | `sdd-discuss` |
+| `discuss_milestone` | every milestone is complete; what comes next? | `sdd-discuss` |
+| `approve_requirements` | the user has to agree to the requirements | `sdd-discuss` |
+| `plan_milestone` | cut the milestone into slices | `sdd-plan` |
+| `approve_roadmap` | the user has to agree to the roadmap | `sdd-plan` |
+| `plan_slice` | break the slice that is due into tasks | `sdd-plan` |
+| `execute_task` | do the task that is due | `sdd-execute` |
+| `resume_task` | a task was started and not finished | `sdd-execute` |
+| `replan_slice` | a task is blocked | `sdd-plan` |
+| `close_slice` | every task of the slice is done | `sdd-verify` |
+| `validate_milestone` | every slice is done; audit the milestone | `sdd-verify` |
+| `complete_milestone` | the audit passed | `sdd-verify` |
+| `stuck` | no slice can start | put it to the user |
+
+The instruction that comes with the step is specific to this project: the task's steps, its files, its verification command. Follow it together with the skill for that step.
+
+If the user asked for something small and self-contained (a fix, a tweak, a one-file change), that is not a milestone: use `sdd-quick` and leave the plan alone.
+
+## Step 2: Say where things stand
+
+Before doing anything, call `sdd` with action `status` and tell the user in a few lines:
+
+- the milestone and how many of its slices are done;
+- the slice and how many of its tasks are done;
+- the next step, and why it is that one;
+- anything waiting on them: an approval, a blocker, an acceptance check marked for a person.
+
+On a first run in a project, also say in three or four lines how this works: the phases, that they approve the requirements and the roadmap before any code is written, and that they can stop after any step.
+
+## Step 3: Run the next step
+
+**Guided (the default).** Do that one step, by its skill. When it ends, report what it produced and what `sdd` says the next step is, and stop. The user reads, then says to continue.
+
+**Auto.** When the user asks for auto mode ("keep going", "run the milestone", "auto"), repeat: call `next`, do the step, record it. Call `next` every time; do not trust what you remember. Stop only when:
+
+- `next` says the step **needs the user** (a discussion, an approval, a blocker that survived a replan, a slice that cannot start);
+- the milestone is complete;
+- a step needs something only the user has: an acceptance check only a person can judge, a missing secret or credential, a decision that would change scope;
+- verification fails and three real attempts did not fix it;
+- the user says stop.
+
+Discussion and approval are never done in auto mode: the user's answers are the specification. Never call `approve` for them.
+
+A long milestone will outgrow one conversation. That is expected and harmless: the database carries everything. When the conversation has become long, say so at the end of a slice and suggest continuing in a new chat with this skill.
+
+## Agents
+
+The steps are written so that work which should start with a clean context can be given to one:
+
+- **With sub-agents** (you have `spawn_agent`): research, each task, and the plan reviews run in their own agents, as the phase skills describe. You stay the lead: you call `sdd`, hand out the work, and check what comes back. An agent's changes can only be brought back with `restore_file`, which exists when Checkpoints or the change protocol is on. If you have `spawn_agent` and not `restore_file`, say so before the first task is executed, and do not execute with agents until the user has turned Checkpoints on or told you to work without agents.
+- **With teammates as well** (you have the `team_*` tools): slices that do not depend on each other can run side by side, one teammate per slice, and a reviewer can stay with a slice. `sdd-execute` says how.
+- **With neither**: do each step yourself, one at a time.
+
+With git available, a slice can also be built in its own worktree and merged when it is verified (`sdd-execute` and `sdd-verify` say how). It is optional, and skipped when the project is not a git repository.
+
+Never assume an agent's claim. A task is done when its verification passed in the real workspace, and not before.
+
+## Steering
+
+At any point the user may change direction. A change to what is wanted goes into the plan first and only then into the work: `add_requirement` or `update_requirement`, `update_milestone` for the context, `add_slices` or `remove_slice` for the slices not yet built. A new requirement takes back the approval of the requirements, so the user is asked again. Completed slices and their records are not changed; a change to something already built is new work, planned like any other. A thought that is not for now is kept with `sdd` action `capture`, so it is not lost.
+
+## Credits
+
+Adapted from [Get Shit Done (GSD 2)](https://getshitdone.help/), source at [gsd-build/GSD-2](https://github.com/gsd-build/GSD-2). The milestone, slice and task hierarchy, the order of the phases, and keeping the plan in a database that says which step is due are GSD's. These skills use their own engine and their own folder (`.sdd/`), and are not compatible with a `.gsd/` folder.

package/assets/skills/tdd-coverage/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: tdd-coverage
+description: >-
+  Measures test coverage and finds what is untested: runs the project's tests
+  with coverage, lists the files, functions and branches below the threshold
+  (80% unless the repo sets its own), and proposes a specific test for each
+  gap, written out on request. Use when the user asks about coverage, missing
+  tests, or what else should be tested before committing.
+disabled: true
+---
+
+# Skill: Coverage and Missing Tests
+
+Finds what the tests do not exercise and says which tests would close the gap. The user may name a file or folder to look at; with nothing named, the whole project.
+
+Part of the TDD set with `tdd-wizard`, `tdd-gen` and `tdd-test`; it works on its own.
+
+## Step 1: Run the tests with coverage
+
+Use the repo's own coverage command if it has one (a `coverage` or `test:coverage` script, a Makefile target, the CI workflow). Otherwise:
+
+| Framework | Command |
+|---|---|
+| Vitest | `npx vitest run --coverage` |
+| Jest | `npx jest --coverage` |
+| pytest | `pytest --cov=<package> --cov-branch --cov-report=term-missing` |
+| go | `go test ./... -coverprofile=coverage.out` then `go tool cover -func=coverage.out` |
+| cargo | `cargo llvm-cov` (or `cargo tarpaulin`) |
+| dotnet | `dotnet test --collect:"XPlat Code Coverage"` |
+| Maven / Gradle | the JaCoCo report task, if the build configures it |
+
+- If the coverage tool is not installed (`@vitest/coverage-v8`, `pytest-cov`, `cargo-llvm-cov`), say which one is missing and ask before adding a dependency to the project.
+- If tests fail, report that first. Coverage of a failing run is not worth analysing; the failures come before the gaps.
+- Coverage output (`coverage/`, `htmlcov/`, `coverage.out`) is build output. Do not commit it; if the repo does not ignore it yet, say so.
+
+## Step 2: Read the result
+
+The threshold is the one the repo configures (the coverage section of its test config, or CI), and **80%** when it sets none. Find:
+
+- files below the threshold, lowest first;
+- functions and methods never called by any test;
+- branches not taken: the `else`, the early return, the `catch`, the default case;
+- from reading the code beside the report, cases a line count cannot show: boundaries (empty, zero, one, maximum), invalid input, the error paths.
+
+Leave out what should not be counted: generated code, type-only files, configuration, the tests themselves. Say what was left out.
+
+A high percentage is not the goal. A line that runs inside a test that asserts nothing about it is covered and untested; say so where you see it.
+
+## Step 3: Propose the tests
+
+For each gap, a test specific enough to write:
+
+- what is untested, with the file and the lines;
+- the behaviour the test would pin down, in one sentence;
+- the test itself, in the project's framework and in the style of its existing tests.
+
+Order them by what matters: untested error handling and core logic before getters and trivial branches. Group them by file.
+
+Propose tests of **behaviour** through the public interface. Do not suggest reaching into private state to make a line turn green.
+
+## Step 4: Report
+
+```
+Coverage: 73% lines, 61% branches (threshold 80%)
+
+Below the threshold:
+  src/services/payment.ts    45%
+  src/utils/validation.ts    62%
+
+Untested:
+  payment.refund()             never called
+  validation.isValidPhone()    empty input, international formats
+```
+
+followed by the proposed tests.
+
+## Step 5: Write them, if asked
+
+Do not write test files unasked. When the user says yes:
+
+1. add the tests to the existing test file for that module, or create one where the project keeps its tests;
+2. run them;
+3. a new test for existing code should **pass**. If one fails, the code may have a real defect: show the user the test and the failure rather than changing either to agree;
+4. run coverage again and report the new figures.
+
+## Credits
+
+Adapted from the `/coverage` command in "[Test-Driven Development with Claude Code: Practical Guide](https://aiskill.market/blog/tdd-with-claude-code)" by Duke Harewood (aiskill.market, January 28, 2026), including its 80% threshold and its report layout.

package/assets/skills/tdd-gen/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: tdd-gen
+description: >-
+  Writes the implementation that makes existing tests pass, test-first: reads
+  a test file, confirms the tests fail, writes the least code that satisfies
+  them, runs them until green, then tidies up with the tests still passing.
+  Never changes the tests. Use when the user has tests, or a test file from
+  tdd-wizard, and asks to implement the code, make the tests pass, or do TDD.
+disabled: true
+---
+
+# Skill: Implement from Tests
+
+The tests are the specification. This skill turns a test file into the implementation it describes, in the red, green, refactor order. The user names the test file or folder; if they did not, ask which.
+
+Part of the TDD set with `tdd-wizard`, `tdd-test` and `tdd-coverage`; it works on its own.
+
+## The rule that makes this TDD
+
+**Do not edit the tests.** Not to fix them, not to loosen an assertion, not to skip one. If a test looks wrong, contradicts another test, or cannot be satisfied, stop and show the user that test and why. They decide.
+
+And the implementation must be real: it works for inputs the tests did not think of. Code that recognises the tests' own values and returns the expected answers for them passes and implements nothing.
+
+## Phase 1: Read the tests
+
+Read the whole file, and anything it imports from the project. Work out:
+
+- what is under test: the modules, classes and functions, and **the import paths the tests use**, since those fix where the code must live and what it must export;
+- each behaviour asserted, including the edge cases and the errors (the exact messages and types, if the tests check them);
+- what is mocked or injected: those are the dependencies the code must accept, in the shape the mocks have;
+- the framework, and how this repo runs its tests (the `tdd-test` skill if it is enabled; otherwise the repo's `test` script or the framework's run-once command).
+
+## Phase 2: Red
+
+Run the tests before writing anything, and check **why** they fail.
+
+- Failing because the code does not exist yet, or does not do the thing: this is the expected start.
+- Failing for another reason (a syntax error in the test, a missing test dependency, a broken config): that is not red, that is a broken test run. Report it; fix it only if it is outside the test file and plainly an environment matter.
+- **Already passing:** say which. There is nothing to implement for those; do not rewrite working code.
+
+## Phase 3: Where the code goes
+
+If the file the tests import exists, read it and extend it. If not, create it at the path the import names, following how the rest of the project is laid out and written (naming, module style, error handling, typing).
+
+## Phase 4: Green
+
+Write the least code that makes the tests pass:
+
+1. the shapes first: the exports, signatures and types the tests use;
+2. then the behaviour, one group of tests at a time;
+3. the edge cases and errors the tests cover.
+
+Add nothing the tests do not ask for: no extra options, no speculative features. If something obviously needed is not tested (for example input the code would crash on), do not build it silently; mention it at the end as a test worth adding.
+
+## Phase 5: Run until green
+
+Run the tests. For each failure, read expected against actual, fix the implementation, run again. Run only the file being worked on while iterating.
+
+If the same test still fails after three real attempts, stop and show the user the test, the current code and the failure. Do not keep trying variations, and do not reach for the test file.
+
+When the file is green, **run the whole suite once**: new code must not break what was passing before.
+
+## Phase 6: Refactor
+
+Only on green. Remove duplication, improve names, simplify what is tangled, add types where the project uses them. One change at a time, with the tests run after each; if one goes red, undo that change.
+
+Do not refactor code that this session did not write, beyond what the change needs.
+
+## Report
+
+- the test file, and how many tests it holds;
+- the first run: how many failed, and that they failed for the right reason;
+- the files created or changed;
+- the final run: the counts for this file and for the whole suite;
+- what was refactored;
+- anything untested that the user should know about, as suggested tests.
+
+If `tdd-coverage` is enabled, offer it as the next step.
+
+## Credits
+
+Adapted from the `/tdd` command in "[Test-Driven Development with Claude Code: Practical Guide](https://aiskill.market/blog/tdd-with-claude-code)" by Duke Harewood (aiskill.market, January 28, 2026): the six phases are that article's. The rule against editing the tests, the check on why a test fails and the stop after three attempts were added here.

package/assets/skills/tdd-test/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: tdd-test
+description: >-
+  Runs the project's tests the way the repo defines: finds the test framework
+  and the repo's own test command, runs everything or just a given file,
+  folder or test name, and reports what passed and what failed with expected
+  against actual. Use when the user asks to run the tests, or to check whether
+  a change broke anything.
+disabled: true
+---
+
+# Skill: Run the Tests
+
+Runs the tests of the repository open in the workspace and reports the result. The user may name a file, a folder or a test; with nothing named, run the whole suite.
+
+Part of the TDD set with `tdd-wizard`, `tdd-gen` and `tdd-coverage`; it works on its own.
+
+## Step 1: Find how this repo runs its tests
+
+Take the first that answers:
+
+1. **The repo's own command.** A `test` script in `package.json`, a `test` target in a `Makefile` / `justfile` / `Taskfile.yml`, a command in the README or in the CI workflow. This wins: it carries the flags and the setup the project needs.
+2. **The framework, from its config:**
+
+| Found | Framework | Run all | Run one file | Run one test by name |
+|---|---|---|---|---|
+| `vitest` in `package.json` | Vitest | `npx vitest run` | `npx vitest run <file>` | `npx vitest run -t "<name>"` |
+| `jest` in `package.json` | Jest | `npx jest` | `npx jest <file>` | `npx jest -t "<name>"` |
+| `mocha` in `package.json` | Mocha | `npx mocha` | `npx mocha <file>` | `npx mocha -g "<name>"` |
+| `pytest.ini`, `[tool.pytest]` in `pyproject.toml`, `conftest.py` | pytest | `pytest` | `pytest <file>` | `pytest -k "<name>"` |
+| `Cargo.toml` | cargo | `cargo test` | `cargo test --test <name>` | `cargo test <name>` |
+| `go.mod` | go | `go test ./...` | `go test ./<package>/` | `go test ./... -run '<Name>'` |
+| `*.csproj` with a test SDK | dotnet | `dotnet test` | `dotnet test <project>` | `dotnet test --filter "<name>"` |
+| `pom.xml` | Maven | `mvn -B test` | `mvn -B test -Dtest=<Class>` | `mvn -B test -Dtest=<Class>#<method>` |
+| `build.gradle*` | Gradle | `./gradlew test` | `./gradlew test --tests <Class>` | `./gradlew test --tests "<Class>.<method>"` |
+
+With a `package.json`, run through the manager whose lockfile exists (`npm`, `pnpm`, `yarn`, `bun`). In a monorepo, run from the package the tests belong to.
+
+If no framework can be found, say so and stop. Do not install one unasked.
+
+## Step 2: Run
+
+- **Run once, not in watch mode.** Several runners watch by default when started interactively (Vitest, Jest with `--watch`); a watching run never ends and the result never comes back. Use the run-once form (`vitest run`, `jest --watchAll=false`, `CI=true`). If the user asks for watch mode, give them the command to run in their own terminal.
+- Run exactly what was asked for: the named file or test, else everything.
+- If the run cannot start (a missing dependency, a syntax error, a config error), that is not a test failure: report it as what it is.
+
+## Step 3: Report
+
+Lead with the counts: passed, failed, skipped, and how long it took. Then, for each failure:
+
+- the test's name and its file;
+- expected against actual, or the error message;
+- the line of the stack trace that is in the project's own code.
+
+Do not paste the whole output when a few lines carry it. Report skipped and disabled tests as skipped; they are not passes.
+
+**Do not fix anything.** This skill runs and reports. If the user then asks for a fix, the tests are the specification: change the code under test, not the test, unless the user says the test is the thing that is wrong.
+
+## Credits
+
+Adapted from the `/test` command in "[Test-Driven Development with Claude Code: Practical Guide](https://aiskill.market/blog/tdd-with-claude-code)" by Duke Harewood (aiskill.market, January 28, 2026).