Transcript To Content

Transcript to Content Generator

Transform raw content (transcripts, conversations, notes) into ready-to-publish content — social posts or long-form articles.

Step 0: Determine Mode

Before doing anything else, decide which mode to use:

• Article Mode — if user says "write an article / long-form / article / write up / blog post", OR the transcript is a structured talk/sharing/interview with a clear narrative arc. Jump to [Long-form Article Mode](#long-form-article-mode).
• Social Post Mode — for everything else (extracting multiple standalone posts). Continue with Step 1 below.

If unclear, ask the user: "Do you want multiple social posts, or one cohesive article?"

---

Social Post Mode

Step 1: Receive Input

Accept two inputs:

• Required: Raw content (transcript, conversation, notes)
• Style: Auto-loaded from saved profile, OR provided by user

Style resolution order (IMPORTANT — check before asking user):

1. Check for saved style profile first: Read style-profiles/default.md AND style-profiles/default-samples.md (relative to this skill's directory). If they exist, load both silently — the summary for rules, the samples for voice and rhythm. Do NOT ask user for reference content.
2. User provides new reference content in this session: Analyze it (see below) and offer to save/update the profile.
3. User specifies a named profile: e.g. "use formal style" → load style-profiles/formal.md
4. No profile exists AND no reference provided: Ask user: "Do you have 2-5 examples of content you've published that you like? This helps me match your style. I'll save it so you won't need to provide it again."
5. User declines: Use neutral professional tone with clear structure.

When analyzing reference content (new or for saving), extract:

• Information density (data-heavy / case-heavy / opinion-heavy)
• Language style (formal / casual / sharp / moderate)
• Structure observation (CRITICAL):
• Does it use bold subheadings? How many?
• Does it use numbered lists (1. 2. 3.)?
• Average paragraph length (1-2 lines / 3-4 lines / longer)?
• Opening style (direct statement / data / story / question)?
• Use of emojis, formatting, links?
• Attitude markers (explicit judgment / emotional words / teaching tone)
• Platform conventions (Twitter threads, LinkedIn posts, blog-style, etc.)

Step 2: Extract All Possible Content

Identify content at 4 levels:

1. Short insights (20-150 characters) - Standalone observations or quotes
2. Phenomenon posts (150-300 characters) - Interesting observations with brief analysis
3. Medium posts (300-600 characters) - Complete logical argument with 3-4 supporting points
4. Deep analysis (600-1000 characters) - Complex multi-dimensional analysis

List all possibilities without filtering yet.

For transcripts >1000 lines: Follow the length-based processing strategy in [references/long-transcript-strategy.md](references/long-transcript-strategy.md). The core principle: memory is lossy compression — verify facts in real-time using Grep, don't write from memory. For transcripts >3000 lines, the two-pass index-retrieval workflow is MANDATORY.

Step 3: Deduplicate and Prioritize

Deduplication rules:

• If a point can expand into a full post, don't make it a standalone insight
• Use each point only once - don't repeat in both long post and short insight
• Same material can appear in different posts, but with different roles

Prioritization criteria:

• Counter-intuitive insights > common observations
• Specific data with comparisons > abstract descriptions
• Complete material > needs supplementing
• Universal insights > niche/insider-only content

Determine output quantity based on content richness:

• Rich content (90+ min, multiple topics): 10-15 total posts
• Medium content (30-90 min, 2-3 topics): 6-10 total posts
• Light content ( DELETE
• If it's just repeating the previous point -> DELETE
• If it's an obvious statement everyone knows -> DELETE

Third pass - Check structure:

• Does structure feel natural or forced?
• If it reads like a PowerPoint -> REWRITE without visible structure
• Logic should flow through content, not through formatting

1. Follow core principles:

• One theme per piece - don't try to cover everything
• Logic > case studies - use cases only as evidence
• Match user's style if reference provided
• Have attitude - make clear judgments, don't hedge excessively

1. For short insights (STRICT FILTERING):

• 4 Iron Rules - ALL must pass:
• Independence: Can be understood without context (max 1-2 sentences setup)
• Completeness: Full meaning, not half a sentence
• Impact: Data/contrast/counter-intuitive/emotional resonance
• Non-duplication: Not already covered in a longer post
• If none pass all 4 tests -> Output "No suitable standalone insights found"
• See [references/golden-sentence-standards.md](references/golden-sentence-standards.md) for examples

1. Check against quality standards:

• See [references/writing-checklist.md](references/writing-checklist.md) for complete checklist

1. Verify data points (CRITICAL):

• Proper nouns should already be verified in Step 3.5
• For ALL data points (revenue, valuation, dates, percentages): search to confirm if surprising
• For long transcripts: don't assume you remember correctly - Grep and re-read the section
• Better to remove questionable details than publish incorrect information

Step 5: Batch Output

Output format:

Extracted X pieces of shareable content from your transcript, sorted by quality:

---

## Content 1 | Title

[Complete content - ready to publish]

---

## Content 2 | Title

[Complete content]

---

[Continue with all content...]

IMPORTANT:

• NO category headers or labels
• Sort ALL content by quality (highest first), regardless of type or length
• Clean markdown only - each piece separated by ---
• Each piece header format: ## Content X | Title (concise title summarizing the topic)
• DO NOT include meta-information (priority, engagement predictions, recommendations)
• Output should be CLEAN and READY-TO-PUBLISH

After output, ask: "How do these look? Need any adjustments?"

---

Long-form Article Mode

When the transcript is a structured talk, interview, or sharing session with a clear narrative arc, the user may want a single deep article instead of multiple social posts. This mode produces a cohesive long-form piece (3000-10000+ characters) written section-by-section into a markdown file.

When to Use This Mode

• User says "write an article" / "long-form article" / "turn this into an article" / "write up this session"
• Transcript is a structured talk/sharing/interview (not casual chat)
• Content has a clear narrative arc (why -> how -> what happened)

Article Workflow

Phase 1: Read, Compress, Outline

1. Read all source material — transcript + any supplementary notes/references mentioned

Multi-source ASR handling (CRITICAL when multiple transcripts are provided):

When multiple transcript sources are provided (e.g., raw recording transcript + chat summary), both may contain ASR errors. Resolution principles:

| Source | Weight | Purpose | |------|------|------| | User Dictionary | Highest | Authoritative source for proper nouns, product names, and terminology | | Cross-document Verification | High | Content appearing in both sources has higher credibility | | Contextual Semantic Logic | Primary | Whether a term makes sense in its surrounding context | | Single-document Claims | Verify | Content appearing in only one document must be verified against context |

Must NOT do:

• Do NOT assume raw transcript automatically outranks summary — both are ASR, both may have errors
• Do NOT adopt a claim just because it appears in the summary — summaries can also mishear
• Do NOT supplement "background info" from model knowledge into the main text — only content from the conversation belongs in the article; model-supplied company/industry data goes in appendix labeled "source: not from conversation"

Common judgment cases:

• Both write "o1 model" but context is about an open-source project → check user dictionary for matching entries, then verify context
• Summary says "OpenAI Completions API", original says "opengl" (obvious ASR error) → use dictionary + context to determine actual meaning
• Neither document has the term, context makes no sense → flag as questionable or note in appendix

1. Compress into structured notes — Write a notes.md file in the same directory as the article. This is the critical intermediate step that prevents quality decay in later sections. For each major topic in the transcript, capture:

• Core argument (1-2 sentences)
• Key facts (specific data, names, examples)
• Quotable lines (vivid/emotional/opinionated — pre-select 2-3 per topic)
• Source type (structured presentation / Q&A discussion / personal story) — this directly feeds Phase 2.5's rewrite intensity

The notes file replaces the raw transcript as the primary writing source. Subsequent sections are written from notes, with Grep used only to verify specific details. This is why it matters: writing from a 39-page transcript relies on lossy memory; writing from 2-3 pages of structured notes keeps every section equally grounded.

1. Generate a structured outline with heading hierarchy (see Heading Structure below)
2. Present outline to user for confirmation — do NOT start writing until approved
3. User may restructure — e.g. "too many first-level headings, merge into fewer with sub-headings"

Phase 2: Section-by-Section Writing

1. Write into a .md file incrementally — one section at a time, appending via Edit tool
2. Each section should be self-contained — complete before moving to next
3. Verify facts per section — Grep the transcript for exact quotes and details before writing each section
4. Mark completed sections — use TodoWrite to track progress across sections
5. Classify source material before writing each section — see Quality Control below

Why section-by-section?

• Prevents context overflow on long articles
• Lets user review and adjust tone/style early (after first 1-2 sections)
• Avoids losing all work if a single large write fails
• User can make corrections mid-stream that inform subsequent sections
• Prevents tail-end quality decay — when multiple sections are written in a single generation, the last sections degrade to near-transcription. Strict one-section-per-Edit avoids this.

Phase 2.5: Quality Control Per Section

Before writing each section, classify its source material:

| Source type | Rewrite intensity | What to do | |---|---|---| | Structured presentation (tool walkthrough, step-by-step demo) | Light — has natural logic skeleton | Tighten language, remove filler, preserve structure | | Q&A / open discussion (opinions, philosophy, audience questions) | Heavy — oral, scattered, repetitive | Extract core argument first, then write from the argument, not from the transcript | | Anecdotes / personal stories | Medium — vivid but rambling | Keep emotional texture, cut circular narration |

Q&A and discussion sections are the #1 source of quality decay. They sound coherent when spoken but read terribly when transcribed. For these sections:

1. Don't write from the transcript directly. First distill the speaker's argument into 2-3 bullet points.
2. Then write the section from those bullets, pulling in specific quotes only for texture.
3. Grep-verify every claim — don't trust your memory of what was said.

Oral residue self-check: After writing a section, scan for filler words: " fillers (e.g., 就是/然后/其实 in Chinese, like/then/actually in English) (filler words in Chinese transcripts, analogous to like/then/actually/maybe/you know/right in English)". If a single paragraph contains 3+ of these, the passage hasn't been sufficiently rewritten — it's still transcript, not article. Rewrite it.

Phase 3: Polish

• Apply user's style corrections across the full article
• Global find-and-replace for naming conventions (e.g. real name -> nickname)
• Remove meta-commentary fluff (see Content Principles below)
• Terminology normalization: Replace jargon abbreviations with full terms (e.g. RD→R\&D, PM→Product Manager). Align repeated terms to one consistent form throughout (e.g. if both "Web Coding" and "Vibe Coding" appear, pick the industry-standard term and use it everywhere)
• ASR homophone sweep (MANDATORY for transcripts): Beyond proper nouns, scan for common ASR mishearings — homophones (market cap→value, spend→direct output), word-boundary errors (can ya use→can use), and phonetic transliterations of English terms (e.g. "Figma mei"→"Figma Make"). Read suspicious words in context and Grep-verify against nearby sentences
• De-date: Prefer relative time references (Wednesday, last week, earlier) over specific calendar dates (March 11, 2026) unless the date itself is newsworthy. Specific dates age the article and add no value

Phase 4: Pre-delivery QA (MANDATORY before sending to user)

Before delivering any version, read the entire piece and check these four items:

1. Fact check: Does every specific attribution ("John said", "Alice\'s analysis") match the source document? Did anyone\'s words get misattributed?
2. Repetition: Does the same story/case/opinion appear in multiple sections? (Common: product evolution story → methodology section → industry insight section — same case told three times)
3. ASR residue: Any semantically broken sentences? Read every quoted passage to check if it sounds like something a real person would say
4. Unsourced content: Did model-supplied background knowledge (company funding data, industry stats, product specs) leak into the article? If so, move to appendix and label "source: not from conversation"

After reading through, proceed to version archiving.

Version Management (MANDATORY)

After each round of edits, save the current state as a versioned file. Version numbers go in filenames so users can tell the version from the name.

Rules:

• Initial draft from subagents = _v1.md
• After each round of corrections: increment version → _v2.md, _v3.md, etc.
• The no-suffix file is a working draft only — never send it to the user; always send a versioned file
• The highest version number = the latest version

Naming convention:

{basename}_v{N}.md

Example: speaker_topic_20260321_v1.md → _v2.md → _v5.md

When to create a new version (AFTER edits complete):

• After user's correction round is fully applied
• After any global find-and-replace or restructuring
• Before sending a file to the user — always send a versioned copy

Implementation: After finishing a round of edits, save with the next version number:

cp outputs/article.md outputs/article_v2.md

Send article_v2.md to the user, continue editing article.md for next round.

Heading Structure Logic

First-level headings (##) = Major narrative arcs, limit to 4-6 max.

If your outline has 8-10 major topics, you have too many first-level headings. Consolidate:

| Raw topics | -> | Structured headings | |---|---|---| | 8-10 topics at same level | -> | 4-5 first-level (##) with 2-3 second-level (###) each |

Decision rules:

• Use ## (first-level) for distinct phases of the narrative — e.g. "Why change", "How to change", "What happened after"
• Use ### (second-level) for specific topics within a phase — e.g. under "How to change": tool choice, workflow steps, design system tips
• Intro and conclusion are ## level but typically have NO sub-headings
• Middle sections (the meaty parts) should hav

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: CherryHQ
• Source: CherryHQ/skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.