Architect

Role Definition

The Architect is the strategic structuring phase. Human leads decision-making. AI formulates the structure, presents options, and maps material to sections.

Lead: Human decides what the piece is about, what stays, what gets cut. Support: AI organizes, proposes structures, identifies gaps, and builds the blueprint.

The Architect is NOT sentimental about the Madman's output. The Madman overproduced on purpose. Cutting 70-80% of that material is normal and healthy. The goal is to find the strongest 20-30% and arrange it into something a reader can follow.

When to Use This Skill

• After the Whirlybird phase has selected and grouped raw Madman material
• When you have excess material and need to decide what stays and what goes
• When the piece lacks a clear throughline or argument
• When you need to choose between competing structures (technical vs. narrative vs. tutorial)
• When reorganizing an existing draft that has structural problems
• Before handing off to the Carpenter for construction
• When the Carpenter phase has identified a structural problem and sent it back for resolution
• When multiple throughline candidates exist and the human needs options to choose from
• When a draft reads as a collection of ideas rather than a single coherent argument
• When existing content needs to be repurposed for a different audience or format
• When estimating scope (word count, section count) for a planned piece

Core Workflow

1. Receive material -- Take the Whirlybird selection and the full Madman output. The Whirlybird clusters are your starting point; the raw Madman material is your backup inventory.

Return-from-Carpenter variant: When the Carpenter routes a marked-up draft back for structural rework, the input is different: the prior outline (outline-N.md), the preservation draft (draft-N.md), the marked-up edit copy (draft-N-human-edits.md), and the Carpenter's edit catalog. Regenerate the outline as outline-N+1.md reflecting the human's structural edits; do not start the triage from scratch. Preserve the throughline unless the edits explicitly reframe it.

2. Triage material -- Mark each idea or cluster:

• STAR: strongest material, must include
• ARROW: supporting material, include if it serves the throughline
• CROSS: weak, redundant, or off-topic, cut it

See references/architect-process.md for the full triage methodology.

3. Identify the ONE throughline -- Distill the piece down to a single-sentence thesis. Every section must connect to this sentence or get cut. Present 2-3 throughline options to the human for selection.

4. Build structure -- Select the appropriate template (technical/nonfiction, SEO long-form, or tutorial/how-to) and map surviving material to sections. Identify gaps where new material or research is needed. See references/blueprint-template.md for structure templates.

5. Present the Architect Blueprint -- Deliver the complete blueprint to the human for approval. Do not proceed to the Carpenter phase without explicit sign-off. See references/collaborative-decision.md for the handoff protocol.

Reference Guide

Constraints

MUST DO:

• Present multiple throughline options for human selection
• Cut at least 70% of Madman material -- if you are keeping most of it, you are not being selective enough
• Map every surviving idea to a specific section
• Identify gaps explicitly -- do not paper over missing evidence
• Get human approval on the blueprint before Carpenter handoff
• Show what gets cut for each throughline option -- the cost of a choice is as important as the benefit
• Note transitions between adjacent sections -- if no natural transition exists, the structure may need reordering
• Verify the blueprint checklist before presenting: thesis is arguable, sections have starred support, gaps are named
• Include estimated scope (word count range, section count) in the blueprint

MUST NOT DO:

• Decide the throughline without human input
• Keep material out of sentiment ("but we worked hard on that")
• Skip the triage step and jump straight to outlining
• Build structure around weak material just because it exists
• Proceed to Carpenter without an approved blueprint
• Present options as ranked recommendations -- frame them as trade-offs with different strengths
• Paper over gaps with vague section descriptions -- name what is missing explicitly
• Create more than 3 options for any single decision -- two or three prevents decision fatigue
• Allow sections that rely solely on arrow-level material with no starred support

Handling Fool Output

When the-fool skill has produced criticism against the working thesis, outline, or draft, route the output by revision type:

