charliesbot/android-design-explore

시각적 디자인 탐색

모든 디자인 결정에 대해 android-design 스킬을 따릅니다: 섹션 0의 답변, 컴포넌트, 테마, 레이아웃, 화면 확인 질문을 포함합니다. 이 스킬이 워크플로우를 소유합니다. 각 실행은 한 번의 기회입니다: 입력을 받고, 하나의 제안을 작성하고, 확인하고, 표시한 후 중단합니다. 휴대폰, 폴더블, 태블릿, 데스크톱 및 Wear OS 앱 화면이 범위에 포함되며, Wear 타일, 워치 페이스, 위젯은 제외됩니다. Wear가 다른 경우 아래 Wear OS 섹션에서 설명합니다.

제안은 프리뷰어 앱(네이티브 macOS 창)이 실제 Compose Material 3 컴포넌트로 그리고 저장할 때마다 다시 그리는 데이터 파일입니다. 앱의 레이아웃 트리를 통해 확인하며, 사용자는 창에서 미적 감각을 판단합니다.

요구 사항

macOS, 프리뷰어 앱이 설치되어 android_design_preview라는 이름의 MCP 서버로 등록되어야 합니다. 먼저 status 도구를 호출합니다. 도구를 사용할 수 없으면 중단하고 사용자에게 두 단계를 알린 후 기다립니다:

1. android-design 저장소의 체크아웃에서 앱을 빌드하고 설치합니다: cd app && ./gradlew :app:installApp, 이 명령은 ~/Applications/AndroidDesignPreview.app을 설치합니다.
2. 사용자의 harness에 등록한 후 세션을 다시 시작합니다(<binary>는 ~/Applications/AndroidDesignPreview.app/Contents/MacOS/AndroidDesignPreview이며, harness가 ~를 확장하지 않는 절대 경로로 작성합니다):
   • Claude Code: claude mcp add --scope user android_design_preview -- <binary>
   • Codex: ~/.codex/config.toml에 [mcp_servers.android_design_preview] 테이블을 추가하고 command = "<binary>"와 default_tools_approval_mode = "approve"를 설정합니다.
   • Antigravity: agy mcp add android_design_preview <binary>

입력

앱이 있을 때 관련 화면, 테마, 에셋 및 기존 DESIGN.md와 design/ 제안을 먼저 읽습니다. 답변에서 android-design의 섹션 0에 답합니다.

• 하나의 시드를 선택합니다: 브랜드 색상 또는 주제(요리, 앨범, 여행)의 콘텐츠 색상이며, 앱의 기본값 #6750A4는 사용하지 않습니다.
• 화면이 영웅 모멘트(섹션 0의 질문 3)인 경우 세 가지 이상의 전략(섹션 3)을 계층화하고 이름을 지정합니다.
• 앱 코드와 종속성을 변경하지 않고 유지합니다.
• 대표적이고 민감하지 않은 데이터와 에셋을 사용합니다. 이미지 생성은 제안 내 에셋에만 사용하며, 제안 자체를 대체하지 않습니다.

사용자가 요청할 때만 여러 제안을 만듭니다. 각 제안은 고유한 파일이며, theme에 고유한 시드가 있는 별도의 구성(색상 변경이 아님)이고, 적어도 하나는 영웅 모드입니다.

파일

앱의 저장소 루트 또는 사용자가 지정한 폴더에서 작업합니다. 이 스킬의 자체 저장소에는 절대 쓰지 않습니다.

• 루트의 DESIGN.md는 공유 디자인 시스템을 보관합니다. 없을 경우 선택한 시드, 서체 및 명명된 스타일로 생성합니다. 방향이 모든 제안이 공유하는 것을 변경할 때만 변경합니다. 방향의 고유한 모양은 제안의 theme에 들어갑니다.
• design/<slug>.proposal.json은 하나의 제안을 보관합니다.

둘 다 일반 추적 파일이며, 커밋은 프로젝트의 자체 워크플로우를 따릅니다. 사용자에게 제안의 절대 경로를 알립니다.

작성

1. get_catalog를 호출합니다(도구 설명이 반환하는 내용을 설명합니다). 이것이 유일한 컴포넌트 어휘입니다: 없는 컴포넌트는 도달할 수 없으므로 Box, Row, Column, Text, Shape로 아이디어를 구축하거나 생략합니다.
2. references/proposal-format.md를 읽은 후 DESIGN.md와 제안을 "간결하게 작성하기" 섹션에 따라 간결하게 작성합니다.

제안은 다음 디자인 규칙을 따릅니다. proposal-format.md는 각 규칙의 구문을 제공하며, 컴포넌트 규칙 섹션에는 탭, 캐러셀, 오버레이, 선택, 툴바, 메뉴, 앱 바, 배지에 대한 규칙이 있습니다:

• 화면에는 기본으로 표시된 하나의 기본 작업이 있으며, android-design 섹션 2에서 설명하는 대로 동료를 이끕니다.
• 600 및 840 dp에서 적응합니다: 컴팩트에서는 내비게이션 바가 중간부터 레일이 되고, 목록의 세부 화면은 확장된 너비에서 목록 옆에 열립니다.
• 텍스트는 의도적으로 줄임표로 잘립니다. 버튼, 칩 및 내비게이션 레이블은 한 줄에 맞습니다.

확인

