Tweet Post

Overview

The user wants tweet-length technical posts written as a personal engineering narrative compressed to X-post size, not marketing copy and not a generic listy summary. This applies whatever the subject is — something the user built, a research paper or finding, a technical insight — the compression discipline and narrative arc are the same regardless of content type; only the voice changes (see Voice, below). The single biggest failure mode is treating "tweet-like" as only a brevity instruction and losing the narrative arc in the process — a tweet under this skill still has a hook, a turn, and a close that echoes it; it's just all of that packed into ~110 words instead of a paragraph each. The whole point of this skill is to hit that density without collapsing into a bare feature list.

This skill is scoped to X/Twitter only. If the user asks for a LinkedIn post or something longer, that's a different pacing and structure (more room per beat, no hashtag convention) — don't force this skill's word cap or hashtags onto it; ask what length/platform the user actually wants.

The structure

Every post follows this shape, in order:

1. Hook — one or two sentences naming a broader problem, risk, or insight in the field, not the specific thing built. The reader should recognize the pain before they know a solution exists. Never open by describing the artifact.
2. Turn — one sentence pivoting from problem to reveal: "To address this, here's X" when the user built the thing, or "A recent paper/team addresses this by X" when the post covers someone else's work. Either way this is the bridge from problem to solution — lead with the artifact or finding, not a first-person construction verb.
3. Substance — narrate what the thing does or what was found, in the voice that matches who did the work (see Voice, below). Bullets or emoji markers are fine here for scannability (pick emoji that match the content, not generic decoration) — keep each line terse.
4. Reasoning — state at least one explicit design decision (if the user built it) or one notable methodological choice / implication (if it's someone else's work), and the thinking behind it — e.g., "One principle I intentionally included is..." or "What's notable is that the authors chose to...". This is the sentence that makes the post read as engineering judgment, not a spec sheet or a press release. Don't skip this — it's the most commonly dropped section and the one that matters most.
5. Systemic note (optional) — one sentence on how this fits a larger workflow, if relevant (e.g., how it's meant to be used alongside other tools or people).
6. Close — a generalized, aphoristic sentence that echoes the opening hook's theme. Not a punchline about the specific feature. The post should feel like it completes an argument, not that it ends a list.

Voice

Voice depends on whose work the post describes — this is the one thing that changes across content types, everything else in the structure stays fixed.

• If the user built the thing: first person for the substance and reasoning sections ("I designed," "I included") — this is the user announcing something they made, not third-party marketing copy describing a product. The one exception is the Turn/bridge sentence itself, which uses "Here's X" rather than "I built X" — everything downstream of that bridge stays in first-person ownership voice.
• If the post covers someone else's work — a research paper, a lab's finding, a third party's project — attribution stays third person throughout the substance and reasoning sections: researchers at X, the paper's authors, Anthropic's team, never "I" as if the user did the work. The only first-person voice allowed here is a short reflection if the user wants to add their own take — and it must read clearly as commentary on the work, not a claim of authorship over it.
• Exception within the Reasoning section: when stating a hard design constraint (something made mandatory/non-optional/required), phrase the constraint itself passively — "X is made non-optional," not "I made X non-optional." The rest of the reasoning sentence (the justification/"why") stays in whatever voice fits naturally. E.g. "Checkpoints are made non-optional on purpose — a step an agent can skip, it eventually skips exactly when it matters."
• No warm-up phrases, no hedging — consistent with the user's general style. But this is one context where a reflective, slightly philosophical tone is wanted, unlike the user's terser preference for direct technical answers elsewhere.
• Emoji-as-bullet-markers are acceptable here for scannability, even though the user's general preference is anti-decoration. Social/announcement posts are the exception.

Accuracy, when the post covers someone else's work

These apply whenever the subject is a paper, finding, or project the user didn't build themselves — they don't apply to the user's own announcements, where they're the authority on what they built.

• Never invent findings. Work only from what's actually provided (the paper, abstract, or write-up). Infer the post's structure, never the substance. If something important is missing, say so and ask rather than filling the gap plausibly.
• Preserve numbers exactly. A reported 12% improvement stays 12%, on the specific benchmark it was measured on — never rounded into a vibe, never generalized from one dataset into a claim about everything.
• Don't upgrade correlation into causation, and don't upgrade "on this benchmark, under these conditions" into "in general." If the source hedges, the post hedges.
• Flag limitations that change the interpretation in one honest clause, not a disclaimer dump — e.g. if a result only holds at large scale, or was only tested in one language.

Language level (A2–B1)

Write the output at CEFR A2–B1 English. This constrains sentence construction, not the ideas. Keep the thinking hard and the sentences easy.

• Sentences mostly under 20 words. One idea per sentence.
• Active voice. Subject-verb-object order.
• Common everyday verbs: "use" not "utilize", "start" not "commence", "show" not "demonstrate", "so" not "thereby".
• Simple connectors only: and, but, so, because, when, if, however, which means, for example. Avoid "whereby", "insofar as", "notwithstanding", "albeit".
• No idioms, no decorative metaphor, no phrasal verbs where a plain verb exists.
• Don't stack subordinate clauses. Split into two sentences instead.

Exempt from the level cap. These are not "advanced English" and must not be simplified away:

• Technical terms, jargon, and proper nouns (LLM, non-deterministic, RLHF, DDIM, Anthropic, ContentRouter).
• Code, commands, file paths, API and model names.
• Exact numbers, units, dataset and benchmark names.
• Verbatim quoted text from a source.

CEFR measures general language, not domain vocabulary. A sentence can be A2 in grammar and fully technical in content. That is the target.

Precision outranks the level. If a simpler sentence would change the meaning, weaken a hedge, or drop a caveat, keep the harder construction and move on. Never trade accuracy for reading level.

This covers every beat: hook, turn, substance bullets, reasoning, and close. The aphoristic close and its antithesis structure are still wanted — an em-dash contrast is a rhetorical device, not grammatical complexity. Just keep each half of it short and plain.

On Arabic posts, apply the fusha rules already in the Language section instead. CEFR applies to the English output only.

Length & hashtags

Target 100–120 words, plus 2–3 hashtags on their own line at the end. This is the standard output for this skill. Fit the six-part structure into that budget by compressing every section, not by dropping one:

• Hook: 1 sentence.
• Turn: 1 sentence.
• Substance: 2–4 short bullets (or one dense sentence if bullets don't fit) — name the dimensions/features, don't explain each one.
• Reasoning: 1 sentence. This is the section most likely to get cut under length pressure — don't cut it. A post that hits 110 words but drops the design-philosophy line is worse than one that runs slightly long but keeps it.
• Close: 1 sentence, echoing the hook.
• Hashtags: 2–3, specific to the content — not generic filler like #innovation or #tech. Mix a broad field tag with a specific one, e.g. #AI #CodeReview #SoftwareEngineering. Keep hashtags in English even on Arabic posts, consistent with keeping English tech terms untranslated.

If the user gives a different explicit length — a real X/Twitter character limit (~280 chars), "make it longer," or a request for the full narrative version — follow that instead. The user's latest explicit instruction always overrides this default, and skip hashtags if they've asked for a hard character limit that can't fit them.

Language

• Default to English unless the user writes in Arabic or asks for it.
• Arabic: use standard/formal Arabic (fusha), not Egyptian ammiya, unless told otherwise. Keep English tech terms untranslated (Agentic AI, Skill, Claude, etc.). Same hook → turn → substance → reasoning → close shape applies.
• If the user wants an Arabic LinkedIn post (not a tweet) built around a research paper, linkedin-arabic-science-post is the right skill for that longer, LinkedIn-paced format — this skill only covers the tweet-length case, regardless of subject matter.
• If the user actually wants a LinkedIn post rather than a tweet, don't use this skill's word cap or hashtag rule for it — LinkedIn posts run longer with no hashtag convention. Confirm which platform the user means if it's ambiguous.

Example (~110 words + hashtags)

This is the calibration example — match this shape, register, and length:

Most agent failures aren't reasoning failures — they're state failures. An agent forgets a decision, second-guesses itself mid-task, or drifts from the plan with nothing to catch it.

To fix this, here's a Sequential Orchestrator: a single-model framework that runs execution in strict sequence, gated by mandatory checkpoints.

🔨 Builder mode commits to an approach 🔍 Critic mode reviews it against the original intent 📍 A fixed trace vocabulary keeps the reasoning legible after the fact

Checkpoints are made non-optional on purpose — a step an agent can skip, it eventually skips exactly when it matters.

Reliable agents aren't the best reasoners. They're the ones that know when to stop and check their own work.

#AgenticAI #LLM #AIEngineering

Note how the close ("the ones that know when to stop and check their own work") answers the open ("aren't reasoning failures, they're state failures") — that mirroring, at tweet length, is the tell of a well-formed post under this skill.

Example, someone else's work (~105 words + hashtags)

Same shape, third-person attribution throughout the substance and reasoning:

Most claims about model scale assume bigger always means better. The data rarely backs that up cleanly.

A new paper from a DeepMind team tests that assumption directly, across benchmark families rather than a single leaderboard.

📊 Gains past 30B parameters flatten on reasoning tasks 📊 They keep climbing on retrieval-heavy tasks 🔍 The split holds across three model families, not just one

What's notable is that the authors controlled for training data volume, not just parameter count, so the split isn't just an artifact of more tokens.

Scale isn't one lever. It's several, and they don't move together.

#MachineLearning #ScalingLaws #DeepLearning

Anti-patterns — don't do these

• Opening with the artifact/finding ("Here's a skill that..." / "A new paper shows...") instead of the field-level problem.
• Using "I built a..." as the Turn sentence instead of "Here's..." — the bridge should present the artifact, not lead with a first-person construction verb.
• For the user's own builds: third-person/descriptive voice ("it evaluates," "it doesn't just flag") instead of first-person ownership voice ("I designed it to evaluate").
• For someone else's work: first-person voice ("I found," "I built") as if the user did the research or built the thing — attribution has to stay third-person (the authors, the team) outside of an explicitly marked reflection.
• Closing on a punchy feature-specific one-liner instead of echoing the opening hook's theme.
• Compressing hard to hit a stated word-count ask at the cost of dropping the reasoning/philosophy sentence — that sentence is the one thing a generic summary can't fake.
• Listing features without explaining the design decision behind at least one of them.
• Running past 120 words "to fit everything in" instead of compressing the substance section — the reasoning and close matter more than feature completeness.
• Generic or filler hashtags (#innovation, #tech, #AI alone with nothing specific) instead of tags tied to the actual content.
• Packing the hook or close into one long clause chain to sound profound — the antithesis works better in two short sentences than one long one.
• Writing a LinkedIn-length post (200+ words, multiple paragraphs, no hashtags) when the user asked for a tweet — the platforms have different pacing; don't reuse LinkedIn habits here just because the underlying narrative shape is similar.