Skip to main content
skill CX Codex

authoring-analysis — Claude Code skill: authoring decisions

Decides what counts as default content and what needs a block before import HTML is generated for AEM Edge Delivery Services. Runs as a page-import step.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add adobe/skills --skill authoring-analysis -a claude-code
Open on GitHub

What authoring-analysis does

The skill walks every content sequence on a page and returns a verdict: default content or a named block. Step 3a is a mandatory check first — could an author type this in Word or Google Docs? Headings, paragraphs, lists and inline images pass. Card grids, accordions, tabs and side-by-side columns do not, because they need structure.

When the match is unclear, it pulls in neighbours: content-modeling for a contested block choice, block-collection-and-party to confirm the block exists. Before any HTML is written it fetches the pre-decoration structure with node .claude/skills/block-collection-and-party/scripts/get-block-structure.js cards, which shows how many columns each row takes and where images sit. That kills the usual wrong-structure mistake.

You do not call it yourself. It is step 3 inside page-import. Inputs come from identify-page-structure: section boundaries with styling notes, content sequences and the block inventory, plus screenshot.png for visual reference. Skip that skill and there is nothing to analyse.

What it helps with

  • split a scraped page into default content and blocks
  • confirm a chosen block exists in the Block Collection
  • get exact row and column structure before writing HTML
  • resolve a sequence that fits both cards and columns
  • keep section styling separate from content decisions

Example prompts for the agent

  • run authoring-analysis on the section with the 8-card grid
  • this block is ambiguous — have authoring-analysis call content-modeling
  • fetch the cards block structure before generating HTML

How to install authoring-analysis

1Skills CLI (Vercel)

npx skills add adobe/skills --skill authoring-analysis -a claude-code

2Manually: put the files in place

~/.claude/skills/authoring-analysis/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/authoring-analysis/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about authoring-analysis

How do I install authoring-analysis in Claude?

Run npx skills add adobe/skills --skill authoring-analysis -a claude-code. The skill lands at ~/.claude/skills/authoring-analysis/SKILL.md.

What does authoring-analysis do?

It decides, per content sequence, whether the author types plain content or picks a block, and validates block selection and section styling before import HTML is generated for AEM Edge Delivery Services.

Can I invoke authoring-analysis directly?

No. It is step 3 of the page-import pipeline and is called from there. Direct use only makes sense when debugging that pipeline.

Source text

SKILL.md · Apache-2.0
---
name: authoring-analysis
description: "Use this when the page-import pipeline needs to determine the authoring approach (default content vs blocks) for scraped content before generating import HTML for AEM Edge Delivery Services. Covers validating block selection and section styling for import/migration. Do not invoke directly — called by page-import as a pipeline step."
license: Apache-2.0
metadata:
  version: "1.0.1"
---

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

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

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

## **IMPORTANT: Step 3e Execution Trigger**

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

## 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!)

**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 ➡️
```

---

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

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

---

### Step 3c: Validate Block Exists (IF NEEDED)

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

---

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

**CRITICAL:** Before generating any HTML in next skill, fetch the pre-decoration HTML structure for ALL blocks you'll use.

```bash
# 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

---

### Step 3 Output Format

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

---

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

**⚠️ 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

---

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

© adobe · Apache-2.0 · adobe/skills

Similar skills

All skills for Agent setup: memory, context, orchestration →

From the same set53

whitepaper Turns a Markdown file into a laid-out PDF whitepaper with a cover and table of contents. Handy when the document has to ship as PDF rather than .md. CX Codex +1 1,600installs preview-import Starts a local AEM dev server to verify imported HTML in Edge Delivery Services. Checks block rendering, inspects metadata, and catches 404 errors. CX Codex +1 1,600installs page-decomposition A helper skill for the page-import pipeline: it splits a single section into content sequences and describes them neutrally, without block names. CX Codex +1 1,600installs find-test-content Finds existing pages using a specific block in AEM Edge Delivery Services projects. Reports page URLs, block counts, and active variants for development and testing. CX Codex +1 1,600installs identify-page-structure Splits a scraped webpage into sections and content sequences for AEM Edge Delivery Services import. Runs as a pipeline step, not by hand. CX Codex +1 1,600installs block-collection-and-party Finds reference blocks, plugins, and code patterns for AEM Edge Delivery Services across Block Collection and Block Party. Helps bootstrap EDS component development. CX Codex +1 1,600installs testing-blocks Runs linting, real-browser validation and unit tests on AEM Edge Delivery Services changes. Useful right before you open a pull request. CX Codex +1 1,600installs analyze-and-plan Defines acceptance criteria, authoring rules, and a Definition of Done before coding AEM Edge Delivery Services blocks. Useful for scoping changes and catching edge cases early. CX Codex +1 1,600installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor