Building a ChatGPT-Driven LinkedIn Publishing System: From WordPress Articles to Human-Approved, Analytics-Driven Posts

By INGOAMPT · Developer architecture and implementation guide · Updated August 2026

Most “AI LinkedIn automation” demos stop at the easy part: give an LLM a topic, generate a post, and schedule it. A more useful engineering problem is different: can we build a system in which ChatGPT understands our existing technical articles, learns from our own LinkedIn performance, proposes better content over time, asks for human approval only at the final boundary, publishes through LinkedIn’s official API, and then feeds the real result back into the next decision?

The answer is yes. The interesting part is that we do not need to train a bespoke “viral LinkedIn model”. ChatGPT can remain the reasoning and writing layer, while WordPress supplies source material, a private GitHub repository contains the application, MCP exposes controlled tools to ChatGPT, LinkedIn’s official APIs provide publishing and analytics, and a small database provides memory. LinkedIn officially exposes w_member_social for posting on behalf of an authenticated member, while r_member_postAnalytics can provide member-post reporting including impressions, reach, reactions, comments, reshares, saves, sends, link clicks, followers gained from content and profile views driven by content. [1]

Executive summary

At INGOAMPT, we would build the core application independently of MCP and then expose its safe operations as MCP tools. GitHub stores and versions the source code; it is not the automation engine itself. MCP is the controlled bridge between ChatGPT and our backend. LinkedIn OAuth is the permission mechanism. WordPress is the content source. A database stores what was published and what happened afterwards.

This distinction matters because MCP is an interface, not the business logic. If ChatGPT’s MCP product experience changes, the application should still work via the OpenAI Responses API, a CLI, an HTTP endpoint or a scheduled worker. OpenAI currently documents remote MCP support in the Responses API, including remote servers reachable through Streamable HTTP or HTTP/SSE. OpenAI also documents full MCP developer-mode write/modify actions in ChatGPT as a beta capability for Business and Enterprise/Edu workspaces; MCP calls in the API can be subject to approval controls. [2]

The minimum useful system is therefore:

The most difficult dependency is not ChatGPT. It is LinkedIn API access. Self-service “Share on LinkedIn” provides w_member_social, but the deeper Community Management capabilities used for member analytics are vetted and not simply available to every new application. LinkedIn documents Development-tier review requirements such as an approved use case, verified business identity/domain and app verification; Standard-tier review adds requirements including a privacy policy and a screen recording of the application. [3]

What we are building and why

The objective should not be phrased as “build a bot that makes viral posts”. Virality cannot be guaranteed by an LLM, MCP server or posting schedule. A technically defensible objective is:

Use our own content and our own historical performance data to increase the expected quality, relevance and business value of future LinkedIn posts, while keeping a human as the final publisher.

That changes the architecture substantially. Instead of this:

topic → AI → post → publish 

we build:

WordPress corpus + historical LinkedIn performance + recent publishing history + business objective ↓ candidate article selection ↓ several content strategies ↓ several drafts ↓ factual + style + repetition checks ↓ ranking/scoring ↓ best candidate ↓ human approval ↓ LinkedIn ↓ real performance ↓ database ↺ next generation cycle 

This is closer to a recommendation-and-feedback system than to model training. There is usually no need to fine-tune an LLM during the MVP. Store structured historical evidence and inject the relevant observations into the generation context. Later, once there are enough observations, statistical models can predict which topic, format or hook is likely to perform better for a particular audience.

LinkedIn’s current member-post analytics make this considerably more interesting than it used to be. The memberCreatorPostAnalytics API supports single-post and aggregated analytics, and its documented metrics now include IMPRESSION, MEMBERS_REACHED, REACTION, COMMENT, RESHARE, POST_SAVE, POST_SEND, LINK_CLICKS, FOLLOWER_GAINED_FROM_CONTENT and PROFILE_VIEW_FROM_CONTENT. [4]

