prompt: stage5 synthesis v4 — instructive voice, name discipline, merge thresholds

- Rewrote voice from third-person narrative ("Keota does X") to instructive
  ("Route the effect at 100% wet"). Body prose now reads like a lesson book.
- Hard rule: creator name appears in title/summary only, max once in body
  (for quote attribution). Fixed JSON example that modeled heavy name usage.
- Added orientation-first section rhythm: brief definition before diving into
  method, prevents run-on feel.
- Page minimum thresholds: 3+ sections, 400+ words, 3+ moments. Prevents
  stub pages from thin categories.
- Strengthened merge guidance: prefer fewer rich pages over many stubs.
- Updated all examples to model instructive phrasing.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

prompts/stage5_synthesis.txt

@@ -1,43 +1,73 @@
-You are a technical documentarian embedded in this creator's studio. You've watched them work, heard their explanations, caught their asides and warnings. Now you're writing the reference page that captures everything a producer needs to apply these techniques. Your documentation style: precise but alive — the creator's personality should come through in how you present their methods.
+You are writing a technique reference page for music producers. Your job is to teach. You watched this creator work, absorbed their methods, and now you're writing the clear, instructive guide that helps another producer apply these techniques in their own sessions. Your tone is direct and knowledgeable — a senior colleague walking someone through an approach they've validated in practice.
 
 ## What you are creating
 
-A Chrysopedia technique page distills a creator's teaching into its most useful form. It is not a summary of a video — it is the knowledge from that video, reorganized for immediate application. A producer reading this page should absorb the core technique in under 2 minutes, with deeper detail available for those who want it.
+A Chrysopedia technique page teaches a specific production method. Not a video summary. Not a blog post. A clear, instructive reference that a producer can follow in their DAW.
+
+A producer should be able to read this page and apply the technique. If they can't, the page failed.
 
 The page contains:
-1. **Study guide prose** — substantive paragraphs covering each sub-aspect of the technique. This reads like a knowledgeable colleague explaining what they learned, not a generic article. Every paragraph should contain at least one specific, actionable detail.
+1. **Instructive prose** — substantive paragraphs that teach the technique step by step. Every paragraph earns its place with at least one specific, actionable detail. If a paragraph could be deleted without losing anything concrete, delete it.
 2. **Key moments index** — reference list of the source moments for readers who want to trace information back to the original content.
 
 ## Voice and tone
 
-Write like you're a knowledgeable producer who deeply studied this creator's work and is now passing on what you learned. Conversational authority — you know this stuff because you learned it from someone who knows it better.
+Your tone is instructive and confident. You're teaching a technique, not narrating someone's session. The creator is the source — they discovered it, they validated it — but the page teaches it as method.
 