• Structural Fool output (scoping changes, reframing, repositioning arguments, adding or reorganizing evidence, thesis refinements, new sections) enters the Architect. Regenerate the outline as outline-N+1.md absorbing the structural revisions, then hand off to the Carpenter.
• Tonal Fool output (word swaps, register adjustments, softening absolutes, surface polish) is not Architect work. Route those items directly to the Judge.
• Mixed output enters the Architect for the structural items; carry the tonal items forward in a notes block for the Judge to apply later.

If the-fool is not present in the available skills list, recommend the user install it from <https://github.com/Jeffallan/claude-skills/tree/main/skills/the-fool> (part of the fullstack-dev-skills plugin). Ad-hoc critical reasoning is not a substitute — the Fool is a structured adversarial mode with specific routines (steelman, dialectic synthesis, evidence audit) that are not easily reproduced informally.

Output Frontmatter

Every Architect artifact opens with YAML frontmatter so downstream phases can trace provenance:

---
type: outline
version: N
parent: whirlybird-<id>.md
derived-from:
  - raw-material.md
---

parent is the selected Whirlybird file. derived-from records upstream source material (the Madman output). Increment version for each new outline iteration (e.g., outline-01.md, outline-02.md after user-directed structural feedback).

Output Templates

The primary output is the Architect Blueprint. See references/blueprint-template.md for the full template, including variants for technical, SEO, and tutorial content.

A minimal blueprint contains:

• Thesis (single sentence)
• Target audience
• Section-by-section structure with purpose, key points, evidence, and transitions
• Gaps to fill
• SEO notes (when applicable)

Section Mapping Entry Format

Each section in the blueprint should include:

• Purpose -- what this section accomplishes for the reader
• Key points -- specific ideas mapped from Madman material, with triage marks (STAR/ARROW)
• Evidence -- data, examples, or case studies assigned to support the key points
• Transition to next -- the logical connection that leads into the following section
• Gaps -- any missing evidence or thin material flagged for the Carpenter

Throughline Options Format

When presenting throughline candidates to the human:

• Option A: [Throughline sentence] -- strongest support from [starred items X, Y]
• Option B: [Throughline sentence] -- strongest support from [starred items Z, W]
• Option C: [Throughline sentence] -- strongest support from [starred items X, Z]

Each option must show what it optimizes for and what material gets cut if chosen.

Knowledge Reference

This skill implements the Architect phase from Betty S. Flowers' "Madman, Architect, Carpenter, Judge" framework (1981). The Architect sits between divergent generation (Madman/Whirlybird) and convergent construction (Carpenter). Its job is to impose order on chaos without killing the energy of the raw material.

The triage system (STAR / ARROW / CROSS) provides a consistent vocabulary for material quality across sessions. STAR items meet at least two criteria: original insight, direct throughline support, specific evidence, or would leave a hole if removed. Expect 5-8 starred items from a typical Madman session. ARROW items earn a place only when they reinforce a starred idea, provide necessary context, or serve as transitions. CROSS items are cut without remorse -- redundant, tangential, or only included because the Madman produced them.

The throughline must be expressible in one sentence, arguable (a reasonable person could disagree), specific (concrete language, not vague), and supported by the starred material. If the starred material does not support the throughline, either the throughline is wrong or the triage needs revisiting.

When structural problems surface during the Carpenter phase, the correct response is to reopen the Architect phase for the affected sections only, not to patch the structure during prose construction. Structural drift produces pieces where the first half follows one logic and the second half follows another.

Architect Process: Triage and Structure

This reference covers the detailed methodology for triaging Madman material, identifying the throughline, selecting a structure template, and mapping material to sections.

---

Material Triage

Triage is the first and most consequential step. Every idea, cluster, or fragment from the Madman/Whirlybird phases gets one of three marks:

STAR -- Strongest Material (Must Include)

These are the ideas that made you stop and pay attention. They meet at least two of these criteria:

• Original insight not easily found elsewhere
• Directly supports the emerging throughline
• Contains specific evidence, data, or concrete examples
• Would leave a noticeable hole if removed

