boar_review

Files (13)

• SKILL.md
• generator.cjs · fixtures/
• helpers.mjs · fixtures/
• money.mjs
• money.test.mjs
• openrouter.mjs
• openrouter.test.mjs
• process.mjs
• prompt.md
• review.mjs
• review.test.mjs
• runner.mjs
• runner.test.mjs

SKILL.md (first lines)

# Review a result

This takes the place a code review has in a code workflow. It reads the result as its reader will: the text, and how it looks on its platform. Five readers answer in parallel, a finding counts only when two of them raise it, and Claude sorts what counts. It never scores the result, and it never invents a fact to meet a finding.

## Inputs

- **The ticket** (`gh issue view <n> --comments`) and its spec: what the result must do, its **Result** line (where the result belongs: platform, place, name) and its **Marketing** line.
- **The result's own link**: the one the maker reported, or the one the user gives. The Result line's link is the place (a folder, list or board), not the result: find the result there by its name only when no link was given.
- **The result's text**, read through its platform's connector (the document's content, the task's description, the board's items, the artifact's page).
- **The repository's own rules** the spec or the repository names for such a result: a style guide, a tone of voice, a template. None is fine.

## Steps

1. **Look at it.** With the Playwright tools, open the result's own link. If a login wall appears, stop and ask the user to sign in in that browser window once, then go on. Take full-page screenshots (several when the page is long) into `tmp/boarlabs/review/<ticket>-<pass>/`. A result that cannot be seen in a browser is read as text only; say so in the report.
2. **The prompt.** Fill [`prompt.md`](prompt.md) beside this file into that folder: the ticket, the spec's entry for this result, the rules, the Marketing line and the text. On a second pass, also its section on earlier findings.
3. **The panel.** Run it and wait:

   ```bash
   node "${CLAUDE_PLUGIN_ROOT}/skills/boar_review/review.mjs" --prompt <folder>/prompt.md \
     --image <folder>/<shot-1>.png [--image <folder>/<shot-2>.png]... --out <folder>/result.json
   ```

   The readers are Fable, Codex and three OpenRouter models (`OPENROUTER_API_KEY`, which `./start.sh` exports from `.env`). It exits 1 when fewer than three answered, since two readers agreeing means little then; without the OpenRouter key only Fable and Codex answer. Tell the user why and stop: the ticket does not close unchecked.
4. **Count.** Group the readers' findings by what they object to. A finding **counts** when at least two readers raise it; the rest stay in `result.json`, out of the report.
5. **Sort** every finding that counts, exactly one way:
   - **taken**: change the result on its platform, and say what changed;
   - **dropped**: it contradicts the ticket, the spec or a decision the user made, or a check shows it is wrong; say why;
   - **open**: only a new fact, a number, or the user's own decision could meet it; it goes to the user as a question.

   Meet a finding only from the ticket's own sources: cut, reorder, say a thing more plainly. Never add a claim, a number or a quotation nobody gave you. With `Marketing: no`, a marketing register (sales language, hype, calls to action) is itself a Standards finding.
6. **A second pass**, only when something changed: new screenshots, the prompt with the first pass's counting findings, the same command into `<ticket>-2/`. It says which earlier findings still stand and what is new. There is no third pass; what is still open after it goes to the user.
7. **The report**, for the ticket's closing comment: each pass's outcome, naming every reader that did not answer and why; every counting finding with the readers that raised it and whether it was taken (what changed), dropped (why) or open (the question); the run's cost (`spent` in `result.json`, plus any sentence it printed about a crossed threshold). The screenshots stay in `tmp/` and are not committed.

From boarlabsxyz/skills, MIT.

More from boarlabsxyz/skills