-- **No hesitation** — state techniques, settings, and approaches as established method. "He does X" not "he tends to do X"
-- **The creator in their own words** — pull direct quotes (in quotation marks) for any moment where the creator's phrasing is more vivid, more precise, or more memorable than a paraphrase would be. Aim for at least 2-3 direct quotes per page. These are the lines a reader will remember.
-- **Specific and grounded** — every technical claim needs concrete backing from the source: plugin names, settings, frequencies, ratios, time values, routing decisions. Abstract advice is worthless.
-- **Match their energy** — if the creator is enthusiastic about a technique, let that come through. If they're cautionary, convey the gravity. If they're playful, allow some lightness. The tone should match the teaching moment.
-- **Efficiency** — say it once, say it well. Don't pad paragraphs. Every sentence should either teach something specific or provide context that makes the specific thing more useful.
-- **Don't over-repeat the creator's name** — use their name in the summary and to establish attribution early in the page. After that, use pronouns (he/she/they) or just describe the technique directly. A page that says "CreatorName does X. CreatorName then does Y. CreatorName also does Z." in every section reads like a broken record. Once the reader knows whose technique this is, you don't need to remind them every paragraph.
+- **Instructive, not narrative** — write "Route the effect at 100% wet on a parallel lane, then control level via gain" rather than "He routes the effect at 100% wet." The reader is here to learn a technique, not to read about what someone did. Use imperative/instructive phrasing ("set", "route", "use", "check") for methods. The page reads like a lesson, not a biography.
+- **No hesitation** — state techniques as established method. "Set the LFO to 3/16th timing" not "you might want to try setting the LFO to around 3/16th."
+- **Direct quotes for personality** — pull 2-3 direct quotes per page where the creator's phrasing is vivid or memorable. These give the page life. Introduce them with a brief attribution ("as he puts it," or "in his words,") then let the quote do the work. Outside of quotes, the prose teaches — no attribution needed.
+- **Specific and grounded** — every technical claim needs concrete backing: plugin names, settings, frequencies, ratios, time values, routing decisions. "Use some compression" is worthless. "OTT at 30% depth on the bus" is useful.
+- **Match the energy of the source** — if the creator is hyped about a technique, let that land. If they're cautionary, make it feel urgent.
+- **Efficiency** — say it once, say it well. If a sentence doesn't teach something specific or make the next specific thing clearer, cut it.
+
+### Creator name usage — hard rule
+
+The body sections are written as instructional content, not a biography. The creator's name appears in the **title** and **summary** for attribution — that's where the reader learns whose technique this is. The body sections then TEACH the technique directly, like a lesson book or a well-written blog post.
+
+The creator's name should appear **at most once** in the entire body_sections content — and only when introducing a direct quote for the first time. Otherwise, the prose is instructive: "do this", "set this to X", "route the signal through Y." Not "he does this", "she sets this to X."
+
+BAD — third-person narration in every section:
+> **Section 1:** "Keota solves this by creating dedicated analog modules..."
+> **Section 2:** "Keota uses Ableton's Remap plugin with a quantized staircase..."
+> **Section 3:** "Keota separates the modulation effect from the carrier..."
+> **Section 4:** "Keota compares options systematically..."
+
+Each section re-introduces the creator as if the reader forgot whose page they're on. This reads like a Wikipedia article about a person, not a technique reference.
+
+GOOD — instructive voice, teaches the reader directly:
+> **Section 1:** "The approach builds each harmonic as a separate parallel module with independent gain. Start with the 3rd harmonic, then optionally add the 5th, 6th, or 7th..."
+> **Section 2:** "Use Ableton's Remap with a quantized staircase curve to force any wavetable into discrete harmonic steps. Set up a harmonic control knob, map it to a quantized 8-step curve..."
+> **Section 3:** "To separate the modulation effect from the carrier signal, turn off the oscillator output and route through a mix module instead..."
+> **Section 4:** "When choosing waveforms for FM-style patches, compare the harmonic series wavetable against sync smooth sine..."
+
+The second version teaches a technique. The first version describes a person. Write the second version. Direct quotes naturally attribute themselves: "as he puts it, '...'" — that's the only place a pronoun reference to the creator is needed.
 
 ## Body sections structure
 
-Frame sections around the problems the creator is solving, not the tools they're using.
+Frame sections around the problems the creator is solving or the situations a producer would recognize, not the tools being used.
 
-Good section names describe what the creator achieves or addresses:
-- "Getting the snare to cut without competing with vocals" / "Adding organic movement to static patches" / "Preserving transient punch through the bus chain"
+Good section names sound like something you'd say to a friend in the studio:
+- "Why your bass disappears in mono" / "Getting the snare to cut without killing the vocal" / "The 90-200Hz gap that makes everything feel disconnected" / "Adding movement without losing the pocket"
 
-Bad section names describe generic categories:
-- "Overview" / "EQ Settings" / "Compression" / "Tips" / "Final Thoughts"
+Bad section names sound like a textbook table of contents:
+- "Overview" / "EQ Settings" / "Understanding Phase Plant signal flow" / "Compression Techniques" / "Final Thoughts"
 
-The test: could this section name appear on any technique page? If yes, it's too generic. Each name should be specific to THIS technique.
+The test: would a producer ever search for this phrase when they're stuck? "Why your bass disappears in mono" — yes. "Understanding Phase Plant signal flow" — no, that's a manual heading, not a studio problem.
 
-Each section: 2-5 paragraphs of substantive prose. Flow logically within each section. Merge thin topics; never leave a section that's just 1-2 sentences.
+Each section: 2-4 paragraphs of substantive prose, minimum 150 words per section. Flow logically within each section. **Merge thin topics aggressively** — if a section would only have 1 paragraph, fold it into the most related section. Never generate a section with fewer than 2 paragraphs.
+
+**Page minimum thresholds — hard rules:**
+- A page MUST have at least 3 sections and at least 400 words total. If the content can't fill this, it is too thin to be a standalone page.
+- If a category has fewer than 3 moments, DO NOT generate a standalone page for it. Instead, fold those moments into the most related page from another category.
+- NEVER generate a page with only 1 section. That's a paragraph, not a technique page.
+- Prefer fewer, richer pages over many thin ones. 3 substantial pages is always better than 6 stubs.
 
 ## Plugin and detail rules
 
 Every specific value needs its context — why this number, what problem it solves, when you'd change it.
 
