Workspace: all context paths below (identity, audience, strategy, voice, brand, raw, output, index, log, workspace preferences and context scripts) resolve from context/ in the kit root. Read both the root AGENTS.md and context/AGENTS.md. Skill-local references/ resolve from this skill directory.
X Article writer
Turn the author's material into an article a reader can use. Text and graphics explain the same argument. In a content waterfall the X Article adapts the approved newsletter; it does not invent a new thesis.
Ground the brief
Read identity/positioning.md, identity/proof.md, audience/ideal-follower.md, strategy/pillars.md, strategy/funnel.md and voice/linkedin-voice.md. Then read the actual source: the newsletter, transcript, framework or post the article comes from. Use the voice guide for the author's voice, not LinkedIn's hook length or formatting limits.
Establish a short working brief: the reader's problem, the thesis, the author's own contribution, the evidence, the section order and the graphics. Ask only for information that changes the argument.
For a supplied X URL, read the actual post and any linked Article, including its cover and inline graphics. If access is partial, say what was read. Never infer an article from its preview.
Write the article
- Lead with the strongest supported result and the reader's payoff. The title is specific; the introduction states the result, the author's relevant proof and what the reader will be able to build.
- Follow the result with the mechanism: the tools, the order of operations, the decisions and the reasons. Keep the author's concrete details and first-person experience.
- Make it personal through documented habits, mistakes and decisions, not by swapping "you" for "I".
- Keep the author's own names for their frameworks and explain each the first time.
- Prefer the shortest complete explanation. A section can be 2 sentences and a graphic. Do not pad to a word count. When the author has hand-edited an earlier version, that edit sets the depth and pace.
- State the action or belief directly, then the reason needed to understand it. Use short lists for concrete inputs, stages and routing choices.
- Explain a failure through the missing input or decision the author names (for example the context an AI draft lacked), not through a vague "it needs something worth saying".
- Keep each section on its named job. Do not restore examples, scripts or side topics the author cut just because they are relevant.
- Separate what was demonstrated from what is proposed. Numbers come only from
identity/proof.md; keep differing time windows separate. - Use a reference article for craft only: how it sets stakes and lets graphics carry information. Never import its anecdotes, numbers or distinctive lines.
- Numerals, no em dashes, no hashtags, no generic AI phrases.
- Links to the author's own site carry UTM parameters (source
x, campaign = the waterfall's slug). Links to GitHub, YouTube and other sites stay clean.
Graphics
Place each graphic where it explains the next step of the argument. A caption must add information; omit it when the figure explains itself. Pasted editor text such as "Provide a caption (optional)" is interface residue, not copy. Use graphics-designer or flowchart for new figures and keep the editable source. For the X handoff, export a cover and full-resolution inline images numbered in article order, with a short placement guide.
The video post
When the waterfall needs the X post for a new video: 1 short line about the reader's world or the result, 1 or 2 lines on what the video shows, the native video if available, and the full https://www.youtube.com/watch?v=<id> URL. No shortened links.
Deliver
Return the article, the title, the cover and the inline graphics with their positions, plus any unresolved facts. Drafting does not authorize publishing or scheduling. If a scheduler does not support native Articles, hand over the draft and assets for the native X editor and say so.
When asked to learn from a finished piece, compare the author's final hand edit with the preceding draft and record what they added, cut and renamed as reusable rules. Their final choices on length, examples, headings and tone win over earlier drafts. Learning from a piece does not by itself ask for another rewrite or for publication.
Review before returning: does the title promise something useful, does the opening carry the strongest supported result, would the author recognise their reasoning, can a reader scan it and act, and do text, figures and links describe the same system?


