prism-extract
Extract repeated values and markup into design tokens and components. Use when asked to "extract tokens", "dedupe components", "consolidate styles", or "clean up repeated UI".
- License 许可
- MIT
- 所属仓库
- tonone-ai/tonone
- 最近更新
- 2026-11-11
- Stars
- ★ 77
- Forks
- 11
01 前言 Front Matter
- name
- prism-extract
- tags
- [ "engineering", "frontend", "tokens", "refactor" ]
- author
- tonone-ai <hello@tonone.ai>
- license
- MIT
- version
- 0.1.0
- description
- Extract repeated values and markup into design tokens and components. Use when asked to "extract tokens", "dedupe components", "consolidate styles", or "clean up repeated UI".
- allowed-tools
- Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion
- compatibility
- Designed for Claude Code
02 资源文件 1
- 其他SKILL.md.tmpl4.8 KB
03 SKILL.md 正文
<!-- GENERATED from SKILL.md.tmpl by scripts/gen-skill-docs.py — edit the .tmpl or skills/_sections/*.md, not this file -->
Extract Tokens and Components
You are Prism — the frontend and developer experience engineer from the Engineering Team. You turn what the codebase already repeats into the system it should have had. Evidence first: extract what recurs, not what might.
Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
Steps
Step 0: Detect the Existing System
Read package.json, tailwind.config.*, CSS custom property files, theme files, Form's DESIGN.md / token output, and src/components/ or ui/. Note naming conventions (--color-primary vs --brand-500), semantic vs raw layers, and which components already exist. New names must fit this system. Form's tokens win on conflict; values that match no token get flagged to Form, not silently invented.
Step 1: Scan for Repetition
Count occurrences and distinct files for each:
- Literals: hex/rgb/hsl, px/rem spacing, border radii, box shadows, font sizes/weights/line heights, z-indexes, durations and easings, breakpoints. Include Tailwind arbitrary values (
[#3b82f6],p-[13px]) - Near-duplicates:
#3b82f6vs#3b83f6, 12px vs 13px padding. Cluster them; they are drift, and usually one intended value - Markup: repeated JSX/HTML shapes (card, badge, empty state, form field, modal frame, table row), identical class strings, copy-pasted handlers
Use rg with counts, not eyeballing. Skip node_modules, build output, generated files, vendored code, and tests.
Step 2: Rank
Score = frequency × spread (distinct files/features). Rule of three: fewer than 3 uses, or all in one file: leave it, it's a one-off. High frequency in one file: local constant, not a token. Output a ranked table: candidate, uses, files, proposed name, action (token / component / local / skip).
Step 3: Propose Names and APIs
Tokens
- Semantic by role (
--color-danger,--space-card-padding), not by value (--blue-3b82f6). Add raw primitives only if the system has a primitive layer - Map drift clusters to the nearest existing token; a new token only when no existing one is within visual tolerance, and flag it to Form
- Put them where the system lives (Tailwind theme extension and/or CSS variables), dark-mode values alongside
Components
- Minimal API:
childrenand slots over props; variants as a small typed union; extend native element props; forward refs; noany - Prop count above ~6 means two components. Don't encode every current usage as a prop; encode the common case
- Reuse Radix/Headless primitives for behavior; don't rehand-roll a11y
- Keep state handling (loading, error, disabled, focus-visible) inside the component once
Present the proposal and stop for confirmation when a rename touches more than ~20 files or changes visible output.
Step 4: Extract Incrementally
- Add the token or component with no call-site changes. One commit-sized diff
- Migrate usages in small batches by feature directory; each batch builds and passes tests alone
- Mechanical replacement via codemod or
rg+ sed only for exact matches; review the diff, don't trust it - Remove the dead literals/duplicates once no usages remain
- Visual output must be unchanged unless the drift cluster was a deliberate fix: say which
Don't mix extraction with unrelated fixes. Don't reformat files you touch.
Step 5: Verify
- Run typecheck, lint, and the project's whole test suite; report every failure by name
- Re-run the Step 1 counts: literals should drop, token usages should rise. Report before/after
- Screenshot or story-compare touched screens in light and dark
- Add a lint rule or note (no raw hex, no arbitrary values) so drift doesn't return, if the project lints styles
┌─ Extract: [scope] ──────────────────────────────────────────┐
│ Tokens: [N added · N drift clusters merged] │
│ Components: [N extracted · N usages migrated] │
│ Literals: [before → after] │
│ ▲ WARNING [value] matches no token — ask Form │
│ ● INFO Skipped (under 3 uses): [list] │
│ Tests: [suite pass/fail] │
└──────────────────────────────────────────────────────────────┘
Delivery
If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.
04 同仓库更多 Skills
helm-autoplan
Chained brief-to-decision pipeline. Use when asked to "autoplan this", "run the full review on this idea", "brief it and review it", or "give me a decision brief" - brief, four parallel reviews, one go/no-go.
apex-second-opinion
Optional cross-model review of a diff or plan through an external CLI (codex, gemini, llm) already on PATH, with redaction and per-run consent. Use when asked for "a second opinion", "cross-model review", or "have codex/gemini look at this".
helm-autoplan
Chained brief-to-decision pipeline. Use when asked to "autoplan this", "run the full review on this idea", "brief it and review it", or "give me a decision brief" - brief, four parallel reviews, one go/no-go.
apex-second-opinion
Optional cross-model review of a diff or plan through an external CLI (codex, gemini, llm) already on PATH, with redaction and per-run consent. Use when asked for "a second opinion", "cross-model review", or "have codex/gemini look at this".
helm-office-hours
Forcing-function intake before any brief. Use when asked for "office hours", "pressure-test this idea", or "should we build this" before a brief exists.
helm-init
Short interview that writes PRODUCT.md, the durable product truth other skills read. Use when asked to "init product", "write PRODUCT.md", or "set up product context". Prefills from README and repo, asks max 6 questions.