sergebulaev/linkedin-skills is a 12-skill, MIT-licensed bundle that lets Claude Code and Codex draft, audit, and optionally publish LinkedIn posts and comments from a terminal. It fits a small founder-led or marketing team already running one of those agents and wanting an approval-first workflow. It is not a managed service: publishing depends on third-party APIs you configure, secure, and maintain. This review is based on the repository and its release notes, not an installation.

the buyer problem: approving AI-written posts without giving up control

A founder or operations lead who wants a steadier LinkedIn presence rarely lacks tools. A tool that writes in a generic voice, schedules something the company would not sign, or quietly holds credentials to a business account is the bigger concern. The decision here is narrow and practical: adopt this open-source skill bundle, commission something custom, or stay manual. This article is written for that reader at the evaluating stage, before any key is connected or any post is scheduled. For context on demand, Google Trends recorded “claude” at 2,000+ searches in the UK and “anthropic” at 1,000+ in the US in late September 2026; those are demand signals only and say nothing about this project’s quality.

key facts at a glance

what the bundle actually contains

The README lists 12 skills: Post Writer, Comment Drafter, Reply Handler, Post Audit, Humanizer, Hook Extractor, Content Planner, Engagement Monitor, Profile Optimizer, Employee Advocacy, Repurposer, and Interviewer. They fall into a write side that drafts posts, comments, and replies; a read side that pulls post bodies, comment threads, and engagers through Apify actors; and an optional publish side that schedules and posts through Publora. The README states every skill shows a draft first and waits for approval.

One documentation inconsistency is worth flagging. The repository’s own description text still says “11 Claude Code and Codex skills” while the README and its skill table say 12. A v1.1.14 note says a stale “11” line in the README was corrected in that release, so the description field is simply behind the code. Treat it as lag in the listing, not a functional defect.

maintenance signals from the recent releases

The project ships often and documents its own defects, which matters more to a buyer than a feature list. The maintainers’ notes between 15 and 29 September 2026 describe fixes to real failure modes:

• v1.1.11 (2026-09-15): reworked how the skills tell a user that a publishing layer is not connected, so the message appears once and only when the request actually needed it.
• v1.1.12 (2026-09-15): addressed a case where a filled Voice Profile could be committed to git. The notes state the sync no longer copies filled templates and that check_no_secrets.py now fails when a tracked template is marked filled: yes. The maintainers report 99 offline tests at this release.
• v1.1.13 (2026-09-18): added lib.unpublish() and stated plainly that the name oversells it. The call cancels scheduled posts but cannot remove a published one; the notes quote a 409 response with the code POST_IS_PUBLISHED from the upstream publishing API. The maintainers report 102 offline tests.
• v1.1.14 (2026-09-23): added eight offline tests for the image client and, per the notes, moved the suite from 102 to 110 tests.
• v1.1.15 (2026-09-29): fixed a Profile Optimizer input that asked for a profile URL the read layer cannot open, and an AttributeError in the voice-profile sub-skill where a helper was called from the wrong namespace. The maintainers report 113 tests.

The test counts above are the maintainers’ own figures; they were not reproduced for this review. Two of those releases fixed user-visible defects in already-published versions, which is the useful signal: a bundle like this can install cleanly and still behave wrong until the specific bug you care about is patched.

deployment and security checks before production

The bundle is local code plus optional external services, so most production risk sits in configuration rather than in the skills. Before a team connects anything, these checks follow directly from the documentation:

