seed-design

SEED Design

SEED Designの公式ドキュメントとCLIを単一の情報源として使用します。このスキルにはドキュメントの内容を複製せず、共通デザイン知識 → プラットフォーム実装 → プラットフォーム別Doctorへと進む探索・判定手順のみを記載します。

1. まずリクエストを分類する

プロジェクトを調査する前に、リクエストを次のいずれかに分類します。

分類	例	プラットフォームの判定
共通コンポーネント仕様・Foundations	Anatomy、Properties、Guidelines、色、タイポグラフィ、スペーシング	不要
プラットフォーム実装	使い方、Props、インストール、セットアップ、スニペット、コード作成、CLI実行	必要
Doctor・マイグレーション	使用状況の診断、deprecated、互換性、アップグレード	必要

共通仕様やFoundationsについてのみ尋ねられた場合は、プロジェクトがなくても共通ドキュメントをすぐに読みます。実装コードも合わせて尋ねられた場合は、まず共通ドキュメントを読んでからプラットフォームを判定し、該当するプラットフォームのドキュメントを組み合わせます。

SEEDリポジトリ作業のルーティング

現在のリポジトリのpackage.jsonの名前が@seed-design/projectで、リクエストが利用者向けの案内ではなくリポジトリ作業の場合は、以下の専用スキルを先に読みます。この表は入口のみを示し、各手順をこのドキュメントに複製するものではありません。

リクエスト	使用するスキル
コンポーネントのパス・APIの比較・カラー トークンの調査、実装・ドキュメントの作成	seed-component
変更の影響・検証・基準ブランチの計画、changeset、明示的に依頼された提出	seed-change
deprecatedの表示・マイグレーション・削除	seed-deprecation
PR snapshotの生成と結果の確認	seed-snapshot-release

調査や計画の結果だけをもとに、ファイルの作成や提出を開始してはいけません。seed-changeのブランチ結果がunknownの場合は、提出しません。

2. プラットフォームを判定する

プラットフォームによって結果が異なるリクエストにのみ、以下の順序を適用します。

1. ユーザーが明示したプラットフォーム：ReactまたはLynx
2. 対象ワークスペースの設定：seed-design.json.framework
3. 対象ワークスペースの直接依存関係
   • React：@seed-design/react、@seed-design/css
   • Lynx：@seed-design/lynx-react、@seed-design/lynx-css、または@lynx-js/react

優先順位の高い明確な手がかりを、優先順位の低い手がかりで上書きしてはいけません。ただし、同じ対象内で設定と依存関係が矛盾する場合は、設定が古い可能性があるため、ユーザーに確認します。

モノレポではルートのpackage.jsonだけを確認せず、まずリクエスト対象のワークスペースを探します。ルートへのリクエストでReactとLynxのワークスペースが両方見つかった場合、または対象パスが不明確な場合は、実装・インストール・Doctorを開始する前に、どのワークスペースまたはプラットフォームを対象とするかを尋ねます。

手がかりがない場合や、同じ段階で複数のプラットフォームが同時に見つかった場合も、ユーザーに尋ねます。**不確かな状況でReactをデフォルトとして使用してはいけません。**これはエージェントのドキュメントルーティング規則であり、既存のCLIの公開動作やseed-design.jsonのデフォルト値を変更する規則ではありません。

プラットフォームの判定後、必要な場合に限り、以下のプロジェクト情報も収集します。

