Add solve-issues skill and guide for GitHub bug reports

@@ -0,0 +1,17 @@
+---
+name: solve-issues
+description: Solve bug reports from the GitHub issues of the Cannabis Freedom Index - check each claim against the cited law, correct the country profile, history or penalty data, test, commit with the issue number and answer the issue. Use when asked to fix, solve, work through or triage GitHub issues or bug reports (e.g. "solve issue 268", "fix the open High bugs", "/solve-issues Czechia").
+---
+
+Follow `docs/SOLVE-ISSUES.md`. It is the shared guide for every agent working on this repository;
+this skill only points to it.
+
+1. Read `docs/SOLVE-ISSUES.md`, then the parts of `docs/DATA-MAINTENANCE.md` and `docs/WRITING.md`
+   it names.
+2. Pick the issues: the numbers, country or severity in the arguments, or else the open `bug`
+   issues by severity (`gh issue list --label bug --state open`). Group issues about the same
+   country or the same kind of mistake.
+3. For each issue: read the cited source yourself, decide what is confirmed, fix the data, run the
+   checks, and commit only your own files with `(#<number>)` in the message.
+4. Comment on and close issues only when the user asked for it; otherwise report the drafted
+   comments. Never push unless asked.

@@ -8,4 +8,6 @@ cannabis law (`changes.yaml`, `articles/`) and a cultural atlas (`culture/`), bu
 - **To work through several countries**, follow `docs/EXPAND-COUNTRIES.md`. Start with
   `node scripts/country-gaps.cjs --rank 25` (optionally `--region Africa`).
+- **To solve GitHub issues** (bug reports about the data), follow `docs/SOLVE-ISSUES.md`. Start with
+  `gh issue list --label bug --state open`.
 - Data rules: `docs/DATA-MAINTENANCE.md`. How texts read: `docs/WRITING.md`. Atlas entries:
   `docs/CULTURE.md`.

@@ -0,0 +1,84 @@
+# Solving GitHub issues
+
+How to work through the bug reports in `burningtree/cannabis-freedom-index`: one issue or a batch.
+Most reports name a country, a claim on its page and a law that contradicts it. Written for any
+agent or person; the data rules live in `docs/DATA-MAINTENANCE.md` and `docs/WRITING.md`.
+
+## 0. Before you start
+
+- Run `git status` and `git log --oneline -5`. Others work here at the same time: don't edit files
+  with someone else's uncommitted changes, and commit only your own lines.
+- Don't start dev or preview servers. One `npm run build` at a time (`pgrep -f "astro build"`).
+
+## 1. Pick the issues
+
+```bash
+gh issue list --label bug --state open --limit 50 --json number,title
+gh issue view 268 --json title,body,comments
+```
+
+- Titles carry a severity, `[Critical]` before `[High]` and the rest. Without instructions, take
+  Critical first, then High, oldest first.
+- Group issues about the same country, or the same mistake in several countries (an old currency,
+  serum against whole blood, hemp counted as medical production): fix them in one pass.
+- Read the comments. An issue someone already answered or is working on is not yours.
+
+## 2. Check the claim before fixing it
+
+A report is a lead, not a source. Reports are often right, sometimes partly wrong, and sometimes
+overreach (a proposed new score, a "binding" law that is only a draft).
+
+- Open the law, judgment or official page the report cites, and read the passage yourself. Prefer
+  the official gazette or law portal; a faithful reproduction is a fallback.
+- Check the date: is the cited rule in force now? Was it amended later?
+- Decide for each point: **confirmed**, **partly confirmed** (fix what holds, say what does not),
+  or **not confirmed** (change nothing, explain why with the source).
+- If a source cannot be opened, say so; never describe a source as read when it was not.
+
+## 3. Fix the data
+
+- Find every place the wrong claim lives: `grep -rn "<phrase>" countries/ changes.yaml articles/
+  culture/`. The country page, map, rankings, answers and exports are built from the profile, so
+  fix the data, not the output. If a script or component hard-codes the error, fix that too.
+- Rewrite the affected text by the rules in `docs/WRITING.md` and DATA-MAINTENANCE.md, "Writing
+  context sections well": plain words, every sentence cited (`[@key]`), the primary source added
+  to the profile's `sources` with a `locator` for the section or paragraph.
+- Penalty tables follow DATA-MAINTENANCE.md, "Penalty steps": every figure in its field, the
+  right `currency` (a country that changed currency gets the new one, converted at the official
+  rate, with the old figure in `note` only if the law still states it).
+- Statuses (`hemp`, `production`, `driving` and the rest) must say what the corrected text says.
+- **Scores:** change one only if the law or practice really differs from what the score assumed,
+  calibrated against comparable countries. Then the newest scored history entry's "after" changes:
+  add or fix a dated entry so the timeline still makes sense (`node scripts/data-status.cjs chain
+  <id>`). A wording or measurement correction moves no score.
+- A dated event found while checking (a new law, an amendment, a ruling) goes into `changes.yaml`
+  as a history entry, `checked: true` only if you read its source.
+- Set the profile's `updated:` to today.
+
+## 4. Check
+
+```bash
+node scripts/profile-audit.cjs <id>   # no errors
+npm run answers:test                   # answers and profile claims
+npm run history:test                   # when changes.yaml changed
+npm run build                          # schemas, citations, links
+npm run seo:audit
+```
+
+Read the built page in `dist/country/<id>/index.html` and confirm the corrected wording is there
+and the old one is gone. If an issue shows a check the tests could have caught, add a test for it
+in `scripts/profile-claims.test.mjs`.
+
+## 5. Commit, answer, close
+
+- Commit per issue, or per group, with the issue number in the message:
+  `Czechia: name serum for the 2 ng/mL driving limit (#268)`. Only your own files.
+- For a batch of five or more, write `docs/research/bug-review-<date>.md`: a table of issue,
+  profile and resolution (including what was disproved), and the sources read with their limits.
+- Answer each issue with a short comment: what changed, which sources were read, what was not
+  confirmed and why, and the commit hash. Say that the fix is committed locally and not yet pushed
+  or deployed, unless it is.
+- **Comment and close only when the user asked you to** in this request (`gh issue comment`,
+  `gh issue close --reason completed`). Otherwise list the drafted comments in your report and ask.
+  Close a disproved report with `--reason "not planned"` and the source that disproves it.
+- Never push unless the user asks.