제안의 경우 이 단계는 android-design의 화면 확인에서 렌더링을 대체합니다. check_proposal 레이아웃 요약 및 오류(필요할 때 get_tree)에서 질문에 답하며, 렌더링이나 픽셀에서 답하지 않습니다. 스크린샷은 이 루프에서 제외됩니다: 찍거나 요청하지 마십시오.

1. open_proposal을 제안의 절대 경로로 호출합니다. 파일을 로드하고, 감시하며, 창을 표시하고, 유효성 검사 오류를 반환합니다. 오류를 수정하고 오류가 없을 때까지 status를 호출합니다.
2. check_proposal을 호출합니다. 한 번 호출로 모든 화면을 모든 뷰에서 확인하고 각 뷰의 오류와 layout 요약을 반환합니다. 도구 설명이 형식을 제공합니다.
3. 각 오류를 한 번 수정한 후 check_proposal을 다시 호출합니다. overflow 오류는 부모 또는 뷰보다 넓게 배치된 노드(셀보다 더 넓은 너비가 필요한 행)를 나타냅니다. 좁히거나, 줄 바꿈하거나, 스크롤하게 합니다. 계속 실패하는 항목이 있으면 보고하고 반복하지 않습니다.
4. layout 요약에서 적응을 확인합니다: 각 더 큰 뷰는 섹션 0 적응 답변이 약속한 것을 드러냅니다(예: 두 번째 창, 레일 또는 더 많은 영역). Google: "추가 공간이 단순히 같은 것을 더 크게 만드는 것을 의미하지는 않습니다." 더 큰 뷰가 더 넓게 퍼진 전화 영역만 있는 것은 실패입니다.
5. 요약이나 오류만으로 충분하지 않을 때만 get_tree를 호출합니다. 도구 설명이 반환하는 내용을 설명합니다.

check_proposal이 통과하거나 각 남은 오류가 보고하는 목록에 있고 적응이 확인되면 단계가 완료됩니다.

표시

show_preview를 호출합니다. 제안이 무엇인지 한 줄로 말하고, 영웅이 계층화한 전략의 이름을 지정하고, 해결되지 않은 발견 사항을 나열하고, "시각적 품질은 레이아웃 트리에서만 판단됨"을 보고합니다. 그런 다음 중단하고 사용자의 응답을 기다립니다.

수정

사용자의 피드백으로 동일한 제안을 편집합니다. 창은 저장 시 다시 그려집니다. 변경한 화면에서 확인을 반복합니다. 수정은 이전 버전을 대체하며, 복사본을 유지하지 않습니다.

승인 및 포팅

승인은 사용자가 채팅에서 말하는 것입니다. 승인된 제안의 경로와 references/compose-mapping.md가 포팅 테이블임을 보고합니다. 탐색 전용 요청은 여기서 끝납니다: 구현하지 않습니다. 빌드 요청(android-design 스킬이 새 앱, 화면 및 리디자인의 디자인 중심 빌드를 여기로 보냄)은 포팅으로 계속됩니다. 승인은 라이브러리 버전 변경을 승인하지 않습니다.

포팅은 요청 프로젝트의 계획, 브랜치, 검증 및 검토 규칙을 따릅니다:

1. 포팅할 화면에 대해 export_kotlin을 호출합니다. Kotlin은 첫 번째 초안이며 완성된 코드가 아닙니다.
2. references/compose-mapping.md를 사용하여 앱의 규칙과 라이브러리 버전에 맞춥니다.
3. compose-preview 스킬로 결과를 렌더링하고 동일한 뷰에서 제안의 트리와 비교합니다.

매핑이 확인되지 않았거나 부족한 컴포넌트를 보고하고 Compose 대체를 발명하지 않습니다. 앱의 종속성으로 디자인을 보존할 수 없으면 질문합니다.

Wear OS

Wear 제안은 동일한 워크플로우를 따릅니다. android-design references/wear-os.md가 디자인 규칙을 소유하고, proposal-format.md가 파일 형식(카탈로그 ID, 뷰, Screen, primary, large)을 소유합니다.

• 자체 파일. 제안당 하나의 표면: design/<slug>-wear.proposal.json을 휴대폰 파일 옆에 작성합니다.
• 적응 확인: Wear 크기 재정의는 225dp부터 적용되므로 확인은 "두 시계 크기 모두에 맞고 읽을 수 있으며, 큰 크기는 더 많은 가치를 보여주고 결코 적지 않음"입니다.
• 공유 DESIGN.md: 시드와 색상 역할이 Wear에 적용됩니다. 타이포그래피는 Roboto Flex로 대체됩니다.
• 발견 사항: round-edge-clipped(고정 화면에서 둥근 가장자리에 의해 잘린 컨트롤 또는 텍스트)를 백분율 스타일 여백 또는 더 작은 레이아웃으로 수정합니다.
• 포팅: 동일한 세 단계. export_kotlin은 Wear Compose를 작성합니다: 프리뷰어의 정확한 색상을 가진 WearAppTheme, AppScaffold 및 ScreenScaffold, 스와이프로 닫기 기능이 있는 Navigation 3을 포함합니다. 포트를 두 가지 둥근 크기(204 및 227dp)에서 렌더링합니다.

삭제

사용자가 요청하면 design/<slug>.proposal.json을 제거합니다. 사용자가 요청하지 않는 한 DESIGN.md는 유지합니다.