Content Strategy And Assembly

Content Strategy and Assembly

Methodology for producing content by discovering what already exists in the corpus, assembling it against a content-type spec, and iterating through anti-slop quality gates until the output reads like a human wrote it.

Core philosophy: The author's taste is primary. This skill handles the grunt work of discovery, assembly, and slop removal. The author edits for voice, judgment, and the things only they can add.

When to Use This Skill

Apply this skill when:

• Producing a newsletter post, blog post, or LinkedIn post from existing corpus material
• Filling in an outline the author has already created
• Turning raw notes, transcripts, or KB nodes into publishable content
• Assembling content from multiple sources that need to be synthesized

Do NOT use for:

• Writing from scratch with no existing material (write raw thought first)
• Technical documentation (use technical-business-writing)
• Sales copy or landing pages (use copywriting-masters)
• Content editing only, no assembly (use a dedicated content-editing skill)
• One-shot generation (this skill is explicitly multi-step)

Core Principles

1. Never One-Shot

Content generation is a multi-step process. One-shotting produces the worst possible output because the model has to predict tokens for structure, evidence, transitions, and tone simultaneously.

Pattern: Discover → Select → Spec → Assemble → Validate → Refine

Each step narrows the problem space for the next. By the time assembly happens, the model knows exactly what to write, what evidence to use, and what structure to follow.

2. Voice Floor, Not Voice Ceiling

This skill does not try to perfectly replicate the author's voice. That is impossible and attempting it produces uncanny-valley slop.

Instead, enforce a floor: the output must NOT read like AI wrote it. The author's edits add the rest.

The distinction:

• Ceiling approach: "Write like the author" → produces mimicry slop
• Floor approach: "Don't write like an AI" → produces clean prose the author can work with

Read: references/voice-calibration.md for the author's voice fingerprint and anti-patterns.

3. Evidence-First Assembly

Every claim in the output must trace to a source in the corpus. Content without evidence is opinion dressed as insight.

Attribution during assembly:

[SOURCE: knowledge_base/technical/context-engineering.md] — direct reference
[SOURCE: transcript, client call 2026-01-15] — from conversation
[INFERRED: from patterns across 3+ sources] — synthesis
[AUTHOR: original thought from outline] — the author's own contribution

After assembly, strip attribution markers from the draft but keep a separate evidence map so the author can verify any claim.

4. Anti-Slop as Eval Loop

Content quality follows the eval-loop pattern:

SYMPTOM: "This paragraph reads like ChatGPT wrote it"
    │
    ▼
GENERALIZE: Which anti-slop class? (hedge words? colon-sentences? filler?)
    │
    ▼
ROOT CAUSE: Specific pattern (e.g., "3 em-dashes in one paragraph")
    │
    ▼
TARGET: "Zero filler phrases, ≤2 em-dashes per article"
    │
    ▼
FIX: Replace specific patterns
    │
    ▼
VERIFY: Run detection regexes
    Pass → next section
    Fail → fix and re-verify

Read: references/anti-slop-rules.md for the full detection catalog with regexes.

Workflow

Step 1: DISCOVER — What Do We Already Have?

Before writing anything, find what exists in the corpus on this topic.

1a. Search the knowledge base:

# Find relevant KB nodes
Grep: pattern="[topic]" glob="knowledge_base/**/*.md"

# Check synthesis docs first (95% of answers)
Grep: pattern="[topic]" glob="**/_synthesis/*.md"

1b. Search transcripts and context packages:

# Transcripts with relevant discussion
Grep: pattern="[topic]" glob="transcripts/**/*.md"

# Context packages with implementation evidence
Grep: pattern="[topic]" glob="**context_packages**/*.md"

1c. Check published content for prior art:

# What has already been published on this topic?
Grep: pattern="[topic]" glob="published_content/**/*.md"

1d. Build a source inventory:

## Source Inventory for [Topic]

### Direct Sources (will cite)
- [file path] — [what it contributes, 1 line]
- [file path] — [what it contributes, 1 line]

### Background Sources (informed thinking, won't cite directly)
- [file path] — [what it contributes, 1 line]

### Gaps (need author input or new research)
- [what's missing] — [why it matters for this piece]

Present this inventory to the author before proceeding. Gaps may change the outline.

Step 2: SELECT — Content Type and Framework

Match the content type to a framework from references/content-type-specs.md.

Framework selection factors:

• What is the author's outline already implying? Follow their structure.
• What is the goal? (teach, persuade, share experience, provoke thought)
• What is the audience? (practitioners, executives, general tech)

Step 3: SPEC — Define the Output Document

Before writing, spec exactly what the output looks like. This is the spec-driven-dev pattern applied to content.

For each section in the outline:

## Section: [Name]
- Word count target: [range]
- Source material: [which sources from Step 1]
- Purpose: [what this section accomplishes for the reader]
- Tone: [conversational/technical/provocative — match to author's register]
- Must include: [specific evidence, examples, or arguments]
- Must avoid: [specific anti-slop patterns likely for this section type]

Total piece targets:

• Newsletter post: 800-1500 words
• Blog post: 1500-3000 words
• LinkedIn post: 150-300 words

Present the spec to the author for approval before assembly.

Step 4: ASSEMBLE — Write the Draft

Assemble section by section, not end-to-end.

For each section:

1. Read the source material identified in the spec
2. Write the section following the spec constraints
3. Mark evidence inline: [SOURCE: file.md] for every claim
4. Move to next section

Assembly rules:

• Write in the voice floor register (see references/voice-calibration.md)
• Short paragraphs (3-4 sentences max)
• No formal transitions between sections — just start the next thought
• Concrete examples over abstract claims
• If a section needs the author's personal experience, leave a placeholder: [AUTHOR: need your example of X here]

After full assembly, create the evidence map:

## Evidence Map
| Claim | Source | Verification |
|---|---|---|
| "context drift affects 80% of long sessions" | context-drift.md:14 | Direct quote |
| "multi-step processing reduces verbosity" | anti-slop post, line 77 | Author's prior published claim |