canvas-component-composability
Canvas上で動作するReactコンポーネントを、スロットと分解を重視したパターンで設計し、肥大化したコンポーネントのリファクタリングや、propsとslotsの使い分けを支援することで、Canvasとの互換性を保ちながら再利用性と保守性の高いコンポーネントを構築するSkill。
📜 元の英語説明(参考)
Design Canvas-ready React components with slots and decomposition-first patterns. Use when (1) Designing a component's prop/slot structure, (2) A component is growing too large, (3) Deciding between props vs slots, (4) Refactoring monolithic components, (5) Modeling repeatable list/grid content. Ensures Canvas compatibility.
🇯🇵 日本人クリエイター向け解説
Canvas上で動作するReactコンポーネントを、スロットと分解を重視したパターンで設計し、肥大化したコンポーネントのリファクタリングや、propsとslotsの使い分けを支援することで、Canvasとの互換性を保ちながら再利用性と保守性の高いコンポーネントを構築するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o canvas-component-composability.zip https://jpskill.com/download/9230.zip && unzip -o canvas-component-composability.zip && rm canvas-component-composability.zip$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9230.zip -OutFile "$d\canvas-component-composability.zip"; Expand-Archive "$d\canvas-component-composability.zip" -DestinationPath $d -Force; ri "$d\canvas-component-composability.zip"完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
canvas-component-composability.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
canvas-component-composabilityフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
[スキル名] canvas-component-composability
多くのpropsを持つモノリシックなコンポーネントよりも、小さく、焦点を絞ったコンポーネントを優先してください。コンポーネントが多くの無関係なpropsを蓄積し始めたら、より小さく、構成可能な部品に分解します。
参照マップ
必要な場合にのみ参照をロードします。
- 繰り返し可能なリスト/グリッドと配列からスロットへの変換:
references/repeatable-content.md - 空のflex/gridコンテナ内のスロットのインタラクティブ性:
references/repeatable-content.md("Slot container minimum size" セクション)
コンポーネントを分解すべき兆候
以下のような場合、コンポーネントの分割を検討してください。
- 明確な目的を持つpropsが6〜8個以上ある場合
- スタンドアロンのコンポーネントとして意味をなす要素のprops（breadcrumbs、titles、metadata、navigation）
- コンポーネントを使用できる場所を制限する組み込みのレイアウトの仮定
- 独立して再利用できる複数の異なる視覚的なセクション
柔軟な構成のためにスロットを使用する
スロットは、構成可能性のための主要なメカニズムです。propsを介して複雑なデータを渡す代わりに、スロットを使用して、親コンポーネントが子コンポーネントを受け入れるようにします。これは、Canvasユーザーがコンポーネントを他のコンポーネント内に配置してページを構築する方法と一致します。
スロットとpropsの使い分け
| スロットを使用する場合 | propsを使用する場合 |
|---|---|
| 子コンポーネントの可変の数 | 単一の必須の値（テキスト、URL） |
| ユーザーが構成する必要があるコンテンツ | 構成オプション（サイズ、色） |
| 複雑なネストされた構造 | 単純なデータ（文字列、ブール値） |
| インスタンス間で異なるコンテンツ | インスタンス間で一貫性のあるコンテンツ |
component.ymlでスロットを宣言する
component.ymlでスロットを宣言し、JSXで名前付きpropsとしてレンダリングします。
正確なスロットスキーマと制約（map vs []、スロットキー、childrenの処理）については、canvas-component-metadataを信頼できる情報源として従ってください。
一般的な分解パターン
ページレベルの要素は個別のコンポーネントであるべき
多くのページに表示されるが、常に一緒に必要とされるわけではない要素は、個別のコンポーネントである必要があります。
繰り返されるパターンを小さなコンポーネントに抽出する
同じ要素の組み合わせが繰り返される場合は、それを抽出します。
- 日付 + カテゴリ/タグ ->
article-meta - カバー画像 + ダウンロードボタン ->
resource-cover - ラベル + 値のペア ->
metadata-item - アイコン + テキストリンク ->
icon-link
組み込みのレイアウトの代わりにレイアウトコンポーネントを使用する
コンテンツコンポーネントに2カラムまたはグリッドレイアウトを組み込まないでください。レイアウトコンポーネントを使用し、コンテンツをそれらに構成します。
分解しない場合
以下の場合、コンポーネントを一緒に保持します。
- それらは常に一緒に表示され、別々に意味をなさない場合
- それらは、持ち上げるのが厄介な重要な内部状態を共有している場合
- 視覚的なデザインがそれらを密接に結び付けている場合（たとえば、要素の重複、共有の背景）
- 分解すると、他に役立たない1〜2個のpropsを持つコンポーネントが作成される場合
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Prefer small, focused components over monolithic ones with many props. When a component starts accumulating many unrelated props, decompose it into smaller, composable pieces.
Reference map
Load references only as needed:
- Repeatable lists/grids and array-to-slot conversion:
references/repeatable-content.md - Slot interactivity in empty flex/grid containers:
references/repeatable-content.md("Slot container minimum size" section)
Signs a component should be decomposed
Consider breaking up a component when it has:
- More than 6-8 props that serve distinct purposes
- Props for elements that make sense as standalone components (breadcrumbs, titles, metadata, navigation)
- Built-in layout assumptions that limit where the component can be used
- Multiple distinct visual sections that could be reused independently
Use slots for flexible composition
Slots are the primary mechanism for composability. Instead of passing complex data through props, use slots to let parent components accept child components. This matches how Canvas users build pages by placing components inside other components.
When to use slots vs props
| Use slots for | Use props for |
|---|---|
| Variable number of child components | Single, required values (text, URL) |
| Content that users should compose | Configuration options (size, color) |
| Complex nested structures | Simple data (strings, booleans) |
| Content that varies between instances | Content consistent across instances |
Declare slots in component.yml
Declare slots in component.yml and render them as named props in JSX.
For exact slot schema and constraints (map vs [], slot keys, children
handling), follow canvas-component-metadata as the source of truth.
Common decomposition patterns
Page-level elements should be separate components
Elements that appear on many pages but are not always needed together should be separate components.
Extract repeated patterns into small components
When the same combination of elements is repeated, extract it:
- Date + category/tag ->
article-meta - Cover image + download button ->
resource-cover - Label + value pairs ->
metadata-item - Icon + text link ->
icon-link
Use layout components instead of built-in layouts
Do not bake two-column or grid layouts into content components. Use layout components and compose content into them.
When not to decompose
Keep components together when:
- They always appear together and never make sense separately
- They share significant internal state that would be awkward to lift up
- The visual design tightly couples them (for example, overlapping elements, shared backgrounds)
- Decomposition would create components with only 1-2 props that are not useful elsewhere