@noir-ai/skills 1.9.3 → 1.9.4-beta.2

package/builtin/noir-execute/SKILL.md

@@ -1,17 +0,0 @@
----
-name: noir-execute
-description: Use when executing a written implementation plan, task by task — driving the SDD execute phase.
----
-
-Execute an approved implementation plan one task at a time, with a review gate between tasks. The plan is the contract; this skill drives it.
-
-## Procedure
-1. **Load the plan.** Read the plan file under `.noir/plans/`. If none, stop and point to `noir-plan`.
-2. **One task at a time.** Work the tasks in order. For each task: read its files/interfaces, write the failing test, implement minimally, run the test, commit when green.
-3. **Review between tasks.** After each task, run typecheck + lint + tests and review the diff before moving on. The SDD engine records the execute-phase checkpoint observably (`noir.checkpoint`).
-4. **Stay in scope.** Commit per logical change with a conventional-commit message; never bundle unrelated changes. If you discover missing scope, return to `noir-clarify` / `noir-plan` rather than improvising.
-5. **Hand off to verify.** When all tasks are done, point to `noir-verify` before claiming completion.
-
-## Notes
-- Discipline is observable, not rhetorical: the SDD engine's gates record that each task was reviewed. This skill is the playbook.
-- On doubt mid-execution, return to the plan or clarify — do not guess.

package/builtin/noir-explore/SKILL.md

@@ -1,16 +0,0 @@
----
-name: noir-explore
-description: Use when answering means sweeping many files, directories, or naming conventions — to fan out read-only search and return the conclusion, not the file dumps.
----
-
-Locate code across the codebase without reading every file into context. Prefer a read-only search fan-out that returns locations and a short conclusion; read whole files only for the few you actually need to edit.
-
-## Procedure
-1. **Frame the question.** State precisely what you are looking for — a symbol, a pattern, a naming convention, or where something is defined. A fuzzy query yields a fuzzy sweep.
-2. **Fan out.** Use `grep` / `glob`, or dispatch a read-only search subagent across the likely locations. State the search breadth up front (medium for a focused module, very thorough for cross-package naming or convention questions).
-3. **Return the conclusion.** Summarize where things live with `file:line` references and the one-line gist of each match — not the raw matched lines. Call out conventions discovered (e.g. "errors are thrown in `src/errors/`, not at call sites").
-4. **Read targeted.** Open only the specific files or line ranges you need to act on. Everything else stays a citation.
-
-## Notes
-- Keep raw search output out of context where possible — process it in a sandbox or subagent and surface only the derived answer. Large `grep` dumps cost context for the rest of the session.
-- This skill locates code — it does not review, audit, or refactor it. Hand to `noir-review` for judgment on what you found.

package/builtin/noir-intake/SKILL.md

