one-pager-builder

One-Pager Builder Skill

Foundation: This skill inherits the quality framework from skills/builders/builder-foundation/SKILL.md. The Mid-Draft Quality Check applies in simplified form here due to the document's brevity (250-400 words). Below are one-pager-specific quality prompts.

Purpose

Create a tight, impactful one-pager from a North Star document and plan (produced by idea-refiner). Output is a single versioned Markdown file designed to be read in under 30 seconds and drive a specific decision.

When To Use

• User asks to create a one-pager, executive summary, brief, or pitch document
• A North Star and plan exist (from idea-refiner) or user provides equivalent context
• The document must be skimmable and decision-driving

Output Format

File: <slug>-one-pager-v<N>.md

---

Document Template

# <Product/Initiative Name>

> <Tagline — one sentence that captures the value proposition>

---

## The Problem

<2-3 sentences: what's broken, who it affects, what it costs>

## The Solution

<2-3 sentences: what you're proposing, how it works at a high level>

## Key Differentiators

- **<Differentiator 1>** — <one sentence explanation>
- **<Differentiator 2>** — <one sentence explanation>
- **<Differentiator 3>** — <one sentence explanation>
- **<Differentiator 4>** — <one sentence explanation> _(optional)_

## Proof Points

| Metric | Value | Source |
|--------|-------|--------|
| <metric> | <number> | <source> |
| <metric> | <number> | <source> |
| <metric> | <number> | <source> |

## Call to Action

<1-2 sentences: what the reader should do next — approve, fund, schedule a meeting, pilot>

---

*<Author> | <Date> | <Version>*

---

Writing Rules

1. 250-400 words maximum. If it's longer, it's not a one-pager. Cut ruthlessly.
2. Inverted pyramid structure. Most important information first. If the reader stops after the tagline and problem statement, they should still get the core message.
3. Numbers over adjectives. "Reduces processing time by 73%" not "significantly faster." Every differentiator and proof point should be quantified where possible.
4. Skimmable in 30 seconds. Bold the key phrases. Use short sentences. No walls of text. A decision-maker glancing at this during a meeting should grasp it immediately.
5. One decision per document. The CTA asks for exactly one thing. Multiple asks dilute impact.
6. No jargon without context. If the audience is executive leadership, don't use engineering acronyms without defining them. Match the North Star audience level.
7. Problem before solution. Always establish why this matters before explaining what you're proposing.
8. Proof points are verified. Every number in the Proof Points table must have a source. If a number can't be sourced, use a range estimate and note the methodology.

---

Per-Section Success Criteria

Opus 4.7 follows instructions literally. A vague section produces output that matches the template but misses intent. Lock these per-section "Done When" criteria before drafting:

Section	Done When
The Problem	Reader sees the gap, the cost of the gap, and who feels it. Quantified with at least one number. ≤ 60 words.
The Solution	Reader has a one-sentence summary of WHAT the solution is, plus the architectural-level mechanism (the Mermaid diagram supports this). Avoids feature lists. ≤ 90 words + diagram.
Key Differentiators	Reader can repeat the 3 differentiators without re-reading. Each differentiator names what is unique vs. status-quo, with a number or specific reference. No vague "better", "faster", "more flexible".
Proof Points	Every number sourced. No unsourced superlatives. The reader can verify a claim within one click.
Call to Action	Single specific next step (not "contact us", not "learn more"). Names who to contact / which doc to read / which decision to make by when.

If your draft satisfies the layout but fails any Done When, rewrite the section. A one-pager that reads as bullet-points but lacks specific intent is a 4.7-failure mode.

---

Mermaid Diagram

Every one-pager should include exactly 1 Mermaid diagram — a high-level ecosystem or architecture overview placed in the Solution section. This diagram provides a 10,000-foot visual that a non-technical reader can absorb in 5 seconds.

Guidelines

• Maximum 6-8 nodes. One-pagers are about simplicity. If the diagram needs more nodes, the concept needs further simplification.
• Use graph LR (left-to-right) for flow/ecosystem diagrams or graph TD (top-down) for layered diagrams.
• Descriptive, non-technical labels. Use plain language: "Create Token" not "HTS Token Creation via SDK". Keep all labels on a single line (max 3-4 words). Never use \n or <br/> for line breaks in Mermaid labels - neither renders reliably (Notion cuts off multi-line text, \n is ignored).
• Solid arrows for direct flows, dotted arrows for optional or supporting relationships.
• No subgraphs — keep it flat and clean.
• No emojis in diagrams.
• The diagram renders natively in Notion. Do not use ASCII art.

