Files
pbakaus_impeccable/skill/reference/polish.md
T
e7e923c4ef Skill + craft cleanup, detector hardening, native subagent pipeline (#152)
* skill: drop quality tiers, keep the real brand-craft guardrails

Codex's craft/brand pass introduced fast/ship/showpiece "quality bars"
plus brand-specific build gates, asset ledgers, sub-agent review, and
self-graded fallback labels. In practice those tiers became escape
hatches rather than craft pressure: the final output should always be
10/10, and the real decision points are splashiness and maximalism, not
quality.

Removed:
- All quality-bar / showpiece / fast / ship framing in shape.md and craft.md
- Standalone Brand Direction (#4) and Asset Requirements (#10) sections
  in shape's brief; renumbered back to 1-10
- The Brand hard rules section in brand.md (folded its real prohibitions
  into the existing Imagery and Brand bans sections)
- Brand-specific build-gate item, mock-fidelity bullet, production-bar
  bullet, present-step bullet in craft.md
- Asset ledger ceremony in craft Step 4
- Review-only sub-agents and "self-reviewed fallback, not independently
  validated" machinery in craft.md and polish.md
- The For brand surfaces, assess hard failures subsection in polish.md
  and the brand checklist row
- tests/brand-showpiece-reference.test.mjs (and its package.json wiring)

Kept (the real nuggets):
- Asset-substitution prohibition: image-led briefs ship real/generated
  assets or canvas/SVG/WebGL, not generic CSS panels, cards, bullets,
  or copy
- Repeated tiny uppercase tracked kicker labels as a brand ban
- Detector/QA output is defect evidence only, never proof of quality
- "What visual assets are real content here?" discovery question
- Inspect each major section individually for brand and long-form work
- repeated-section-kickers detection rule + fixture
- CLI improvements (JSON to stdout, -json/-fast aliases, severity field)
- critique.md: npx impeccable detect --json fix

Harness output dirs refreshed via bun run build. Full test suite (186)
passes.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* skill: strip gate ceremony; require shape pause; allow compact briefs

The setup gate table and IMPECCABLE_PREFLIGHT banner pushed every
craft run through ritual restatement (PRODUCT.md → original prompt
→ round 1 → round 2 → 70-line "confirmed brief" → critique → summary,
all saying the same thing). Replaced with imperative prose that still
demands the same work but skips the user-facing telemetry.

Specifically:

SKILL.md
- Drop the Setup gate table and IMPECCABLE_PREFLIGHT banner.
- Keep the imperative steps explicitly: load context, identify register
  and load brand.md or product.md, AND load the matching command
  reference (craft.md / shape.md / etc.) when a sub-command is invoked.
  The command-reference step is non-negotiable; without craft.md loaded
  the agent skips the shape-and-confirm pause.

craft.md
- Drop the Build Gate / Craft Contract formal sections; replace with
  one paragraph stating prerequisites.
- Step 1 explicitly requires ending the response after presenting the
  shape output; the user must confirm before any code lands. Allows a
  compact 3-5 bullet brief when the prompt + PRODUCT.md already pin
  direction (full 10-section structure reserved for genuinely
  ambiguous tasks).
- Step 3 image gate skips silently when image generation isn't
  natively available; no user-facing announcement.
- Step 6 explicitly legitimizes "first pass clean, shipping" as a
  valid endpoint and bans inventing fake defects to demonstrate
  iteration.

shape.md
- Cap discovery at 1 round by default; second round only when first
  leaves material gaps.
- Adds an "assert-then-confirm, not menu-with-escape" rule: when
  PRODUCT.md and the prompt make one option obvious, name it and ask
  for confirm or override instead of enumerating "Restrained /
  Committed / Or something else?" as a real choice.
- Phase 2 brief has two forms now: compact (default for clear briefs)
  and full structured (genuinely ambiguous). Open Questions can't
  double as leading-with-Recommend; if you'd write "Recommend: X",
  decide X.
- Image gate same as craft.md.

Validated end-to-end with a Haiku skill-on observability run: agent
loads craft.md plus the brief's recommended implementation refs,
pauses for one productive question (accent color, trace fidelity,
CTA), and ships an artifact with zero side-tab violations vs. the
original v1 baseline. Cost trades up modestly for that quality.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* craft.md Step 6: Reading the screenshot is the inspection, not taking it

A v4 eval run took 4 targeted screenshots (hero, mobile, tablet,
query-section) and then never Read any of them back. The agent treated
browser_screenshot itself as "I inspected" and shipped without the
multimodal feedback loop ever closing. Detector caught the resulting
slop (5+ side-tab violations) on adjacent runs that did the same thing.

Step 6 now spells out the pattern explicitly: take the screenshot,
then Read the resulting PNG so its image content enters the
conversation as multimodal input, then critique what you actually see
in the image. With a check: "if your critique could have been written
without looking at the image, you didn't look at the image."

Validated with v5b: agent took 6 screenshots, Read all 6 back, and
shipped with zero detector findings (vs the previous greenfield runs
that hit 1-12 findings each).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* craft + brand: framework foundation, build-pipeline respect, image verification

Three closely-linked additions surfaced by an eval-harness session
investigating why the agent always shipped flat single-file HTML and
zero imagery on greenfield brand briefs.

1. craft.md gains a new Step 0 "Project Foundation" before Shape.
   Detects existing framework / component library / icon set and
   uses what's there. Greenfield: ask the user via AskUserQuestion
   with sensible defaults framed by the brief (Astro for content/
   brand sites, SvelteKit/Next/Nuxt for app surfaces, single
   index.html only for one-shot demos). Skipping the framework
   decision and writing flat HTML "to satisfy the spec" produces
   work that reads as a 2018 prototype regardless of visual
   quality.

2. craft.md Step 5 production bar gains two bullets:
   - Respect the build pipeline. Edit source files and run the
     project's `npm run build`; do not write to build/ / dist/ /
     .next/ directly with cat/heredoc/Bash redirects. Bypassing
     the pipeline skips asset hashing, image optimization, code
     splitting, and CSS extraction.
   - Verify external image URLs before referencing them. Use an
     image-search MCP, web-fetch tool, or browser if available;
     guessed photo IDs ship as broken-image placeholders.

3. brand.md "Imagery" section:
   - Generalizes the Unsplash URL guidance to "verify URLs
     before referencing them" with a hierarchy: image-search MCP
     > web-fetch > confidence-restricted manual selection >
     fewer photos.
   - Tightens the tech/dev-tool exception. Old line "zero imagery
     can be correct" gave models a permission slip. New framing
     keeps the underlying truth (typography + code + diagrams
     primarily carry voice) but raises the floor: imagery still
     earns its place when it serves the brief, and skipping it
     requires naming the typographic/diagrammatic move that's
     carrying the visual weight instead. "Zero imagery is the
     failure mode of laziness, not restraint."

Eval-harness corpus that prompted this: 19/19 brand landing tasks
shipped 0 images each, including ones where Opus had taste enough
to break the dev-tool color default lane. The skill needs to teach
both halves of the decision; the harness shouldn't have to nudge.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* detector: body-text-viewport-edge rule + OKLCH/var-resolution + anchor-inherit FP fixes

New rule: body-text-viewport-edge flags body paragraphs that render flush
against the left/right viewport edges (no container padding). Tested via
the new tests/fixtures/antipatterns/body-text-viewport-edge.html fixture
(3 flag cases, 5 pass cases) and the test in detect-antipatterns-browser.

False-positive class fixes — all jsdom-mode only (real browsers resolve
the cascade correctly so these gates stay inert there). Five related
gaps that compounded into ~14× spurious contrast findings on Tailwind v4
pages with OKLCH color tokens:

  • OKLCH parser. jsdom returns the literal "oklch(...)" string from
    getComputedStyle; the detector now converts to sRGB via Björn
    Ottosson's matrices. Handles Tailwind v4's compact minified form
    "oklch(21.5%.02 50)" (no space after %).
  • var() resolution. resolveBackground + checkElementColors now
    accept the existing customPropMap and parse `var(--color-paper)`
    etc. as proper RGB via the new parseColorResolved helper.
  • bg-color before bg-image. The old order bailed on any gradient
    ancestor before checking for a solid background-color underneath,
    causing the body's decorative paper-grain gradient to be measured
    against instead of the page's actual `bg-paper` cream.
  • body/html-level gradient → white fallback. When the only opaque
    ancestor we can read is body/html with a gradient overlay (and
    jsdom can't decompose `background: var(--paper) gradient` to
    extract the solid color), return white instead of falling through
    to resolveGradientStops — which was picking up paper-grain noise
    colors and using them as the bg.
  • Anchor-inherit workaround for jsdom :link UA specificity.
    Tailwind v4's preflight declares `a { color: inherit }` (0,0,1).
    jsdom's UA stylesheet has `:link { color: blue }` at (0,1,1) and
    wins the cascade. Real Chrome wraps :link in :where() (0,0,0) so
    the page rule wins. When the page declares the inherit rule AND
    we see jsdom's default `rgb(0,0,238)` on an anchor, walk to the
    nearest non-anchor ancestor and use its color.
  • Alpha-fallback safety gate. When text has alpha<1 AND we couldn't
    find an opaque ancestor (effectiveBg null), skip the contrast
    finding. Covers any remaining FP class the deeper fixes miss.

Verified end-to-end against an Opus iter-1 artifact on Tailwind v4 with
14 cream/cream FPs + 2 blue-link UA FPs before; 0 findings after, while
the color.html fixture's 12 real low-contrast cases continue to flag
(verified via direct detectHtml calls).

cli/engine/detect-antipatterns-browser.js is the generated browser
distribution — regenerated from .mjs via scripts/build-browser-detector.js
(no manual edits to the generated file).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* craft.md: tighten verbose passages, de-codex Step 6, cut redundancies

Cumulative reduction: 218 → 155 lines (-29%).

Step 0: drop the "Why this matters" paragraph at the end. The body of
Step 0 already makes the framework-pick point; the paragraph just
re-explains it with extra rhetoric.

Step 1: replace the 4-sentence "you must end your response" block with a
single line. The original said the same thing three different ways.

Step 3: trim the conditional / defensive scaffolding (Purpose subsection,
"do not skip because the eventual UI is semantic..." paragraph,
duplicated approval-loop guidance). Mock fidelity inventory preserved.

Step 4: drop the "keep UI text semantic" sentence; it duplicates Step 5's
"Semantic first" rule. The rasterized-vs-semantic decision rule stays.

Step 5: tighten each production-bar bullet to bold-lead + specifics
format. All 15 rules preserved (real content, mock ingredients, semantic
first, spacing/alignment, typography, state coverage, interaction quality,
icon set, build pipeline, image URL verification, optimized imagery,
premium motion, maintainability, technical cleanliness, ask-when-uncertain).

Step 6: rewrite around "look at what you built like a designer would —
your eyes are whatever the harness gives you." Drops Codex-specific
"In Codex, use browser-use" bias. Drops the verbose 3-step Read pattern
(condensed to one sentence). Drops the 1-8 numbered checklist (replaced
by a tight paragraph). Keeps the load-bearing rules: read the PNG,
don't fabricate iteration, mock fidelity reference, exit bar = studio
defensibility.

Step 7: drop the closing "Iterate based on feedback. Good design is
rarely right on the first pass" preachy filler.

All em-dashes converted to semicolons / colons / periods to satisfy
the skill prose validator.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* build: native subagent pipeline + Codex-only asset producer

Adds an agent cross-compile pipeline alongside the existing skill
pipeline. Sources live at skill/agents/*.md; providers that declare
agentFormat (codex-toml, claude-md) emit native subagent files. An
optional providers: <list> field on an agent gates which harnesses
get a copy; default (no field) ships everywhere.

The impeccable-asset-producer agent is opt-in to Codex only. It's
useful for Codex's native image generation path and is untested
elsewhere; Claude has no native image gen anyway.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* brand: inverse-test + cultural-symbol palette guardrail

Two additions to the brand register reference:

- Inverse slop test: describe the page the way a competitor would
  describe theirs. If that sentence fits the modal landing page in
  the category, restart.
- Palette guardrail: when a cultural-symbol palette is the obvious
  pull, reach past it. Let cultural reading come from typography,
  imagery, and copy.

Harness mirrors regenerated; some also catch up to the image-
verification paragraph from e3ad2ef that hadn't been re-synced.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* PRODUCT.md: widen audience beyond developers

Designers, product managers, and engineers all use AI coding tools
and want better design output. Keeping the audience narrow to
"frontend and full-stack developers" understates who the skill is
actually for. Also retitles "developer" to "user/builder" in the
purpose statement.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* site + build: bump rule count to 29, strip changelog from detector check

Two changes:
- site/pages/index.astro: three live mentions of "28 rules / checks"
  bumped to 29 after the body-text-viewport-edge rule landed in
  b9bf496.
- scripts/build.js: the detection-count validator was reading the
  unstripped content, so historical counts inside changelog entries
  (e.g. "28 rules" from an older release note) were flagging against
  the current detector total. The command-count check already strips
  the changelog ul; the detection check now does the same.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* test: align hero-eyebrow-chip fixture with relaxed rule gates

b9bf496 intentionally relaxed two gates in checkHeroEyebrow:
- removed the heading-size ≥ 48px anchor (modern hero h1s use
  clamp/vw/var that jsdom can't resolve)
- raised the eyebrow text ceiling from 30 to 60 chars

Two fixture cases that satisfied the negative side of the old gates
now match the rule:

- "Body-Sized Heading Below Eyebrow" — 24px h1 with tracked-caps
  label above. Per the rule's stated intent ("a tiny tan label
  directly above any h1 is the antipattern regardless of how big
  the h1 ends up"), this is a flag.
- "Long Uppercase Sentence Above Hero" — 46-char tracked-caps label
  is under the new 60-char ceiling, so still eyebrow-shaped.

Both cases moved from the should-pass column to should-flag, with
case descriptions rewritten to explain the gate they exercise.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Paul Bakaus <paulbakaus@pauls-mbp-3.lan>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-12 23:11:18 -07:00

12 KiB

Additional context needed: quality bar (MVP vs flagship).

Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.

Detector and automated QA output are defect evidence only. A clean script result is never proof that the design is strong; gather browser evidence and inspect the real interaction path.

Design System Discovery

Aligning the feature to the design system is not optional. Polish without alignment is decoration on top of drift, and it makes the next person's job harder. Discovery comes before any other polish work.

  1. Find the design system: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: design principles, target audience, color tokens, spacing scale, typography styles, component API, motion conventions.
  2. Note the conventions: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established? What flow shapes are used for comparable actions (modal vs full-page, inline vs route, save-on-blur vs explicit submit)?
  3. Identify drift, then name the root cause: For every deviation, classify it as a missing token (the value should exist in the system but doesn't), a one-off implementation (a shared component already exists but wasn't used), or a conceptual misalignment (the feature's flow, IA, or hierarchy doesn't match neighboring features). The fix differs by category: patch the value, swap to the shared component, or rework the flow. Fixing the symptom without naming the cause is how drift compounds.

If a design system exists, polish must align the feature with it. If none exists, polish against the conventions visible in the codebase. If anything about the system is ambiguous, ask. Never guess at design system principles.

Pre-Polish Assessment

Understand the current state and goals before touching anything:

  1. Review completeness:

    • Is it functionally complete?
    • Are there known issues to preserve (mark with TODOs)?
    • What's the quality bar? (MVP vs flagship feature?)
    • When does it ship? (How much time for polish?)
  2. Think experience-first: Who actually uses this, and what's the best possible experience for them? Effective design beats decorative polish; a feature that looks beautiful but fights the user's flow is not polished. Walk the path from their perspective before opening DevTools.

  3. Identify polish areas:

    • Visual inconsistencies
    • Spacing and alignment issues
    • Interaction state gaps
    • Copy inconsistencies
    • Edge cases and error states
    • Loading and transition smoothness
    • Information architecture and flow drift (does this feature reveal complexity the way neighboring features do?)
  4. Triage cosmetic vs functional: Classify each issue as cosmetic (looks off, doesn't impede the user) or functional (breaks, blocks, or confuses the experience). When polish time is tight, functional issues ship first; cosmetic ones can land in a follow-up. Quality should be consistent; never perfect one corner while leaving another rough.

CRITICAL: Polish is the last step, not the first. Don't polish work that's not functionally complete.

Polish Systematically

Work through these dimensions methodically:

Visual Alignment & Spacing

  • Pixel-perfect alignment: Everything lines up to grid
  • Consistent spacing: All gaps use spacing scale (no random 13px gaps)
  • Optical alignment: Adjust for visual weight (icons may need offset for optical centering)
  • Responsive consistency: Spacing and alignment work at all breakpoints
  • Grid adherence: Elements snap to baseline grid

Check:

  • Enable grid overlay and verify alignment
  • Check spacing with browser inspector
  • Test at multiple viewport sizes
  • Look for elements that "feel" off

Information Architecture & Flow

Visual polish on a misshapen flow is wasted work. Match the shape of the experience to the system, not just the surface.

  • Progressive disclosure: Match how much is revealed when, compared to neighboring features. A settings page exposing 40 fields when the rest of the app reveals 5 at a time is drift, even if every field is perfectly styled.
  • Established user flows: Multi-step actions follow the same shape as comparable flows elsewhere: modal vs full-page, inline edit vs separate route, save-on-blur vs explicit submit, optimistic vs pessimistic updates.
  • Hierarchy & complexity: The same conceptual weight gets the same visual weight throughout. Primary actions don't become tertiary in one corner of the product, and tertiary actions don't shout.
  • Empty, loading, and arrival transitions: How content arrives, updates, and leaves matches how it does in adjacent features.
  • Naming and mental model: The feature uses the same nouns and verbs as the rest of the system. A "Workspace" here shouldn't be a "Project" three screens away.

Typography Refinement

  • Hierarchy consistency: Same elements use same sizes/weights throughout
  • Line length: 45-75 characters for body text
  • Line height: Appropriate for font size and context
  • Widows & orphans: No single words on last line
  • Hyphenation: Appropriate for language and column width
  • Kerning: Adjust letter spacing where needed (especially headlines)
  • Font loading: No FOUT/FOIT flashes

Color & Contrast

  • Contrast ratios: All text meets WCAG standards
  • Consistent token usage: No hard-coded colors, all use design tokens
  • Theme consistency: Works in all theme variants
  • Color meaning: Same colors mean same things throughout
  • Accessible focus: Focus indicators visible with sufficient contrast
  • Tinted neutrals: No pure gray or pure black; add subtle color tint (0.01 chroma)
  • Gray on color: Never put gray text on colored backgrounds; use a shade of that color or transparency

Interaction States

Every interactive element needs all states:

  • Default: Resting state
  • Hover: Subtle feedback (color, scale, shadow)
  • Focus: Keyboard focus indicator (never remove without replacement)
  • Active: Click/tap feedback
  • Disabled: Clearly non-interactive
  • Loading: Async action feedback
  • Error: Validation or error state
  • Success: Successful completion

Missing states create confusion and broken experiences.

Micro-interactions & Transitions

  • Smooth transitions: All state changes animated appropriately (150-300ms)
  • Consistent easing: Use ease-out-quart/quint/expo for natural deceleration. Never bounce or elastic; they feel dated.
  • No jank: Smooth animations; use atmospheric blur/filter/mask/shadow effects when they add polish, but bound expensive paint areas and avoid casual layout-property animation
  • Appropriate motion: Motion serves purpose, not decoration
  • Reduced motion: Respects prefers-reduced-motion

Content & Copy

  • Consistent terminology: Same things called same names throughout
  • Consistent capitalization: Title Case vs Sentence case applied consistently
  • Grammar & spelling: No typos
  • Appropriate length: Not too wordy, not too terse
  • Punctuation consistency: Periods on sentences, not on labels (unless all labels have them)

Icons & Images

  • Consistent style: All icons from same family or matching style
  • Appropriate sizing: Icons sized consistently for context
  • Proper alignment: Icons align with adjacent text optically
  • Alt text: All images have descriptive alt text
  • Loading states: Images don't cause layout shift, proper aspect ratios
  • Retina support: 2x assets for high-DPI screens

Forms & Inputs

  • Label consistency: All inputs properly labeled
  • Required indicators: Clear and consistent
  • Error messages: Helpful and consistent
  • Tab order: Logical keyboard navigation
  • Auto-focus: Appropriate (don't overuse)
  • Validation timing: Consistent (on blur vs on submit)

Edge Cases & Error States

  • Loading states: All async actions have loading feedback
  • Empty states: Helpful empty states, not just blank space
  • Error states: Clear error messages with recovery paths
  • Success states: Confirmation of successful actions
  • Long content: Handles very long names, descriptions, etc.
  • No content: Handles missing data gracefully
  • Offline: Appropriate offline handling (if applicable)

Responsiveness

  • All breakpoints: Test mobile, tablet, desktop
  • Touch targets: 44x44px minimum on touch devices
  • Readable text: No text smaller than 14px on mobile
  • No horizontal scroll: Content fits viewport
  • Appropriate reflow: Content adapts logically

Performance

  • Fast initial load: Optimize critical path
  • No layout shift: Elements don't jump after load (CLS)
  • Smooth interactions: No lag or jank
  • Optimized images: Appropriate formats and sizes
  • Lazy loading: Off-screen content loads lazily

Code Quality

  • Remove console logs: No debug logging in production
  • Remove commented code: Clean up dead code
  • Remove unused imports: Clean up unused dependencies
  • Consistent naming: Variables and functions follow conventions
  • Type safety: No TypeScript any or ignored errors
  • Accessibility: Proper ARIA labels and semantic HTML

Polish Checklist

Go through systematically:

  • Aligned to the design system (drift named and resolved by root cause)
  • Information architecture and flow shape match neighboring features
  • Visual alignment perfect at all breakpoints
  • Spacing uses design tokens consistently
  • Typography hierarchy consistent
  • All interactive states implemented
  • All transitions smooth (60fps)
  • Copy is consistent and polished
  • Icons are consistent and properly sized
  • All forms properly labeled and validated
  • Error states are helpful
  • Loading states are clear
  • Empty states are welcoming
  • Touch targets are 44x44px minimum
  • Contrast ratios meet WCAG AA
  • Keyboard navigation works
  • Focus indicators visible
  • No console errors or warnings
  • No layout shift on load
  • Works in all supported browsers
  • Respects reduced motion preference
  • Code is clean (no TODOs, console.logs, commented code)

IMPORTANT: Polish is about details. Zoom in. Squint at it. Use it yourself. The little things add up.

Sweat the details. Zoom in until the alignment is right and the spacing reads as deliberate. Then ship.

NEVER:

  • Polish before it's functionally complete
  • Polish without aligning to the design system; that's decoration on drift
  • Guess at design system principles instead of asking when something is ambiguous
  • Spend hours on polish if it ships in 30 minutes (triage)
  • Introduce bugs while polishing (test thoroughly)
  • Ignore systematic issues (if spacing is off everywhere, fix the system, not just one screen)
  • Perfect one thing while leaving others rough (consistent quality level)
  • Create new one-off components when design system equivalents exist
  • Hard-code values that should use design tokens
  • Introduce new patterns or flows that diverge from established ones

Final Verification

Before marking as done:

  • Use it yourself: Actually interact with the feature.
  • Test on real devices: Not just browser DevTools.
  • Ask someone else to review: Fresh eyes catch things.
  • Compare to design: Match intended design.
  • Check all states: Don't just test happy path.
  • Treat automation carefully: Run detector or QA commands when they are available and relevant, fix their defects, but never cite a clean result as proof that the work is polished.

Clean Up

After polishing, ensure code quality:

  • Replace custom implementations: If the design system provides a component you reimplemented, switch to the shared version.
  • Remove orphaned code: Delete unused styles, components, or files made obsolete by polish.
  • Consolidate tokens: If you introduced new values, check whether they should be tokens.
  • Verify DRYness: Look for duplication introduced during polishing and consolidate.