arla6ka/design.how

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.

소스 보기

사용 방법

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

시작 전 확인

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

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

Component docs

A draft entry for one component, built only from what its sources say. Gaps are marked, not filled. It does not judge the design and it publishes nothing. The heading order and a worked example are in references/doc-format.md.

Steps

  1. Paste the nine headings from references/doc-format.md into the draft, empty.
  2. Find the component. Read its code, props type, styles and stories, and record each as a Sources line.
  3. Find two real uses, by call-site search or from the ask. One real use or none changes the stop table below.
  4. Trace which source gave each example, variant, prop, state and token. Every disagreement between sources is a line under Conflicts, with the quoted rule that settles it, or "no rule, not chosen".
  5. Fill each section from sourced facts, copying token names and example code character for character.
  6. Write Usage rules last. Each rule is rule/<component>-<slug>, a condition, an action, a reason, its evidence (two call sites, a measurement with its path, a named principle, or the person's words), and a Don't: line with real code that breaks it. A rule you cannot break with a snippet is cut.
  7. Fill Guessed at, one line per judgement call. Reread the draft against the Done list below.

Output

The entry, then Sources, Conflicts, Guessed at, and Gates (a question with its default) only where a rule adds one. Run on its own, it saves to docs/system/<name>.md with a draft comment on line 1 and writes each missing example file. The reply opens with the path, what the entry covers and its status, then up to three questions with defaults and one prompt the person can paste to take the next step.

Stops

Missing after searchingWhy it stops
The codeNothing else sources the variants, props or behaviour
The variant list (props type or stories)A guessed list documents a different component
Any use, real or plannedInvented uses read like real ones and readers copy them first

A props type with no variant prop is an empty list. Variants reads "None" and the run goes on. One real use, planned uses and a deprecated predecessor are marked as such, not stopped on. A stopped run returns the stop, the facts sourced so far by section, and the smallest reply that unblocks it ("one screen name, what put the component there, and which variant showed").

Rules

  • Never write a variant, prop, token name, example or use that has no listed source. A planned use says planned.
  • Never invent a state or a precedence order to make a section look complete.
  • A behaviour that looks like a bug is written as it is, followed by a Defect: line to the owner with what goes wrong for the user and the smallest fix.
  • A part also used on its own gets a ### Parts subsection under Description. A compound component (Tabs with Tab) is one entry.
  • Do not edit the code, stories or spec being documented.
  • Counts in the reply come from grep -o on the saved file, below the draft comment.

Done

Every variant, prop, token and example has a Sources line. Every Usage rule has evidence and a Don't: line. Every conflict is shown. The nine headings are present in order, and a section with nothing sourced reads Not applicable: <reason>.

관련 작업

같은 저장소의 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
커뮤니티

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". One named screen goes to ui-review, one component to component-docs, a token report to token-mapping. A repo with no UI yet is out of scope.

설치 수
2
GitHub Stars
141
업데이트
10월 19일
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일