Groniz
Log InGet started

How to Turn Git Commits into Build-in-Public Posts with Codex

Codex can inspect a selected range of Git commits, group related changes, and trace each draft claim to code, tests, or documentation. Groniz can then publish or schedule the approved post to X or LinkedIn. The job is…

Codex can inspect a selected range of Git commits, group related changes, and trace each draft claim to code, tests, or documentation. Groniz can then publish or schedule the approved post to X or LinkedIn. The job is not to prettify git log. Commits are engineering evidence, not a ready-made public story. Remove private details, explain the user problem, and be honest about uncertainty. A human still needs to explain why the work mattered and which tradeoffs shaped it. Before delivery, inspect the chosen integration's live Groniz settings and approve the destination, copy, media, and time.

From commit range to approved post

Selected commit range
  -> classify public, private, and irrelevant changes
  -> build an evidence-backed progress story
  -> create an X or LinkedIn draft
  -> founder/engineer reviews and adds judgment
  -> discover live Groniz settings
  -> approve, deliver, and verify

This article covers X and LinkedIn as possible destinations, but does not claim a live end-to-end test for either. Connector capabilities vary, so follow the selected integration's live schema.

Prerequisites

You need:

  • Codex CLI, the IDE extension, or the desktop app running in the repository. This workflow does not work in ChatGPT on the web.
  • An exact commit range, branch comparison, or date window you want to discuss.
  • Durable repository guidance in AGENTS.md covering confidential paths and public terminology.
  • A Groniz account plus a connected X or LinkedIn integration.
  • A human author who can verify the story and approve publication.
  • Optional screenshots or diagrams with permission to publish.

Codex works with repository context. Its official AGENTS.md guide explains how durable instructions apply across a project, which is useful for rules such as "never expose customer names from fixtures." Codex skills can hold repeatable editorial steps. Codex MCP support can connect the coding agent to an external publishing system.

Connect Codex to Groniz

The Skill route is:

npx skills add groniz/groniz-cli

For MCP, set the environment variable before Codex launches, then add Groniz:

export GRONIZ_API_KEY="your-api-key"
codex mcp add groniz \
  --url https://mcp.groniz.com/mcp \
  --bearer-token-env-var GRONIZ_API_KEY

Codex rejects a plaintext token in config.toml. Keep the bearer token in the environment and launch Codex after the variable exists. You can also use the standalone Groniz CLI if Codex can invoke an authenticated local binary.

Why commit history is useful but incomplete

Commits provide dates, diffs, tests, issue references, and documentation updates. They show what changed, but rarely explain the full public story. "Refactor retry queue" might describe invisible maintenance or work that a future feature depends on. It could also be a genuine improvement whose effect has not been measured yet. Codex should classify the change before drafting instead of inventing a benefit from the commit message.

A build-in-public post also needs the author's perspective. Why did this problem matter? Which tradeoff was difficult? What changed in your understanding, and what remains unfinished? On LinkedIn, that human contribution matches the platform's advice to review and revise AI-assisted writing and ground it in your expertise. See LinkedIn's AI writing guidance.

The Codex social publishing hub covers the larger workflow. If your source is a formal release rather than daily work, follow the GitHub release-to-X thread guide. For LinkedIn destination setup, see the LinkedIn publishing guide.

Select and sanitize the commit range

Start with an explicit range, branch comparison, or date window. Pin the source revision so later commits cannot silently change the evidence. Ask Codex to inspect commit messages and diffs without editing anything. Have it sort changes into:

  • Public user-visible progress.
  • Technical learning worth explaining.
  • Maintenance that provides necessary context.
  • Private, security-sensitive, customer-specific, or unreleased material.
  • Noise such as formatting, dependency churn, merges, and generated files.

Anything visible to Git could end up in the draft, but that does not make it safe to publish. Diffs can contain customer data, internal URLs, credentials, incident details, security-sensitive behavior, or the name of an unreleased feature. Exclude those items before asking for prose instead of relying on the final proofread to catch them.

Add repository rules like these to AGENTS.md if they apply:

## Public progress posts

- Treat customer names, fixture data, incident IDs, and security details as private.
- Describe only behavior verified in code, tests, or public documentation.
- Mark unreleased work as in progress; never describe it as shipped.
- Ask the author for motivation, tradeoffs, and lessons instead of inventing them.
- Drafting never authorizes publication.

Reusable asset: commit evidence digest

Have Codex fill this before it writes prose:

# Build-in-public evidence digest

