write skill

Write: edit the person's material into a post

You are not generating a post about a topic. You are editing something the person already knows into the shape a feed rewards, in their voice. That distinction is what keeps the post out of LinkedIn's generic-AI demotion and what makes a reader stop.

1. Inputs, and what to do if one is missing

• A story with a receipt (stories/<slug>.md). Missing → run /open-stanley:mine or ask for the material ("tell me what happened, two minutes, voice note is fine"). Don't draft from a topic. status: needs-confirmation means the lesson rests on an unverified summary line: ask the human first, don't draft. origin: ai-suggested means the idea came from an AI's advice the human followed: the draft credits that or is about what they did with it, never "here's what I figured out".
• The claim, from the human. One sentence of what they believe about the story. Missing → ask exactly one question, or, if the user said "just go", use the story's own quoted line as the claim and mark the draft unclaimed so the audit and the handover say it needs their sentence.
• Voice (voice.md exemplars + yaml). Missing → onboarding.
• Platform and whether it also goes to X (default: both, same time, X as thread if no Premium; from strategy.md).

1b. Platform, language and mode from setup

Read platforms:, languages: and drafting: in strategy.md. Write for the platform the draft is for, in that platform's shape: LinkedIn the full story; X one long post or a thread; Threads short and conversational, a stream of thought is fine; an Instagram or TikTok caption that carries the video in its first line; Substack Notes like a short post. A second language is written in that language from the story, in the voice of that language's exemplars in voice.md, never translated line by line. With drafting: questions, do not write the post: give the situation in two lines, the one question that makes it theirs, and two or three angles, then audit what they write back.

2. Drafting

Read 10–15 exemplars from voice.md right before writing; match their sentence rhythm, vocabulary level, punctuation, and how they open and close. Then apply its Change list and the open experiments in strategy.md: the person's current voice is where they start, and most people use this plugin because their posts are not read yet. Keep their words and what they know; change the habits the evidence says hold them back, one experiment at a time, and tag the draft with the arm it takes. If the user asked for a shape ("PG-style", "like Dharmesh's episode posts") or the lane names a reference creator, read that creator's entry in shapes/ (vault) or skills/study/references/creators-latest.md (then creators-2026-09.md for creators not in it) and borrow the moves only; every word still comes from the story and the voice. Then:

1. Open on the event or the claim, in the first person. Posts opening with "I…" ran +8–25% over "You should…" across 226K posts; opening with a question ran −5%; hot-take framing had the worst risk-reward of any pattern; steady positive tone beat tension→resolution arcs. (skills/stanley/references/research-linkedin-2026.md.) "Ran a quick experiment with my team this weekend." "Someone tried to hack my GSuite today." "One of the debates I've had for 15 years and mostly lost is…" No framing sentence, no rhetorical question, no "In today's…". The first ~140 characters are all LinkedIn shows; make them a complete thought that a founder scrolling at speed would stop on.

   The two-sentence test. A real user read the first two sentences of each weekly draft and stopped on two of three. Before handover, read only the first two sentences and ask: is there something surprising, funny or personal in them? A flat operational scene fails ("A few weeks ago I saw our agent keep asking a customer's team for information they already had."), and so does context before the point. What passed: an experiment told result first ("We fine-tuned a model to write without slop. It still sounded like slop."), and a hook that puts the reader's own experience first ("Do models sound like slop to you?"). Rewrite until the two sentences pass, or say in the handover that they do not and why.

   Three more things the same user rejected, which apply to anyone: never frame a post as the author being smarter than the model, a colleague or the reader (it reads as arrogant even when it is a joke); a personal tool trick ("I make Claude drive ChatGPT's deep research") is not a post for a general audience unless the lane is about tools; in an experiment post, put the links (the model, the paper) in the first comment, not the body.

2. Say what happened with the specifics only this person has. The number, the name (if sensitivity: ok), the date, the thing that went wrong. Quote the source where its words are better than yours.

3. The claim, once, plainly. Not restated three ways. If the story has two lessons, that's two posts.

4. End on the last real sentence, or, if this person does it (check voice.md), one specific open question that a peer could actually answer. Never a summary, never "Agree?", never "What do you think?".

5. Length: LinkedIn 1,300–1,900 characters for a story; 400–900 for a single claim; aphorisms are fine when the exemplars show them. Paragraphs of 1–3 sentences, not one line each. Zero hashtags, no links in the body (first comment if needed).

6. X: the same post as a single long post if the user has Premium; otherwise a thread of 3–7 tweets separated by ---, where tweet 1 stands alone as a post and the last tweet carries the claim, not "that's a wrap". Links go in the first reply. references/platforms.md has the rest.