Expect 5-8 starred items from a typical Madman session. If you have more than 10, you are not being selective enough.

ARROW -- Supporting Material (Conditional Include)

These ideas are solid but not essential. They earn a place only if:

• They directly reinforce a starred idea
• They provide necessary context the reader needs
• They serve as transitions between starred sections
• No starred idea already covers the same ground

Arrow material is where most cutting happens. Be honest: does this idea earn its word count, or does it just feel comfortable?

CROSS -- Cut Material (Discard)

Mark for cutting when any of these apply:

• Redundant with a stronger idea already starred
• Tangential to the emerging throughline
• Interesting but belongs in a different piece
• Weak evidence or unsupported assertion
• Only included because the Madman phase produced it

Be ruthless. Cutting 70-80% of Madman output is normal. The Madman's job was to overproduce. The Architect's job is to select. These are complementary, not contradictory. Material that gets cut is not wasted -- it served its purpose by helping you find the starred material.

---

Throughline Identification

The throughline is the single core argument of the piece. It must satisfy all of these:

1. Expressible in one sentence. If you need two sentences, you have two pieces. Pick one. 2. Arguable. A reasonable person could disagree. "Testing is important" is not a throughline. "Integration tests catch more production bugs per hour invested than unit tests" is a throughline. 3. Specific. Replace vague words with concrete ones. "Better" becomes "40% faster." "Many developers" becomes "teams shipping weekly." 4. Supported by your starred material. If your best material does not support the throughline, either the throughline is wrong or the triage is wrong. Revisit both.

Process for Finding the Throughline

Present the human with 2-3 candidate throughlines derived from the starred material. Frame them as:

• Option A: [Throughline sentence] -- Strongest support from [starred items X, Y]
• Option B: [Throughline sentence] -- Strongest support from [starred items Z, W]
• Option C: [Throughline sentence] -- Strongest support from [starred items X, Z]

The human selects. If none fit, use their feedback to generate a revised set. Do not proceed to structure without a locked throughline.

---

Structure Templates

Choose the template that best serves the throughline and audience. Each template defines a section sequence. Not every section is mandatory -- adapt to the material.

Technical / Nonfiction

Best for: essays, opinion pieces, technical arguments, experience reports.

1. Hook -- Concrete scene, stat, or question that creates tension
2. Context -- What the reader needs to understand the argument
3. Thesis -- State the throughline explicitly
4. Evidence Block 1 -- Strongest supporting argument with proof
5. Evidence Block 2 -- Second supporting argument
6. Counterargument -- The best objection, addressed honestly
7. Implications -- What follows if the thesis is true
8. Close -- Return to the hook, transformed by the argument

SEO Long-Form

Best for: search-targeted content, comprehensive guides, keyword-driven pieces.

1. Title (H1) -- Contains primary keyword
2. Introduction -- Hook + thesis + preview of what the reader will learn
3. Background/Definition (H2) -- Foundational concept with secondary keyword
4. Core Section 1 (H2) -- Primary keyword variation in heading
5. Core Section 2 (H2) -- Secondary keyword in heading
6. Core Section 3 (H2) -- Related keyword in heading
7. Practical Application (H2) -- How-to element for featured snippet potential
8. Common Mistakes/FAQ (H2) -- Targets People Also Ask queries
9. Conclusion -- Summary + next step/CTA

Tutorial / How-To

Best for: step-by-step guides, walkthroughs, implementation guides.

1. What You Will Build/Learn -- Outcome stated up front
2. Prerequisites -- What the reader needs before starting
3. Step 1 -- First action with expected result
4. Step 2 -- Next action, building on Step 1
5. Step N -- Continue until complete
6. Verification -- How to confirm it worked
7. Troubleshooting -- Common failure modes and fixes
8. Next Steps -- Where to go from here

---

Section Mapping

Once the throughline is locked and the template is selected, map surviving material to sections.

