Files
pbakaus_impeccable/skill/reference/audit.md
T
3e38e595c7 Add platform axis (web / ios / android / adaptive) (#269)
* Add a platform axis (web / ios / android / adaptive) to the skill

Orthogonal to register: register decides whether design IS or SERVES the
product; platform decides the delivery target and which native conventions
apply. Set `## Platform` in PRODUCT.md; a missing field defaults to `web`,
so legacy projects are unaffected.

- extractPlatform() in skill/scripts/context.mjs (mirrors extractRegister);
  the CLI appends a NEXT STEP directive to read the native reference(s).
  `adaptive` (Flutter / RN / KMP shipping both iOS and Android) loads both
  ios.md and android.md.
- New reference/ios.md (Apple HIG distilled) and reference/android.md
  (Material 3 distilled); reference/web.md is a thin pointer. The native
  refs frame register's role as narrow: platform conformance is the bar,
  brand lives in the expressive layer the platform gives you, never by
  breaking the rails.
- Setup step 5 loads the native reference(s) when platform is native. Live
  mode and the detect CLI stay web-only, gated off ios/android/adaptive.
- init asks platform right after register; adapt/audit/animate/layout carry
  short platform divergence notes; all secondary spots thread `adaptive`.
- a11y stays in audit.md (loading it at design time makes output timid), so
  the native refs carry no Accessibility section; audit.md's Platform
  section owns native a11y.
- Tests: extractPlatform unit coverage + skill-behavior scenario 10
  (PRODUCT.md platform ios -> agent loads ios.md).

Source-first: only skill/, scripts/, tests/, CLAUDE.md, NOTICE.md, the
changelog and version are committed; the sync workflow regenerates the
provider trees and ./plugin on merge.

ios.md / android.md are distilled from the MIT-licensed
ehmo/platform-design-skills; attribution in NOTICE.md.

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

* Address review: gate web tools on native platforms, drop version churn

Maintainer-review fixes applied with AI assistance (Claude Code), on top
of the rebased platform-axis commit:

- Design hook (post-edit and Cursor pre-edit) now resolves the project
  platform via loadContext + extractPlatform and skips its web rule scan
  for ios / android / adaptive projects, so React Native / Flutter code
  never draws web-shaped findings (new hook-lib resolveProjectPlatform /
  isNativePlatform helpers, covered by unit and subprocess tests).
- context.mjs CLI warns on an unrecognized ## Platform value (e.g. a
  toolchain name like `flutter`) instead of silently defaulting to web;
  extractRegister / extractPlatform now share extractSectionValue.
- Removed reference/web.md: nothing loaded it; CLAUDE.md carries the
  "web has no extra rulebook" explanation.
- init.md: skip live-mode config (Step 6) for native platforms; note the
  per-app PRODUCT.md pattern for repos shipping web + native.
- android.md: Material-everywhere apps that also ship on iPhone still
  owe iOS OS guarantees (safe areas, Reduce Motion, edge-swipe back).
- ios.md: reworded a design-time line that framed Dynamic Type as an
  accessibility check (a11y stays owned by audit.md).
- Renumbered the new skill-behavior scenario to 14 after main's 10-13;
  updated CLAUDE.md scenario list; added android + unrecognized-value
  CLI test cases.
- No version or changelog changes: versioning happens at release time.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Tighten platform reference prose

Editorial pass on the platform-axis text, applied with AI assistance
(Claude Code) under maintainer direction:

- ios.md / android.md rewritten to house style: single-line paragraphs
  (no hard wraps), one-sentence scope intro, deduplicated intro/slop-test,
  register-compression down to two sentences. In-file attribution
  paragraphs removed (NOTICE.md owns attribution); "read on top of the
  register reference" cruft removed (SKILL step 5 and the context.mjs
  directive already say it). Bans sections dropped: they restated the
  rules above them; the two additive items (tab-bar overload,
  hover-dependent affordances) folded into rules. ~40% smaller each.
- Sub-command Platform sections (adapt, audit, animate, layout), SKILL
  step 5, init.md platform prose, and the context.mjs directive trimmed
  the same way.

Build (prose validators, counts) and both test runners green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Treat an empty PRODUCT.md section as absent, not the next heading

Copilot review catch: extractSectionValue read the next `## ...` heading
as the section value when a field was left empty, which made the CLI
warn "value `## Product Purpose` is not recognized". Stop at the next
heading and return null instead. Regression tests for extractPlatform,
extractRegister, and the CLI warning path. Applied with AI assistance
(Claude Code) under maintainer direction.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Only read a token list of both native targets as adaptive

Bugbot catch: after the exact platform tokens failed, any Platform line
containing the words ios and android was classified adaptive, so
negated or explanatory prose ("web only, not ios or android") silently
loaded both native refs and skipped the hook, with no warning. The
combo parse now accepts only list separators and the two platform
words; anything else falls through to the CLI's unrecognized-value
WARNING. Regression tests added. Applied with AI assistance (Claude
Code) under maintainer direction.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Paul Bakaus <paul.bakaus@gmail.com>
2026-07-08 17:11:31 -07:00

6.9 KiB

Run systematic technical quality checks and generate a comprehensive report. Don't fix issues; document them for other commands to address.

This is a code-level audit, not a design critique. Check what's measurable and verifiable in the implementation.

Platform

The dimensions below are written for web. Native (ios / android / adaptive) audits translate: accessibility means VoiceOver / TalkBack correctness (labels, roles, reading order, Dynamic Type / scalable text reflow); touch targets are 44 pt (iOS) / 48 dp (Android); appearance covers Dark Mode / dark theme. detect.mjs is web-only; never run it against native code. See ios.md / android.md (adaptive audits both).

Diagnostic Scan

Run comprehensive checks across 5 dimensions. Score each dimension 0-4 using the criteria below.

1. Accessibility (A11y)

Check for:

  • Contrast issues: Text contrast ratios < 4.5:1 (or 7:1 for AAA)
  • Missing ARIA: Interactive elements without proper roles, labels, or states
  • Keyboard navigation: Missing focus indicators, illogical tab order, keyboard traps
  • Semantic HTML: Improper heading hierarchy, missing landmarks, divs instead of buttons
  • Alt text: Missing or poor image descriptions
  • Form issues: Inputs without labels, poor error messaging, missing required indicators

Score 0-4: 0=Inaccessible (fails WCAG A), 1=Major gaps (few ARIA labels, no keyboard nav), 2=Partial (some a11y effort, significant gaps), 3=Good (WCAG AA mostly met, minor gaps), 4=Excellent (WCAG AA fully met, approaches AAA)

2. Performance

Check for:

  • Layout thrashing: Reading/writing layout properties in loops
  • Expensive animations: Casual layout-property animation, unbounded blur/filter/shadow effects, or effects that visibly drop frames
  • Missing optimization: Images without lazy loading, unoptimized assets, missing will-change
  • Bundle size: Unnecessary imports, unused dependencies
  • Render performance: Unnecessary re-renders, missing memoization

Score 0-4: 0=Severe issues (layout thrash, unoptimized everything), 1=Major problems (no lazy loading, expensive animations), 2=Partial (some optimization, gaps remain), 3=Good (mostly optimized, minor improvements possible), 4=Excellent (fast, lean, well-optimized)

3. Theming

Check for:

  • Hard-coded colors: Colors not using design tokens
  • Broken dark mode: Missing dark mode variants, poor contrast in dark theme
  • Inconsistent tokens: Using wrong tokens, mixing token types
  • Theme switching issues: Values that don't update on theme change

Score 0-4: 0=No theming (hard-coded everything), 1=Minimal tokens (mostly hard-coded), 2=Partial (tokens exist but inconsistently used), 3=Good (tokens used, minor hard-coded values), 4=Excellent (full token system, dark mode works perfectly)

4. Responsive Design

Check for:

  • Fixed widths: Hard-coded widths that break on mobile
  • Touch targets: Interactive elements < 44x44px
  • Horizontal scroll: Content overflow on narrow viewports
  • Text scaling: Layouts that break when text size increases
  • Missing breakpoints: No mobile/tablet variants

Score 0-4: 0=Desktop-only (breaks on mobile), 1=Major issues (some breakpoints, many failures), 2=Partial (works on mobile, rough edges), 3=Good (responsive, minor touch target or overflow issues), 4=Excellent (fluid, all viewports, proper touch targets)

5. Anti-Patterns (CRITICAL)

Check against ALL the DON'T guidelines from the parent impeccable skill (already loaded in this context). Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy).

Score 0-4: 0=AI slop gallery (5+ tells), 1=Heavy AI aesthetic (3-4 tells), 2=Some tells (1-2 noticeable), 3=Mostly clean (subtle issues only), 4=No AI tells (distinctive, intentional design)

Generate Report

Audit Health Score

# Dimension Score Key Finding
1 Accessibility ? [most critical a11y issue or "--"]
2 Performance ?
3 Responsive Design ?
4 Theming ?
5 Anti-Patterns ?
Total ??/20 [Rating band]

Rating bands: 18-20 Excellent (minor polish), 14-17 Good (address weak dimensions), 10-13 Acceptable (significant work needed), 6-9 Poor (major overhaul), 0-5 Critical (fundamental issues)

Anti-Patterns Verdict

Start here. Pass/fail: Does this look AI-generated? List specific tells. Be brutally honest.

Executive Summary

  • Audit Health Score: ??/20 ([rating band])
  • Total issues found (count by severity: P0/P1/P2/P3)
  • Top 3-5 critical issues
  • Recommended next steps

Detailed Findings by Severity

Tag every issue with P0-P3 severity:

  • P0 Blocking: Prevents task completion. Fix immediately
  • P1 Major: Significant difficulty or WCAG AA violation. Fix before release
  • P2 Minor: Annoyance, workaround exists. Fix in next pass
  • P3 Polish: Nice-to-fix, no real user impact. Fix if time permits

For each issue, document:

  • [P?] Issue name
  • Location: Component, file, line
  • Category: Accessibility / Performance / Theming / Responsive / Anti-Pattern
  • Impact: How it affects users
  • WCAG/Standard: Which standard it violates (if applicable)
  • Recommendation: How to fix it
  • Suggested command: Which command to use (prefer: {{available_commands}})

Patterns & Systemic Issues

Identify recurring problems that indicate systemic gaps rather than one-off mistakes:

  • "Hard-coded colors appear in 15+ components, should use design tokens"
  • "Touch targets consistently too small (<44px) throughout mobile experience"

Positive Findings

Note what's working well: good practices to maintain and replicate.

List recommended commands in priority order (P0 first, then P1, then P2):

  1. [P?] {{command_prefix}}command-name: Brief description (specific context from audit findings)
  2. [P?] {{command_prefix}}command-name: Brief description (specific context)

Rules: Only recommend commands from: {{available_commands}}. Map findings to the most appropriate command. End with {{command_prefix}}impeccable polish as the final step if any fixes were recommended.

After presenting the summary, tell the user:

You can ask me to run these one at a time, all at once, or in any order you prefer.

Re-run {{command_prefix}}impeccable audit after fixes to see your score improve.

IMPORTANT: Be thorough but actionable. Too many P3 issues creates noise. Focus on what actually matters.

NEVER:

  • Report issues without explaining impact (why does this matter?)
  • Provide generic recommendations (be specific and actionable)
  • Skip positive findings (celebrate what works)
  • Forget to prioritize (everything can't be P0)
  • Report false positives without verification