li-post: LinkedIn Posts with a Review Panel

What it does

li-post turns a domain, or a single idea, into a finished LinkedIn post, and it gets there through a defined chain of checks. A scout finds what is happening, a writer drafts from verified facts, a panel of reviewers tries to break the draft, and nothing goes out until I say “post it”.

In short. li-post is a small editorial desk: a researcher, a writer, a fact-checker, a compliance reader and an editor, with me as the only person who can publish.

The problem

I have knowledge worth sharing and no rhythm, no time and no answer to the blank page. A chatbot asked to “write a LinkedIn post” produces something generic, and I still have to check every fact myself.

The risks are specific:

• A wrong number that undoes months of trust.
• A claim nobody can verify, or one that says more than its source.
• An image used without permission, or a remark about a named company that is not fair comment.
• An opinion that is not mine. This worried me most. I did not want a system that invents a view and attaches my name to it.

What it produced

• 18 posts between 12 September and 3 November 2026, of which 11 were published and 7 remain drafts.
• 16 text posts and 2 carousels.
• 17 scouting runs, each saved as a report.
• 16 review files, each the written record of a debate.

The number. 18 posts, 11 published, and nothing published without my explicit instruction.

How it is built

li-post is a Claude Code skill: a folder of instructions, reference files, templates and Python scripts. The skill is the writer and the chair. Four named agents work for it, and scripts handle everything that should be counted rather than judged.

The four agents

Agent	Job	Tools	Can block a post?
trend-scout	Finds what happened in a domain over the last 10 days and returns 3 ranked ideas	Web search, web fetch	Not a reviewer
li-fact-check	Checks every number, date, name, quote and cause against its source	Files, web pages, search	Yes
li-compliance	Checks copyright, defamation, confidentiality, privacy, regulated advice, platform policy	Files, web pages	Yes
li-editor	Reads as the target reader; at most 5 line edits for hook, clarity and voice	Files only	No, advises only

All four run on Claude Sonnet. None of the three reviewers can edit anything. The writer is not a fifth agent. It is the skill itself, which keeps the drafting and the final decisions in one place.

What scripts do instead of agents

I gave anything countable to a Python script, because a script gives the same answer every time, for free, in under a second.

• The linter. It fails any em dash, engagement bait, blank placeholder, fake bold text, or text over 3,000 characters, and checks every carousel slide.
• The repeat check. It scores a new idea from 0 to 100 against every post I have written and every past post I imported. A score of 50 or more skips the idea; 20 to 49 needs a new angle.
• The scout check. An idea passes only with at least 2 dated facts inside the window from at least 2 different sites, and one from a primary or established source.
• The verdict. A script derives approved, approved with edits or blocked from the reviewers’ structured answers, so the chair cannot talk itself into a pass.
• The publish gate. publish-text refuses a post that is not ready, not approved, fails lint or is already posted.

Facts before views

A file called views.md holds my domains, my audience and an off-limits list. It also has a place for my opinions, written in my words. The rules around it matter more than the file.

• The scout never sees my views. It reports what happened, never what would support a position.
• A view goes in only after the facts are verified, only where the evidence is consistent with it, and always labelled as my opinion.
• When evidence contradicts a view, the post follows the evidence.
• The system never writes a view I did not give.

I should be candid: at the time of writing, that file holds domains and an audience but no recorded opinions of mine. There is also no separate voice.md. The skill reads one if it exists, so “in my voice” currently rests on the craft rules, the editor’s voice check and my own review.

A run, step by step

Here is one real cycle, from 3 November 2026. The numbered steps follow the diagram above.

Finding and verifying the idea

1. I start it with a domain, here “Frontier research and updates”. It can also run from a schedule, though a scheduled run can draft but never publish.
2. The scout searches. It took the window 20 October to 3 November and returned ranked ideas under a hard ceiling of 20 searches and 12 page fetches.
3. A script checks the ideas. The top one, a mid-tier model sitting at the highest cyber-risk threshold, passed the sourcing rules.
4. The writer verifies the facts. It re-opened the sources behind the numbers the post would lean on, and drops any figure it cannot confirm.
5. The repeat check runs against all 18 posts and my imported history.

Writing and linting

6. The writer drafts. Body, turn and takeaway first, then five hooks in at least three patterns. This one used a before-and-after structure and came to 1,396 characters.
7. The linter runs. Every error is fixed before review, and the character count is stamped into the file.

The panel

8. Three reviewers read it at once. They work independently and do not see each other’s findings.

  Round 1: three independent reviews
        |
        v
  Round 2: only if two findings clash
        |
        v
  Chair rules on every finding,
  applies the accepted edits
        |
        v
  Round 3: re-check changed lines
        |
        v
  Script writes the verdict

9. A script writes the verdict. For this post it was approved with edits: three rounds, six edits applied, no open blockers.

Saving and publishing