• seed-design.jsonのpathと、そのディレクトリにある@fileヘッダーファイル → スニペットのインストール状況
• インストール済みの@seed-design/*バージョン
• バンドラーの設定（vite.config、rsbuild.config、webpack.configなど）
• ロックファイルから判定したパッケージマネージャー（bun → pnpm → yarn → npm）

3. 公式ドキュメントのルーティング

ドキュメント一覧や対応範囲をスキルに複製しません。リクエストごとに、まず以下のインデックスを読み、インデックスに記載されたリンクをそのままたどります。

• 全ドキュメントのインデックス：https://seed-design.io/llms.txt
• Reactドキュメントのインデックス：https://seed-design.io/react/llms.txt
• Lynxドキュメントのインデックス：https://seed-design.io/lynx/llms.txt

1つのリクエストの実行中は、URLを正規化したドキュメントプールを維持します。全体インデックス、選択したプラットフォームのインデックス、各leafドキュメントは、URLごとに一度だけ読み、その後の手順やルールでは同じ内容を再利用します。レポートのreferencesに同じURLを繰り返し記載するのは出典を保持するためであり、再度読むことを意味しません。HTTPキャッシュは前提としません。

以下の順序を守ります。

1. 全体インデックスから、共通のComponents・Foundations・Patterns、または選択したプラットフォームの現在のエントリーポイントを探します。
2. プラットフォーム実装のリクエストでは、選択したプラットフォームのインデックスを読み、タイトル・category・説明から必要なドキュメントを探します。
3. インデックスに記載されたleaf URLを開き、実際の仕様を読みます。記憶しているパスやURLの組み合わせからleafドキュメントを作成してはいけません。
4. インデックスを正常に読んだうえで関連項目が見つからない場合は、現在の公式ドキュメントは存在しないと判断します。インデックス自体を読めなかった場合は、存在しないと断定してはいけません。

CLIのdocsコマンドを使用する場合も、まずインデックスでドキュメントとidを確認します。URLパスとCLIのidが同じだと仮定せず、idを確定できない場合は、インデックスに記載されたURLを直接読みます。

コンポーネントに関する回答の順序

1. 仕様についての質問であれば、共通コンポーネントのドキュメントのみを読みます。
2. 実装についての質問であれば、プラットフォームを判定し、該当するプラットフォームのドキュメントを読みます。
3. 仕様と実装の両方について尋ねられた場合は、まず共通ドキュメントを読み、判定したプラットフォームのドキュメントを続けて読みます。
4. 共通ドキュメントのidと実装ドキュメントのidが異なる場合は、共通ドキュメントのPlatform表と、選択したプラットフォームのインデックスから実際のidを探します。
5. 選択したプラットフォームのドキュメントまたはregistry項目がない場合は、そのプラットフォームの実装・ドキュメントが存在しないことを伝えます。他のプラットフォームのドキュメントで代用してはいけません。

スニペットが必要な場合は、選択したプラットフォームのregistryのみを使用します。

https://seed-design.io/__registry__/{react|lynx}/{registryId}/index.json
https://seed-design.io/__registry__/{react|lynx}/{registryId}/{itemId}.json

個別スニペットのパスは{itemId}/index.jsonではなく、{itemId}.jsonです。

CLIドキュメント

全体・プラットフォームのインデックスから、CLI、Commands、Configurationに該当する現在のリンクを探し、内容を読みます。ドキュメントがどのプラットフォームのツリーにあるかだけを根拠に、対応プラットフォームやオプションを推測してはいけません。コマンド・フラグ・設定フィールドには、リンク先のドキュメントまたはインストール済みCLIのソースに明記された値のみを使用します。

4. 판단이 필요한 절차

요청	읽을 참조
스니펫 버전 맞추기, 파일 충돌, 패키지 호환	migration.md
changelog 해석과 업그레이드 경로	upgrade.md
코드 사용 상태 진단	doctor.md

마이그레이션과 업그레이드도 플랫폼을 먼저 판별합니다. 참조 파일의 React 전용 옵션이나 호환표를 Lynx에 적용하지 말고, 선택된 플랫폼의 패키지와 changelog만 대조합니다.

Doctor 요청은 doctor.md의 적응형 탐색 절차를 먼저 따릅니다.

1. 사용자 지정 경로
2. node_modules, .git, .claude/worktrees를 제외한 seed-design.json
3. 설정 발견 여부와 관계없이 직접 @seed-design/* 의존성이 있는 workspace
4. 두 후보를 package 경계로 중복 제거
5. 사용자 명시 → framework → 직접 의존성 순의 플랫폼 확정
6. 공개 진입점과 앱·라이브러리 빌드 증거에 따른 비배타적 역할 판정

• React Doctor: doctor-react.md를 함께 읽습니다.
• Lynx Doctor: doctor-lynx.md를 함께 읽습니다.

플랫폼 프로필은 문서 지원 현황을 복제하지 않고 인덱스·패키지·registry 탐색의 시작점만 제공합니다. 일반 진단은 공통 룰 전체를 scope에 넣고, 현재 인덱스에서 발견한 공식 계약과 각 룰의 적용 조건으로 검사 여부를 정합니다. 사용자가 config·setup·foundations·components·compatibility·library 중 범주를 지정했다면 그 범주만 실행합니다. 여러 workspace의 전체 진단은 리포트를 workspace별로 따로 만듭니다.

Doctor는 문제를 찾는 진단이고, upgrade.md는 실제로 버전을 올리는 절차입니다. 진단이 버전 격차를 알려도 사용자가 수정을 요청하기 전에는 업그레이드를 실행하지 않습니다.

5. 코드 작성과 기존 코드 진단

rules/의 룰은 SEED 코드를 작성할 때 지키는 계약이자 Doctor의 판정 기준입니다. Doctor에서는 선택된 플랫폼 프로필과 각 룰의 적용 조건을 함께 사용합니다.

• project-config: 현재 CLI 설정 계약, framework 충돌, snippet path·alias 연결
• package-compatibility: 플랫폼 패키지 설치본 조합
• project-setup: 선택된 플랫폼 문서가 요구하는 앱 설치·스타일 연결
• snippet-compatibility: 현재 패키지와 설치 스니펫의 CLI compat 결과
• foundation-contract: 토큰 존재·공개성·내부 스타일 API 의존
• library-authors: 공식 저자 문서가 있는 플랫폼의 peer·external·CSS·배포 계약
• outdated-version: 직접 설치한 패키지의 최신 세대 격차만
• snippet-generation: 설치 스니펫과 registry의 최신 세대 차이만
• no-deprecated-component: 플랫폼에 유효한 출처가 있는 deprecated 항목만
• component-guidelines: 공통 디자인 문서와 매핑 가능한 플랫폼 구현의 대조

토큰은 문서·CSS·플랫폼 API에서 표기가 달라질 수 있습니다. 공통 Foundations 문서에서 의미와 토큰을 확인한 뒤, 코드 표기는 선택된 플랫폼 구현 문서에서 확인합니다. 한 플랫폼의 코드 표기를 다른 플랫폼에 복사하지 않습니다.

6. 응답과 실행 원칙

• 공식 문서를 실제로 읽고 근거 링크와 함께 답합니다.
• 설치·실행 명령은 대상 프로젝트의 패키지 매니저에 맞춥니다.
• read-only 진단과 실제 수정 요청을 구분합니다.
• Doctor 결과는 schema v2 YAML을 단일 원천으로 임시 디렉토리에 기록하고, 사용자가 "YAML만"을 명시하지 않으면 같은 디렉토리에 HTML 리포트도 함께 생성합니다. 대상 프로젝트에는 쓰지 않습니다.
• 각 finding의 remediation에는 대상·문제·요구사항·제약·근거·검증을 포함한 복사 가능한 수정 프롬프트를 기록합니다. 프롬프트를 만드는 것은 진단이며, 사용자가 별도로 수정을 요청하기 전에는 실행하지 않습니다.
• 없는 경로나 API를 추측하지 않습니다.
• 작업이 끝나면 현재 맥락에 맞는 다음 단계만 짧게 제안합니다.