The Ghost-in-the-Loop Workflow: How Solo Developers Use Make and GitHub Webhooks to Draft Build-in-Public Social Updates

Shipping software as a solo developer or small team requires balancing deep focus with the distribution work of building in public. Documenting progress on platforms like X or LinkedIn is effective for growth, but manually drafting updates for every major commit, closed issue, or feature deployment breaks the development flow.

The common reaction is to automate the entire pipeline, letting a script write and publish social posts directly from git push events. This approach usually backfires. Automated posts written by LLMs without human intervention tend to use repetitive phrases, lack technical nuance, and sound artificially enthusiastic, which can alienate developers and technical audiences.

To solve this, developers are building “ghost-in-the-loop” workflows. By connecting GitHub webhooks to automation platforms like Make and using LLM APIs, they generate raw social media drafts based on actual code changes. Crucially, these drafts are sent to private messaging channels or database tables where a human must edit, approve, and queue them, ensuring the final voice remains authentic.

Setting Up the Git-to-Draft Pipeline

The technical architecture of this workflow relies on capturing granular data directly from the development environment and passing it to an LLM with specific context before staging it for review.

[GitHub Push Event] 
        │
        ▼ (Webhook Payload)
   [Make.com Scenario] ───► [LLM API Prompting]
                                   │
                                   ▼ (Draft Generated)
                           [Slack / Discord / Notion] ───► [Human Review & Publish]

The automation begins with a GitHub webhook. When configured for a specific repository, GitHub sends a real-time JSON payload whenever a developer pushes code, opens a pull request, or merges a branch.

To configure the webhook: 1. Navigate to the repository settings on GitHub, select Webhooks, and click Add webhook. 2. Set the Payload URL to the custom webhook address provided by a tool like Make. 3. Set the Content Type to application/json. 4. Choose the specific events to trigger the webhook. Selecting just Pushes prevents the system from being overloaded with minor internal updates.

The incoming webhook payload contains rich, contextual data. Key fields include the repository name, the committer’s details, an array of commit objects containing individual commit messages, and a list of modified, added, or deleted files.

Designing the LLM Parsing Stage

Once Make receives the JSON payload, the next step is parsing the commit messages and file changes. A common failure mode is passing raw, unpolished commit messages directly to the LLM. Solo developers often write short, functional messages like fix: resolve auth bug or feat: update UI component that lack the context needed to generate an engaging social post.

To bypass this, the Make scenario can run a conditional filter. If the commit message is too short or contains specific internal keywords, the system can pull additional context by querying the GitHub API for the specific commit diff or looking at the pull request description.

This consolidated data is then sent to an LLM API, such as OpenAI’s GPT-4o, using a highly structured system prompt. The goal of the prompt is to extract the core utility of the update and draft a concise social post.

An effective prompt template focuses on technical accuracy over marketing copy:

You are an assistant writing draft technical updates for a developer's build-in-public journey.
Analyze the following git commit messages and file changes:
{{commit_messages}}
{{modified_files}}

Write a concise draft for a social update. 
Rules:
- Focus on the practical value of the change (what problem does it solve?).
- Do not use exclamation marks or hype words.
- Explain the "why" behind the code changes, not just the "what."
- Keep the draft under 280 characters.

By explicitly banning hype language, the LLM avoids generic marketing cliches and produces a raw draft that mirrors the developer’s actual working style.

Keeping the Human in the Loop

The critical junction of this workflow is the staging area. Rather than using an integration to publish the draft directly to a social media scheduler, the Make scenario routes the generated draft to an internal review channel.

Three staging destinations work well for solo operations: * Slack or Discord Webhooks: Make posts the generated text directly to a private channel alongside a button link. The developer can copy, edit, and paste the text directly into their posting tool of choice. * Notion Databases: The scenario creates a new page in a “Social Content” database with the status set to “Draft.” The page contains the generated text, the commit date, and the original commit messages for reference. * Airtable or Trello: Similar to Notion, this creates a card in a review pipeline, allowing the developer to batch-review drafts at the end of the day or week.

Using these staging areas means the developer spends less than 30 seconds reviewing, tweaking, and approving a post that has already been formatted, categorized, and contextualized. It reduces the cognitive friction of staring at a blank screen while preserving the control required to keep the content genuine.

Managing API Costs and Avoiding Noise

Running an automation on every single git push can quickly lead to API fatigue and unnecessary costs. Developers can optimize this setup by applying three practical constraints within Make:

1. Filter by Branch: Configure the Make scenario to only proceed if the webhook payload indicates the push was made to the main or production branch. This ensures that experimental code and WIP branches do not trigger drafts.
2. Commit Message Filters: Add a router in Make that checks the commit message for specific flags. For example, the automation could run only if the commit message contains a specific tag, such as [public] or feat:. This gives the developer manual control over which commits are worthy of a social update.
3. Batching: Instead of running the scenario instantly on every push, use Make’s data store to collect commits throughout the day. A scheduled trigger can then bundle these commits into a single daily summary draft every evening, reducing API calls and creating a cohesive daily update.

By treating automation as a drafting assistant rather than an autonomous publisher, solo developers can consistently share their progress without sacrificing their time or their voice.

This article was generated with the help of AI.