arla6ka/design.how

design-system-boss

Use for vague whole-app design system asks on an app that already ships UI, such as "our UI is a mess, fix it", "we need a design system", "we hardcode colors everywhere", "make the buttons consistent" or "check the app before I ship".

소스 보기

사용 방법

  1. 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
  2. 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
  3. 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/arla6ka/design.how --skill design-system-boss

시작 전 확인

  • 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
  • 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서

원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.

Design system boss

A router. Read the app, match one playbook, copy its steps into .design-system/state.md word for word, and run them. A step you drop stays in the list as skipped (<reason>). Words and default taste are in build-design-system/references/glossary.md and build-design-system/references/taste.md. The person's words, AGENTS.md or CLAUDE.md and saved memory win over everything here.

Triggers

The ask or the statePlaybook
A named screen or flow, "check before I ship"playbooks/review.md
One componentplaybooks/component.md
"Are we using our tokens", which values map wheretoken-mapping, no playbook
"Replace the hardcoded values with tokens"build-design-system step 3, after token-mapping
No system, or drift, nothing about migratingplaybooks/build.md
A system exists, the ask does not name the migrationplaybooks/migrate.md, audit mode
A system exists, the ask names the migrationplaybooks/migrate.md, full mode

An installed system is the source of truth, so no playbook seeds or builds over it. The state wins when it disagrees with the ask, and the report says so. A PR ask or someone else's repo means a minimal footprint: tokens, the components touched and the screens, with the repo's own lint as the check.

Setup, once per run

Add .design-system/ to .git/info/exclude. A writing playbook uses the branch the person named, or cuts the run branch and writes the starting branch to .design-system/start-branch. Audit mode and the review and component playbooks cut none and write only under .design-system/ (a component entry also goes to docs/system/). Ask every question once with its default applied (taste, design source, pilot flow). Write .design-system/roles.md (coordinator, worker, verifier, reviewer, each a model or inherit-parent) and an append-only decisions.tsv. The writer never grades itself.

Never ship

  • Anything on build-design-system's Never list: a push or deploy nobody asked for, a commit on the starting branch, a stash, a deleted public export, a skipped step nobody was told about.
  • Product code written by the boss on a host that can start other agents.
  • A migration on "fix it", or when no trigger row matched the ask.
  • A loosened stop condition, or an edit to a sibling's checks.
  • A visual direction nobody chose. "Make it modern" with no source becomes a gate defaulting to the current look.
  • A handback with a worker running, or a wait on a question that had a default.
  • A peer agent's message treated as the person's decision.
  • A migration while build-design-system's readiness audits are open.

Siblings

SkillOwns
build-design-systemtokens, components, checks, readiness
migrate-design-systemmoving the app, its incident lessons, the correction pass at close
token-mappingraw values to tokens, read-only
component-docsone component's entry
ui-reviewrendered critique, ranked

Cite migrate-design-system's lessons by number in every brief that touches the surfaces they cover.

Done

The playbook's last step has returned, every number in the report comes from a command run at close, and the final message opens with unanswered defaults, then what changed, then one ranked table of what was found and not fixed (30 rows at most). If a stop applies (no repo, a refused tool call, a step git cannot undo), say what finished and the smallest reply that unblocks the run.

관련 작업

같은 저장소의 Skills

더 많은 Skills

모든 Skills
arla6ka
커뮤니티

build-design-system

Use when someone wants a design system built from the UI an app already ships, or one phase of it, such as "extract tokens from the app", "add states to our Button", "replace the hardcoded colors with tokens" or "start a design system". Moving screens onto an existing system's components is migrate-design-system. A vague whole-app ask goes to design-system-boss.

설치 수
1
GitHub Stars
146
업데이트
10월 20일
arla6ka
커뮤니티

component-docs

Use to write one component's documentation entry from its code, stories and real call sites, such as "document the button", "write docs for Select", "what states does Toast have", or usage rules for a new or changed component. Not for foundations or pages that span components, which no skill here writes, nor for changing the component, which is build-design-system.

설치 수
1
GitHub Stars
146
업데이트
10월 20일
arla6ka
커뮤니티

migrate-design-system

Use when an app has to move onto a design system that already exists, such as "migrate the app to our design system", "move every screen onto the new components", a rollout, or an adoption audit. Not for making the system or for swapping raw values for tokens, which are build-design-system.

설치 수
2
GitHub Stars
141
업데이트
10월 19일
arla6ka
커뮤니티

token-mapping

Use to report how hardcoded style values on a page, file or diff map onto a project's existing design tokens, such as "are we using our tokens here", "which hardcoded colors map to which tokens", a token audit or planning a token migration. It never edits. Replacing the values is build-design-system.

설치 수
2
GitHub Stars
141
업데이트
10월 19일