polisd

Live today · the design tab

You already have a design system.
Nobody ever wrote it down.

Forty files of generated components, and somewhere in them a type scale, a palette and a spacing rhythm that nobody chose on purpose. Polishd reads it back out of your rendered pages and prints the brand guide you never made — after the build, not before.

Every number above is measured, not guessed — each page tallies its own rendered CSS once per visitor session, and the flags are arithmetic. The model gets the last word, on a tally it can't argue with, and it sees the pages too: a review shoots the first screen of the top pages and pictures each flagged value in place.

Live today · stages 01–04

What gets measured,
gets improved.

Refining needs evidence. This is the captured half of the loop — no surveys, no session-replay creep, running on your own database, on a dashboard at /polishd.

Live today · actionables

A bug, not a chart.
File it, fix it, or hand it off.

Both reviews hand what they find to one list: the analytics losses and the design issues together, each with its evidence and, for a design value, a picture of where it renders. File one and it's verified against your source first. Mark one fixed, or ignore it with a reason the model reads back.

# Fix the analytics and design problems Polishd found

**A1.** Readers rage-click post headings, mistaking the link styling for a link.
  - Evidence: `h2.post-title` · 53 rage clicks · 31 sessions
  - Source: `app/posts/[slug]/page.tsx`

**D1.** The byline grey fails on paper.
  - Evidence: `#a8a29e` on `#ffffff` at 13px (2.6:1)
  - Where it renders: `#a8a29e` — 212 uses as text on 7 pages (pictured on /posts/the-slow-web)
  - Suggested fix: Use `#57534e` for captions (7.4:1).
…

Finish with a fenced JSON verdict block, one entry for each of A1, A2, D1 …

A citation that isn't in the data is thrown away before anything is filed. Marking a finding fixed tells the model it was fixed, and on which day, so data from before the fix doesn't bring it back. A pasted verdict only ever matches the finding it was given.

Just landed · fixes

Issue in, PR out.
On the GitHub Actions you already run.

Create fix hands a filed issue to the coding agent your repo already runs — the Claude Code GitHub Action. It scopes the bug, proves it's real and pushes a fix; Polishd opens the pull request, linked to the issue, and reads the agent's verdict back onto the row.

# .github/workflows/claude.yml
on:
  issue_comment:
    types: [created]
jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1

Polishd runs nothing itself: the agent runs in your repository, on your Actions minutes and your Claude plan or API key, with the token you already gave Polishd — no new permissions. Copilot's coding agent works too, assigned instead of mentioned. A bug that isn't real comes back as a verdict, not a diff, and nothing is written to a pull request without your click.

The loop

Every rough edge,
from signal to shipped fix.

Seven stages, one cycle. Five of them are live now, fixes included — the last two are coming soon.

Next · stages 06–07

The half that closes the loop.

Finding the rough edge is only worth something if the fix is proven. These two stages are in build — what's live now is the first five.

flag polishd.experiment("tappable-headings")

rage 53 → 7   verdict ship

Shapes shown are illustrative — the API isn't settled yet.

Start the loop

Three commands.
Then your own dashboard.

No third-party service, no script tag, no account. Events land in your database — SQLite locally, Postgres in production.

$ npm i @polishd/next

$ npx polishd init

$ npm run dev
# → /polishd