Skip to content
cccskills
FreePublished on GitHub

fix-design-notes

Read design review notes attached to a pull request’s screenshots, locate the affected components, and fix the product code using the team’s design rules. Repeat the review and inspect screenshots to verify the result.

OriginalShow the original description

Design notes on a PR, "Design review (advisory)" in the evidence check, "worth fixing", layout.split-row, OW-LIST, a reviewer says the UI looks off. Use to read what the design review found on a PR's screenshots, fix it in code, and prove the note is gone.

Works withGitHub
See how to install

Good for

  • Resolving design notes on a pull request
  • Reproducing reported layout problems locally
  • Fixing shared components behind repeated UI issues
  • Documenting why a design suggestion should be kept unchanged

Files included (1)

  • SKILL.md3.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Skill: Fix design notes

Every PR that records evidence screenshots gets an advisory design review. Its notes ride in the Evidence preview check, next to the evidence they are about: one summary line, and the notes as the check's text. They never change the evidence verdict, but a note marked Worth fixing is a defect a careful designer would send back. Fix it, or say in the PR why the screen is right.

Read the notes

sha=$(gh pr view <pr> --json headRefOid --jq .headRefOid)
check() { gh api "repos/{owner}/{repo}/commits/$sha/check-runs?check_name=Evidence%20preview" --jq ".check_runs[0].output.$1"; }
check summary   # ends with "Design review (advisory): 3 notes, 1 worth fixing." or "no notes."
check text      # the notes, then the same notes as JSON

Each note gives:

FieldUse it to
rulelayout.* was measured from the DOM (exact). S2, V2… are DESIGN.md; OW-* are the OpenWork Design rules in evals/design-review/rubric.md (judged from pixels; may vary run to run)
Screenshotthe spec step that took it, and the spec file
Where in the codegrep for the hook ([data-library-row="…"] → data-library-row) or the class list to find the component
Reproducethe command that re-records the screenshots and reviews them locally

The JSON block at the end of the check text has the same notes for scripts. The screenshots themselves are in the review report the check links to.

Reproduce, fix, verify

  1. Run the note's reproduce command. Read --json output, not prose: pnpm evals:e2e <slug> --local && pnpm --dir evals design:review -- --test-run latest --json (judged notes need OPENAI_API_KEY or ANTHROPIC_API_KEY; measured ones do not).
  2. Find the component from the hook or class list. Read DESIGN.md and the rule in evals/design-review/rubric.md before changing anything: the fix follows the team's pattern, not the note's wording.
  3. Fix it in the product code, never in the spec or the rubric.
  4. Re-run the same command. The note must be gone and no new Worth fixing note may appear. Look at the screenshot yourself: a passing rule is not a good screen.
  5. Push. CI re-runs the review; the evidence check's summary says Design review (advisory): no notes. or lists only what you decided to keep.

When the screen is right

A judged note can be wrong, and a team decision can outrank a generic rule. Leave the code, and put one line in the PR body under Evidence: Design review: kept OW-LIST-HEADER on the Library; the columns are compared (see DESIGN.md S2). Do not edit the rubric to silence a note in the same PR that triggers it.

Rules

  • Measured notes are facts about the layout; do not argue with the numbers.
  • Never chase a judged note across runs: if it flips between runs, it is low confidence. Fix what you can see in the screenshot.
  • Fix the shared component when the hook points at one (a row used by every list), not each screen.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

add-a-feature

FreeSummary

Manage OpenWork feature releases with feature flags, switches that control access to new behavior. Register features before coding, release them by organization and deployment, prepare a global shutdown option, and remove temporary flags after rollout.

  • Registering a feature before implementation
  • Releasing a feature to selected organizations
  • Separating cloud and self-hosted availability
different-ai/openwork24.2KUpdated Oct 18, 2026

Connect OpenCode browser tools to a locally running OpenWork Electron app to inspect its UI, enter a task, and check the response. This skill supports exploration and debugging through CDP, Chrome's remote control protocol.

  • Connecting browser tools to a local Electron development app
  • Inspecting screen state during debugging
  • Entering a task in the composer and running it
different-ai/openwork24.2KUpdated Oct 18, 2026

Check added lines in a change for information identifying customers, prospects, partners, or outside individuals. Report locations and generic remediation without reproducing identities, and escalate cases where the information is already public.

  • Checking changes for customer and partner identities
  • Reviewing documents and test data for identifying details
  • Reporting disclosure locations without repeating identities
different-ai/openwork24.2KUpdated Oct 18, 2026

Connects supported AI clients, including Claude Code and Codex, to OpenWork through MCP, a protocol for accessing external tools. It guides account sign-in and verifies that tools for finding and running organization capabilities are available.

  • Connecting an AI client to OpenWork organization resources
  • Signing in and verifying available MCP tools
  • Switching organizations or troubleshooting authentication
different-ai/openwork24.2KUpdated Oct 18, 2026

Review an outside contributor’s pull request before running its code. Identify concealed behavior, obfuscated code, risky dependencies, and build hooks, with file locations and specific checks for maintainers to follow up.

  • Screening an outside contributor’s pull request before execution
  • Checking encoded code and unexplained network calls
  • Reviewing dependency changes and installation scripts
different-ai/openwork24.2KUpdated Oct 18, 2026

create-plugin

FreeSummary

Create an OpenCode plugin for OpenWork with custom tools and hooks, which run code at specific events. The skill builds the plugin file and adds its entry to the project configuration.

  • Adding custom tools to OpenWork
  • Creating a plugin to save and list notes
  • Running custom code before or after tool execution
different-ai/openwork24.2KUpdated Oct 18, 2026

See all skills by different-ai

Report a problem with this skill