create-article

Write Article

Produces a high-quality article from a target audience definition and a set of relevant sources. Adapts tone, depth, and structure to fit the audience.

Prerequisites

• Target audience: Who will read this article (e.g., "senior backend engineers", "product managers unfamiliar with ML", "general tech enthusiasts")
• Relevant sources: URLs, file paths, or inline content to draw from (research papers, blog posts, docs, notes, etc.)
• Topic (optional): If not inferable from sources, state the article topic explicitly

If sources are not yet gathered, run /research-article first to discover the state of the art and produce a research brief whose key sources feed this skill. If you decide not to run it, say so and give your reasoning before proceeding, so the user can course-correct.

Steps

1. Read all provided sources thoroughly.
2. Identify the core insight or argument the article should convey.
3. Calibrate tone and depth to the target audience.
4. Draft the article using the structure below, following the formatting rules.
5. Verify all links: curl every URL in the article and replace any that return 4xx, 5xx, or connection errors.
6. Discover related articles in the same repository (see "Finding Related Articles" below) and add a "See also" section.
7. Revise for clarity, flow, and conciseness.
8. Include session_link: http://localhost:10000/?session=<id> in the frontmatter, using the current session ID from context. If no session ID is available, omit the field.

Formatting Rules

• One sentence per line: Each sentence occupies its own line in the markdown source. This produces cleaner git diffs since changes to one sentence don't affect adjacent lines. Paragraphs are separated by a blank line, with sentences within a paragraph on consecutive lines (not separated by blank lines).
• Link all sources: Every source referenced in the article body must include a verified hyperlink, not just a textual citation (e.g., [Author, "Title"](https://...) not just Author, "Title").
• Verify links: After drafting, curl every hyperlink and replace any that return 4xx or connection errors before finalizing the article.
• Bold important statements: Highlight the most important statements, key claims, and takeaways in bold so readers scanning the article still capture the core message. Be selective: bold sentences or phrases that carry the argument, not routine sentences. Avoid bolding more than one statement per paragraph on average.
• Plain vocabulary: Prefer common, everyday words over less frequent synonyms, so the article is easy to read (for example, "use" over "utilize", "help" over "facilitate", "show" over "elucidate"). Keep technical terms where they are the precise and expected choice; the goal is to avoid uncommon or showy words, not to lose precision. Calibrate this to the audience: write simpler for general readers, and allow more domain terms for expert readers.
• Name the referent: Avoid bare referential words like "this", "that", "these", and "those" when the referent could be ambiguous, since they force the reader to backtrack and resolve what is meant. Prefer naming the thing directly. For example, write "the parser fails on nested generics" rather than "this fails on nested generics", or "that approach trades latency for throughput" rather than "that trades latency for throughput". Referential words are acceptable when the referent is unambiguous and immediately adjacent, or when repeating the noun would be clunky.