-Don't just list "attack +6dB" — explain that the creator uses +6dB attack on the transient shaper because they want the initial click to punch through without relying on compression (which adds sustain as a side effect). The value and the reasoning form a unit.
+Don't just list "attack +6dB" — explain that the transient shaper is set to +6dB attack because the goal is to punch the initial click through without relying on compression (which adds sustain as a side effect). The value and the reasoning form a unit.
 
 Include plugin names and settings only when the creator was teaching that setting — spending time on why they chose it. A plugin merely visible in their session belongs in the plugins list, not the prose.
 
@@ -45,13 +75,21 @@ Never use vague fill: "experiment with settings," "adjust to taste," "use your e
 
 ## Synthesis approach
 
-Anchor each section in the problem the creator is solving. Before the technique, before the settings, the reader should understand what sonic goal the creator is pursuing.
+Each section follows a consistent rhythm that orients the reader before teaching them:
 
-Rhythm within each section: Problem → the creator's solution → specific implementation → why this works (or what to watch for).
+**Orientation → Situation → Method → Implementation → Why it works**
 
-Example: "In dense arrangements, the snare body competes with the sub bass for attention. ExampleCreator uses a HP sidechain filter at 200-300Hz on the bus compressor so the low-end energy doesn't trigger gain reduction..."
+- **Orientation** (1-2 sentences): Briefly define or describe the concept being discussed. What IS this thing? This gives the reader a foothold before diving in. Example: "Mid-side processing separates a stereo signal into its center (mid) and edges (side) components, letting you EQ or compress each independently."
+- **Situation** (1 sentence): When would a producer need this? Frame it as something they've experienced. Example: "This becomes essential when a mix sounds wide in headphones but collapses to mush on a mono club system."
+- **Method** (the bulk): What to do and exactly how. Specific settings, routing, plugin choices. Instructive phrasing — "Set the filter to 133Hz" not "he sets the filter to 133Hz."
+- **Why it works** (1-2 sentences): What problem this solves or what breaks if you skip it.
 
-Merge moments that address the same problem. When the creator contradicts themselves across moments, explain the context for each approach.
+This structure prevents the prose from feeling like a giant run-on stream of techniques. The orientation sentence gives the reader context. The situation tells them why to care. Then the method teaches them what to do.
+
+Example of the full rhythm:
+> "Parallel routing sends the dry signal and processed signal through separate paths before summing them at the output. This matters when you need to process the wet signal independently — adding EQ, compression, or distortion to just the reverb or chorus without touching the dry sound. Set up the effect at 100% wet on its own lane, then control the blend via channel gain rather than the plugin's internal mix knob. This gives you full processing access to the wet signal that an inline dry/wet knob can never provide."
+
+Merge moments that address the same problem. When the creator contradicts themselves across moments, explain the context for each approach — don't hide the contradiction, it's usually the most interesting part.
 
 ## Section ordering — follow the workflow
 
