authoring-analysis について
authoring-analysisは、ページ内の各コンテンツ系列にデフォルトコンテンツと既存ブロックのどちらを使うか判断するスキルです。page-importでの作成方針を支援し、HTML生成前にブロック構造とセクションのスタイルを確認します。
主な機能
- 01系列ごとにデフォルトコンテンツを判定
- 02構造化コンテンツにブロックを選択
- 03不明確なブロック選択の検証
- 04ブロックのHTML構造を取得
- 05単一ブロックのセクションスタイルを確認
活用シーン
- 01ページ内の各系列の表現方法を選択
- 02HTML生成前にブロックのマークアップを確認
- 03セクションスタイルをメタデータに含めるか判断
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ adobe/ skills --skill authoring-analysisインストール後、Claude Code で/authoring-analysisを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
.releaserc.jsonCHANGELOG.mdpackage.json詳細
作成方法の分析
各コンテンツシーケンスについて、作成方法を判定します。デフォルトコンテンツか、特定のブロックかを決定します。
このスキルを使用するタイミング
次の場合にこのスキルを使用します。
- コンテンツシーケンスを含むページ構造がある(identify-page-structure から取得)
- ブロックの一覧がある(ローカル+Block Collection)
- David's Model に従って作成方法を決定できる状態である
呼び出し元: page-import スキル(ステップ 3)
前提条件
identify-page-structure スキルから、以下が必要です。
- ✅ スタイルに関する注記付きのセクション境界
- ✅ セクションごとのコンテンツシーケンス(中立的な説明)
- ✅ ブロックの一覧(ローカル+Block Collection と用途)
- ✅ 視覚的な参照用の screenshot.png
関連スキル
- page-import - このスキルを呼び出すオーケストレーター
- identify-page-structure - セクション構造とブロックの一覧を提供します
- content-modeling - ブロックの選択が不明確な場合に、このスキルから呼び出されます
- block-collection-and-party - ブロックを検証するために、このスキルから呼び出されます
- generate-import-html - このスキルの出力を使って HTML を作成します
重要:ステップ 3e の実行条件
ステップ 3(すべてのシーケンスの分析)の完了後、以下に該当する場合は、必ずステップ 3e を実行してください。
- ✅ 少なくとも 1 つのセクションに、ブロックとなるシーケンスがちょうど 1 つ含まれている
- ✅ identify-page-structure で、そのセクションに他とは異なる背景スタイルが設定されている
該当するセクションがない場合 → ステップ 3e をスキップします
該当するセクションが 1 つでもある場合 → 条件を満たす各セクションについてステップ 3e を実行します
作成方法の分析ワークフロー
前提: 以下の情報が揃っています。
- スタイル付きのセクション境界
- セクションごとのコンテンツシーケンス
- 使用可能なブロックの選択肢
各コンテンツシーケンスについて、以下の必須手順に従います。
ステップ 3a:必須 - デフォルトコンテンツの確認(最初に実施!)
質問:「作者は Word/Google Docs で普通に入力するだけで、これを作成できますか?」
デフォルトコンテンツとは、以下を指します。
- ✅ 見出し、段落、リスト
- ✅ テキスト内のインライン画像
- ✅ シンプルな引用
- ✅ つまり……コンテンツを入力するだけ
デフォルトコンテンツではないもの:
- ❌ 繰り返される構造化パターン(カードグリッド、機能リスト)
- ❌ インタラクティブなコンポーネント(アコーディオン、タブ、カルーセル)
- ❌ 複雑なレイアウト(横並びの列、分割されたコンテンツ)
- ❌ 装飾のために特定の構造が必要なもの
判定:
- YES(通常の入力で作成できる)→ デフォルトコンテンツとして記録し、完了 ✅
- NO(構造が必要)→ ステップ 3b に進みます
例:
"Large centered heading, paragraph, two buttons"
→ Can author just type heading, paragraph, links? YES
→ Decision: DEFAULT CONTENT ✅
"Two centered buttons"
→ Can author just type two links? YES
→ Decision: DEFAULT CONTENT ✅
"Four items in grid, each with image, heading, description"
→ Can author just type this? NO - requires grid structure
→ Decision: Proceed to Step 3b ➡️
"Expandable questions and answers"
→ Can author just type this? NO - requires interaction/decoration
→ Decision: Proceed to Step 3b ➡️
ステップ 3b:ブロックの選択(デフォルトコンテンツではない場合のみ)
ブロック一覧を踏まえて質問します。「作者なら、このコンテンツの作成にどのブロックを選ぶでしょうか?」
content-modeling を呼び出す判断フロー
明確に一致する場合(content-modeling を呼び出さない):
パターンとブロックの用途が 1 対 1 で一致する場合:
- 「画像/テキスト付き項目のグリッド」+「cards」ブロックがある → 使用します ✅
- 「展開可能な質問」+「accordion」ブロックがある → 使用します ✅
- 「タブ付きコンテンツパネル」+「tabs」ブロックがある → 使用します ✅
- 「横並びのコンテンツ」+「columns」ブロックがある → 使用します ✅
- 「切り替わる画像」+「carousel」ブロックがある → 使用します ✅
「明確に一致する」条件:
- コンテンツの説明がブロックの用途に正確に一致する
- 構造に曖昧さがない
- ブロックが一覧にある
一致が不明確な場合(content-modeling を呼び出す):
使用するブロックが曖昧な場合:
- 「画像付きの項目が 3 つ」— cards でしょうか? columns でしょうか? → 呼び出します
- 「アイコン付きの機能リスト」— cards でしょうか? カスタムリストブロックでしょうか? → 呼び出します
- 「写真付きの顧客の引用」— quote ブロックでしょうか? cards でしょうか? testimonial ブロックでしょうか? → 呼び出します
一覧に該当するブロックがない場合:
- コンテンツに構造が必要だが、一致するブロックがない → 呼び出します
- content-modeling は、標準的なモデルを推奨したり、カスタムブロックの作成を提案したりできます
複雑な作成上の検討が必要な場合:
- 「ページの途中にあるヒーロー風のコンテンツ」→ 呼び出します
- 「カード風の項目が 2 つだけ」→ 呼び出します
- 作者のメンタルモデルを検証する必要がある → 呼び出します
「不明確」と判断する条件:
- 使用できそうなブロックが複数ある
- 明らかに一致するブロックがない
- 作者の視点からの検証が必要
- カスタムブロックの作成が必要になる可能性がある
ステップ 3c:ブロックの存在を確認する(必要な場合)
ブロックが Block Collection の共通セットに含まれていない場合のみ:
block-collection-and-party スキルを呼び出して、以下を行います。
- ブロックが存在することを確認する
- 実際の使用例の URL を取得する
- コンテンツモデルを確認する
ステップ 3d:ブロックの HTML 構造を取得する(HTML の生成前)
重要: 次のスキルで HTML を生成する前に、使用するすべてのブロックの装飾前 HTML 構造を取得してください。
# Get structure examples for each block
node .claude/skills/block-collection-and-party/scripts/get-block-structure.js cards
node .claude/skills/block-collection-and-party/scripts/get-block-structure.js tabs
node .claude/skills/block-collection-and-party/scripts/get-block-structure.js accordion
node .claude/skills/block-collection-and-party/scripts/get-block-structure.js columns
間違いを防げる理由:
- 正確な行と列の構造がわかります(例:カードでは、各カードは 2 列の 1 行です)
- すべてのバリエーションを確認できます(例:「Cards」と「Cards (no images)」)
- 装飾のないクリーンな HTML が表示されます
- HTML 生成で最も多いエラーである、誤った構造を防げます
出力を次の用途に使います。
- 各行に必要な列数を把握する
- 画像とコンテンツの配置場所を確認する
- コンテンツを適切なバリエーションに合わせる
- 想定される構造に完全に一致する HTML を生成する
ステップ 3 の出力形式
すべてのシーケンスについて分析を完了します。
Section 1 (light):
- Sequence 1: "Large centered heading, paragraph, two call-to-action buttons"
→ Decision: DEFAULT CONTENT
→ Reason: Author can type heading, paragraph, links normally
→ Note: Prominent styling is a CSS concern
- Sequence 2: "Two images side-by-side"
→ Decision: Columns block (2 columns)
→ Reason: Side-by-side layout requires structure
→ Obvious match with "columns" block in inventory
Section 2 (light):
- Sequence 1: "Centered heading"
→ Decision: DEFAULT CONTENT
→ Reason: Just a heading - author types it
- Sequence 2: "Grid of 8 items, each with icon and short text"
→ Decision: Cards block
→ Reason: Repeating structured pattern, needs block
→ Obvious match with "cards" block in inventory
- Sequence 3: "Two centered buttons"
→ Decision: DEFAULT CONTENT
→ Reason: Just two links - author types them
Section 3 (grey):
- Sequence 1: "Eyebrow text, heading, paragraph, button stacked vertically"
→ Decision: DEFAULT CONTENT
→ Reason: Author types text and link normally
- Sequence 2: "Four items in grid, each with image, category tag, heading, description"
→ Decision: Cards block
→ Reason: Repeating structured pattern
→ Obvious match with "cards" block in inventory
Section 4 (dark):
- Sequence 1: "Tab navigation with three switchable content panels"
→ Decision: Tabs block
→ Reason: Interactive component, needs decoration
→ Obvious match with "tabs" block in inventory
ステップ 3e:セクションのスタイルを検証する(単一ブロックのセクションのみ)
⚠️ 実行条件: このステップは、ステップ 3 の完了後に実行します。次の条件をすべて満たす場合に限り、このステップを実行してください。
- ✅ ステップ 3 を完了している(どのシーケンスがブロックになるかを特定している)
- ✅ ちょうど 1 つのブロックになったシーケンスを含むセクションが少なくとも 1 つある
- ✅ そのセクションに、identify-page-structure で識別した独自の背景スタイルがある
これらの条件を満たすセクションがない場合 → ステップ 3e を完全にスキップし、次のスキルに進みます
これらの条件を満たすセクションがある場合 → 該当する各セクションについて、以下のすべてのサブステップを必ず実行してください
この検証が重要な理由:
セクションにブロックが 1 つだけ含まれる場合、背景スタイルは次のいずれかである可能性があります。
- ブロック固有のデザイン(例:暗い背景画像を使ったヒーロー)→ section-metadata を追加しない
- セクションコンテナのスタイル(例:タブブロックを含む暗いセクション)→ section-metadata を追加する
検証せずに section-metadata を追加すると、ブロックのスタイルと競合したり、作成が複雑になったりするおそれがあります。
複数のシーケンスを含むセクション: 常に section-metadata を維持します(スタイルはすべてのコンテンツに適用されるため、ステップ 3e で検証しません)
ブロックが 1 つだけの各セクションについて、以下のすべてのサブステップを実行してください。
サブステップ 1:候補となるセクションを特定する
ステップ 3 の出力を確認します。次の条件に当てはまるセクションを見つけてください。
- セクションにコンテンツシーケンスが 1 つだけ含まれる
- そのシーケンスがブロックになった(デフォルトコンテンツではない)
- セクションに identify-page-structure で識別した独自の背景スタイルがある
例:
Section 1 (dark blue):
- Sequence 1: Large centered heading, paragraph, two buttons
→ Decision: Hero block
Section 3 (grey):
- Sequence 1: Tab navigation with three switchable panels
→ Decision: Tabs block
サブステップ 2:候補となる各セクションのスクリーンショットを確認する
screenshot.png を開き、セクションを視覚的に確認します。
次の質問を検討してください。
Q1:背景は画像(写真、グラデーション、イラスト)ですか?
- はい → ブロック固有のデザインである可能性が高いです
- いいえ(単色)→ Q2 に進みます
Q2:コンテンツは色付きの領域全体に端から端まで広がっていますか。それとも、セクションのパディングが見えますか?
- 端から端まで広がっている(フルブリード)→ ブロック固有のデザインである可能性が高いです
- コンテンツの周囲にパディングが見える → セクションコンテナのスタイルである可能性が高いです
Q3:そのブロックタイプは、通常、独自の背景スタイルを持っていますか?
- ヒーロー、バナー、全幅 CTA → 独自の背景を持つことがよくあります
- タブ、アコーディオン、カード、カラム → セクションの背景を使うことがよくあります
サブステップ 3:判断する
分析に基づき、ブロックが 1 つだけの各セクションについて判断します。
次の場合は section-metadata をスキップします。
- 背景が画像またはグラデーションである(ブロック固有)
- コンテンツがフルブリード/端から端まで広がっている(セクションのパディングが見えない)
- ブロックタイプが通常、固有の背景を持つ(ヒーロー、バナー)
次の場合は section-metadata を維持します。
- 背景が単色で、セクションのパディングが見える
- ブロックタイプが通常、セクションのスタイルを継承する(タブ、カード、アコーディオン)
- スタイルがブロックのデザインではなく、コンテナのコンテキストを明確に示している
サブステップ 4:判断を記録する
検証した各セクションについて、次の項目を記録します。
- セクション番号
- ブロックタイプ
- 背景の分析(画像か単色か、フルブリードかパディングありか)
- 判断(section-metadata を維持するかスキップするか)
- 理由
出力例:
VALIDATED SECTIONS:
Section 1 (dark blue):
- Block: Hero
- Background: Full-width dark blue gradient image
- Layout: Edge-to-edge, no visible section padding
- Decision: SKIP section-metadata
- Reason: Background is hero's design, not section styling
Section 3 (grey):
- Block: Tabs
- Background: Solid grey (#f5f5f5)
- Layout: Content centered with visible padding (~80px on sides)
- Decision: KEEP section-metadata style="grey"
- Reason: Section provides container styling for tabs block
判断に迷った場合:
背景がブロック固有かセクション全体に適用されるか判断できない場合:
- section-metadata を維持することをデフォルトとします(より安全で、追加するよりも作成者が削除しやすいため)
- あいまいな点を説明するメモをドキュメントに追加します
- ユーザーに確認を求めることも検討してください
ステップ 3e の完了チェックリスト:
次のスキルに進む前に、以下が完了していることを確認してください。
- ✅ 背景スタイルのある単一ブロックのセクションをすべて特定した
- ✅ 候補となる各セクションについて、元のスクリーンショットを確認した
- ✅ 候補となる各セクションについて、Q1、Q2、Q3 に回答した
- ✅ 候補となる各セクションについて、スキップするか維持するかを判断した
- ✅ 各判断の理由を記録した
- ✅ 検証結果を反映してセクションのスタイルに関するメモを更新した
最終出力
このスキルでは、作成に関する分析を網羅的に行います。
1. すべてのシーケンスに関する作成上の判断:
- 各シーケンスにデフォルトコンテンツまたは特定のブロック名を指定します
- 判断の根拠を記録します
2. 取得したブロック構造:
- 使用するすべてのブロックの HTML 構造の例
3. セクションのスタイルの検証(該当する場合):
- スタイルを検証した、更新済みのセクションリスト
- 一部のセクションは「セクションメタデータなし」と記載される場合があります
次のステップ: これらの出力を generate-import-html スキルに渡します