That means a developer-focused system can optimise for something more meaningful than “likes”. An INGOAMPT article intended to drive developers to a tutorial might prioritise link clicks and saves. A thought-leadership article might optimise for comments, profile views and followers gained. A product launch might optimise for link clicks and then use website-side attribution to measure trial registrations or sales.

There is evidence that systematic publishing can produce genuine audience growth, although this must not be confused with proof that AI automation causes growth. Buffer’s Tamilore Oladipo reports growing to more than 22,000 LinkedIn followers over roughly six years of consistent publishing. In another first-person case study, Sweta Sharma reports rebuilding from zero to roughly 4,500 followers and 416,000 impressions in five months after deliberately restructuring her content strategy. These examples support the value of consistent, intentional publishing; they do not establish that an AI or MCP system was responsible for the growth. [5]

That distinction is central to the engineering philosophy of this project: automation should improve consistency, experimentation, measurement and reuse of knowledge — not manufacture fake engagement.

Architecture: ChatGPT, MCP, GitHub, LinkedIn and WordPress

Why WordPress? WordPress already exposes structured content through its REST API. A public post collection can be retrieved through /wp-json/wp/v2/posts; authenticated POST requests to the same resource can create posts. Public content is generally available without authentication, while protected/private content requires authentication. WordPress has supported Application Passwords for remote REST authentication since version 5.6. [6]

For this LinkedIn system, WordPress should normally be read-only: retrieve article title, canonical URL, publication date, excerpt, categories, body and perhaps featured-media metadata. There is no reason to grant the LinkedIn agent WordPress write access unless a separate editorial workflow genuinely needs it.

Why GitHub? Keep the application in a private repository initially. GitHub gives us history, pull requests, automated testing and deployment workflows, but API keys and OAuth tokens must not be committed to that repository. GitHub Actions provides encrypted secrets at repository, organisation or environment level, and protected environments can require reviewer approval before environment secrets become available to a job. [7]

Why MCP? Without MCP, the system can already work:

scheduled backend → OpenAI API → draft → approval UI → LinkedIn API 

With MCP, ChatGPT can interact with the same backend conversationally:

User: "Prepare today's strongest developer post."
ChatGPT ↓ list_unused_articles() ↓ get_strategy_snapshot() ↓ get_article() ↓ save_draft()
User reviews draft
User: "Approved."
ChatGPT ↓ publish_approved_draft() 

OpenAI’s Responses API can import tools from a remote MCP server, and OpenAI recommends treating MCP data sharing carefully; MCP tool calls default to approval-oriented behaviour in the API precisely because tools can send data to and take actions through external services. [8]

That gives us a useful design rule: build the house first; MCP is the intercom.

Building the system from scratch

The following implementation sequence avoids tying the project to any single LLM client or automation platform.

1. Create a private repository and domain model. Start with tables such as articles, drafts, published_posts, metric_snapshots, approvals and strategy_observations.
2. Connect WordPress. Import published articles, normalise HTML into clean text and calculate a content hash so an edited article can be detected without creating duplicates. WordPress’s REST API is designed to query and manipulate this content as JSON. [9]
3. Create a LinkedIn Developer application. Enable the self-service Share on LinkedIn product for w_member_social. Use LinkedIn’s three-legged OAuth flow so the actual member grants the application permission. [10]
4. Implement official LinkedIn posting. The current Posts API supports organic text, image, video, document, article, multi-image, poll and celebration content; it replaces the older ugcPosts API. Requests use the versioned REST API headers documented by LinkedIn. [11]
5. Build the drafting service. Supply ChatGPT with article evidence, recent-post history, analytics summary, voice rules and business objective. Generate several candidates rather than one.
6. Implement the server-side approval gate. Never rely on “the prompt says ask first” as the safety mechanism.
7. Expose read and write operations as MCP tools. Keep retrieval tools separate from publishing tools.
8. Add scheduling. Schedulers should generate candidates; they should not bypass approval. Three daily drafting windows can be used without forcing three daily publications.
9. Add analytics. Once the application is approved for r_member_postAnalytics, collect delayed snapshots and feed the evidence into future ranking. [12]
10. Harden and deploy. Add idempotency, retries, audit logging, token rotation, monitoring and tests before trusting the application with a professional identity.

