Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
Use when a project that consumes the Artificer design system needs to upgrade to a newer version — detect the installed version, diff the vendored copy against the target, and walk the breaking changes safely. Triggers on 'upgrade Artificer', 'bump Artificer', 'migrate Artificer', 'update the design system', 'we're on an old Artificer', 'Artificer keywords are illegible', 'theme stopped persisting after Artificer update'.
npx claudepluginhub cameronsjo/attunements --plugin artificer-design-systemHow this skill is triggered — by the user, by Claude, or both
Slash command
/artificer-design-system:artificer-upgradeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You're in a **downstream** project — one that consumes the Artificer design
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
You're in a downstream project — one that consumes the Artificer design
system (vendored src/, npm @cameronsjo/artificer, or the jsDelivr CDN) — and
it needs to move to a newer version. This skill detects what version the project
is on, figures out what changed between there and the target, and produces a
migration checklist scoped to this consumer, surfacing the three changes that
regress visibly in production if you miss them.
The authoritative matrix lives in the design system's docs/UPGRADE.md. This
skill is the interactive counterpart: it does the detection and the
consumer-specific reasoning so you don't have to read the whole matrix cold.
The one rule: never swap palette values or replace
artificer.csswithout walking the per-version notes. Three upgrades in the 0.7→0.10 range have a visible production regression if cherry-picked blindly — the brandPurpleBright contrast lift, thepx → remtype scale, and thelocalStoragetheme key.
Try these in order; stop at the first that answers:
getComputedStyle(document.documentElement).getPropertyValue('--art-version').
Returns e.g. "0.10.1".package.json → @cameronsjo/artificer version, or npm ls @cameronsjo/artificer.artificer.css reads Artificer v<x>.<link> URL (…/artificer@<x>/…).If --art-version is absent and no banner says ≥ 0.9.0, treat the project as
0.8.x or earlier — the token was minted in the v0.9.0 baseline contract.
Confirm the target version (usually current main / latest npm). State both
plainly: "You're on X, moving to Y."
For each version boundary the project crosses, check these. Skip boundaries below the project's current version.
Crossing 0.8.0: Whimsy layer added (additive, opt-in). Nothing forced.
Crossing 0.9.0 (baseline contract):
--border, accent set, status quartet, --brand, --ease.) Absence fails
silently. Grep the vendored CSS / :root overrides for each.--art-version present? Is there a FOUC bootstrap that sets
html[data-theme] before first paint? (Missing → theme flash on load.).whimsy--brand is used, are the literal-hex fallbacks present?Crossing 0.10.0 (the high-risk boundary):
px → rem type scale. Grep the project for --t-*-size: overrides set in
px. Each must become rem or it fights the scale and breaks browser zoom.localStorage theme key. Grep for 'artificer-theme' (hyphen). The key is
now 'artificer.theme' (dot). Any custom toggle or React adapter on the
old key silently desyncs persisted theme..avatar / .accordion / focus tokens / breakpoint tokens
are additive — adopt as needed.@media (pointer: coarse)) grows controls to ≥44px — check
dense layouts.Crossing 0.10.1 (strict fix — take it regardless):
--brand-purple-bright defined? If the project is on the old dark value
#7050b8 (or binds .tok-keyword to bare --brand-purple), syntax keywords
render at ≈1.67–2.35:1 — illegible. Mint #b095e0 (dark) / #5a35b0 (light)
and rebind .code-block .tok-keyword.Tailor the checklist to how this project consumes Artificer:
<head>,
not a deferred/bundled script — verify it runs before hydration. React consumers:
the Icon/useIcons/useWhimsy adapters and the 'artificer.theme' key.integrity= together, or the stylesheet silently fails
to load.src/ copy: you're hand-mirroring — diff your copy against the
target artificer.css and re-apply any local overrides on top (watch for the
px → rem ones).# Artificer v<x> header tells you if it's stale.Output a concrete, ordered checklist for this project — each item a specific
file/grep/edit, not a generality. End with the verify list: --art-version
correct, theme persists, no FOUC, keywords legible, text scales with zoom, focus
rings present.
An upgrade is consumer usage of Artificer, so once the migration lands, you
MUST invoke /artificer-feedback — per the standing early-and-often mandate.
The skill does the assembly — you MUST NOT draft the issue or de-dupe against
existing ones first. Don't wait for a gap "worth reporting": which version pair you
crossed, what bit (the px → rem scale? the artificer.theme key? a missing
baseline token?), and what this guide's matrix got right or wrong is the
highest-signal feedback the design system can get — it's friction under real
upgrade constraints. You MUST NOT pause to ask permission — standing
pre-approval covers it. You SHOULD run it in the background (fork / subagent)
so it never interrupts the work; fire-and-forget, MUST NOT batch or curate.
(Waived only when Cameron unprompted declines, or you're working inside the
artificer-design-system repo itself.)
--art-version lets a consumer know what
they're running before they touch anything./artificer-feedback.