10. The post is saved with its sources, scout report and debate file, and three index files are rebuilt.
11. I say “post it”. Claude in Chrome opens LinkedIn, types the text with real keystrokes, checks that the composer matches the file exactly, clicks Post and checks the live post line by line. The post went out the same day.

The controls

The design assumes the model will sometimes be wrong and builds the checks around that.

The control. A post can reach LinkedIn only through the Publish step, only when I ask for it in chat, and only if a script accepts it.

What cannot happen without me

• Nothing posts on its own. A request covers only the posts it names, and a scheduled or unattended run never publishes.
• No page or file can instruct a publish. A web page or message that tells the agent to post is ignored.
• No post is ready without a verdict. An approved or approved-with-edits verdict is required, and forcing past it is something I have told the skill never to do.
• No invented specifics. No made-up experiences, test results, numbers, quotes or names.

What blocks a post

Severity	Meaning	Who can raise it
Block	The post cannot go out as written	Fact-check, compliance
Fix	Should change before posting	All three
Suggest	Optional improvement	All three

The chair’s rules are strict. Every block must be fixed. Accuracy and compliance beat style, so an editor’s rewrite that adds an unsourced fact is declined. Every decision is recorded, including the suggestions I turned down.

A blocked post gets at most 2 attempts to clear. After that it stays a draft and the reason is reported.

What the panel does not claim

• Compliance flags risk and is not legal advice. When it marks “needs human review”, I should ask a lawyer.
• The fact-checker confirms only what it can open. Pages that block automated reading are checked through other outlets or flagged.

What it cost and what it produced

Cost

I have not recorded token cost for li-post. What I can state is the shape of it. A review takes about 2 to 4 minutes and uses three Sonnet runs, plus re-checks. The scout runs a bounded number of searches. The repeat check, linter and verdict cost nothing because they are scripts.

What it cost. I do not have a dollar figure for this system, and I will not guess one.

Output

• 18 posts, 11 published, over about seven weeks.
• 16 reviews, every one ending as approved with edits, with 3 rounds each and between 3 and 12 edits applied.
• Two posts never reviewed. Two of the 7 drafts date from 12 September, the day the panel was built, and carry no review.

What it did not produce

The number. No engagement figures are recorded. I cannot report reach, comments or any professional outcome from these posts, and I will not imply one.

What worked and what did not

What worked

• The review panel caught real things. By my count of the saved review files, the panel raised roughly 55 fix-level findings across 16 reviews. The compliance reviewer once flagged that carrying my institution’s name on a carousel could read as an institutional endorsement. I added “Views are my own.”
• Independent reviewers beat one checker. Each judges the post without being swayed by the others, with tools matched to the job.
• Scripts for anything countable. Character counts, repeat scores and verdicts never drifted.
• The repeat check. A script that compares an idea with 18 posts beats an agent re-reading my archive on every run.
• Facts before views. Keeping the scout blind to my opinions removed the main route to a post that argues first and cites later.

Where it failed

Where it failed. The panel almost never blocks. A reviewer that always passes tells me less than it seems to.

• Every review ended the same way. All 16 approved with edits. By my count only about one block-level finding was ever raised. Either the writer is already conservative, or the reviewers are lenient, and the record cannot tell me which.
• The editor cannot say no. It advises only, so a post that is accurate and dull still passes.
• A reviewer can only check what it can open. Blocked pages are checked indirectly.
• No feedback loop. With no engagement data, the system cannot learn which hooks and structures work.
• My voice is thinly specified. No voice.md and no recorded views means the writer leans on generic craft rules.
• Seven drafts remain unposted, five of them reviewed and approved with edits.

The small-model experiment

I tried the writing step on a local model, Qwen3-8B through Ollama, using the same craft files and a brief of verified facts. The aim was to see whether the cheap step could leave the cloud.

Setting	Time	Output tokens	Length
Thinking off	75.7 s	266	781 characters
Thinking on	209.4 s	678	747 characters

Both drafts passed the check that every number appears in the brief. Both fell short of my 900-character target and lacked the opinion label.

The faster draft also misread its source. It framed a 9% and a 74% survey figure as “before AI” and “now”, when they were two different measures. Every number was in the brief, so the number check passed, yet the sense was wrong. The thinking-on draft kept the distinction.

My conclusion is narrow. The local model is not the production path, and a number check is not a meaning check. That is exactly why a fact-checking reviewer reads the post against its source.

What I would build differently

• Record engagement. Without it the system optimises nothing. A weekly pull of reach and comments per post would let the scout and writer learn.
• Test the reviewers against known errors. I would plant a wrong number and an unfair claim in a draft and check that the panel catches them, so I know the false-negative rate instead of assuming it.
• Write a real voice file. Samples of my posts, and my own words on a few recurring views, would replace the generic craft rules.
• Let the editor block on voice. Accuracy and risk should block, but a post that does not sound like me should also stop.
• Cap the draft backlog. A rule that the scout pauses when 5 drafts are waiting would force decisions.

I would keep the core design: scripts for counting, agents for judgement, a human for publishing.