$npx -y skills add andrewstellman/quality-playbook --skill hybrid_fixtureA skill plus Python orchestrator that helps a small business reconcile expense receipts against their bookkeeping ledger. Used by bin/tests/test_classify_project.py as a known-Hybrid target for the v1.5.3 project-type classifier: SKILL.md at fixture root AND substantial code un
| 1 | # Receipt Reconciler (Hybrid classifier fixture) |
| 2 | |
| 3 | A skill plus Python orchestrator that helps a small business reconcile |
| 4 | expense receipts against their bookkeeping ledger. Used by |
| 5 | `bin/tests/test_classify_project.py` as a known-Hybrid target for the |
| 6 | v1.5.3 project-type classifier: SKILL.md at fixture root AND substantial |
| 7 | code under `bin/`. |
| 8 | |
| 9 | The fixture is a synthetic skill, not a real one in production use. Its |
| 10 | SKILL.md prose is shorter than its code LOC; the heuristic should classify |
| 11 | it as Hybrid (the band where SKILL.md exists alongside dominant code). |
| 12 | |
| 13 | ## Overview |
| 14 | |
| 15 | Receipts arrive as photos, PDFs, or paper that has been scanned. The |
| 16 | ledger is a CSV exported from the bookkeeping system. The skill's job is |
| 17 | to match each receipt to a ledger entry, flag mismatches, and produce a |
| 18 | reconciliation report the operator can hand to their accountant. |
| 19 | |
| 20 | The skill is hybrid because the matching itself is mechanical (CSV parsing, |
| 21 | fuzzy string matching, date arithmetic) but the judgment calls — is this |
| 22 | $24.99 charge from the same coffee shop as that $25.04 charge in the |
| 23 | ledger, or two separate visits — need a model to decide. |
| 24 | |
| 25 | ## Phase 1 — Receipt ingestion |
| 26 | |
| 27 | The orchestrator's `bin/ingest.py` walks the receipts folder, OCRs anything |
| 28 | that needs OCR, and emits a normalized JSON record per receipt: vendor, |
| 29 | date, amount, last-four-of-card. The JSON is the contract between the |
| 30 | mechanical layer and the skill prose. |
| 31 | |
| 32 | The skill's role in Phase 1 is to verify the OCR output: when the OCR |
| 33 | confidence is below the configured threshold, the skill is asked to look |
| 34 | at the original image and either correct the field or flag it as unread- |
| 35 | able. Unreadable receipts go into a manual-review queue. |
| 36 | |
| 37 | ## Phase 2 — Ledger ingestion |
| 38 | |
| 39 | The orchestrator's `bin/ledger.py` parses the bookkeeping CSV, normalizes |
| 40 | column names, and emits a JSON record per ledger entry. No skill involvement |
| 41 | in Phase 2 — the CSV format is fixed, parsing is mechanical. |
| 42 | |
| 43 | ## Phase 3 — Matching |
| 44 | |
| 45 | The orchestrator's `bin/matcher.py` proposes candidate matches: for each |
| 46 | receipt, the top-K ledger entries by combined date proximity and amount |
| 47 | similarity. The skill is asked to confirm or reject each proposed match, |
| 48 | with an explanation when a match is rejected. |
| 49 | |
| 50 | The skill's confirmations and rejections are written back through the |
| 51 | orchestrator's API so the orchestrator can track which receipts have been |
| 52 | matched and which still need human review. |
| 53 | |
| 54 | ## Phase 4 — Reconciliation report |
| 55 | |
| 56 | The orchestrator's `bin/report.py` consolidates matched receipts, unmatched |
| 57 | receipts, and unmatched ledger entries into a single report. The skill is |
| 58 | asked to write the report's narrative summary: which categories had clean |
| 59 | reconciliation, which had problems, what the operator should look at first |
| 60 | when reviewing. |
| 61 | |
| 62 | ## Anti-patterns |
| 63 | |
| 64 | The skill explicitly does not categorize expenses against tax categories, |
| 65 | estimate deductibility, or otherwise act as a tax advisor. Those decisions |
| 66 | are out of scope and the skill points the operator at their accountant. |