55 added, 34 removed. Audit A to A.
---
name: article-writing
description: Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
origin: ECC
---
# Article Writing
- Write long-form content that sounds like a real person or brand, not generic AI output.
+ Write long-form content that sounds like an actual person with a point of view, not an LLM smoothing itself into paste.
## When to Activate
- drafting blog posts, essays, launch posts, guides, tutorials, or newsletter issues
- turning notes, transcripts, or research into polished articles
- matching an existing founder, operator, or brand voice from examples
- tightening structure, pacing, and evidence in already-written long-form copy
## Core Rules
- 1. Lead with the concrete thing: example, output, anecdote, number, screenshot description, or code block.
+ 1. Lead with the concrete thing: artifact, example, output, anecdote, number, screenshot, or code.
2. Explain after the example, not before.
- 3. Prefer short, direct sentences over padded ones.
- 4. Use specific numbers when available and sourced.
- 5. Never invent biographical facts, company metrics, or customer evidence.
+ 3. Keep sentences tight unless the source voice is intentionally expansive.
+ 4. Use proof instead of adjectives.
+ 5. Never invent facts, credibility, or customer evidence.
## Voice Capture Workflow
If the user wants a specific voice, collect one or more of:
- published articles
- newsletters
- - X / LinkedIn posts
+ - X posts or threads
- docs or memos
- - a short style guide
+ - launch notes
+ - a style guide
Then extract:
- sentence length and rhythm
- - whether the voice is formal, conversational, or sharp
- - favored rhetorical devices such as parentheses, lists, fragments, or questions
- - tolerance for humor, opinion, and contrarian framing
- - formatting habits such as headers, bullets, code blocks, and pull quotes
+ - whether the writing is compressed, explanatory, sharp, or formal
+ - how parentheses are used
+ - how often the writer asks questions
+ - whether the writer uses fragments, lists, or hard pivots
+ - formatting habits such as headers, bullets, code blocks, pull quotes
+ - what the writer clearly avoids
- If no voice references are given, default to a direct, operator-style voice: concrete, practical, and low on hype.
+ If no voice references are given, default to a sharp operator voice: concrete, unsentimental, useful.
+ ## Affaan / ECC Voice Reference
+
+ When matching Affaan / ECC voice, bias toward:
+ - direct claims over scene-setting
+ - high specificity
+ - parentheticals used for qualification or over-clarification, not comedy
+ - capitalization chosen situationally, not as a gimmick
+ - very low tolerance for fake thought-leadership cadence
+ - almost no bait questions
+
## Banned Patterns
Delete and rewrite any of these:
- - generic openings like "In today's rapidly evolving landscape"
- - filler transitions such as "Moreover" and "Furthermore"
- - hype phrases like "game-changer", "cutting-edge", or "revolutionary"
- - vague claims without evidence
- - biography or credibility claims not backed by provided context
+ - "In today's rapidly evolving landscape"
+ - "game-changer", "cutting-edge", "revolutionary"
+ - "no fluff"
+ - "not X, just Y"
+ - "here's why this matters" as a standalone bridge
+ - fake vulnerability arcs
+ - a closing question added only to juice engagement
+ - forced lowercase
+ - corny parenthetical asides
+ - biography padding that does not move the argument
## Writing Process
1. Clarify the audience and purpose.
- 2. Build a skeletal outline with one purpose per section.
- 3. Start each section with evidence, example, or scene.
- 4. Expand only where the next sentence earns its place.
- 5. Remove anything that sounds templated or self-congratulatory.
+ 2. Build a hard outline with one job per section.
+ 3. Start sections with proof, artifact, conflict, or example.
+ 4. Expand only where the next sentence earns space.
+ 5. Cut anything that sounds templated, overexplained, or self-congratulatory.
## Structure Guidance
### Technical Guides
+
- open with what the reader gets
- - use code or terminal examples in every major section
- - end with concrete takeaways, not a soft summary
+ - use code, commands, screenshots, or concrete output in major sections
+ - end with actionable takeaways, not a soft recap
- ### Essays / Opinion Pieces
- - start with tension, contradiction, or a sharp observation
+ ### Essays / Opinion
+
+ - start with tension, contradiction, or a specific observation
- keep one argument thread per section
- - use examples that earn the opinion
+ - make opinions answer to evidence
### Newsletters
- - keep the first screen strong
- - mix insight with updates, not diary filler
- - use clear section labels and easy skim structure
+ - keep the first screen doing real work
+ - do not front-load diary filler
+ - use section labels only when they improve scanability
+
## Quality Gate
Before delivering:
- - verify factual claims against provided sources
- - remove filler and corporate language
- - confirm the voice matches the supplied examples
- - ensure every section adds new information
- - check formatting for the intended platform
+ - factual claims are backed by provided sources
+ - generic AI transitions are gone
+ - the voice matches the supplied examples
+ - every section adds something new
+ - formatting matches the intended medium