LinkedIn permissions. Do not request every scope you see. For a personal-profile publishing agent, the useful minimum is usually:

LinkedIn’s own permission tables identify w_member_social as a three-legged member permission and r_member_postAnalytics as a Community Management permission. The Posts API separately describes r_member_social as restricted. [13]

OAuth example in Python. The critical security rule is to verify the OAuth state value before exchanging an authorisation code. LinkedIn explicitly recommends this to protect against CSRF. LinkedIn currently documents 60-day access-token lifetimes and notes that programme-level refresh tokens are only available to a limited set of partners, so token lifecycle handling must be designed rather than assumed. [14]

import os import secrets from urllib.parse import urlencode
import requests
CLIENT_ID = os.environ["LINKEDIN_CLIENT_ID"] CLIENT_SECRET = os.environ["LINKEDIN_CLIENT_SECRET"] REDIRECT_URI = os.environ["LINKEDIN_REDIRECT_URI"]
AUTHORIZE_URL = "https://www.linkedin.com/oauth/v2/authorization" TOKEN_URL = "https://www.linkedin.com/oauth/v2/accessToken"
Add r_member_postAnalytics only after LinkedIn has provisioned it.
SCOPES = ["openid", "profile", "w_member_social"]
def build_authorisation_url() -> tuple[str, str]: state = secrets.token_urlsafe(32)
params = {
    "response_type": "code",
    "client_id": CLIENT_ID,
    "redirect_uri": REDIRECT_URI,
    "state": state,
    "scope": " ".join(SCOPES),
}

return f"{AUTHORIZE_URL}?{urlencode(params)}", state
def exchange_code(code: str, returned_state: str, expected_state: str) -> dict: if not secrets.compare_digest(returned_state, expected_state): raise ValueError("OAuth state mismatch")
response = requests.post(
    TOKEN_URL,
    data={
        "grant_type": "authorization_code",
        "code": code,
        "client_id": CLIENT_ID,
        "client_secret": CLIENT_SECRET,
        "redirect_uri": REDIRECT_URI,
    },
    timeout=20,
)
response.raise_for_status()
return response.json()

Posting example in Node.js. LinkedIn’s Posts API uses POST https://api.linkedin.com/rest/posts, and a successful create operation returns the post identifier in the x-restli-id response header. The API requires Linkedin-Version and X-Restli-Protocol-Version: 2.0.0; keeping the marketing API version in configuration avoids hard-coding a version that later sunsets. [11]

export async function publishLinkedInPost(text) { const token = process.env.LINKEDIN_ACCESS_TOKEN; const author = process.env.LINKEDIN_AUTHOR_URN; const apiVersion = process.env.LINKEDIN_API_VERSION;
if (!token || !author || !apiVersion) { throw new Error("LinkedIn configuration is incomplete"); }
const response = await fetch("https://api.linkedin.com/rest/posts", { method: "POST", headers: { Authorization: Bearer ${token}, "Content-Type": "application/json", "Linkedin-Version": apiVersion, "X-Restli-Protocol-Version": "2.0.0", }, body: JSON.stringify({ author, commentary: text, visibility: "PUBLIC", distribution: { feedDistribution: "MAIN_FEED", targetEntities: [], thirdPartyDistributionChannels: [], }, lifecycleState: "PUBLISHED", isReshareDisabledByAuthor: false, }), });
if (!response.ok) { const body = await response.text(); throw new Error(LinkedIn ${response.status}: ${body}); }
return { postUrn: response.headers.get("x-restli-id"), }; } 