Commit range:
Source branch and revision:
Public theme:
Reader problem:

## Evidence
| Claim candidate | Commit/file/test | Confidence | Public? |
| --- | --- | --- | --- |

## Author input required
- Why did this matter now?
- What tradeoff changed the implementation?
- What surprised us?
- What remains unresolved?

## Exclusions
- Private identifiers:
- Unreleased behavior:
- Unmeasured outcome claims:

The digest keeps verified facts separate from the interpretation that only the author can provide.

Create a channel-native draft

Once the author answers the open questions, choose one reader and one point. If you try to summarize every commit, the post turns back into a changelog.

For X, a useful structure is:

What we were trying to improve
What changed
The specific lesson or tradeoff
What is still in progress
One approved link or question

For LinkedIn, give the idea more room:

The user or engineering problem
Why the obvious approach was not enough
The decision and its constraint
What the team learned
What remains unresolved
One approved link or question

Then prompt Codex:

Using the approved evidence digest and author answers, draft one build-in-public
post for [X or LinkedIn]. Focus on one change and one honest lesson. Trace each
factual claim to the digest, preserve in-progress or shipped status, and include
only the approved link. Return the draft plus a claim audit. Stop before any
external write.

For X, keep the draft concise and below the current Groniz provider limit of 4,000 characters. If you include an image, remember that the X connector does not send image alt text. The account connection uses OAuth 1.0a. For LinkedIn, write a complete professional reflection in readable paragraphs instead of dressing up commit bullets as prose. Groniz supports LinkedIn profiles and Pages, so select the intended destination during integration discovery. Treat these as two different drafts, not a cross-posting toggle.

Human review checkpoint

The author should check every shipped or in-progress label, version, link, and claimed outcome. Remove customer clues, exploit details, internal hostnames, private issue links, and screenshots with sensitive UI. If the evidence proves only an implementation change, the post must not imply a measured improvement.

Replace generic lessons with the decision the team actually made. Name the option it rejected, the constraint that drove the choice, or what it would do differently.

Keep the two approvals separate:

  1. Editorial approval confirms the exact copy, claims, link, and media.
  2. Delivery approval confirms the destination, post type, settings, and publication time.

Editorial approval does not authorize an external write. The author should approve delivery only after reviewing the assembled request.

Deliver through Groniz

Have Codex discover the live connection and schema:

groniz whoami
groniz integrations:list
groniz integrations:settings <integration-id>

Groniz handles OAuth, per-platform formatting, scheduling, and delivery across 32+ networks. Provider capabilities differ, so the settings response is authoritative for required fields, current limits, supported formats, and available dynamic integration tools. Call only the tools it lists. If the post has approved media, upload it before creating the request:

groniz upload ./artifacts/progress-screenshot.png

Use the returned .path, not the local file or an external URL. Ask Codex to display the exact integration, final copy, media path, publication mode, time, and timezone. Do not publish or schedule until that final request has explicit approval.

For the selected target, the generic CLI form is:

groniz posts:create \
  -c "APPROVED_BUILD_IN_PUBLIC_CONTENT" \
  -m "<returned-groniz-media-.path>" \
  -s "2026-08-22T15:00:00Z" \
  -t schedule \
  -i "TARGET_INTEGRATION_ID" \
  --settings '<required-settings-json>'

Replace the settings placeholder with the required values from the chosen X or LinkedIn integration. The media value must be the .path returned by the upload. If you prepare both destinations, run discovery again and build a separate command for the second target. Codex must show each completed command and wait for explicit publication approval.

Verify delivery and handle failures

Record the returned Groniz post ID and status, along with the scheduled or published time and platform URL when Groniz provides them. Open the native post and check the account identity, formatting, link preview, media, and timestamp against the approved request.

If delivery fails, refresh the live settings and check authorization, permissions, required fields, content length, post type, media path, and timezone. A timeout may still have created the post, so check before retrying to avoid a duplicate. Fix delivery fields without regenerating the approved prose. If the copy itself must change, send it back for editorial review.

Measure the next iteration

Use X or LinkedIn's native metrics and read the replies. Track the measures available to the account, such as impressions, engagement, clicks, profile activity, and substantive conversations. Record whether readers understood the change or asked for context that the post left out.

Compare themes across a series instead of treating one post as proof of the best format or publication time. Link each result to its evidence digest so later posts can use verified observations. Groniz delivers the approved post. It does not guarantee growth or run autonomous content experiments.

To connect Codex to the delivery layer, create a Groniz Connectors API key.

More to read