Article outlining
Turn a topic or rough material into an outline that can support a useful, honest article. This method produces a proposed outline and evidence plan; it does not publish, send, or change a content-management system.
Intake
Use the material already supplied before asking for more. Establish only the facts that change the outline:
- the intended reader and the decision or understanding the article should improve; - the central claim, observation, or question; - evidence available, including its limits; and - any required format, length, voice, or publication constraints.
When the request is exploratory, state narrow assumptions and offer a first outline rather than turning it into a long interview. Ask a question only when the answer would materially change the argument.
Five-part outline workflow
Follow `references/editorial-development.md` for the detailed development loop. Keep the phases distinct; do not jump from a topic to research or a polished claim before the reader problem and argument are developed.
1. **Explore.** Restate the reader's problem and the article's useful promise. Separate observed facts, lived experience, and the author's interpretation. 2. **Choose the story.** Propose one bounded thesis, the tension or counterargument it must answer, a relevant metaphor or explanatory frame, and a practical takeaway. Do not promote a small observation into universal proof. 3. **Position and plan evidence.** After the argument is developed, identify the current consensus, the article's alignment or disagreement with it, and genuine opposing views. Capture source URLs as research is gathered; never add a statistic, case study, or attributed position without its source. 4. **Build the action path.** Sequence the opening, context, argument, counterpoint, concrete examples, and conclusion so each section advances the thesis. Allocate a purpose and word budget to each section, identify sections that should merge, and give the reader a usable next step rather than a generic call to action. 5. **Review with the author.** Check that the title, thesis, headings, evidence needs, and conclusion agree. Propose concrete drift corrections or cuts, let the user accept or reject them, and flag unresolved evidence or claims that should be narrowed before drafting.
Output
```markdown # [Working title]
## Reader and purpose [Who this is for and what it should help them understand or decide]
## Thesis [One bounded, supportable claim]
## Outline 1. **[Section]** — [purpose, key point, evidence needed, target words] 2. **[Section]** — [purpose, key point, evidence needed, target words] 3. **[Counterpoint or limitation]** — [genuine view or limit, and what it qualifies] 4. **[Practical conclusion]** — [specific next step, options by reader resources]
## Evidence plan - [Claim] — [source, supplied observation, or information still needed]
## Positioning and flow - [Current consensus, the article's alignment or counter-position, and opposing views to address] - [Sections to merge, cut, or reorder if they do not advance the thesis]
## Risks or open questions - [Any unsupported claim, missing audience choice, or factual gap]
## Next action [If this outline is approved, hand it to the writing workflow for drafting; do not publish or distribute it here.] ```
Evidence and boundaries
- Cite every non-trivial external claim inline in the eventual article and list its sources. Re-check each URL against the claim before finalizing. - Preserve counterevidence, uncertainty, and the scope of supplied examples. - Keep client, employer, customer, and personal information private unless its owner explicitly authorizes publication. - A request to publish, schedule, upload, or distribute is a separate action requiring the host's normal approval path.
Handoff
Hand the approved outline to a writing workflow for drafting, or to the host's configured publishing workflow only after the user explicitly asks for that next action.