1. Know where credentials live. Reading uses an APIFY_TOKEN, publishing uses a PUBLORA_API_KEY plus a LinkedIn platform id, and images use a PIXFARO_TOKEN, all read from a local .env. The README warns that some checks read only .env and the shell, so a connector configured elsewhere can look missing while actually working.
2. Keep secrets out of git. The v1.1.12 note is the one to act on: a filled Voice Profile holds client names, ICP details, and numbers, and because it is not a credential a scanner would not flag it. Confirm the tracked templates are blank and add filled copies to .gitignore before the first commit.
3. Choose one publish route. The README offers an authorized connector with no key on disk, or an API key in .env. Pick deliberately; the connector is the smaller secret-management surface.
4. Check the ceilings. The publishing layer’s free tier is documented at 15 posts per month, and reading is billed per 1,000 results. Model your real cadence against those limits before promising a daily schedule.
5. Plan for irreversibility. Treat scheduled and published as different states. The code refuses to delete a published post, and a live post comes down manually on LinkedIn.

limitations and what this will not solve

This is a content-operations layer, not a strategy or a managed service. It will not make LinkedIn content good by itself, and several skills depend on a filled voice profile and a Story Bank before they have anything specific to say. Reading skills fall back to asking you to paste text when no token is connected, which keeps them usable but limits automation. The maintainers also spell out at least one hard capability limit: the Profile Optimizer cannot open a profile from a URL, so it asks for pasted sections. Anyone expecting a one-click feed analysis should read that before buying in.

evaluation questions and alternatives

Before adopting the bundle, or choosing a managed scheduler or an agency instead, answer these in writing:

• Who approves each post, and is that approval enforced by the tool or only by habit?
• Where do the Apify, Publora, and Pixfaro credentials live, and who can rotate them?
• What is the monthly cost at your real posting and reading volume?
• What is the revert path when a scheduled post is wrong, and who owns a post that is already live?
• Who maintains the integration when an upstream API changes a response code or a plan limit?

The alternatives are straightforward. A managed scheduling tool removes the maintenance burden but rarely gives you this much control over drafting and auditing. A ghostwriting or agency arrangement provides voice and judgment but not code you can inspect. A custom internal pipeline costs more up front but fits unusual approval or compliance rules. The bundle sits between those options: it gives you source you can read and adapt, and in exchange you own its upkeep.

who should use it, and who should not

Consider it if you already run Claude Code or Codex, want a reviewable approval-first workflow, and have someone comfortable managing a Python environment and a .env file. The MIT license and active release cadence make it reasonable to inspect, fork, or extend. A solo founder with a technical streak, or a small marketing team with a developer on call, is the clearest fit.

Look elsewhere if no one on the team wants to own dependency updates, secret rotation, and upstream API changes. It is also a poor fit if your organization requires vendor support, formal SLAs, or a hosted dashboard for approvals, since this is self-managed code that depends on third-party services for reading and publishing. And if the actual problem is messaging rather than tooling, no bundle will fix it.

verdict

For a team already inside the Claude Code or Codex workflow, sergebulaev/linkedin-skills is a credible, actively maintained starting point, and its release notes are unusually candid about what each version fixed and what it still cannot do. The honest caveats are the same ones that apply to any self-managed agent bundle: you own the credentials, the secret hygiene, the publishing limits, and the upgrade path, and two recent releases show real defects that shipped before being fixed. Adopt it deliberately, with a named owner and a documented approval step, and it is worth evaluating; adopt it as a set-and-forget service and it will create exactly the kind of risk it was meant to reduce.

how XP812 can help you wire this up safely

If you want an approval-first LinkedIn workflow but do not want to personally own an open-source bundle’s upgrades and secret handling, I can help you scope the integration. What I would need first is a look at your current setup: which agent runtime you use, how credentials are stored today, and the publishing or scheduling account the posts would reach, plus a shortlist of anything that must never go out automatically. From there the work usually takes one of two shapes: hardening the existing bundle so credentials, backups, and the revert path are explicit, or building a thin internal service around the parts you actually use. That is a scoping conversation rather than a promise of a particular result, because the shape depends on your environment and on what the upstream APIs allow. You can review custom software development and system integration or start a conversation about your setup.

sources

• sergebulaev/linkedin-skills repository and README
• Release v1.1.15 (2026-09-29)
• Release v1.1.13 (2026-09-18)
• Release v1.1.12 (2026-09-15)