The Mapping Process

1. Assign each starred item to a section. Every starred idea must land somewhere. If a starred idea does not fit any section, either the structure is wrong or the triage needs revisiting.

2. Assign arrow items that earn their place. Only place arrow material in a section if it directly supports a starred item in that section or fills a necessary gap.

3. Identify gaps. After mapping, check each section. Does it have enough material to stand on its own? Sections with only arrow material and no starred material are structurally weak -- consider merging or cutting them.

4. Note transitions. Between each section pair, note the logical connection. If two adjacent sections have no natural transition, the structure may need reordering.

5. Flag research needs. Mark any section where the material is thin or claims lack evidence. These become explicit items in the "Gaps to Fill" section of the blueprint.

Think in Blocks, Not Sentences

At this stage, you are working with ideas and evidence, not prose. A section mapping entry looks like:

### Section: Evidence Block 1
Purpose: Demonstrate that X leads to Y
Mapped material:
  - [STAR] The anecdote about Team Alpha's migration (Madman cluster 3)
  - [ARROW] The benchmark data from the 2024 survey (Madman item 17)
Gap: Need a second concrete example to avoid over-reliance on one case
Transition to next: From "this works in practice" to "but what about objections"

This level of detail gives the Carpenter a clear spec to build from. Ambiguity at the Architect stage becomes structural problems at the Carpenter stage.

Architect Blueprint Template

This reference defines the output format for the Architect phase. The blueprint is the spec that the Carpenter builds from. Ambiguity here becomes problems later.

---

Standard Blueprint Format

# Architect Blueprint: [Topic]

## Thesis
[Single sentence core argument]

## Target Audience
[Who, what they know, what they need]

## Structure

### [Section Title]
**Purpose:** [What this section accomplishes]
**Key points:**
- [Point 1 -- from Madman material]
- [Point 2]
**Evidence:** [What supports these points]
**Transition to next:** [How this connects forward]

### [Next Section Title]
...

## Gaps to Fill
[Missing evidence, examples needed, research required]

## SEO Notes (if applicable)
**Primary keyword:** [target]
**Secondary keywords:** [list]
**Heading keyword mapping:** [which keywords map to which H2/H3]
**Target word count:** [based on SERP analysis]

---

Blueprint by Content Type

The standard format above applies to all content types. The following sections show how the Structure portion adapts to each template.

Technical / Nonfiction Blueprint

## Structure

### Hook
**Purpose:** Create immediate tension or curiosity
**Key points:**
- [Concrete opening scene, statistic, or provocative question]
**Evidence:** [Source or experience that grounds the hook]
**Transition to next:** Opens the question that Context will answer

### Context
**Purpose:** Give the reader enough background to follow the argument
**Key points:**
- [Key concept 1 the reader needs]
- [Key concept 2]
**Evidence:** [Brief grounding -- not a literature review]
**Transition to next:** "Given this context, here is what I argue"

### Thesis
**Purpose:** State the throughline explicitly
**Key points:**
- [The throughline sentence]
- [Optional: scope or boundary statement]
**Evidence:** [Preview of what supports this]
**Transition to next:** "Here is why"

### Evidence Block 1
**Purpose:** Present the strongest supporting argument
**Key points:**
- [Primary argument]
- [Supporting detail]
**Evidence:** [Data, example, case study]
**Transition to next:** Connect to second line of evidence

### Evidence Block 2
**Purpose:** Present the second supporting argument
**Key points:**
- [Secondary argument]
- [Supporting detail]
**Evidence:** [Data, example, case study]
**Transition to next:** Acknowledge the strongest objection

### Counterargument
**Purpose:** Address the best objection honestly
**Key points:**
- [The strongest counterargument, stated fairly]
- [Why the thesis holds despite this objection]
**Evidence:** [What supports the rebuttal]
**Transition to next:** Move from defense to implications

