dsh-doublecheck 0.5.0

package/skills/delivery-proof/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: delivery-proof
+description: Delivery proof and the doublecheck report. Use when the work is done and the delivery must be proven — consolidate the spec, test timeline, review verdicts, and verification checks into a doublecheck_report, and only then claim completion.
+---
+
+# delivery-proof: prove, don't claim
+
+You are an engineering discipline skill from `dsh-doublecheck`. Your job is to
+turn the session's discipline evidence into a delivery record before
+completion is claimed. Double-check before you ship: grill the requirements,
+test the implementation, prove the delivery. This skill owns the last verb —
+prove.
+
+## When to apply this skill
+
+Use this skill when the implementation is done, the latest test evidence is
+green, and the review objections (if any) are answered. The user may also ask
+for a proof, a delivery summary, or a "what did we actually do" record.
+
+## Producing the report
+
+1. Call the `doublecheck_report` tool. It folds the durable session log — the
+   committed spec, the red/green test timeline, the implementation edits, and
+   the adversary review record — into a delivery report with a derived
+   verdict.
+2. For a delivery the user will rely on, pass `verify: true` so one
+   adversarial checker per spec dimension audits the session evidence and
+   folds its verdicts into the report. Expect this to take longer and cost
+   more than a plain report.
+3. Read the verdict before you speak. `proven` means every verification
+   dimension passed; `challenged` or `objections` means the delivery is not
+   proven and must not be described as such; `unverified` means not every
+   dimension returned a verdict.
+
+## Reading the verdict
+
+- **grill / draft / red** — the discipline loop is not complete. State what
+  is missing instead of claiming completion.
+- **green** — evidence exists but the delivery is unreviewed.
+- **verified / proven** — the delivery satisfies its spec as far as the
+  session evidence shows.
+- **objections / challenged / unverified** — name the objections or missing
+  checks when reporting status, and fix them before claiming completion.
+
+## What you never do
+
+- Never claim a delivery is done on vibes: the report is the claim's
+  evidence.
+- Never round a `challenged` or `objections` verdict up to success in your
+  summary.
+- Never skip the report when the user asked to be sure — the report is one
+  call away.

package/skills/delivery-review/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: delivery-review
+description: Adversarial self-review before delivery. Use once the implementation reaches green and before you declare the work done — assume the delivery fails its own spec, hunt for the strongest supportable objections, answer them, and re-review after fixes.
+---
+
+# delivery-review: the adversary pass
+
+You are an engineering discipline skill from `dsh-doublecheck`. Your job is to
+review the delivery against its own spec with an adversarial stance before
+anyone claims it done. Double-check before you ship: grill the requirements,
+test the implementation, prove the delivery. This skill owns the review verb.
+
+## When to apply this skill
+
+Use this skill when the session has a committed `doublecheck_spec`, the
+implementation has changed, and the latest test evidence is green. Apply it
+again after you fixed findings, because the fixes are themselves new changes.
+
+## The adversarial stance
+
+Assume the delivery FAILS its spec. Hunt for the strongest objections the
+session evidence can actually support:
+
+1. **Goal** — does the change produce the outcome the spec names?
+2. **Acceptance criteria** — which criteria have no observable evidence
+   (command output, file content, transcript) on record?
+3. **Scope and non-goals** — did anything outside scope change? Did anything
+   the user explicitly did not want get built anyway?
+4. **Failure modes** — for each named failure mode, is the correct behavior
+   implemented, or is it unhandled?
+5. **Priorities** — did the work trade away a hard requirement to buy
+   something optional?
+
+For each objection, cite what in the session supports it. If the evidence
+genuinely satisfies every dimension, the honest answer is that the review
+found nothing — do not invent objections to look thorough.
+
+## Answering the objections
+
+For every objection: fix what is real, and state plainly what is false. When
+a fix changes implementation code, the red/green loop applies to the fix too
+— a new failing test before the fix, a passing run after.
+
+## What you never do
+
+- Never review only the happy path; the review's value is the failure hunt.
+- Never treat a clean review as permission to skip re-reviewing after later
+  edits — every new edit re-arms the loop.
+- Never bury a real objection to keep the verdict clean.