Tell it from the user's point of view: when agents or models did the work, the user asked, assigned or reviewed ("I asked Opus to write the design doc"), never the model acting alone. Lead with the diagnosis, not the flat anecdote: why it happened and whether it is a one-off or a pattern is the angle. Before handover, compare the draft's core point with the user's posts from the last six weeks by theme, not wording; the audit's overlap check sees only words, and two posts that make the same point from different examples read as repetition to the people who follow them.

Two checks the audit cannot make for you. Pronouns: read every "it", "this", "they" and ask what it points at; if two nouns could claim it, use the noun. Describe products plainly ("an app that matches people by hobby", not "the platform") because a second-language voice is hurt most when a reader has to guess. Cliffhanger hooks: if the first line is meant to stop at the fold ("The main advice I gave them was"), never write "..." yourself, LinkedIn adds "…more"; count the characters so the cut lands on the cliffhanger (about 205 on desktop), and start the next paragraph with the answer, because a held-back point that is not delivered immediately is the bait pattern readers now skip.

Things that mark a draft as generated and therefore get demoted and skipped: three short sentences in a row; "not X, it's Y"; a rule-of-three list; em dashes (unless the exemplars use them); bolded-term-colon lists; "delve/leverage/robust/pivotal/…"; an editorializing tail ("…, highlighting the need for…"); "experts say"; a closing question addressed to everyone. The audit catches most of these; write so it has nothing to catch.

3. Audit, critic, handover

1. Tag the draft with its lane and shape (opener:, body:, ending: from skills/study/references/shape-vocabulary.md) and, if strategy.md has an open experiment, the variant this post takes (alternate variants post by post). publish records these so stanley-stats can tell you later what worked.
2. Save the draft to drafts/<date>-<slug>.md (git keeps versions; the paid product lost a hook in a rewrite once, don't), and its tags to drafts/<date>-<slug>.meta.json: {"story", "lane", "shape": {opener, body, ending}, "experiment": {name: variant}, "origin", "status": "draft", "image": "<file or empty>"}. The tags travel with the draft so that publish and, for a post that went live outside the plugin, recap can put them in the ledger without guessing (post-add --from-meta).
3. skills/stanley/scripts/stanley-audit drafts/<file> --platform linkedin --vault <vault> [--has-image] (and --platform x for the thread). Fix every BLOCK yourself. Re-run until clean. The landing: line is the 2026 research compressed to eight yes/no items (first person, complete thought before the fold, a named entity early, a number, a question ending, an image, the length band, no links); every no is either fixed or named in the handover with the reason. That line replaces re-reading research-linkedin-2026.md each run; read the file when a no needs its evidence.
4. If the draft is a full post (not a comment), ask the critic agent (agents/critic.md) for its three answers and include them in the handover only if they change something.
5. Render the preview: skills/stanley/scripts/stanley-preview drafts/<file> --platform linkedin --out drafts/<slug>.png --name … --headline … (and --platform x for the thread). The fold line is what gets hooks fixed. The script writes the HTML always and the PNG only where Playwright has a Chromium; on a device without one, render the HTML in the cloud container or screenshot it with the browser tool rather than installing anything into the user's folders. The fold mark is an estimate (about 210 characters on desktop, fewer on a phone); the real test is opening the scheduled post on a phone once.
6. Reach band: skills/stanley/scripts/stanley-stats --vault <vault> --days 365 --predict drafts/<file> [--has-image] prints the p25/median/p75 impressions and engagement of the user's own past posts that share the draft's features (lane, image, first-person hook, a name early, a question ending, length band). Quote the median and the band in one line of the handover ("posts like this did 660–1,270 impressions for you, median 950; your overall median is 1,145"), and say which missing feature would move it to a better set. Under 3 posts with metrics the script says so and you skip the line. It is a band from the ledger, never a forecast; do not round it into a promise.
7. Hand over: the draft and the preview image, then at most three lines: any WARN the human should decide on, the receipts used (story slug + source), and the one question ("this says 2.0 out of 5 — that's from your Sunday message, right?"). Then stop.

4. Revisions

When the user edits or reacts:

• "too long" → cut the setup and the restated claim first, never the specifics.
• "sounds like AI" → find the pattern (usually staccato lines, a tricolon, a wrap-up, or a generic adjective), fix that, and add the pattern to learn/diffs.jsonl via skills/stanley/scripts/stanley-vault diff-add so learn can propose a rule.
• "change the hook to start with X" → keep everything else byte-identical; diff before you send.
• When they paste their own final version, that's the ground truth: store the diff, and use their version for publishing, formatted for X only if they asked.

Every accepted change is logged. Every third recurrence of the same change becomes a proposed rule (see /open-stanley:learn).