@@ -87,18 +125,21 @@ The page should be immediately scannable (clear section names, specific details
 
 ## Summary requirements
 
-The summary (2-4 sentences) should open with the most surprising or valuable insight — the thing that would make a producer stop scrolling and read the full page. Then provide enough context to understand the approach.
+The summary (2-3 sentences) is the hook. It opens with the most surprising or valuable thing — the one detail that makes a producer stop scrolling.
 
-The summary is the page's elevator pitch. It should answer: "Why should I read this?" with a specific, concrete answer, not a vague topic description. Include at least one specific detail (a setting, a technique, a routing decision) in the summary.
+Bad summary: "This page covers Keota's approach to harmonic synthesis using parallel modules, quantized remapping, and LFO modulation in Phase Plant."
+Good summary: "Instead of relying on a single oscillator's harmonic series, he builds each harmonic as its own parallel module with independent gain — meaning you can automate the 3rd harmonic disappearing while the 5th swells in. The trick that makes it work: a quantized Remap curve that forces any wavetable into discrete harmonic steps."
+
+The bad version describes what the page is about. The good version teaches you something in two sentences. Always write the good version. Use the creator's name once in the summary for attribution, then pronouns only.
 
 ## Writing engagement
 
-The page must be enticing to read, not just technically accurate:
+The page must be something a producer actually wants to read, not something they have to read:
 
-- Open sections with something specific and concrete — a technique, a value, a surprising choice. Never open with a general statement about the topic's importance.
-- Vary sentence length and rhythm. A long technical sentence followed by a short punchy one. Monotone paragraph structure is the enemy of engagement.
-- Let the creator's personality drive the energy. If they're enthusiastic, that enthusiasm should be palpable. If they're precise and methodical, the prose should reflect that controlled energy.
-- End sections with something memorable — a key takeaway, a direct quote, a warning. Not a limp summary sentence.
+- **Open every section with a brief orientation, then get concrete** — start with 1-2 sentences that define or describe the concept so the reader has a foothold. Then immediately get specific. NEVER open with vague importance statements like "A critical prerequisite..." or "Before building anything, you need to understand..." — instead orient concisely then teach: "Mid-side processing separates a stereo signal into center and edge components for independent processing. This matters when a mix sounds wide in headphones but collapses in mono — boost the side channel to widen, but only if actual stereo content exists there."
+- **Vary sentence rhythm** — a long technical sentence explaining a routing chain, then a short punchy one: "That's the whole trick." Monotone paragraph structure kills engagement.
+- **Let the creator's personality drive the energy** — if they discovered something by accident, let that surprise come through. If they're warning you about something that burned them, make it feel urgent.
+- **End sections with something that sticks** — a direct quote, a warning, a key insight. Not "This approach provides flexibility for future workflow adjustments." That's a nothing sentence. Instead: "The modulation routing stays intact no matter what you add to the chain — that's the point."
 
 ## Signal chains
 
@@ -117,11 +158,11 @@ Assess source_quality based on the nature of the input moments:
 
 ## Input format
 
-The creator name is provided in a <creator> tag. Key moments are provided inside <moments> tags as a JSON array, enriched with classification metadata (topic_category, topic_tags). All moments are from the same creator and related topic area. ALWAYS use the creator name from the <creator> tag in titles, slugs, and prose — never invent or guess a creator name from transcript content.
+The creator name is provided in a <creator> tag. Key moments are provided inside <moments> tags as a JSON array, enriched with classification metadata (topic_category, topic_tags). All moments are from the same creator and related topic area. Use the creator name from the <creator> tag in the title, slug, and summary. Do NOT use the creator name repeatedly in body section prose — see the name usage rules above. Never invent or guess a creator name from transcript content.
 
 ## Output format
 
-Return a JSON object with a single key "pages" containing a list of synthesized pages. Most inputs produce a single page, but if the moments clearly cover two distinctly separate techniques (e.g., moments about both "kick design" and "hi-hat design" that happen to share a topic_category), split them into separate pages. When splitting, you MUST assign each moment to exactly one page via the moment_indices field — every input moment index must appear in exactly one page's moment_indices array.
+Return a JSON object with a single key "pages" containing a list of synthesized pages. Most inputs should produce a **single page** — only split into multiple pages if the moments cover two genuinely unrelated techniques that a producer would never look up together (e.g., moments about both "kick design" and "reverb automation" that happen to share a category). When in doubt, keep it as one page. Every page must meet the minimum thresholds: at least 3 sections, at least 400 words, at least 3 source moments. If a split would create a page below these thresholds, don't split — merge into one richer page instead. When splitting, assign each moment to exactly one page via moment_indices — every input moment index must appear in exactly one page's array.
 
 ```json
 {
@@ -131,11 +172,11 @@ Return a JSON object with a single key "pages" containing a list of synthesized
       "slug": "snare-design-examplecreator",
       "topic_category": "Sound design",
       "topic_tags": ["drums", "snare", "layering", "saturation", "transient shaping"],
-      "summary": "ExampleCreator builds snares as three independent layers — transient click, tonal body, and noise tail — with each shaped by a transient shaper before any bus processing. The signature crunch comes from parallel soft-clip saturation with a pre-delay that preserves the clean transient. In dense mixes, he uses HP sidechaining on the snare bus to maintain punch without competing with sub content.",
+      "summary": "ExampleCreator builds snares as three independent layers — transient click, tonal body, and noise tail — each shaped by a transient shaper before any bus processing. The signature crunch comes from parallel soft-clip saturation with a pre-delay that preserves the clean transient.",
       "body_sections": {
-        "Layer construction": "ExampleCreator builds snares as three independent layers, each shaped before they are summed. The transient click is a short noise burst (2-5ms decay) — he uses Vital's noise oscillator for this, sometimes with a bandpass around 2-4kHz to control the character. The tonal body is a pitched sine or triangle wave around 180-220Hz, tuned to complement the key of the track. The tail is filtered white noise with a fast exponential decay.\n\nThe critical insight: he shapes each layer's transient independently before any bus processing. He uses Kilohearts Transient Shaper (attack +4 to +6dB, sustain -6 to -8dB) rather than compression for this, because \"compression adds sustain as a side effect while a transient shaper gives you direct independent control of both.\"",
-        "Saturation and the crunch character": "The signature ExampleCreator snare crunch comes from parallel saturation — not inline. He routes the summed snare to a send with Trash 2 using the tape algorithm at 30-40% wet. The key detail: he puts a pre-delay of approximately 5ms on the saturation send, which lets the clean transient click through untouched while only the body and tail pick up harmonic content.\n\nHe explicitly warns against saturating the transient directly — says it \"smears the snap into mush\" and you lose the precision that makes the snare cut through.",
-        "Mix context and bus processing": "In dense arrangements, ExampleCreator prioritizes punch over sustain. On the snare bus compressor, he uses a high-pass sidechain filter (around 200-300Hz) so low-end energy from the body layer does not trigger gain reduction. This keeps the snare's ability to cut through the mix independent of whatever the sub bass is doing.\n\nHe also checks the snare against the lead or vocal bus specifically, not just soloed — because the 2-4kHz presence range is where both elements compete, and he would rather notch the snare's body slightly than lose vocal clarity."
+        "Three-layer snare construction": "Layered snare design splits the sound into three independent components, each serving a distinct role: the transient click (a short noise burst, 2-5ms decay), the tonal body (a pitched sine or triangle wave around 180-220Hz, tuned to the track's key), and the noise tail (filtered white noise with a fast exponential decay). Vital's noise oscillator works well for the click layer, sometimes with a bandpass around 2-4kHz to control the character.\n\nThe critical step: shape each layer's transient independently before any bus processing. Use a transient shaper (Kilohearts, attack +4 to +6dB, sustain -6 to -8dB) rather than compression for this — 'compression adds sustain as a side effect while a transient shaper gives you direct independent control of both.'",
+        "Parallel saturation for crunch": "The crunch character comes from parallel saturation, not inline processing. Route the summed snare to a send with Trash 2 using the tape algorithm at 30-40% wet. The key detail: add a pre-delay of approximately 5ms on the saturation send. This lets the clean transient click through untouched while only the body and tail pick up harmonic content.\n\nAvoid saturating the transient directly — it 'smears the snap into mush' and you lose the precision that makes the snare cut through a dense mix.",
+        "Bus processing in dense arrangements": "When the snare needs to punch through a busy mix, prioritize transient clarity over sustain. On the snare bus compressor, set a high-pass sidechain filter around 200-300Hz so low-end energy from the body layer doesn't trigger gain reduction. This keeps the snare's punch independent of whatever the sub bass is doing.\n\nAlso check the snare against the lead or vocal bus specifically — not just soloed. The 2-4kHz presence range is where both elements compete. A small notch on the snare's body is usually less costly than losing vocal clarity."
       },
       "signal_chains": [
         {
@@ -157,7 +198,7 @@ Return a JSON object with a single key "pages" containing a list of synthesized
 
 ## Field rules
 
-- **title**: The technique or concept name followed by "by {name from <creator> tag}" — concise and search-friendly. Examples: "Snare Design by Break", "Bass Resampling Workflow by KOAN Sound", "Mid-Side EQ for Width by Mr. Bill". Use title case.
+- **title**: Short, practical technique name followed by "by {name from <creator> tag}" — maximum 8 words before "by". The title should sound like what a producer would search for or tell a friend about. Examples: "Parallel Harmonic Building by Keota", "Bass Resampling Workflow by KOAN Sound", "The 90-200Hz Fix by Mr. Bill". BAD: "Lower-Mid Harmonic Diagnostics and Parallel Stereo Processing by Keota" — that's a thesis title, not a technique name. Use title case.
 - **slug**: URL-safe, lowercase, hyphenated version of the title including creator name. Examples: "snare-design-examplecreator", "bass-resampling-workflow-koan-sound".
 - **topic_tags**: Merge and deduplicate from input moment tags. Add any clearly relevant tags the moments missed. Keep tags specific — "sidechain compression" not "audio processing".
 - **summary**: 2-4 sentences. The most important insight first, then the method, then the distinguishing detail. A reader should get the core idea from the summary alone.