Belief Article Pipeline

How does a public belief become a page without losing the argument?

Use the belief-article-* skill family as one loop:

belief-article-orchestrator
  -> belief-article-brief
  -> belief-article-argument
  -> belief-article-design
  -> belief-article-page
  -> belief-article-qa

The orchestrator owns sequence. The specialist skills own their station. The page is not done until QA proves the public route, article copy, return path, design memory, and close-out are coherent.

Standard

1. Brief names claim, audience, outcome, and source material.
2. Argument turns the claim into sections, proof, pressure checks, and reader action.
3. Design memory names the visual thesis and page-local component rules.
4. Page assembly creates or edits src/pages/beliefs/**/index.tsx.
5. QA checks route registration, article structure, return navigation, legibility, and no private leakage.
6. A receipt or wiki-log entry records material evolution.

Action

Run the skills in sequence. Do not skip directly to page assembly unless the brief, argument, and design memory already exist and are current.

The minimum handoff between stations is:

Station	Output
Brief	Claim, audience, source, intended reader action
Argument	Sections, proof, pressure checks, links
Design	Visual thesis, components, constraints
Page	Public TSX route and local components
QA	Pass/fail record and next question

Checks

• The article has one public claim.
• The argument changes reader action.
• Design supports the thesis, not decoration.
• QA runs after page assembly.
• Lessons feed back into the skill chain.

Failure Modes

• Claim drift: the page becomes interesting but no longer argues the intended belief.
• Design decoration: visuals do not carry the thesis.
• QA skipped: routing, links, or private leakage are found after publish.
• No receipt: the article teaches nothing back to the skill chain.

Context

• Perspective — public argument depends on context, not isolated claims.
• Triad System — Reality, Dream, and Bridge keep the article grounded.
• Documentation Writing Standard — prose should be short, clear, and useful.
• Design System Standard — article components need legible, tokenized presentation.

Questions

What belief should the reader be able to act on after the page?

• What proof makes the belief credible?
• What reader action should change?
• What feedback should improve the next article loop?