Skill: Phoenix HTML Briefing Structure

A section-by-section spec for a single self-contained HTML executive briefing: inlined CSS, Google Fonts, no build step, mirrors the DDN-Nebius reference.

Overview

Section-by-section layout spec for a Phoenix-branded HTML executive briefing: top bar, hero, the method (PQS + PVP concept cards), the engine (4-step method grid), live worked example (signal board, pain block, PVP card, anatomy grid), beyond-one-account playbook table, and footer. Includes design-system constraints: one gradient-text word, one primary button, mesh-bg only behind hero, 8px grid, sentence case, no em dashes.

Use cases

  • Phoenix-branded briefings without redesign work

    The skill teaches Claude the canonical layout: top bar plus hero, concept cards for PQS and PVP, a four-card method grid, the live worked example with signal board and anatomy grid, a five-row playbook table for the customer's full ICP, and the soft-CTA footer. The output mirrors the bundled DDN-Nebius reference: one gradient-text word in the hero, one primary button in the footer, mesh-bg only behind the hero.

  • Design-system constraints enforced by default

    8px grid for spacing, sentence-case headings, mono font for numbers and tool names, no em dashes anywhere on the page, light-first color palette with HG blue plus HG purple plus coral accent. Claude flags every drift from these constraints before producing the final HTML.

View full skill

Phoenix HTML Briefing Structure

The canonical layout for a Phoenix-branded PVP-PQS executive briefing. The reference is shipped under /samples/phoenix-pvp-pqs-ddn-nebius.html: open it first. This skill is the section-by-section spec for what each block contains and the Phoenix design-system constraints to honor.

When to use

  • Building the final HTML output of a Phoenix PVP-PQS briefing.
  • Adapting the layout for a different customer or a non-greenfield variant.
  • Reviewing an existing HTML draft against the design-system constraints.

Section order

  1. Top bar (sticky)
  2. Hero
  3. Section 01: The method (PQS plus PVP concept cards plus the thesis callout)
  4. Section 02: The engine (four-card method grid)
  5. Section 03: Live worked example (case header, context paragraphs, capacity chart, signal board, pain block, PVP card, anatomy grid)
  6. Section 04: Beyond one account (five-row playbook table)
  7. Footer (soft CTA)

Every section uses .phx-container to constrain width and starts with a .phx-eyebrow tag (numbered "01 ..." through "04 ...").

1. Top bar

Sticky strip with three slots: brand on the left (live dot plus "HG Insights · Phoenix MCP"), meta on the right (Strategic briefing · For: [CUSTOMER] · Internal-only marker). Mono font. The live dot is the only animated element on the page.

2. Hero

  • .mesh-bg background: the only place on the page mesh-bg appears
  • .phx-eyebrow tag above the headline (e.g., "From signal to specificity")
  • .phx-display headline with exactly one .gradient-text word: pick the word that anchors the customer's value claim. In the DDN example it's "data".
  • Subheadline names the constraint: "X used to take N hours of analyst work. Phoenix MCP collapses it into one agent run."
  • .hero-meta four-up grid below: Method · Engine · Worked example · Target motion

3. Section 01: The method

Two concept cards side by side, then a thesis callout.

Concept card 01 (PQS):

  • Badge: .badge-primary "Concept 01"
  • Heading: "Pain-qualified segment"
  • Body: 2 to 3 sentences defining the concept
  • .concept-example: a vivid example in the customer's industry vocabulary, not generic GTM language

Concept card 02 (PVP):

  • Badge: .badge-purple "Concept 02"
  • Heading: "Permissionless value proposition"
  • Body: 2 to 3 sentences
  • .concept-example: same vocabulary rule

Thesis callout: .thesis block with purple left border. Label "The constraint". One paragraph naming the practice constraint (50 to 100 hours per account, PVP layer is where leverage lives and almost everyone fails).

The concept examples are the most important localization point in the whole briefing. Generic examples make the entire briefing feel generic. In the DDN run the examples are about H200 clusters, I/O wait, llama-70B fine-tuning, EXAScaler. For a different customer, use their vocabulary.

4. Section 02: The engine

Four method cards in a row. Each card has a mono step label ("STEP 01 · DEFINE" through "STEP 04 · DEPLOY"), a .phx-h3 heading, a 2-sentence body, and a dashed-top section with Phoenix MCP tool names in mono labeled "PHOENIX MCP" in purple.

The four steps map to the four phases of the framework runtime (define, investigate, compose, deploy). Tool names should match the actual tools used in Phase 2 of the framework.

5. Section 03: Live worked example

The longest section. Sub-blocks in order:

Case header

  • .case-name: target name in huge type (80px). One word per line if two words. Italicize the legal suffix (N.V., Inc., LLC) with <em>.
  • .case-stats: 2x2 grid of headline stats. Each stat has a mono label, a heading-font value, and a mono sub-line under the value (the source or timing).

