菜单
Triage and fix a reported bug in aireceipts, with a red-then-green test as proof. Use when the user reports a bug, points at a failing issue, or asks to fix something broken (e.g. via an agent:fix label).
用 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 | fix-issue |
| description | Triage and fix a reported bug in aireceipts, with a red-then-green test as proof. Use when the user reports a bug, points at a failing issue, or asks to fix something broken (e.g. via an agent:fix label). |
| trigger | /fix-issue |
Read the issue. Classify it: a receipt output bug (I5 golden regression?), a pricing
bug (I2 — did it fabricate or misattribute a $?), a parse bug (a real vendor
transcript the adapter mishandles), or a CLI/UX bug. The classification decides which
gate matters most.
Before touching product code, write the test that fails because of the bug — a fixture
transcript, a golden, or a unit test, whichever is closest to the report. Run it
unmasked and confirm it's red (echo $? is non-zero) for the right reason, not a typo
in the test itself.
Smallest change that makes the failing test pass without breaking others. If the fix
touches src/pricing/**, keep the Stryker mutation score from decreasing. If it changes
receipt output, update goldens deliberately and explain why in the PR — a golden diff
with no explanation is a red flag for reviewers.
Show both: the test failing before the fix (paste or reference the pre-fix run) and passing after. This is the actual proof the bug is fixed, not just "tests pass now."
Full unmasked verification block. Branch off origin/main, PR titled
fix: <short description> referencing the issue. Never touch main directly.
