bosi-programming-skills

Review the changes since a fixed point (commit, branch, tag, or merge-base) along three axes — Standards (does the code follow this repo's documented coding standards?), Spec (does the code match what the originating issue/PRD asked for?) and Tests (are the tests sound, and does changed behaviour have one?). Runs the three reviews in parallel sub-agents and renders them as a three-tab dark-theme HTML page opened in the browser, or, with `--headless`, returns them as plain text without asking anything. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X", or when another skill or agent needs a review it can act on.

The house coding standards — clean code, TypeScript import and export rules, frontend accessibility, and how tests are written — as a catalog to check code against. Use when code is being reviewed against these standards, when asked what the house standards are, or when writing code in a project that has adopted them.

Turn a code diff or pull request into a dark-theme interactive web page that maps what changed, how the changed pieces relate, and which design patterns the change uses or breaks. Use this whenever the user wants to see, picture, map, diagram or visualize a change rather than read it - "visualize this PR", "show me what this diff touches", "draw the relations in this branch", "what patterns does this PR use", "map this change", "I can't follow this diff", "graph the dependencies of these commits" - and also when a diff is large or unfamiliar enough that a picture would land faster than prose. Accepts a PR URL or number, a git ref range, a .diff/.patch file, or the current working tree. This one is for code diffs; for a change to documentation or other prose files use docs-visualizer instead.

Turn a documentation or prose diff into a dark-theme interactive web page that maps which docs and sections changed, how they link to each other, which writing patterns and anti-patterns the change uses, and what the prose actually claims. Use this whenever the user wants to see rather than read a change to text files - "visualize this docs PR", "map what changed in these docs", "show me the structure of this markdown change", "what is this README rewrite actually doing", "which sections link to what", "did this rewrite break any links", "I can't follow this docs diff" - and also when a prose diff is large or reflowed enough that a picture would land faster than the patch. Accepts a PR URL or number, a git ref range, a .diff/.patch file, or the current working tree. For code diffs use code-visualizer instead.

Go find out instead of predicting. Use whenever you are about to state something you have not run or read - how a function behaves, whether a test passes, what a config holds, why something broke, what a ticket actually says. Also use when you catch yourself writing "should", "probably" or "typically" about this codebase, and before any debugging conclusion. Covers reading, running and probing digital objects.

Take a task from a rough idea to a merged PR, cooked in six named phases — Reading the Recipe, Mise en Place, Cooking, Tasting, Plating, Documentation — each one able to end in a clean context, except Reading the Recipe and Cooking/Tasting, which default to continuing straight into the next phase. Use when the user says "run the recipe", "cook this ticket", "cook this task", or "feature recipe".

Orchestrate a ticket from the Maestri canvas by running recipe-relay with each unit handed to a fresh agent terminal instead of a sub-agent, one model for planning and another for code, on any harness the canvas has a preset for. The run never stops to ask; the orchestrator takes each stated recommendation, logs it to a shared note, and ends with a draft PR after a better-code-review pass it fixes. Use when the user is in Maestri and asks to work a ticket, issue or task through the recipe with a team of agents, or names this workflow.

Run feature-recipe phase by phase through isolated sub-agents, auto-taking every checkpoint's own stated recommendation instead of asking, moving from one unit to the next without pausing, and ending with a headless better-code-review pass whose findings it fixes. Use when the user wants the feature recipe run hands-off but supervised in the current session, without a cron job and without every design decision landing back in chat.

Output gate for anything a human will read. Run it before you summarize findings or an investigation, before you create or update a Linear issue or comment, a Todoist task, a Notion page, a Slack message, or any technical markdown doc (README, ADR, runbook, changelog, investigation notes). It fixes the shape — bullets over prose, evidence inline, action items as a checklist, no filler — and adds the attribution tag the destination requires. Skip it for yes/no answers, single-line factual replies, code-only output, clarifying questions, git commit messages and PR descriptions.