Shipping Artifacts: The Docs That Make AI-Built Code Reviewable

Purpose

AI agents write code fast, but they leave no durable record of intent — what the system is supposed to do, who is allowed to do what, where the secrets live, which rules are actually verified. Without that record, no human (and no auditing agent) can tell whether the code is safe to ship. This skill defines the small set of documents that restore reviewability.

These docs are written for two readers: a human reviewer and the next AI coding agent. They are the intended-state half of every later audit — a security or performance review is only as good as the intent it can compare the code against.

Locations and names: the repo's setup wins

Every location, file name and doc-format convention in this plugin is a default. The host repo's own setup comes first. Before writing anything (a system doc, the coverage map, an audit report), look for that setup:

1. Agent instructions — AGENTS.md, CLAUDE.md, and whatever they import or point to. They often name the docs folder, the files in it, who maintains each one, and how dates are recorded.
2. A docs location — an existing docs/, documentation/ or similar folder.
3. Existing equivalents — a document that already covers what one of the files below covers, under any name (ARCHITECTURE.md, docs/security.md, docs/env.md). Match on what it covers, not on its file name.
4. An existing test-coverage map — a file that maps behaviour to the tests covering it, such as docs/test-coverage.md. Match on what it covers: a TESTS.md or testing.md that describes how the repo tests is the testing method, not the coverage map.
5. A reports location — wherever the repo already keeps audit or review output.

Then: