القائمة
Use when improving an existing website or codebase while retaining its recognizable identity, especially when evidence, scope, or redesign approval is uncertain.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Imagery, illustration, and iconography direction for web UI. Use for hero images, photo treatment, illustration style, icon sets, favicons, OG/social cards, decorative graphics, image-shaped holes, and removing generic AI imagery.
OKLCH color-system guidance for cohesive palettes and contrast-safe tokens. Use when choosing colors, generating ramps, fixing muddy palettes, creating semantic state colors, checking WCAG contrast, or defining theme variables.
State matrix for interactive UI. Use when building or reviewing buttons, links, inputs, tabs, toggles, menus, cards, or controls that need hover, focus, active, disabled, loading, selected, error, keyboard, or ARIA states.
Honest, Tufte-informed web data visualization. Use for charts, dashboards, metrics, KPI tiles, sparklines, chart accessibility, chartjunk removal, genre choice, lie-factor checks, direct labels, data tables, and themed SVG/HTML.
Design-system interview before new frontend builds or redesigns. Use for vague site/app/landing/dashboard requests, generic-looking UI, direction-setting, aesthetic choices, type/color/density decisions, and DESIGN-SYSTEM.md tokens.
Empty, loading, and error-state design. Use for first-run screens, zero results, empty lists/tables/dashboards, loading skeletons, offline/permission errors, retries, layout stability, and state copy.
| name | improve-existing-website |
| description | Use when improving an existing website or codebase while retaining its recognizable identity, especially when evidence, scope, or redesign approval is uncertain. |
Improve what is weak without sanding away what makes the product recognizable. Existing work contains both signal and drift; evidence decides which is which.
Open the rendered priority path before prescribing. Trace entry, decision, action, and recovery at wide and narrow widths. Then inspect source hierarchy, tokens, repeated components, content, analytics or user evidence supplied in scope, and business cues.
Label what you can point to EVIDENCE. Label every interpretation INFERRED. A direct observation is “the primary action changes label across three screens”; “the brand values warmth” is inferred unless the brief or product evidence says so.
Done when: the priority path, recurring system choices, and highest-cost failures are observable rather than guessed.
Record signals worth preserving: distinctive type, color relationships, interaction patterns, content voice, layout logic, or customer-recognizable assets. Classify each candidate change:
| Class | Meaning | Authority |
|---|---|---|
| Preserve | coherent, repeated, brief-supported identity | repair defects without replacing the signal |
| Normalize | accidental variation against an established pattern | safe to align when evidence is strong |
| Approval needed | a new hierarchy, palette, voice, or material redesign | show the choice and wait for owner agreement |
Use references/signal-vs-drift.md when repetition, age, or inconsistency could plausibly
be intentional. Age alone is not evidence of drift.
Done when: every proposed change names what survives and why the change is authorized.
Complete assets/INFERRED-SYSTEM.template.md across audience, territory, type, color,
layout, components, voice, and accessibility. Score readiness with
references/inspection-state-machine.md. Ask only questions whose answers would change
the safe direction; otherwise state the inference and its evidence.
Do not solve a system problem with isolated polish. Choose a narrow vertical slice that proves the direction across a real path—for example navigation, one content section, one form or state, and the narrow layout—before propagating it.
Done when: the direction can be approved, rejected, or resumed without reconstructing the investigation.
For each repair, record the observed failure, preserved signal, smallest coherent edit,
owner or approval source, and proof. After approval, use
references/repair-handoffs.md for evidence-justified specialist passes. Verify the same
path and viewports used during inspection; comparison must show that the defect changed
and the preserved signal survived.
If work pauses, save the current state, unresolved question, evidence, and exact next
decision using references/inspection-state-machine.md. Resumption starts from that
checkpoint, not from a fresh aesthetic opinion.
Done when: the implementation report distinguishes repaired drift, preserved identity, browser/static proof, and deliberately deferred ambiguity.
references/audit-procedure.md — extraction order.references/signal-vs-drift.md — identity versus accident.references/decision-records.md — scope ADR rules.references/inspection-state-machine.md — readiness and approval.assets/improve-checklist.md — completion ledger.references/repair-handoffs.md — routing and skip rules.references/interview-contract.generated.md — canonical state/question authority.assets/improve-checklist.md is the completion authority for inspection, labels,
approval, handoffs, and evidence.
Canonical detail: contract.json.
table_with_evidence with status, reason, remediation, evidence, provenance.