For a WordPress article post, do not assume LinkedIn will scrape the URL and construct the card for you. The current Posts API explicitly says API partners should provide article fields themselves; thumbnails use an uploaded image URN. [11]

Our MCP surface should be deliberately small.

list_wordpress_articles( limit: int, unused_only: bool )
get_article( article_id: str )
get_strategy_snapshot( lookback_days: int )
get_post_metrics( linkedin_post_urn: str )
save_draft( article_id: str, content: str, strategy: dict )
publish_approved_draft( draft_id: str )
record_metric_snapshot( linkedin_post_urn: str ) 

Notice what is missing: like_100_posts(), auto_comment_on_people(), scrape_connections() and similar growth-hacking tools. Those are unnecessary for this architecture and can cross directly into the kind of unauthorised automation LinkedIn prohibits. [15]

A ChatGPT-to-MCP call through the OpenAI Responses API can remain surprisingly small. OpenAI’s official API supports a remote MCP server through the built-in mcp tool type and a server_url. [8]

import os from openai import OpenAI
client = OpenAI()
response = client.responses.create( model=os.environ["OPENAI_MODEL"], tools=[ { "type": "mcp", "server_label": "ingoampt_linkedin", "server_url": os.environ["MCP_SERVER_URL"], "allowed_tools": [ "list_wordpress_articles", "get_article", "get_strategy_snapshot", "save_draft", ], } ], input=""" Prepare the strongest next LinkedIn draft.
Use an unused WordPress article. Use our historical LinkedIn performance evidence. Do not publish anything. Save the final candidate as a draft and explain why you selected it. """, )
print(response.output_text) 

The key point is that the drafting call does not even import the publishing tool. The publish capability can be exposed only in the approval transaction. This is safer than giving the model every tool at every stage. OpenAI similarly recommends narrowing the tools made available and using approval controls for actions. [8]

Open-source projects and alternatives

We do not need to start from a blank repository. There are already open-source LinkedIn MCP experiments worth reading. However, they fall into two fundamentally different categories: projects using LinkedIn Developer APIs and OAuth, and projects automating the LinkedIn website or using unofficial data sources. For production, INGOAMPT would strongly prefer the first category because LinkedIn’s User Agreement expressly prohibits scraping and unauthorised automated methods for actions such as creating, liking, commenting on or resharing posts. [15]

GitHub popularity should not be confused with production suitability. The most-starred project in this sample is also the one whose browser-session approach presents the clearest platform-policy risk. Conversely, a tiny official-API-focused repository may be a better foundation for a professional account.

Our practical strategy would therefore be a clean-room combination of ideas rather than blindly deploying one repository: take the small official-OAuth posting patterns from projects such as FilippTrigub’s, study the remote MCP/OAuth structure in fredericbarthelet and jordanburke, borrow the draft/analytics data-model ideas from southleft, then implement our own approval and analytics services against LinkedIn’s current official documentation.

There are also several alternatives to owning the full integration:

The existence of these projects and products answers an important question: you are not the first person to build AI-assisted LinkedIn publishing. What remains interesting is building a system around your own technical corpus + your own outcome data + ChatGPT + controlled approval, rather than cloning a generic ghost-writing product.

Analytics, approval and the feedback loop

The analytics loop is the part that turns a content generator into an engineering system.

Article A ↓ Strategy: engineering story ↓ Post A ↓ 24-hour metrics ├── 18,400 impressions ├── 112 reactions ├── 39 comments ├── 64 saves ├── 128 link clicks └── 23 followers gained ↓ feature store
Article B ↓ Strategy: generic summary ↓ Post B ↓ 24-hour metrics ├── 4,900 impressions ├── 41 reactions ├── 5 comments ├── 8 saves ├── 17 link clicks └── 2 followers gained ↓ feature store ↓ ChatGPT receives evidence ↓ "Prefer concrete engineering stories; generic summaries underperformed." 

