authoring-analysis

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Authoring Analysis

创作分析

Determine authoring approach for EACH content sequence: default content or specific block.
为每个内容序列确定创作方式:默认内容或特定区块。

When to Use This Skill

何时使用此技能

Use this skill when:
  • You have page structure with content sequences (from identify-page-structure)
  • You have block inventory (local + Block Collection)
  • Ready to make authoring decisions following David's Model
Invoked by: page-import skill (Step 3)
在以下场景使用此技能:
  • 你拥有来自identify-page-structure技能的带内容序列的页面结构
  • 你拥有区块清单(本地 + Block Collection)
  • 准备按照David's Model做出创作决策
调用方: page-import技能(步骤3)

Prerequisites

前置条件

From identify-page-structure skill, you need:
  • ✅ Section boundaries with styling notes
  • ✅ Content sequences per section (neutral descriptions)
  • ✅ Block inventory (local + Block Collection with purposes)
  • ✅ screenshot.png for visual reference
从identify-page-structure技能中,你需要:
  • ✅ 带样式说明的章节边界
  • ✅ 每个章节的内容序列(中性描述)
  • ✅ 区块清单(本地 + 带用途说明的Block Collection)
  • ✅ screenshot.png用于视觉参考

Related Skills

相关技能

  • page-import - Orchestrator that invokes this skill
  • identify-page-structure - Provides section structure and block inventory
  • content-modeling - This skill invokes it when block selection is unclear
  • block-collection-and-party - This skill invokes it to validate blocks
  • generate-import-html - Uses this skill's output to create HTML
  • page-import - 调用此技能的编排器
  • identify-page-structure - 提供章节结构和区块清单
  • content-modeling - 当区块选择不明确时,此技能会调用它
  • block-collection-and-party - 此技能调用它来验证区块
  • generate-import-html - 使用此技能的输出来创建HTML

IMPORTANT: Step 3e Execution Trigger

重要提示:步骤3e执行触发条件

After completing Step 3 (analyzing all sequences), you MUST execute Step 3e if:
  • ✅ At least one section contains exactly ONE sequence that became a block
  • ✅ That section has distinct background styling from identify-page-structure
If NO sections meet these criteria → Skip Step 3e If ANY sections meet these criteria → Execute Step 3e for EACH qualifying section
完成步骤3(分析所有序列)后,若满足以下条件,你必须执行步骤3e:
  • ✅ 至少有一个章节包含且仅包含一个被设为区块的序列
  • ✅ 该章节具有来自identify-page-structure技能的独特背景样式
如果没有章节符合这些条件 → 跳过步骤3e 如果有任何章节符合这些条件 → 为每个符合条件的章节执行步骤3e

Authoring Analysis Workflow

创作分析工作流

Context: You now have:
  • Section boundaries with styles
  • Content sequences per section
  • Available block palette
FOR EACH content sequence, follow this mandatory process:

上下文: 你已拥有:
  • 带样式的章节边界
  • 每个章节的内容序列
  • 可用区块面板
对于每个内容序列,遵循以下强制流程:

Step 3a: MANDATORY - Default Content Check (FIRST!)

步骤3a:强制操作 - 默认内容检查(优先执行!)

Question: "Can an author create this with normal typing in Word/Google Docs?"
Default content means:
  • ✅ Headings, paragraphs, lists
  • ✅ Inline images within text
  • ✅ Simple quotes
  • ✅ Just... typing content
NOT default content means:
  • ❌ Repeating structured patterns (card grids, feature lists)
  • ❌ Interactive components (accordions, tabs, carousels)
  • ❌ Complex layouts (side-by-side columns, split content)
  • ❌ Requires specific structure for decoration
Decision:
  • If YES (can type normally) → Mark as DEFAULT CONTENT, DONE
  • If NO (needs structure) → Proceed to Step 3b
Examples:
"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 ➡️

问题: "作者能否在Word/Google Docs中通过常规输入创建此内容?"
默认内容指:
  • ✅ 标题、段落、列表
  • ✅ 文本内的嵌入式图片
  • ✅ 简单引用
  • ✅ 仅需输入的内容
