Checklists for the AI

---
name: metrc-reconcile
description: >-
  Compare a Metrc active-packages CSV export with an inventory/ERP packages CSV
  export (Distru or any system with a Metrc tag column), find every mismatch by
  tag and quantity using the bundled script, then explain the most likely cause
  of each mismatch and what to check first. Use when the user says "reconcile
  Metrc", "Metrc check", "run the Metrc reconciliation", "why don't Metrc and
  inventory match", or provides two package exports and asks to compare them.
  Read-only: never proposes or performs changes in Metrc.
---

# Metrc reconciliation

Deterministic diff first, explanation second, human decides. You never compare
rows yourself; the script does that. You never change anything in Metrc or the
inventory system.

## Inputs

Ask for two CSV files if not already provided:

1. **Metrc export**: Metrc → Packages → Active → export. Must contain a tag
   (label) column and a quantity column. Unit column is helpful.
2. **Inventory export**: the ERP's active packages with the Metrc tag column
   visible. For Distru: the Packages page CSV export, or `GET /public/v1/packages`
   saved as CSV.

If the user does not know the column names, look at the header row and map
them. Common names are listed in `references/columns.md`.

## Steps

1. Confirm both files exist and have a header row. If either has fewer than
   2 rows, stop and say so.
2. Run the diff script. Do not read the full files into your own reasoning;
   only read the script output.

   ```bash
   node scripts/reconcile.mjs \
     --metrc metrc_packages.csv \
     --erp inventory_packages.csv \
     --metrc-tag "Tag" --metrc-qty "Quantity" --metrc-unit "Unit of Measure" \
     --erp-tag "Metrc Tag" --erp-qty "Quantity" --erp-unit "Unit" \
     --tolerance 0.01 \
     --out deltas.json
   ```

   Adjust the column flags to the actual headers. The script prints a summary
   line and writes `deltas.json` with three arrays: `only_in_metrc`,
   `only_in_erp`, `quantity_mismatch`.
3. If total deltas exceed 200, tell the user the exports are probably from
   different dates or licenses and ask them to confirm before continuing.
4. For each row in `deltas.json`, assign exactly one `most_likely_cause` from
   `references/causes.md`, a `confidence` of high / medium / low, and one
   `next_check` sentence. Use only the fields in the row. Do not invent
   quantities, dates, or product names.
5. Write `reconciliation-report.md` using the template below. Sort each section
   by confidence, low first, so the human reads the uncertain ones first.
6. Tell the user the counts and where the report is. Do not recommend a
   specific quantity edit. Recommend *what to check*.

## Report template

```markdown
# Metrc reconciliation: {date}

Metrc rows: {n}  ·  Inventory rows: {n}  ·  Matched: {n}
Only in Metrc: {n}  ·  Only in inventory: {n}  ·  Quantity mismatch: {n}

## Quantity mismatches
| Tag | Metrc qty | Inventory qty | Δ | Unit | Product | Likely cause | Confidence | Check first |
|---|---|---|---|---|---|---|---|---|

## Only in Metrc (not in inventory)
| Tag | Metrc qty | Unit | Product | Likely cause | Confidence | Check first |

## Only in inventory (not in Metrc active)
| Tag | Inventory qty | Unit | Product | Status | Likely cause | Confidence | Check first |

## Notes
- Anything you are unsure about, and why.
```

## Rules

- Never propose a Metrc edit, adjustment, or finish action. Say what to check.
- Never compare rows without the script. If the script fails, fix the column
  flags or report the error; do not fall back to eyeballing.
- If a unit differs between systems for the same tag, call it `unit_mismatch`
  regardless of the numbers.
- If `only_in_metrc` is large right after a delivery day, mention unaccepted
  incoming transfers as the first thing to check.
- Keep the user's data local. Do not paste full exports into any external
  service.

## Customizing for your operation

- Set `--tolerance` to what your state and lab practice justify (0.01 to 0.5
  in the package unit is typical).