For each published post, store features such as article category, hook type, body length, format, whether a link was included, CTA style, publication time, technical depth and content objective. Then take analytics snapshots — for example after one hour, one day and one week — instead of storing only lifetime totals.

The LinkedIn analytics endpoint supports both single-post and aggregated member analytics and allows date ranges and total/daily aggregation for supported metrics. [4]

Do not optimise against raw counts alone. An account with a growing follower base makes later posts structurally advantaged. Rates provide more useful comparisons:

reaction_rate = reactions / impressions comment_rate = comments / impressions save_rate = saves / impressions reshare_rate = reshares / impressions click_rate = link_clicks / impressions follow_rate = followers_gained / impressions 

A starting INGOAMPT scoring function might be:

content_score = 0.20 × reaction_rate
	•	0.20 × comment_rate
	•	0.15 × save_rate
	•	0.10 × reshare_rate
	•	0.20 × click_rate
	•	0.15 × follow_rate 

Those weights are not universal facts. They are product decisions. A consultancy selling developer services may increase the click/follow weights. A researcher building authority may favour saves, comments and profile views. A product launch should eventually incorporate conversions from the destination website rather than pretending a LinkedIn click equals a sale.

The approval gate must live in code, not merely in the model prompt.

DRAFT ↓ READY_FOR_REVIEW ↓ APPROVED ↓ PUBLISHING ↓ PUBLISHED 

Every draft should have a content hash. Approval records should capture the draft ID, exact hash, approver, timestamp and expiration. Any edit after approval invalidates that approval.

def assert_publishable(draft, approval): if draft.status != "APPROVED": raise PermissionError("Draft is not approved")
if approval.draft_id != draft.id:
    raise PermissionError("Approval belongs to another draft")

if approval.content_hash != draft.content_hash:
    raise PermissionError("Content changed after approval")

if approval.is_expired:
    raise PermissionError("Approval expired")

if draft.linkedin_post_urn is not None:
    raise RuntimeError("Draft has already been published")

This also gives us idempotency: clicking “Approve” twice must not create two LinkedIn posts. GitHub’s protected environments can provide a second approval mechanism for highly sensitive production jobs, but application-level approval is still necessary because a professional-content workflow should preserve the relationship between the exact draft and its authorisation. GitHub documents reviewer-gated access to environment secrets, which is useful as defence in depth. [7]

The system prompt should optimise for evidence, not hype. A practical example:

You are the LinkedIn technical editor for INGOAMPT.
Goal: Turn one verified INGOAMPT article into a high-quality LinkedIn post for software developers, data engineers and technical founders.
Inputs:
	•	article title
	•	article body
	•	canonical URL
	•	previous 90-day post-performance summary
	•	last 30 published hooks
	•	target objective
	•	INGOAMPT voice guide
Rules: 1. Use only facts supported by the supplied article/evidence. 2. Never invent benchmarks, customer numbers or personal experiences. 3. Select one technical insight rather than summarising the entire article. 4. Prefer concrete engineering details to generic AI language. 5. Do not imitate another creator's exact wording. 6. Avoid hooks too similar to anything used during the previous 30 posts. 7. The final post must still sound credible if all emojis and hashtags are removed. 8. Publishing is forbidden. Produce a draft only.
Return JSON: { "article_id": "...", "objective": "...", "hook": "...", "body": "...", "cta": "...", "reasoning_summary": "...", "evidence_used": ["..."], "predicted_strengths": ["..."], "risks": ["..."] } 

Then run a separate critic/ranker. We use a rubric rather than asking the model “is this viral?”:

Hard rejection: fabricated data, fake personal experience, unverifiable quotation, near-duplicate post, misleading promise or content that exists primarily to manipulate engagement.

Three simple developer-oriented templates are enough to start testing.

For example:

The bug wasn’t in the model. It was in the data contract.

