receipt-render

# Receipt Render Read-only render of a **completed diamond** as a shareable, factual one-page **work receipt** — the problem as it was framed, the assumptions tested, what was killed and what was kept. It follows the render fleet's shared conventions and consent gate (`${CLAUDE_PLUGIN_ROOT}/engine/render-conventions.md`; Check 43 applies via the `-render` name), but unlike the diagram specialists (`diamond-render` / `ost-render` / `cycle-render`) it produces a shareable prose artifact and is **not** a `/mycelium:render` dispatcher target. The receipt is a **carrier the user may choose to hand to a colleague**. It is generated fully **locally** — nothing is transmitted. Its footer carries a volitional data flow (an origin line + a pre-filled GitHub Discussion deep-link) so that, *if the user chooses*, the work can surface back to the maintainer. The skill never posts anything; a human reviews a draft and submits it. ## Why this exists (the honest framing) A silent adopter is invisible to a solo maintainer. This skill does not generate adoption and does not phone home. It gives a real piece of completed work a shareable shape with a low-friction, non-leading way for the user (or a colleague they hand it to) to surface themselves — if they want to. It surfaces **behaviour** (what was built), never solicits **praise** (whether it was good). ## When NOT to use - To render a diamond's *state* as a diagram → `/mycelium:diamond-render`. This skill renders *completed work as pro...