capture-report

name	capture-report
description	Use when capturing an investigation, PoC, measurement, or finding as a durable report. Create one directory per purpose with an evidence-complete README stating the question, method, and result, authored in isolation. Trigger on "write up the findings", "document this PoC".

Capture an investigation as a purpose-named report

A report is a durable artifact: the evidence plus the conclusion, one directory per purpose.

• Name by purpose, not by sequence — the directory name must tell a reader why it exists (never test1/).
• Author in isolation. If the work touches the product, build it in a throwaway working copy (the isolate → cherry-pick operation, the isolate-and-integrate skill) so experiments never reach the canonical branch; move the finished artifacts into the report afterward.
• Evidence-complete README, in order:
  1. Purpose — the question being answered.
  2. Method — what was built or measured, and how to reproduce it.
  3. Result / Evidence — the concrete outcome (numbers, captured output, pass/fail), enough to trust without rerunning.
  4. Next steps — only if concrete.

Prefer runnable snippets and real captured output over prose claims. Where to put reports and how to commit them is project-specific — see the project's CLAUDE.md.

Zero-knowledge acceptance gate

Evaluate the finished README without giving the reviewer a repository checkout or any other document. The README must itself define every proper noun and local term at first use, identify the hardware and software under test, reproduce the method, and contain enough evidence to establish the result.

• Reproduce supporting source lines or comments verbatim in fenced blocks and cite path:line; a pointer without the quoted evidence is insufficient.
• Reproduce commands and actual output verbatim, including invocation context, timestamp, and exit status.
• Do not link to another report, doc, wiki, issue, pull request, or external URL. Inline every needed fact and its evidence. Only same-report artifacts and a path:line accompanying already-quoted source are permitted pointers.
• Do not leave project terms undefined, use ambiguous backward references, or narrate draft history and corrections. Rewrite the current account directly.
• Never claim in the report, related pull request, commit, or handoff that the report is self-contained, zero-knowledge readable, independent, or equivalent. If such a claim is written, discard the report work unit and restart from a fresh draft or branch; deleting only the sentence does not cure the failure.

The README is unfinished if a new reader, given only its text, cannot state what was examined, on which hardware, by which method, and with what result.