We spent hours questioning the AI layer before looking at the boundary between two services.

One field had changed meaning without changing type.

The JSON was valid.
The pipeline was healthy.
The result was still wrong.

That is the uncomfortable part of many “AI problems”: once a model becomes part of a larger system, ordinary software-engineering failures do not disappear. They become harder to notice.

In our latest INGOAMPT article, we break down the architecture and the debugging path.

[Article link]

Which failure mode has cost you more time recently: the model itself, or the system around it?

The model should create variations of this structure from real article evidence — never invent the underlying experience merely because the template says “we”. LinkedIn itself recommends that people review, edit and approve AI-assisted content and reminds members that they remain responsible for what they publish. [25]

Security, compliance and realistic results

A private GitHub repository is the right default for the operational system, but private does not mean safe by itself. Never commit LINKEDIN_CLIENT_SECRET, access tokens, WordPress Application Passwords, OpenAI API keys or production database credentials. Keep local secrets in an ignored environment file and production secrets in a proper secret store or GitHub environment secrets. GitHub recommends minimum credential permissions, secret rotation and careful auditing of third-party Actions because compromised workflow dependencies can gain access to secrets available to their job. [7]

A production implementation should also separate read tools from write tools, validate all tool inputs, maintain audit logs, encrypt OAuth tokens at rest, enforce idempotency, restrict outbound domains, apply timeouts/retries, and treat imported web/WordPress content as untrusted input rather than as instructions to the model. OpenAI similarly cautions developers to review what data is shared with remote MCP servers and to log or otherwise govern those exchanges. [8]

Do not replace the official API with hidden browser automation simply because an MCP repository makes it easy. LinkedIn’s current User Agreement prohibits scraping/copying the service with scripts, robots, browser plug-ins or similar technology and separately prohibits bots or other unauthorised automated methods for actions including messages, post creation, comments, likes, shares and other inauthentic engagement. [15]

That is why an official-API architecture is strategically superior even when it takes longer to obtain permissions. A professional account is an identity asset; saving a few hours of API integration is not worth building the system around copied browser cookies or brittle scraping.

AI content itself is not a reason to remove the human. LinkedIn explicitly urges members to review, edit and approve AI-assisted material, says the member remains responsible for what is posted, and recommends transparency when AI has been relied on heavily. [25]

For Community Management access, the compliance burden is also real. LinkedIn documents Development-tier vetting around approved use case and verified business identity, while Standard tier includes a valid privacy policy, compliance requirements and a demonstration recording. LinkedIn also reserves the ability to monitor integrations and suspend API access for non-compliance. [26]

Can such a system generate real followers and engagement? It can contribute to the conditions that make growth more likely: more consistent publishing, systematic reuse of strong source material, less repetition, faster experimentation and measurement against actual outcomes. It cannot create a reliable mathematical path to virality.

These are not controlled experiments demonstrating that AI causes follower growth. That would be an unjustified conclusion. The evidence is more modest and more useful: creators can build substantial real audiences through consistent, relevant content, while software products already exist around drafting, scheduling and analytics. The custom system described here attempts to make that process more measurable and specific to one developer’s own knowledge base.

For developers who sell a product or consulting service, the feedback loop should eventually extend beyond LinkedIn. Add tagged URLs to the article/product CTA, capture downstream website conversions, and optimise for outcomes such as documentation visits, newsletter subscriptions, demo requests, trials or purchases. LinkedIn’s own analytics can report LINK_CLICKS and FOLLOWER_GAINED_FROM_CONTENT, but actual product conversion belongs to the website/application analytics layer. [4]

Finally, review the licence of every open-source component before copying it into the project. Several candidate repositories are MIT- or Apache-licensed, while one sampled project did not expose an obvious licence in the fetched repository page. A public GitHub repository is therefore possible, but we would initially keep the operational INGOAMPT implementation private, keep all personal analytics and credentials private, and later open-source only a sanitised generic framework after a proper licence and security review. [30]