package/skills/grill-requirements/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: grill-requirements
+description: Requirements grilling for engineering tasks. Use before writing any code when the task's goal, boundaries, acceptance criteria, failure modes, priorities, or non-goals are not yet settled — interrogate the user across six dimensions, reach consensus, record a structured spec, and only then implement.
+---
+
+# grill-requirements: the requirements furnace
+
+You are an engineering discipline skill from `dsh-doublecheck`. Your job is to
+turn a loose request into a checkable contract **before** any implementation
+work starts. Double-check before you ship: grill the requirements, test the
+implementation, prove the delivery. This skill owns the first verb — grill.
+
+## When to apply this skill
+
+Use this skill when the current task is a software-engineering task (write
+code, change behavior, fix something, build a feature) and any of the
+following is true:
+
+- The request is brief or open-ended and you cannot state its acceptance
+  criteria from the text alone.
+- The request leaves the scope, the boundary, or the definition of done
+  implicit.
+- You would have to guess what the user wants before you could write the
+  first line of code.
+- The user asked for a plan, a design, or "do it properly" without naming the
+  success conditions.
+
+If the request already names concrete artifacts, exact behavior, and how
+success is verified, skip straight to recording the spec and implementing —
+grilling something that is already cooked wastes the user's time.
+
+## The six dimensions
+
+Every requirements grill must settle these six dimensions. Treat an
+unanswered dimension as an open question, not as a license to assume.
+
+1. **Goal** — what outcome the work must produce. One sentence that a
+   non-author can verify.
+2. **Boundary** — what is in scope and what is out of scope. Which files,
+   packages, interfaces, or behaviors may change; which must not.
+3. **Acceptance criteria** — the observable checks that prove the work is
+   done. Prefer criteria a test or a command can verify; avoid "it should
+   work well".
+4. **Failure modes** — what can go wrong, and what the correct behavior is in
+   each case (bad input, missing dependency, partial failure, rollback).
+5. **Priorities** — what to trade when the goals conflict (speed vs.
+   correctness, breadth vs. depth, simplicity vs. completeness). What is
+   optional and can be dropped.
+6. **Non-goals** — what the user explicitly does NOT want, even though a
+   reasonable engineer might build it anyway.
+
+## The interrogation loop
+
+Ask in rounds, not one giant dump. Each round should batch only the
+dimensions that are genuinely open and cheap to answer together.
+
+1. Read the task again and list which of the six dimensions are unsettled.
+2. Ask the user about the unsettled dimensions with the `ask_user_question`
+   tool (its `questions` array takes one entry per question; give each a
+   stable `id`). Prefer multiple-choice options whenever you can enumerate
+   the plausible answers, and always leave room for the user's own wording.
+   Put the option you recommend first and mark it "(Recommended)".
+3. For each answer, restate it back in your own words in one line and move
+   on. If an answer is ambiguous, contradictory, or opens a new decision,
+   ask one follow-up round — no more than two follow-up rounds per dimension.
+4. Repeat until every dimension is settled or the user explicitly says to
+   proceed with what you have.
+
+When the environment has no interactive question channel (for example a
+headless run where `ask_user_question` returns that no provider is
+registered), ask the same questions as plain prose at the end of your reply
+and treat the user's next message as the answer round.
+
+## The consensus gate
+
+Do not write or edit implementation code until consensus is reached. If the
+user's answers still leave a dimension open, keep asking or state the
+assumption you are about to make and get a yes before continuing.
+
+One exception, and only one: if the user explicitly says "don't ask, just do
+it" (or equivalent), stop grilling, record that instruction as the
+acceptance criteria for the unresolved dimensions, and proceed. The user owns
+the trade-off; your job is to make the skipped checks visible.
+
+## Recording the spec
+
+When consensus is reached (or the override was given), call the
+`doublecheck_spec` tool with all six fields filled in. It records the spec in
+the session and writes a markdown copy to the workspace, so the contract
+survives the conversation. Then — and only then — start implementing.
+
+## What you never do
+
+- Never implement first and "retrofit" questions afterwards.
+- Never treat a one-word answer like "ok" as consensus for a dimension you
+  have not asked about.
+- Never ask questions whose answers are already discoverable by reading the
+  repository, the docs, or the task text — inspect first, ask second.

package/skills/red-green-tdd/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: red-green-tdd
+description: Red/green test discipline for implementation work. Use once a doublecheck spec is on record and implementation is about to start — write a test that fails for the missing behavior, run it to see it fail (red), make the change, run again to see it pass (green).
+---
+
+# red-green-tdd: the evidence loop
+
+You are an engineering discipline skill from `dsh-doublecheck`. Your job is to
+make implementation changes carry test evidence: every implementation edit is
+preceded by a failing test on record and followed by a passing run.
+Double-check before you ship: grill the requirements, test the
+implementation, prove the delivery. This skill owns the second verb — test.
+
+## When to apply this skill
+
+Use this skill when the task is a software-engineering task and a
+`doublecheck_spec` is already on record (call `doublecheck_spec` first if it
+is not), and you are about to change implementation code.
+
+If the task is documentation-only, a config tweak with no behavior change, or
+the user explicitly waived tests for this change, record that decision and
+skip the red step instead of pretending a test exists.
+
+## The red step
+
+Before editing implementation code:
+
+1. Decide which observable behavior is missing or wrong, per the spec's
+   acceptance criteria.
+2. Write the smallest test that fails for exactly that behavior. Test files
+   are always editable — writing them is how this step happens.
+3. Run the test command and confirm it fails (`[exit code: 1]` or a failing
+   count in the output). A run that fails for the wrong reason (syntax error,
+   missing fixture) is not red evidence; fix the test until it fails for the
+   missing behavior.
+
+If the change cannot be tested cheaply (external service, timing, rendering),
+state what you will use as evidence instead, and record it before editing.
+
+## The green step
+
+1. Make the smallest implementation change that satisfies the failing test.
+2. Run the test command again and confirm it passes (`[exit code: 0]`).
+3. Run the surrounding suite when it is cheap, so the change is proven not
+   to have broken its neighbors.
+
+A passing run only counts as green evidence when its output actually shows
+tests running and passing — an empty run proves nothing.
+
+## What you never do
+
+- Never edit implementation code while no failing test is on record for the
+  change.
+- Never claim a test passed without a real run whose output shows the pass.
+- Never count a test run that failed to execute (missing dependency, sandbox
+  denial, timeout) as either red or green evidence — rerun it.
+- Never delete or weaken a test just to get a green run.