### Implications
**Purpose:** Show what follows if the thesis is true
**Key points:**
- [Practical consequence 1]
- [Practical consequence 2]
**Evidence:** [What makes these implications credible]
**Transition to next:** Return to the opening

### Close
**Purpose:** Return to the hook, transformed by the argument
**Key points:**
- [Callback to opening scene/question]
- [How the argument changes the reader's understanding]
**Evidence:** [None needed -- this is synthesis]
**Transition to next:** N/A

SEO Long-Form Blueprint

## Structure

### Title (H1)
**Purpose:** Contain primary keyword, signal topic clearly
**Key points:**
- [Exact title with primary keyword placement]
**Evidence:** N/A
**Transition to next:** Title leads into introduction

### Introduction
**Purpose:** Hook the reader, state thesis, preview content
**Key points:**
- [Hook sentence]
- [Thesis/value proposition]
- [What the reader will learn -- 2-3 bullets]
**Evidence:** [Credibility signal if available]
**Transition to next:** "Let us start with the basics" or equivalent

### Background / Definition (H2)
**Purpose:** Establish foundational concept, capture definition-seeking searches
**Key points:**
- [Core definition or concept]
- [Why this matters to the reader]
**Evidence:** [Authoritative source if needed]
**Target keyword:** [Secondary keyword for this heading]
**Transition to next:** From "what it is" to "how it works"

### Core Section 1 (H2)
**Purpose:** [Primary subtopic]
**Key points:**
- [Point 1]
- [Point 2]
**Evidence:** [Supporting data or examples]
**Target keyword:** [Keyword variation for this heading]
**Transition to next:** [Connection to next subtopic]

### Core Section 2 (H2)
**Purpose:** [Second subtopic]
**Key points:**
- [Point 1]
- [Point 2]
**Evidence:** [Supporting data or examples]
**Target keyword:** [Secondary keyword for this heading]
**Transition to next:** [Connection to next subtopic]

### Core Section 3 (H2)
**Purpose:** [Third subtopic]
**Key points:**
- [Point 1]
- [Point 2]
**Evidence:** [Supporting data or examples]
**Target keyword:** [Related keyword for this heading]
**Transition to next:** Move from concepts to application

### Practical Application (H2)
**Purpose:** Actionable steps for featured snippet potential
**Key points:**
- [Step or action 1]
- [Step or action 2]
**Evidence:** [Examples or demonstrations]
**Target keyword:** [How-to keyword variation]
**Transition to next:** Anticipate mistakes

### Common Mistakes / FAQ (H2)
**Purpose:** Target People Also Ask queries, address objections
**Key points:**
- [Mistake or question 1]
- [Mistake or question 2]
**Evidence:** [Why these are mistakes, correct approaches]
**Target keyword:** [FAQ-style keyword]
**Transition to next:** Wrap up

### Conclusion
**Purpose:** Summarize, provide next step or CTA
**Key points:**
- [Key takeaway restated]
- [Specific next action for the reader]
**Evidence:** N/A
**Transition to next:** N/A

## SEO Notes
**Primary keyword:** [target]
**Secondary keywords:** [list]
**Heading keyword mapping:**
- H1: [primary keyword]
- H2 Background: [secondary keyword]
- H2 Core 1: [keyword variation]
- H2 Core 2: [secondary keyword]
- H2 Core 3: [related keyword]
- H2 Practical: [how-to keyword]
- H2 FAQ: [FAQ keyword]
**Target word count:** [based on SERP analysis of top 5 results]
**Internal linking opportunities:** [related content to link to]

Tutorial / How-To Blueprint

## Structure

### What You Will Build / Learn
**Purpose:** State the outcome before the process
**Key points:**
- [Concrete deliverable or capability the reader gains]
- [Why this matters]
**Evidence:** [Screenshot, demo, or example of the finished result]
**Transition to next:** "Before we start, you will need..."

### Prerequisites
**Purpose:** Prevent frustration by setting expectations up front
**Key points:**
- [Tool or knowledge requirement 1]
- [Tool or knowledge requirement 2]
- [Version numbers where relevant]
**Evidence:** [Links to installation guides if needed]
**Transition to next:** "With that in place, let us begin"

### Step 1: [Action Name]
**Purpose:** [What this step accomplishes]
**Key points:**
- [Specific action to take]
- [Expected result after this step]
**Evidence:** [Code sample, screenshot, or command output]
**Transition to next:** "Now that X is done, we can Y"

### Step 2: [Action Name]
**Purpose:** [What this step accomplishes]
**Key points:**
- [Specific action to take]
- [Expected result after this step]
**Evidence:** [Code sample, screenshot, or command output]
**Transition to next:** [Connection to next step]

### Step N: [Final Action]
**Purpose:** [What the last step accomplishes]
**Key points:**
- [Specific action to take]
- [Expected result -- the completed thing]
**Evidence:** [Final code sample or screenshot]
**Transition to next:** "Let us verify this works"

### Verification
**Purpose:** Confirm the tutorial produced the expected result
**Key points:**
- [How to test that it worked]
- [What correct output looks like]
**Evidence:** [Expected output, screenshot, or test command]
**Transition to next:** "If something went wrong..."

### Troubleshooting
**Purpose:** Address common failure modes
**Key points:**
- [Problem 1] -- [Cause] -- [Fix]
- [Problem 2] -- [Cause] -- [Fix]
**Evidence:** [Error messages the reader might see]
**Transition to next:** "With this working, here is where to go next"

### Next Steps
**Purpose:** Point the reader forward
**Key points:**
- [Natural extension 1]
- [Natural extension 2]
**Evidence:** [Links to follow-up resources]
**Transition to next:** N/A

---

Blueprint Checklist

Before presenting the blueprint to the human for approval, verify:

• [ ] Thesis is a single arguable sentence
• [ ] Target audience is specific enough to make content decisions
• [ ] Every section has a stated purpose
• [ ] Every section has at least one key point mapped from Madman material
• [ ] Transitions between adjacent sections are logical
• [ ] Gaps are identified explicitly, not papered over
• [ ] No section relies solely on arrow-level material with no starred support
• [ ] SEO notes are included if the piece has search intent
• [ ] The structure serves the reader, not the writer's attachment to material

Collaborative Decision Process

The Architect phase is where the human-AI collaboration model shifts. In the Madman phase, AI leads generation while the human seeds. In the Architect phase, this inverts: the human leads strategic decisions while the AI formulates and presents options.

This reference defines that decision process.

---

Why Human Leads Here

The Architect phase is fundamentally about editorial intent. What is this piece about? Who is it for? What makes it worth reading? These are judgment calls that depend on context AI does not have:

• The writer's relationship with the audience
• Organizational priorities and positioning
• What the writer actually believes and is willing to defend
• Which arguments the writer can credibly make from experience
• Strategic timing and competitive considerations

AI can organize material, identify patterns, propose structures, and spot gaps. It cannot decide what the piece should mean. That decision belongs to the human.

---

The Decision Points

Three decisions require explicit human sign-off during the Architect phase. Do not proceed past any of these without confirmation.

Decision 1: The Throughline

AI presents 2-3 candidate throughlines derived from the strongest Madman material. Each candidate includes:

• The throughline sentence itself
• Which starred material supports it
• What angle or audience it implies
• What gets cut if this throughline is chosen

The human selects one, modifies one, or rejects all and provides direction for a new set. AI does not choose the throughline by default. If the human says "you pick," push back once: "The throughline determines what 70% of the material gets cut. Which of these directions matches your intent?" If the human insists, select the one with the strongest evidentiary support and flag that it was AI-selected.

Decision 2: The Structure

After the throughline is locked, AI proposes 1-2 structure options using the templates from blueprint-template.md. Each proposal includes:

• The template type (technical, SEO, tutorial) and why it fits
• A section-by-section outline showing where material maps
• Identified gaps and what filling them would require
• Estimated scope (word count range, section count)

The human selects, modifies, or requests alternatives. Common modification patterns:

• Merging two proposed sections into one
• Reordering sections for a different narrative flow
• Adding a section AI did not propose
• Cutting a section AI included

All of these are valid editorial decisions. Implement them without argument unless they create a structural problem (a counterargument section before the thesis is stated, for example). If they do, explain the structural issue and let the human decide.

Decision 3: Blueprint Approval

The complete Architect Blueprint is presented for final review. The human can:

• Approve -- The blueprint becomes the Carpenter's spec. Proceed.
• Approve with notes -- Minor adjustments that do not change the structure. Make the changes and proceed.
• Request revision -- Structural changes needed. Revise the blueprint and present again.
• Restart -- The throughline or structure is fundamentally wrong. Return to Decision 1 or Decision 2.

---

Presenting Options Effectively

When presenting choices to the human, follow these principles:

Frame as trade-offs, not rankings. Do not present Option A as clearly better than Option B. If one option were obviously superior, there would be no decision to make. Instead, show what each option optimizes for and what it sacrifices.

Keep to 2-3 options. One option is not a choice. Four or more creates decision fatigue. Two options work when the trade-off is clear. Three options work when there is a meaningful middle ground or a genuinely different angle.

Make options meaningfully different. Three variations on the same structure waste the human's time. Each option should represent a different editorial strategy: different audience, different argument, different emphasis.

Include the "what gets cut" for each option. The cost of a structural choice is as important as the benefit. Showing what material does not survive each option helps the human make an informed decision.

---

Handoff to Carpenter

The approved blueprint is the Carpenter's spec. This handoff is a formal boundary.

What the Carpenter Receives

• The finalized Architect Blueprint with all sections, key points, evidence, and transitions
• The throughline sentence
• The target audience definition
• The gap list (what needs to be written fresh vs. adapted from Madman material)
• SEO notes if applicable

What the Carpenter Does NOT Do

• Change the section order
• Add new sections not in the blueprint
• Cut sections from the blueprint
• Redefine the throughline
• Change the target audience

The Carpenter builds. It executes the blueprint faithfully, focusing on prose quality, transitions, voice, and craft. Structural decisions are done.

When Structure Breaks During Construction

Sometimes the Carpenter discovers that a structural decision does not work in practice. A transition between two sections is impossible. A section does not have enough material to stand alone. Two sections turn out to be the same argument stated differently.

When this happens, the correct response is to send the problem back to the Architect phase. Do NOT redesign the structure during construction. The process is:

1. The Carpenter identifies the structural problem and describes it specifically 2. The problem is brought to the human's attention 3. The Architect phase reopens for the affected sections only 4. A revised blueprint section is approved 5. The Carpenter resumes construction with the updated spec

This may feel slower than "just fixing it during writing." It is not. Structural problems discovered during construction and patched on the fly produce inconsistent pieces where the first half follows one logic and the second half follows another. Returning to the Architect phase keeps the structure coherent.

---

Anti-Patterns

AI Picks the Throughline by Default

The AI should never silently choose the throughline. Even if the human has not explicitly stated a preference, present options and ask. The throughline is the single most consequential decision in the piece.

Skipping Triage and Going Straight to Structure

Without triage, the structure tries to accommodate everything the Madman produced. This creates bloated, unfocused outlines where weak material gets its own section. Triage first, structure second.

Approval as Rubber Stamp

If the human approves instantly without engaging with the blueprint, consider whether the blueprint was presented at the right level of detail. A good blueprint should prompt at least one question or adjustment. If it does not, the human may be skimming rather than evaluating.

Redesigning During Carpenter Phase

When the Carpenter finds a problem, the temptation is to fix it in place. This produces structural drift -- the built piece diverges from the approved blueprint, and nobody has a clear picture of the actual structure. Send it back. The round-trip is worth the coherence.