菜单
Multi-agent review of user-facing docs (README, docs/**, --help text) for simplicity and correctness. Use before any release, after any feature PR that touched docs, or when asked to review docs.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
File an issue on this repo's GitHub tracker (anandgupta42/receipts) via `gh issue create`. Use when the user asks to file, add, or track an issue for aireceipts. This repo's issues live on GitHub — do not file them into any local or external issue tracker.
Cut an aireceipts release: verify the version tag matches the manifest, generate a changelog from conventional commits, and prep for npm publish (human clicks). Use when the user asks to release, cut a version, or publish a new version.
Adversarially validate a draft spec BEFORE the maintainer sees it. Use after write-spec finishes, or when the user asks to validate/review a spec. A draft without a validation record cannot be approved or built.
Implement an approved spec end-to-end for aireceipts, including agent-team waves for milestone (M-file) specs. Use when the user says implement/build/ship a spec (e.g. 'build SPEC-0001', 'ship M1').
Critically review an aireceipts PR as an independent critic — different model family from whoever built it, audits test-diffs hardest. Use when asked to review a PR, act as the critic, or before landing/merging any change.
Multi-persona release vetting board — PM, EM, Designer, QA personas deeply analyze the release candidate; produces the signed verdict file WITHOUT which /release refuses to proceed. Use before any release, when asked to vet a release, or when cutting a version.
| name | review-docs |
| description | Multi-agent review of user-facing docs (README, docs/**, --help text) for simplicity and correctness. Use before any release, after any feature PR that touched docs, or when asked to review docs. |
| trigger | /review-docs |
Docs are product surface. This skill runs at least two independent agent reviewers in separate contexts — never one agent wearing both hats, never the agent that wrote the docs — then consolidates findings and applies fixes.
Prompt an agent that has NEVER seen this repo: it gets README.md (and only what the README links) and must, in order: (1) say in one sentence what the tool does; (2) run the quickstart commands verbatim against a fixture; (3) flag every place it stumbled — jargon, missing steps, buried assumptions, anything it had to guess. Length findings count: a section a cold reader skips is a section to cut. Deliverable: stumble list + the one-sentence comprehension check.
A separate agent (different context; Codex preferred — different model family) audits every claim against the code:
--help exists and runs with exit 0 on a
fixture (execute them — don't eyeball).file:line) or a test; overclaims are findings
(I3: docs never promise more than the code does — "never/always/zero" claims get
special scrutiny).Merge both lists, dedupe, apply the accepted fixes (docs edits are cheap — default to fixing, not filing), note rejected findings with one-line reasons. Record the panel's verdict (reviewers, findings count, fixes applied) in the PR or release notes. Docs review is BLOCKING for a release; advisory-but-expected for feature PRs.