MVP timeline and implementation checklist

A competent developer familiar with Python or TypeScript, HTTP APIs and OAuth can build a useful MVP in roughly one to two focused working weeks. That estimate covers engineering time, not LinkedIn’s external approval timetable. Community Management vetting may become the critical path, so the application should be designed to work initially with publishing plus manually imported/exported analytics if necessary, then switch to r_member_postAnalytics when access is provisioned. LinkedIn’s documentation confirms that Community Management access is reviewed and that analytics permission belongs to that programme. [31]

gantt title ChatGPT + LinkedIn MVP dateFormat YYYY-MM-DD axisFormat %d %b
section Foundation
Repository, schema, tests       :a1, 2026-08-24, 1d
WordPress ingestion             :a2, after a1, 1d

section LinkedIn
OAuth and identity              :b1, 2026-08-25, 2d
Posts API                       :b2, after b1, 1d

section AI
Draft generation                :c1, 2026-08-27, 1d
Scoring and deduplication       :c2, after c1, 1d

section Safety
Approval state machine          :d1, 2026-08-28, 1d
Idempotency and audit log       :d2, after d1, 1d

section Agent
MCP tool layer                  :e1, 2026-09-01, 1d
ChatGPT integration             :e2, after e1, 1d

section Feedback
Analytics collector             :f1, 2026-09-02, 1d
Feedback strategy               :f2, after f1, 1d

section Production
Security, deployment, testing   :g1, 2026-09-03, 2d

These are engineering estimates, not promises. A developer new to OAuth, MCP and deployment should expect additional learning time. The LinkedIn approval process can also extend the calendar duration independently of how quickly the code is completed. [32]

The build order we would use at INGOAMPT is deliberately conservative:

Phase A WordPress → ChatGPT → saved draft
Phase B LinkedIn OAuth → manual test post
Phase C WordPress → ChatGPT → approval → LinkedIn
Phase D MCP → conversational access to A–C
Phase E LinkedIn analytics → database
Phase F historical metrics → strategy summary → better next draft
Phase G website conversion data → business-value optimisation 

This order lets every layer be tested independently. It also prevents the most dangerous failure mode in an agentic publishing project: spending days building clever prompts while leaving identity, permissions and write actions loosely controlled.

The finished interaction should feel simple precisely because the backend is strict:

ChatGPT: I analysed 43 eligible INGOAMPT articles, excluded 11 that have recently been promoted, compared the remaining topics with the last 90 days of LinkedIn performance, and selected the database-migration article. Posts built around engineering failure/recovery stories have generated stronger saves and comments than generic summaries.

Draft:
“The database migration wasn’t difficult because of 12 million records. It was difficult because every shortcut became permanent…”

[complete post]

Status: Ready for review. Nothing has been published.

Human: Approved.

System: Approval hash verified → LinkedIn API called → post URN stored → analytics snapshots scheduled.

That is the system we believe developers should build: not an autonomous engagement bot, but an evidence-aware publishing assistant with memory, measurable feedback and a hard human boundary before public action.

ChatGPT supplies the intelligence. MCP supplies the conversational tool boundary. GitHub supplies maintainable source control and deployment infrastructure. WordPress supplies original knowledge. LinkedIn’s official APIs supply publishing and, when approved, creator analytics. The database turns yesterday’s results into tomorrow’s context. [33]

And that is the real opportunity. The advantage is not that AI can produce more words. It is that developers can build a controlled system that remembers which ideas were published, how they were presented, what the audience actually did afterwards, and what should change next time — while the person whose name appears on LinkedIn remains the final editor and publisher.

Primary implementation references: LinkedIn API access and permissions · LinkedIn OAuth · LinkedIn Posts API · Member Post Analytics · LinkedIn Marketing API permissions · OpenAI MCP documentation · WordPress REST API · GitHub Actions secrets.