- Edit `references/causes.md` to add causes specific to you (e.g., "pre-roll
  line consumes flower without a Metrc production batch until Friday").
- Add your lab's typical sample draw to `references/causes.md` so
  `unrecorded_sample` can be assigned with higher confidence.

---
name: compliance-check
description: >-
  Check cannabis menu copy, product labels, ads, social posts, emails or an SOP
  against the operator's own rules file (references/rules.md) and report every
  line that breaks a rule, with the rule quoted and a compliant rewrite. Use when
  the user says "compliance check", "check this copy", "is this label OK",
  "can we post this", "review this ad", "check this SOP", or pastes marketing
  text, a label, or a procedure and asks whether it is allowed. Read-only:
  never publishes, sends or edits anything; the human decides.
---

# Compliance check

Rules first, judgment second, human decides. You never decide what the law is;
you compare text against the rules the operator wrote down. If a rule is not in
`references/rules.md`, you do not enforce it; you flag it as "not covered".

## Inputs

1. **The text to check.** Menu copy, label text, an ad, a post, an email, an
   SOP. If the user gives a file, read it. If they give a photo of a label,
   transcribe the text first and show the transcription.
2. **The rules file.** `references/rules.md`. If it is still the unfilled
   template (a line starts with `TODO`), stop and say which sections need
   filling before a check means anything. Do not guess a state's rules.
3. **Which kind of text this is** (menu, label, ad, SOP). Ask if unclear; the
   rules file has a section per kind.

## Steps

1. Read `references/rules.md` fully. Note the state and the "last reviewed"
   date at the top. If the date is more than 12 months old, say so in the report
   header and carry on.
2. Split the text into numbered lines or sentences so every finding points at
   one place.
3. For each line, check it against every rule in the matching section plus
   the "Every kind of text" section. A rule applies only if the file says it
   does. Use `references/examples.md` to calibrate what counts as a hit.
4. Classify each finding:
   - **BLOCK**: breaks a rule marked `must` in the file.
   - **FIX**: breaks a rule marked `should`, or is a required element that is
     missing (a warning, a symbol, a license number placeholder).
   - **CHECK**: you are not sure the rule applies, or the text is ambiguous.
     Say what a human should look at.
   - **NOT COVERED**: looks like a compliance question but no rule in the file
     speaks to it. List these; they are the operator's to-do list for the rules file.
5. For every BLOCK and FIX, quote the rule (its ID from the file) and write one
   compliant rewrite that keeps the marketing point if a compliant version exists.
   If none exists, say "no compliant version; remove".
6. Write the report using the template below. BLOCK first, then FIX, then CHECK,
   then NOT COVERED. End with the count per class and the one-line verdict:
   "Ready to publish", "Ready after fixes", or "Do not publish".
7. Never say "this is legal" or "this is compliant". Say "no rule in your file
   is broken". The difference matters.

## Report template

```markdown
# Compliance check: {kind}, {date}
Rules file: {state}, last reviewed {date in file}

Verdict: {Ready to publish | Ready after fixes | Do not publish}
BLOCK {n} · FIX {n} · CHECK {n} · NOT COVERED {n}

## BLOCK
| # | Line | Rule | Why | Rewrite |
|---|---|---|---|---|

## FIX
| # | Line | Rule | Why | Rewrite |

## CHECK
| # | Line | What a human should confirm |

## NOT COVERED
- {question the text raises that the rules file does not answer}

## Missing required elements
- {each `must include` item from the rules file that is absent}
```

## Rules

- Never invent a regulation, statute number, agency name or penalty. Quote only
  what is in `references/rules.md`.
- Never write a health, medical or therapeutic claim into a rewrite, even as an
  example of what not to say beyond quoting the original line.
- Never publish, post, send, or edit the checked text anywhere. Output the report only.
- If the text contains customer names or license numbers, keep them out of the
  report; write `[name]` and `LIC-…`.
- If the user asks you to "just make it compliant", still produce the report
  first; the rewrites are in it.

## Customizing for your operation

- Fill `references/rules.md` from `references/rules-template.md`: one section per
  kind of text, one rule per line with an ID, `must` or `should`, and the source
  you took it from (statute, regulator guidance, your lawyer's memo).
- Add your own hits and misses to `references/examples.md` after each run. A
  false alarm becomes a "not a hit" example; a miss becomes a new rule.
- Multi-state: one `rules-<state>.md` per state, and tell the skill which one at
  the top of your message.