Context paragraphs

Two paragraphs: (1) why this target, including greenfield verification plus the named incumbent; (2) the cleanest hook, the connective tissue between the target's heritage and the customer's category. Bold the load-bearing claims. No em dashes.

Capacity chart (or equivalent)

Inline SVG. The DDN reference uses a cumulative-commitment line chart with year markers on the horizontal axis and the customer's category metric (capacity, spend, install count) on the vertical. HG blue stroke, HG purple gradient fill, coral dot for the inflection point. Labeled events along the curve in mono. Chart title in mono, headline below with one <em> in HG blue, footer with source on the left and units on the right.

Alternatives if a line chart doesn't fit the customer's category: a horizontal bar chart of named contracts by value, a geographic footprint diagram, or a timeline of named partnerships or contracts.

Signal board

Card with rounded corners and zero padding. Header bar: live dot, "Phoenix MCP · per-account dossier", credits-and-signals count on the right. 3x3 grid of signals (9 total). Each signal: tool tag in mono (HG blue), intensity tag (right, mono, neutral; .hot coral for the 3 to 4 figures the PVP math depends on), name in heading font, 1 to 2 sentence detail with the key number wrapped in .signal-value (bold).

The signal mix matters: at least 2 SEC filings, at least 2 web sources, at least 2 HG company_* tools, at least 1 explicit "absence is the signal" entry.

Pain block (PQS)

Background gradient coral-to-purple at 5% opacity, coral border at 18%. Badge .badge-accent "PQS · Pain-qualified segment". Pain name: 32px heading with one <em> highlighting the load-bearing phrase. Pain detail paragraph: the math. Bold the key figures. Always cite the public sources by name inside the paragraph.

PVP card

The drafted email. Header bar: From / To / Subject in mono, subject in HG blue heading font 16px. Body: six paragraphs following the PVP Composition skill. Sign-off italic with a divider rule above.

Use .figure spans around named numbers and .highlight spans around the load-bearing customer-product placements. Keep these sparing: 5 to 8 per email.

Anatomy block

4-cell grid of small cards. Each cell: tag in mono purple (the figure being traced, e.g., "$29.4B contracted"), source on one line (what document or page), and "From: tool call(s)" in mono gray (e.g., "sec_filing_section · sec_full_text_search").

Pick the four most load-bearing figures from the PVP. Not every figure needs to appear here: the four most likely to be challenged do.

6. Section 04: Beyond one account

Five-row playbook table. Columns: (1) number 01 to 05 in mono blue, (2) pain segment name in heading font 17px, (3) Phoenix MCP detection signature in body text with tool names in <code> mono blue, (4) PVP hook shape in italic heading font 13px.

The five rows should cover the customer's full ICP, not just the worked example. If the worked example was greenfield, include expansion, repatriation, sovereign, and an inference-cost or capacity-mismatch play.

End the section with a single paragraph that does the arithmetic: 5 PQS times N targets per PQS equals roughly M account-message pairs per quarter. "No analyst hours. No copy team. One agent loop, every account gets its own numbers."

7. Footer

  • .footer-title: 40px heading with one <em> in HG blue. Frames the next step.
  • .footer-cta: one paragraph proposing the working session and the timeline (typically four weeks to first measurable response).
  • .footer-actions: one .btn-primary only (the working session CTA), one .btn-secondary (download or share).
  • .footer-meta: mono strip with HG Insights · Phoenix MCP · year on the left, "Prepared for: [CUSTOMER]" on the right.

Design-system constraints (non-negotiable)

  • One .gradient-text word on the page, in the hero headline.
  • One .btn-primary on the page, in the footer.
  • .mesh-bg only behind the hero. Nowhere else.
  • 8px grid for all spacing. Use --space-* tokens.
  • All numbers, IDs, hex values, contract values, and tool names in var(--font-mono).
  • Card padding stays at --space-3 (24px). Special cards (pain block, chart card) may use --space-4 to --space-6.
  • Sentence case for all headings except proper nouns and acronyms.
  • No em dashes anywhere on the page. HTML body, PVP, pain block, chart labels: nowhere.

Color allocation

ElementColor
Primary lines, links, signal tool names, chart strokevar(--hg-blue-deep)
AI / engine accents (method-step labels, anatomy tags, thesis callout border, chart gradient top)var(--hg-purple)
Pain block, hot signal intensities, eyebrows, chart inflection pointvar(--hg-accent-coral)
Live status dotvar(--success-green)

The page is light-first. If the customer asks for a dark variant, switch foreground/background tokens and adjust the mesh-bg opacity. Don't redesign.

Self-contained output

The final HTML is one file. CSS inlined in a <style> block in the head. Fonts load from Google Fonts (fonts.googleapis.com). No external stylesheets, no build step, no JavaScript. The bundled reference at /samples/phoenix-pvp-pqs-ddn-nebius.html is a working example. Mirror its structure when in doubt.