polarsource/polar · Archived
Check a code change against the repo's Accepted Architecture Decision Records (ADRs) in handbook/engineering/decisions/ and report violations with citations.
npx skills add polarsource/polar --skill adr-check
This repository is archived — consider an actively maintained alternative.
Local development environment management for Polar using Docker
79 installsReact and Next.js performance optimization guidelines from Vercel Engineering. This skill shoul…
66 installsA skill to add a new entry in the section "Backend Development" of the Polar Handbook. Those en…
37 installsPrepare an interview task for a candidate, as part of our hiring process.
7 installsRelated neighbors and high-traction skills in the same topics — useful to compare before installing.
Build custom functionality that merchants can install at defined points in the checkout flow, i…
8.6K installs|- Replace the usage of `expect` and similar functions from `package:matcher` to `package:check…
7.3K installsPre-deployment verification checklist. Use when about to ship a release, deploying a change wit…
5.1K installsThree-layer verification pipeline for AI output. Extracts verifiable claims, finds supporting o…
4.2K installsRun a compliance check on a proposed action, product feature, or business initiative, surfacing…
2.9K installsCheck the status of existing agreements with a vendor across all connected systems — CLM, CRM, …
2.5K installsOther skills from polarsource/polar.
npx skills add polarsource/polar
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
main
Parsed from SKILL.md frontmatter.
Files included with this skill beyond the listing page.
SKILL.md
3,074 B
SUMMARY.md
360 B
The handle is the diff. The evidence is a short report of which Accepted ADRs the change touches and where it breaks them. This is the ADR analogue of [verifier-web](../verifier-web/SKILL.md): that skill replays UI changes, this one reviews a change against the recorded architecture decisions.
ADRs live in handbook/engineering/decisions/. Treat every ADR whose Status is Accepted as binding.
"verify against the architecture decisions".
/polar-code-review.Prefer the branch diff; fall back to the working tree.
git diff --name-only main...HEAD # committed on this branch
git diff --name-only # unstaged
git diff --name-only --staged # stagedThis assumes the branch targets main (the default). If the PR targets another branch, diff against that base instead.
Then read the actual hunks for the changed files (git diff main...HEAD -- <file>).
ls handbook/engineering/decisions/[0-9]*.mdxRead each one. For every ADR with Status: Accepted, extract its Decision (the rule) and its Area (Backend, Frontend, Infra, or Cross-cutting). Apply an ADR only to files in its Area: a frontend ADR does not apply to server/, and vice versa. Reading the ADRs each run keeps the check current as ADRs are added or superseded.
For each Accepted ADR whose Area matches a changed file, read its Decision and Consequences and derive the violation signature from them: the Decision states the rule, and the Consequences often spell out the "must" and the failure it prevents. Then look for that signature in the changed hunks (grep for the concrete identifiers the ADR names, and read the surrounding code). Don't rely on a signature list kept here: it would drift from the ADRs. The ADR text is the source of truth.
Be terse. Do not narrate which ADRs you checked, list applicable/not-applicable ADRs, or explain your process.
No violations and nothing else.(id and title) and the violation: the file:line, one line on what breaks the rule, and the fix.
This skill reviews and reports. It does not edit code; fixes are a follow-up.