Playbook · LinkedIn

Playbook: Run a LinkedIn content system with agents and a human approval gate

Three builders, one pattern: write the rules down once, split the work across single-job agents, and let nothing publish until a person says yes.

Teardowns: 3Stack: Claude CodeHuman approval: every post
Moonshi MohsenRuddin · Paul Iusztin · Doneyli De Jesus Verified Oct 16, 2026 Markdown copy

Who it’s for: founders and solo operators who know they should post on LinkedIn every week and keep not doing it.

Tools these builders use: Claude Code (all three), CLAUDE.md config files and custom skills (Doneyli De Jesus), an idea sheet and a weekly metrics dashboard (Moonshi MohsenRuddin), Opik for tracing and evals and Gemini for grounded search (Paul Iusztin), macOS launchd schedules, Gatus and ntfy for monitoring (Doneyli De Jesus).

The steps

  1. Write the brand rules, audience and pillars down once. Moonshi MohsenRuddin wrote his brand rules, five audience pain points and content pillars a single time. “The system reads them every time for every post.” Doneyli De Jesus did the same with three tiers of CLAUDE.md files and lists “building agents before configuration and skills” as a mistake that gave him inconsistent voice. Sources: Moonshi (teardown, original); Doneyli (teardown, original)

  2. Keep the voice rules in one shared file. Doneyli keeps voice, quality gates and platform formatting in five _shared/ files that all 7 drafting skills reference, so one edit reaches every skill. He found separate copies of the voice rules drifted apart. He also keeps the main CLAUDE.md under 300 lines, after a 2,000-line version left less room for the work and drafts got shorter. Source: Doneyli (teardown, original)

  3. Give each agent one job. Moonshi uses four: a strategist writes briefs, a writer drafts in his voice, an editor reviews against performance data, and an analyst reads the numbers. Source: Moonshi (teardown, original)

  4. Research before writing, then loop write, review, edit. Paul Iusztin’s research agent saves source-backed notes to research.md. A writing workflow drafts from that file plus guideline.md and runs “Generate → review → edit → repeat”. Each pass checks for weak hooks, AI slop, structure issues, voice drift and missing grounding, and every intermediate version is saved. Source: Paul (teardown, original)

  5. Put a hard gate before anything is produced or published. Doneyli’s producer agent reads git history and exits with “SKIP: Calendar unchanged. Waiting for human review.” if nobody has edited the weekly calendar since the planner ran. Moonshi runs every draft through an “adversarial editor gate”, then it waits for him or his colleague Mark. “No post ships without a person saying yes.” Sources: Doneyli (teardown, original); Moonshi (teardown, original)

  6. Schedule only approved posts. Moonshi’s pipeline is fixed: idea → draft → review → approved → scheduled → published, with a skill that schedules approved posts. Source: Moonshi (teardown, original)

  7. Match the model to the job. Doneyli’s fix after an all-Opus first month: Opus for creation and reasoning, Sonnet for extraction and adaptation, Haiku for classification and routing. Source: Doneyli (teardown, original)

  8. Monitor every scheduled run. Each of Doneyli’s agents retries up to 3 times with backoff, reports to Gatus and sends failure alerts through ntfy. Paul traces calls, cost and eval results in Opik: “if you can’t observe your agents, you can’t improve them.” Sources: Doneyli (teardown, original); Paul (teardown, original)

  9. Read the numbers weekly, and read the median. Moonshi pulls metrics each week to refine the next round. He calls the median post (242 → 309, about 1.3x) “the most important number in this whole piece”, even though total monthly reach went from about 2,200 to about 54,000. Source: Moonshi (teardown, original)

Postby’s suggestion (not any one builder’s practice): start with steps 1, 3 and 5. A rules file, one writer agent and a hard approval gate are the parts all three systems share in some form. Add research loops, scheduling and monitoring once you are approving drafts every week.

Human approval points

  • Moonshi: every post, by him or his colleague Mark, after the editor gate.
  • Doneyli: his wife edits the weekly calendar before the producer will run, and reviews drafts (about 2-3 hours a week). The source doesn’t say who presses publish.
  • Paul: the post describes saved intermediate versions for inspection but does not describe an approval step.

Common failure points (as the builders report them)

  • Agents built before config and skills gave inconsistent voice (Doneyli).
  • An oversized CLAUDE.md shortened drafts (Doneyli).
  • Copied voice rules drifted apart (Doneyli).
  • An agent failed silently for a week and analytics went stale (Doneyli).
  • Headline reach can hide a flat median. Moonshi says part of his lift was recovery from an algorithm dip.

Caveats carried over

  • Moonshi: the record post appears as both 26,874 and 25,560 impressions in his source. Unverified which is final. Company and founder account, and the post promotes his consultancy.
  • Paul: no outputs or results shown; the post promotes a course. Built by more than one person (“we built”).
  • Doneyli: paid newsletter issue; his wife and her business aren’t named, so output can’t be checked. No engagement or revenue results. X: Unverified.

Examples

Get one teardown a week.

Same format, a new operator every issue. Double opt-in.