Placement

• Place the diagram immediately after the Solution section's descriptive text, before Proof Points.
• The diagram does NOT count toward the 250-400 word limit (it is a visual element, not prose).

Example

```mermaid
graph LR
    A["Raw Input"] --> B["Processing Engine"]
    B --> C["Output A"]
    B --> D["Output B"]
    E["Enterprise Layer"] -.->|integrates| B
```

---

Mid-Draft Quality Check

One-Pager-Specific Quality Prompts

Dimension	What to Look For
Depth	Does the tagline capture the unique value? Do differentiators quantify claims or stay vague?
Originality	Is the problem statement novel or generic? Does the solution avoid cliched positioning?
Coherence	Do differentiators logically follow from the stated problem? Does the CTA align with the problem/solution?
Completeness	Are all proof points verified with sources? Is exactly one action requested in the CTA?

Document evaluator optional for one-pagers (brief documents). See builder-foundation for details.

---

Cross-Agent Deliverable Review

After drafting, optionally run cross-agent review.

Critic Roles

Codex — Metric Verification

Verify all numbers in proof points are accurate, sources are valid, claims are current. Flag any unverified metrics.

Review the following one-pager document for metric accuracy and source validity.

Verify:
1. Every number in the Proof Points table is accurate and current
2. Every source cited is valid and accessible
3. All claims in the Problem and Solution sections are factually correct
4. Differentiator claims are substantiated and not exaggerated
5. No outdated statistics or deprecated references

Output format:
1) VERIFIED_METRICS (confirmed accurate with source)
2) UNVERIFIED_METRICS (could not confirm — flag for manual review)
3) INCORRECT_METRICS (wrong or outdated — provide correction)
4) MISSING_SOURCES (claims without backing)
5) READY_FOR_DELIVERY (yes/no + reason)

Gemini — Impact & Clarity

Evaluate whether the document drives the intended decision, tagline is compelling, problem statement creates urgency, differentiators are genuinely differentiating, CTA is clear and actionable. Check overall visual hierarchy and readability.

Review the following one-pager document for impact, clarity, and decision-driving effectiveness.

Evaluate:
1. Does the tagline capture the value proposition in one compelling sentence?
2. Does the problem statement create genuine urgency?
3. Is the solution clearly articulated without jargon?
4. Are the differentiators genuinely differentiating (not generic claims)?
5. Does the CTA ask for exactly one clear action?
6. Is the document skimmable in 30 seconds?
7. Is the visual hierarchy effective (bold phrases, short sentences, clear sections)?
8. Does the tone match the intended audience?
9. Would a decision-maker reading this in a meeting be able to act on it immediately?

Output format:
1) IMPACT_ISSUES (weak tagline, unclear urgency, generic differentiators)
2) CLARITY_ISSUES (jargon, long sentences, confusing structure)
3) CTA_ASSESSMENT (clear and actionable / vague / multiple asks)
4) VISUAL_HIERARCHY (effective / needs improvement + specifics)
5) READY_FOR_DELIVERY (yes/no + reason)

Review Procedure

1. Concatenate one-pager content into inline prompts (never reference file paths for critics)
2. Run Codex and Gemini critics in parallel with per-agent timeouts (Codex=480s, Gemini=180s)
3. Merge feedback, prioritizing consensus items. Triage into must-fix vs nice-to-have.
4. Apply accepted changes to the one-pager
5. Max 2 rounds for deliverable review

---

Versioning

• v1: First draft from North Star + plan
• v2: After user feedback or cross-agent review
• v3: Final version

Only keep the latest version. Delete previous versions when a new one is created (e.g., delete <slug>-one-pager-v1.md when <slug>-one-pager-v2.md is written).

---

Review Checklist

Before finalizing, verify items in priority order per builder-foundation tiers.

Critical Items (Claude Weak Spots)

• Tagline is genuinely compelling (not generic "empowering X through Y")
• Problem statement creates real urgency with specific pain (not "organizations struggle with...")
• Differentiators are genuinely differentiating (not features any competitor also has)
• No AI writing patterns - no promotional language, no significance inflation

Standard Items (Claude Strong Spots)

• Total word count 250-400; all proof point metrics have sources
• CTA asks for exactly one action; no jargon; skimmable in 30 seconds
• No placeholder text; tone matches North Star

---

Output Rules

• Never write files larger than 200 lines in a single response
• For large files, write in sequential chunks
• If you hit an output token limit, resume where you stopped

---

Version: 2.0.0