非默认内容指:
  • ❌ 重复的结构化模式(卡片网格、功能列表)
  • ❌ 交互式组件(折叠面板、标签页、轮播)
  • ❌ 复杂布局(并排列、拆分内容)
  • ❌ 需要特定结构用于装饰的内容
决策:
  • 如果是(可常规输入)→ 标记为默认内容,完成
  • 如果否(需要结构)→ 进入步骤3b
示例:
"居中大标题、段落、两个按钮"
→ 作者能否仅输入标题、段落、链接?是
→ 决策:默认内容 ✅

"两个居中按钮"
→ 作者能否仅输入两个链接?是
→ 决策:默认内容 ✅

"网格中的四个条目,每个包含图片、标题、描述"
→ 作者能否仅输入此内容?否 - 需要网格结构
→ 决策:进入步骤3b ➡️

"可展开的问答内容"
→ 作者能否仅输入此内容?否 - 需要交互/装饰
→ 决策:进入步骤3b ➡️

Step 3b: Block Selection (ONLY IF NOT DEFAULT)

步骤3b:区块选择(仅当非默认内容时执行)

With block inventory context, ask: "Which available block would an author choose for this?"
DECISION TREE: When to Invoke content-modeling
OBVIOUS MATCH (Don't invoke content-modeling):
Pattern matches block purpose 1:1:
  • "Grid of items with images/text" + see "cards" block → USE IT ✅
  • "Expandable questions" + see "accordion" block → USE IT ✅
  • "Tabbed content panels" + see "tabs" block → USE IT ✅
  • "Side-by-side content" + see "columns" block → USE IT ✅
  • "Rotating images" + see "carousel" block → USE IT ✅
Criteria for OBVIOUS:
  • Content description matches block purpose exactly
  • No ambiguity about structure
  • Block exists in inventory
UNCLEAR MATCH (Invoke content-modeling):
Ambiguous which block to use:
  • "Three items with images" - Could be cards? Could be columns? → INVOKE
  • "List of features with icons" - Cards? Custom list block? → INVOKE
  • "Customer quotes with photos" - Quote block? Cards? Testimonial block? → INVOKE
Missing from inventory:
  • Content needs structure BUT no matching block exists → INVOKE
  • content-modeling can recommend canonical model or suggest creating custom block
Complex authoring consideration:
  • "Hero-like content but in middle of page" → INVOKE
  • "Card-like items but only 2 of them" → INVOKE
  • Need validation on author mental model → INVOKE
Criteria for UNCLEAR:
  • Multiple blocks could work
  • No obvious block match
  • Need authoring perspective validation
  • Creating custom block might be needed

结合区块清单上下文,询问:"作者会为此内容选择哪个可用区块?"
决策树:何时调用content-modeling
明显匹配(无需调用content-modeling):
模式与区块用途完全匹配:
  • "带图片/文本的条目网格" + 存在"cards"区块 → 使用它 ✅
  • "可展开的问题" + 存在"accordion"区块 → 使用它 ✅
  • "标签式内容面板" + 存在"tabs"区块 → 使用它 ✅
  • "并排内容" + 存在"columns"区块 → 使用它 ✅
  • "轮播图片" + 存在"carousel"区块 → 使用它 ✅
明显匹配的标准:
  • 内容描述与区块用途完全一致
  • 结构无歧义
  • 区块存在于清单中
模糊匹配(调用content-modeling):
区块选择存在歧义:
  • "三个带图片的条目" - 可能是cards?也可能是columns?→ 调用
  • "带图标的功能列表" - cards?自定义列表区块?→ 调用
  • "带照片的客户引用" - 引用区块?cards?推荐语区块?→ 调用
清单中不存在匹配区块:
  • 内容需要结构但无匹配区块 → 调用
  • content-modeling可推荐标准模型或建议创建自定义区块
复杂创作考量:
  • "类似Hero的内容但位于页面中间" → 调用
  • "类似卡片的条目但只有2个" → 调用
  • 需要验证作者的思维模型 → 调用
模糊匹配的标准:
  • 多个区块均可适用
  • 无明显匹配区块
  • 需要验证创作视角
  • 可能需要创建自定义区块

Step 3c: Validate Block Exists (IF NEEDED)

步骤3c:验证区块是否存在(如有需要)

Only if block not in Block Collection common set:
Invoke block-collection-and-party skill to:
  • Confirm block exists
  • Get live example URL
  • Review content model

仅当区块不在Block Collection通用集合中时执行:
调用block-collection-and-party技能来:
  • 确认区块存在
  • 获取在线示例URL
  • 查看内容模型

Step 3d: Get Block HTML Structure (BEFORE generating HTML)

步骤3d:获取区块HTML结构(生成HTML之前)

CRITICAL: Before generating any HTML in next skill, fetch the pre-decoration HTML structure for ALL blocks you'll use.
bash
undefined
关键: 在下一步技能中生成任何HTML之前,获取所有将使用的区块的预装饰HTML结构。
bash
undefined

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

**Why this prevents mistakes:**
- Shows exact row/column structure (e.g., cards: each card = 1 row with 2 columns)
- Reveals all variants (e.g., "Cards" vs "Cards (no images)")
- Displays clean HTML without decoration
- Prevents the #1 HTML generation error: wrong structure

**Use the output to:**
1. Understand how many columns each row should have
2. See where images vs content go
3. Match your content to the correct variant
4. Generate HTML that matches the expected structure exactly

---
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

**此步骤避免错误的原因:**
- 展示精确的行/列结构(例如:cards区块中每个卡片=1行2列)
- 显示所有变体(例如:"Cards" vs "Cards (无图片)")
- 显示无装饰的纯净HTML
- 防止排名第一的HTML生成错误:结构错误

**使用输出内容来:**
1. 了解每行应包含多少列
2. 查看图片与内容的位置
3. 将你的内容匹配到正确的变体
4. 生成与预期结构完全一致的HTML

---

Step 3 Output Format

步骤3输出格式

Complete analysis for all sequences:
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

完成所有序列的分析:
Section 1 (light):
  - Sequence 1: "居中大标题、段落、两个行动号召按钮"
    → 决策:默认内容
    → 原因:作者可常规输入标题、段落、链接
    → 备注:突出样式属于CSS范畴

  - Sequence 2: "两张并排图片"
    → 决策:Columns区块(2列)
    → 原因:并排布局需要结构
    → 与清单中的"columns"区块明显匹配

Section 2 (light):
  - Sequence 1: "居中标题"
    → 决策:默认内容
    → 原因:仅为标题 - 作者直接输入

  - Sequence 2: "8个条目的网格,每个包含图标和短文本"
    → 决策:Cards区块
    → 原因:重复的结构化模式,需要区块
    → 与清单中的"cards"区块明显匹配

  - Sequence 3: "两个居中按钮"
    → 决策:默认内容
    → 原因:仅为两个链接 - 作者直接输入

Section 3 (grey):
  - Sequence 1: "眉栏文本、标题、段落、按钮垂直堆叠"
    → 决策:默认内容
    → 原因:作者可常规输入文本和链接

  - Sequence 2: "4个条目的网格,每个包含图片、分类标签、标题、描述"
    → 决策:Cards区块
    → 原因:重复的结构化模式
    → 与清单中的"cards"区块明显匹配

Section 4 (dark):
  - Sequence 1: "带三个可切换内容面板的标签导航"
    → 决策:Tabs区块
    → 原因:交互式组件,需要装饰
    → 与清单中的"tabs"区块明显匹配

Step 3e: Validate Section Styling (Single-Block Sections Only)

步骤3e:验证章节样式(仅针对单区块章节)

⚠️ EXECUTION TRIGGER: This step is executed AFTER Step 3 is complete. Execute this step if and only if:
  • ✅ You have completed Step 3 (identified which sequences become blocks)
  • ✅ At least one section contains exactly ONE sequence that became a block
  • ✅ That section has distinct background styling from identify-page-structure
If NO sections meet these criteria → Skip Step 3e entirely and proceed to next skill
If ANY sections meet these criteria → You MUST execute all sub-steps below for EACH qualifying section

Why this validation matters:
When a section contains a single block, the background styling might be:
  • Block-specific design (e.g., hero with dark background image) → Don't add section-metadata
  • Section container styling (e.g., dark section with tabs block) → Add section-metadata
Without validation, we risk adding unnecessary section-metadata that conflicts with block styling or makes authoring more complex.
Sections with multiple sequences: Always keep section-metadata (styling applies to all content, not validated in Step 3e)

For EACH section with exactly one block, execute ALL these sub-steps:
Sub-step 1: Identify the candidate sections
Review your Step 3 output. Find sections where:
  • Section contains exactly 1 content sequence
  • That sequence became a block (not default content)
  • Section has distinct background styling from identify-page-structure
Example:
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

Sub-step 2: For each candidate section, examine the screenshot
Open screenshot.png and examine the section visually.
Ask these questions:
Q1: Is the background an image (photo, gradient, illustration)?
  • If YES → Likely block-specific design
  • If NO (solid color) → Continue to Q2
Q2: Does the content fill the colored area edge-to-edge, or is there visible section padding?
  • Edge-to-edge (full-bleed) → Likely block-specific design
  • Visible padding around content → Likely section container styling
Q3: Does the block type typically have its own background styling?
  • Hero, banner, full-width CTAs → Often have own backgrounds
  • Tabs, accordion, cards, columns → Often use section backgrounds

Sub-step 3: Make the decision
Based on your analysis, decide for each single-block section:
SKIP section-metadata if:
  • Background is an image/gradient (block-specific)
  • Content is full-bleed/edge-to-edge (no section padding visible)
  • Block type typically has intrinsic background (hero, banner)
KEEP section-metadata if:
  • Background is solid color with visible section padding
  • Block type typically inherits section styling (tabs, cards, accordion)
  • Styling clearly provides container context (not block design)

Sub-step 4: Document your decisions
For each validated section, note:
  • Section number
  • Block type
  • Background analysis (image vs solid, full-bleed vs padded)
  • Decision (keep or skip section-metadata)
  • Reason
Example output:
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

When in doubt:
If you're uncertain whether background is block-specific or section-wide:
  • Default to KEEPING section-metadata (safer, easier for authors to remove than add)
  • Add a note in your documentation explaining the ambiguity
  • Consider asking the user for guidance

Step 3e Completion Checklist:
Before proceeding to next skill, verify you have completed:
  • ✅ Identified all single-block sections with background styling
  • ✅ Examined original screenshot for EACH candidate section
  • ✅ Answered Q1, Q2, Q3 for EACH candidate section
  • ✅ Made skip/keep decision for EACH candidate section
  • ✅ Documented reasoning for EACH decision
  • ✅ Updated section styling notes with validated decisions

⚠️ 执行触发条件: 此步骤在步骤3完成后执行。仅当满足以下所有条件时执行此步骤:
  • ✅ 你已完成步骤3(确定哪些序列将成为区块)
  • ✅ 至少有一个章节包含且仅包含一个被设为区块的序列
  • ✅ 该章节具有来自identify-page-structure技能的独特背景样式
如果没有章节符合这些条件 → 完全跳过步骤3e并进入下一个技能
如果有任何章节符合这些条件 → 你必须为每个符合条件的章节执行以下所有子步骤

此验证的重要性:
当章节包含单个区块时,背景样式可能是:
  • 区块专属设计(例如:带深色背景图片的Hero)→ 不要添加section-metadata
  • 章节容器样式(例如:带Tabs区块的深色章节)→ 添加section-metadata
若不进行验证,我们可能会添加不必要的section-metadata,与区块样式冲突或使创作更复杂。
包含多个序列的章节: 始终保留section-metadata(样式适用于所有内容,无需在步骤3e中验证)

对于每个仅含单个区块的章节,执行以下所有子步骤:
子步骤1:识别候选章节
查看步骤3的输出。找到以下章节:
  • 章节仅包含1个内容序列
  • 该序列已设为区块(非默认内容)
  • 章节具有来自identify-page-structure技能的独特背景样式
示例:
Section 1 (dark blue):
  - Sequence 1: 居中大标题、段落、两个按钮
    → 决策:Hero区块

Section 3 (grey):
  - Sequence 1: 带三个可切换面板的标签导航
    → 决策:Tabs区块

子步骤2:针对每个候选章节,查看截图
打开screenshot.png并直观检查该章节。
询问以下问题:
问题1:背景是否为图片(照片、渐变、插图)?
  • 如果是 → 可能为区块专属设计
  • 如果否(纯色)→ 继续问题2
问题2:内容是否填满有色区域边缘到边缘,还是存在可见的章节内边距?
  • 边缘到边缘(全宽)→ 可能为区块专属设计
  • 内容周围有可见内边距 → 可能为章节容器样式
问题3:该区块类型通常是否有自己的背景样式?
  • Hero、Banner、全宽CTA → 通常有自己的背景
  • Tabs、Accordion、Cards、Columns → 通常使用章节背景

子步骤3:做出决策
基于你的分析,为每个单区块章节做出决策:
跳过section-metadata的情况:
  • 背景为图片/渐变(区块专属)
  • 内容为全宽/边缘到边缘(无可见章节内边距)
  • 区块类型通常具有固有背景(Hero、Banner)
保留section-metadata的情况:
  • 背景为纯色且有可见章节内边距
  • 区块类型通常继承章节样式(Tabs、Cards、Accordion)
  • 样式明确提供容器上下文(非区块设计)

子步骤4:记录决策
为每个已验证的章节记录:
  • 章节编号
  • 区块类型
  • 背景分析(图片vs纯色,全宽vs带内边距)
  • 决策(保留或跳过section-metadata)
  • 原因
示例输出:
已验证章节:

Section 1 (dark blue):
  - 区块:Hero
  - 背景:全宽深蓝色渐变图片
  - 布局:边缘到边缘,无可见章节内边距
  - 决策:跳过section-metadata
  - 原因:背景是Hero的设计,而非章节样式

Section 3 (grey):
  - 区块:Tabs
  - 背景:纯色灰色 (#f5f5f5)
  - 布局:内容居中,有可见内边距(两侧约80px)
  - 决策:保留section-metadata style="grey"
  - 原因:章节为Tabs区块提供容器样式

存疑时的处理方式:
如果你不确定背景是区块专属还是章节全局样式:
  • 默认保留section-metadata(更安全,作者删除比添加更容易)
  • 在文档中添加备注说明歧义
  • 考虑向用户寻求指导

步骤3e完成检查清单:
进入下一个技能前,验证你已完成:
  • ✅ 识别所有带背景样式的单区块章节
  • ✅ 查看每个候选章节的原始截图
  • ✅ 为每个候选章节回答问题1、2、3
  • ✅ 为每个候选章节做出跳过/保留决策
  • ✅ 记录每个决策的原因
  • ✅ 使用已验证的决策更新章节样式说明

Final Output

最终输出

This skill provides complete authoring analysis:
1. Authoring decisions for all sequences:
  • Each sequence marked as DEFAULT CONTENT or specific block name
  • Reasoning documented
2. Block structures fetched:
  • HTML structure examples for all blocks to be used
3. Section styling validation (if applicable):
  • Updated section list with validated styling decisions
  • Some sections may be marked "no section-metadata"
Next step: Pass these outputs to generate-import-html skill
此技能提供完整的创作分析:
1. 所有序列的创作决策:
  • 每个序列标记为默认内容或特定区块名称
  • 记录决策原因
2. 获取的区块结构:
  • 所有将使用的区块的HTML结构示例
3. 章节样式验证(如适用):
  • 已更新的章节列表,包含已验证的样式决策
  • 部分章节可能标记为"无section-metadata"
下一步: 将这些输出传递给generate-import-html技能