@@ -1,17 +0,0 @@
----
-name: noir-intake
-description: Use when starting a new feature or task from a raw idea, ticket, or issue — before any design or code.
----
-
-Capture a raw request as a grounded task stub before any design or implementation. The job here is to record what is actually known and flag what is not — not to solve, design, or paraphrase ambiguity away.
-
-## Procedure
-1. **Capture the raw input.** Take the idea, ticket, or issue text as-is. Quote the originating words; do not silently summarize. If the source is a paste, keep the paste.
-2. **Ground in project context.** Read `CLAUDE.md` / `AGENTS.md`, recent commits, and any neighbor spec under `.noir/specs/`. Note which existing module or package this request most likely touches — as a hypothesis, not a decision.
-3. **Draft the task stub.** Write `.noir/tasks/<id>.md` with: problem statement (in the user's words), rough acceptance criteria (observable, not vague), likely touch points, and an explicit *Open questions* list. Every blank becomes an open question — never an assumption.
-4. **Start the SDD task.** Call `noir.workflow_status` to confirm the task is at the `intake` phase. The engine records the intake checkpoint observably via `noir.checkpoint`; you do not need to assert it.
-5. **Hand off.** Point to `noir-clarify` to resolve the open questions. Do not design, plan, or code in this phase.
-
-## Notes
-- Intake is a recording step, not a solution step. If you cannot tell whether something is a requirement, write it as an open question.
-- Do not invent acceptance criteria to fill blanks — surface them. `noir-clarify` exists to close them.

package/builtin/noir-plan/SKILL.md

@@ -1,20 +0,0 @@
----
-name: noir-plan
-description: Use when you have an approved spec and need a step-by-step implementation plan — before touching code.
----
-
-Write a step-by-step implementation plan from the approved spec, sized so each task is one reviewable commit. The plan is what `noir-execute` drives; make it complete enough that execution needs no new design decisions.
-
-## Procedure
-1. **Read the spec.** Open the approved spec under `.noir/specs/`. Every requirement, acceptance criterion, and non-goal must map to at least one task — if a requirement has no task, add one before you consider the plan done.
-2. **Lay out tasks in execution order.** For each task, write:
-   - **Files** — exact paths to create and modify (with line ranges where relevant).
-   - **Interfaces** — what the task consumes from earlier tasks (exact signatures) and what it produces for later ones (exact names and types). This block is how a neighbor task learns the contract.
-   - **Test** — the failing test that proves the task, and the command that runs it.
-3. **Right-size each task.** A task is one reviewable commit. Split anything that bundles unrelated changes; merge anything that is just a sub-step of a single change. Prefer bite-sized tasks that can fail and pass independently.
-4. **Self-review the plan.** Check spec coverage (point to a task per requirement), placeholder scan (no TBD / TODO / vague "implement the thing"), and type consistency across tasks (a function called `clearLayers()` in Task 3 must still be `clearLayers()` in Task 7). Fix inline.
-5. **Write and hand off.** Save to `.noir/plans/<topic>.md`. The SDD engine records the plan checkpoint observably via `noir.checkpoint`. Point to `noir-execute`.
-
-## Notes
-- Assume the implementer is a skilled developer with zero context for this codebase. Document the paths, names, and test commands explicitly — no placeholders, no "you know what I mean".
-- If you cannot complete a task without a new design decision, the spec is incomplete — route back to `noir-spec` rather than deciding in the plan.

package/builtin/noir-pr/SKILL.md

@@ -1,12 +0,0 @@
----
-name: noir-pr
-description: Use when committing, pushing, and opening a pull request in one flow.
----
-
-# noir-pr
-
-> **Stub:** this skill ships as a valid, loadable placeholder in S5; its full playbook is deepened in a later slice.
-
-**When to use:** the work is commit-ready and you want to push it and open a PR end-to-end.
-
-**For now:** confirm the commit is sound, confirm the push target with the user, push the branch, then open a PR with `gh pr create` — title and body describing what changed and why.

package/builtin/noir-review/SKILL.md

@@ -1,28 +0,0 @@
----
-name: noir-review
-description: Use when completing a task or before merging — to verify the work meets its requirements.
----
-
-Run a real review on completed work before claiming it done. This skill covers both halves: requesting a review with precisely crafted context, and receiving review feedback with technical rigor rather than performative agreement. The reviewer gets the work product, never your session's reasoning history.
-
-## Procedure
-
-### Requesting a review
-1. **Scope the diff.** Capture `BASE_SHA` (the commit the work started from — never `HEAD~1`, which silently truncates a multi-commit task) and `HEAD_SHA`. Write a one-line description of what was built and a pointer to the plan or requirements it must satisfy.
-2. **Dispatch a reviewer with crafted context, not session history.** Hand the reviewer: the description, the plan-or-requirements pointer, the BASE/HEAD shas, and the diff as a file (e.g. `git diff <BASE> <HEAD> -U10 > .noir/reviews/<task>-diff.patch`). A fresh reviewer seeing only the work product stays focused and preserves your context for continued work.
-3. **Triage findings by severity.** Fix Critical issues immediately, fix Important issues before moving on, and record Minor issues for the final whole-branch pass. Do not batch them all into one fix run.
-4. **Push back when the reviewer is wrong.** If a finding is technically incorrect for this codebase, lacks context, or violates an accepted decision, respond with technical reasoning — working tests, code that proves the existing behavior, or the spec line that mandates the current shape. Do not implement a suggestion just because a reviewer raised it.
-
-### Receiving feedback
-5. **Read, then verify — do not react.** Restate the requirement in your own words (or ask for clarification) before implementing. Check each item against the codebase: is it technically correct here, does it break existing behavior, does it conflict with a prior decision?
-6. **Clarify unclear items as a batch.** If part of a multi-item review is unclear, stop and ask about every unclear item before implementing any of them — items are often related, and partial understanding produces wrong implementation.
-7. **YAGNI-check "implement it properly" suggestions.** Before adding a suggested abstraction or endpoint, grep the codebase for actual usage. If nothing calls it, propose removal before proposing the proper version.
-8. **Acknowledge correct feedback quietly.** State the fix ("Fixed: extracted the magic number to `PROGRESS_INTERVAL`"). No performative agreement, no thanks — the code itself is the acknowledgment.
-
-### Close the loop
-9. **Record the review.** Capture the verdict, the findings acted on, and any deferred Minor items via `noir.checkpoint` (the SDD verify gate). For the final whole-branch review, point `MERGE_BASE = git merge-base main HEAD` so the reviewer sees the entire branch.
-
-## Notes
-- External feedback is a suggestion to evaluate, not an order to follow. Verify, question, then implement.
-- The reviewer and the implementer both report to the work's requirements. If a suggestion violates the spec or adds unused surface area, the answer is evidence-based pushback, not compliance.
-- Discipline is observable, not rhetorical: the SDD engine records that the verify gate ran, with the diff and verdict attached.

package/builtin/noir-skill-author/SKILL.md

@@ -1,12 +0,0 @@
----
-name: noir-skill-author
-description: Use when creating new skills or editing existing ones — TDD for process docs.
----
-
-# noir-skill-author
-
-> **Stub:** this skill ships as a valid, loadable placeholder in S5; its full playbook is deepened in a later slice.
-
-**When to use:** you are authoring or revising a skill and want it loadable, valid, and genuinely useful when invoked.
-
-**For now:** frontmatter is `name: noir-<kebab>` plus a real WHEN `description`, a short body that tells the model when and how to act, and a reference file only if the skill needs one — validate before shipping.

package/builtin/noir-tdd/SKILL.md

@@ -1,49 +0,0 @@
----
-name: noir-tdd
-description: Use when implementing any feature or bugfix — to write the failing test before the implementation.
----
-
-Write the test first, watch it fail for the right reason, then write the minimal code that makes it pass. The cycle is red → green → refactor, in that order. The proof that a test actually tests something is that you saw it fail before the feature existed.
-
-## Procedure
-
-### RED — write one failing test
-- One behavior per test. If the name contains "and", split it.
-- A clear name that describes behavior (`retries failed operations 3 times`), not an index (`test1`).
-- Real code paths, not mocks of the code under test — mock only external boundaries you do not own.
-- Test the public behavior, not the implementation. A test that asserts on internal call shape breaks on every refactor.
-
-### Verify RED — watch it fail
-Run the test before writing any implementation. Confirm:
-- it fails (does not error — a syntax or import error is not a red);
-- the failure message is the one you expected;
-- it fails because the feature is missing, not because of a typo in the test.
-
-A test that passes immediately is testing existing behavior. Fix the test, not the cycle.
-
-### GREEN — write the minimal code
-Write the simplest code that turns the test green. No speculative options object, no "while I'm here" cleanup, no extra branches the test does not exercise. YAGNI is the rule in this step — the next test will ask for the next feature.
-
-### Verify GREEN — watch it pass
-Run the full suite, not just the new test:
-- the new test passes;
-- no other test regressed;
-- the output is pristine — no warnings, no deprecation notices, no swallowed errors.
-
-If another test broke, the implementation is not done. Fix it now, do not commit and move on.
-
-### REFACTOR — clean up, stay green
-Only after green: remove duplication, improve names, extract helpers. Run the suite after each refactor step. No new behavior lands during refactor — that requires a new RED.
-
-### Repeat
-Pick the next behavior, write its failing test, cycle again.
-
-## Why order matters
-Tests written after the implementation pass immediately, and a passing test proves nothing — it might test the wrong thing, it might assert on the implementation rather than the requirement, and you never saw it catch a bug. Test-first forces edge-case discovery before the implementation makes the edge case look easy.
-
-A bug found in the wild is treated the same way: write the failing test that reproduces it, watch it fail, fix at the root, watch it pass. The test stays in the suite as the regression guard.
-
-## Notes
-- Discipline is observable, not rhetorical: the SDD engine records the execute-phase gate, and a regression test counts only after a red→green cycle was observed — a test that passed once is not evidence of a fix.
-- If the test is hard to write, the design is hard to use. Listen to the test before fighting it; the friction usually names a real coupling problem.
-- When you genuinely must explore an API before designing it, throw the exploration away and start the implementation from a fresh failing test. "Keep it as reference" is how tests-after slips in.

package/builtin/noir-test/SKILL.md

@@ -1,12 +0,0 @@
----
-name: noir-test
-description: Use when writing tests — for test design, coverage, and edge cases (not just running them).
----
-
-# noir-test
-
-> **Stub:** this skill ships as a valid, loadable placeholder in S5; its full playbook is deepened in a later slice.
-
-**When to use:** you are writing tests and want them to actually catch bugs — design and coverage, not just running a suite.
-
-**For now:** name each test for a behavior, cover the happy path plus the null/empty/boundary/error cases, and assert on observable outcomes rather than internals.

package/builtin/noir-verify/SKILL.md

@@ -1,17 +0,0 @@
----
-name: noir-verify
-description: Use when about to claim work is complete or fixed — to run verification and gather evidence before asserting success.
----
-
-Run the commands that prove the claim, read their output, and report the actual status with evidence. No completion or fix claim is made until fresh output backs it.
-
-## Procedure
-1. **Name the claim and its proof.** For each thing you are about to assert ("tests pass", "lint clean", "build succeeds", "bug fixed", "requirements met"), name the exact command that would prove it. A claim with no proof command is not yet a claim.
-2. **Run each command fresh.** Full invocation in this turn — not a previous run, not a cached result, not a partial check. Capture stdout, exit code, and failure counts.
-3. **Read the output before asserting.** If the output confirms the claim, state the claim with the evidence. If it contradicts the claim, state the actual status with evidence and stop — do not soften, do not promise a follow-up.
-4. **Refuse common substitutes for evidence.** "Should work now", "I'm confident", "the linter passed so the build is fine", "the agent reported success", and "partial check is enough" are not evidence. Partial output proves nothing about the whole.
-5. **Record and route.** Capture the verification result via `noir.checkpoint` (the SDD engine's verify gate). Only then point to `noir-document`.
-
-## Notes
-- The rule is procedural, not rhetorical: name the proof, run it, read it, then claim. The engine records that the verify gate ran with output attached.
-- A regression test counts only after a red→green cycle is observed. A test that passes once is not evidence of a fix.