Article writing
Write an article that gives a defined reader a useful, supportable point of view. This method returns a draft or revision; it does not publish, distribute, or represent that a draft has been approved.
Before drafting
Read the approved outline, source material, audience, voice guidance, and any publication constraints. Keep a source list while researching so citations do not have to be reconstructed later. If the user has only a topic or rough ideas, use an outlining method first rather than silently creating the argument while drafting.
Identify the intended decision or understanding the article should improve and the detail level its reader can use. If either is materially unclear, ask before turning a draft into generic commentary.
When a house voice is supplied, follow it. Otherwise use plain, direct prose: concrete verbs, short paragraphs, a credible counterpoint where relevant, and no inflated claims or empty scene-setting.
Use this method for drafting or revising a substantive article. Route a request that only needs an argument or evidence plan to an outlining method, and route a short social adaptation to the host's social-content method. Route publishing, scheduling, or uploading requests to the host-owned publishing method; this method returns only the draft.
Draft workflow
Use `references/draft-quality.md` for the detailed drafting and revision loop.
1. **Open with the reader's real problem or a supported observation.** Do not invent a personal story, customer result, or trend to manufacture interest. 2. **Develop one thesis.** Each section should advance it with reasoning, supplied experience, or cited evidence. Merge overlapping ideas; use a list only when its items have a distinct reader-useful function. 3. **Qualify the claim.** Include material limitations, exceptions, and counterevidence. Treat a local example as a local example, and answer a reader's strongest reasonable objection directly. 4. **Make the conclusion useful.** Give the reader a proportionate action, question, or decision rule that follows from the argument, not a sales prompt. Reuse one earned explanatory frame only when it clarifies the conclusion. 5. **Verify, revise, and edit.** Check factual claims against their sources, remove unsupported language, and confirm that the headline and ending match the article's actual argument. For a user-edited draft, reread the complete supplied version before revising, then report word count and estimated read time and propose specific cuts when length exceeds the agreed limit.
Draft structure
```markdown # [Title]
[Opening that names the problem or observation]
## [First argument] [Reasoning and evidence]
## [Second argument or example] [Reasoning and evidence]
## [Limitation or counterpoint] [What the argument does not establish]
## [Practical conclusion] [Specific, proportionate next step]
## Sources - [Source title](URL) — [claim supported] ```
Omit a Sources section only when the draft makes no external factual claims. Place each external factual claim's citation inline beside that claim as well as in the list, adapting the citation style to the requested format.
Host handoffs
If the host environment saves editorial artifacts, keep the approved outline, long draft, and any explicitly requested short adaptation together under the same topic and stable article slug. Reuse the existing artifact on revision; do not create a date or version suffix merely to preserve history.
After an external publishing workflow confirms publication, its host-owned inventory may be refreshed from the confirmed publication record. Do not refresh an inventory, claim publication, or perform a file or publishing write from this drafting method without the required host capability and approval.
Boundaries
- Do not turn tentative observations into quantified outcomes or broad proof. - Do not invent author experience, customer stories, endorsements, or sources. - Do not add causal details, process context, or findings that the supplied observation does not establish. - Keep non-public information anonymous unless its owner explicitly approved publication. - Treat feedback as a revision request, not publication approval. - Publishing, scheduling, uploading, or sending is a separate approved action in the host environment.