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

Codex can read a selected range of Git commits, group the changes into a story for readers, and trace every claim to code, tests, or documentation. Groniz can then publish or schedule the approved result to X or LinkedIn. A prettified git log is not the goal. Commits are engineering evidence, not a public narrative. Filter private details, explain the user problem, preserve uncertainty, and ask a human to add the judgment only the builder can supply. Before delivery, inspect the chosen integration's live Groniz settings and approve the exact 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 uses X and LinkedIn as possible destinations. It does not claim a live end-to-end test for either one; the selected target's live schema wins.

Prerequisites

You need:

• Codex CLI, the IDE extension, or the desktop app working in the repository, not ChatGPT on the web.
• A clean understanding of the commit range 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, and its official AGENTS.md guide explains how durable instructions apply across a project. That makes AGENTS.md useful for rules such as "never expose customer names from fixtures." Codex skills can encode repeatable editorial steps, while Codex MCP support connects 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, so keep the bearer token in the environment and launch Codex only after the variable exists. The standalone Groniz CLI is also supported if Codex can invoke an authenticated local binary.

Why commit history is useful but incomplete

Commits provide dates, diffs, tests, issue references, and documentation changes. That is good evidence of what changed, but it rarely explains the whole public story. "Refactor retry queue" could be invisible maintenance or a prerequisite for a future feature. It might be a real improvement whose effect has not been measured. 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 this problem mattered, what tradeoff was difficult, what changed in your understanding, and what remains unfinished. On LinkedIn, that human contribution aligns with the platform's guidance to review and revise AI-assisted writing and ground it in your expertise. See LinkedIn's AI writing guidance.

For the larger system, use the Codex social publishing hub and the X workflow hub. If your source is a formal release rather than daily work, the GitHub release-to-X thread guide is the closer pattern.

Select and sanitize the commit range

Start with an explicit range, branch, or date window. Ask Codex to inspect commit messages and diffs but make no edits. It should classify 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.

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 separates facts Codex can verify from interpretation it must request from the author.

Create a channel-native draft

Once the author answers the open questions, 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, make the post concise enough for the current Groniz provider limit, which is 4,000 characters. If you include an image, note that the X connector does not send image alt text; the account connection uses OAuth 1.0a. For LinkedIn, favor a complete professional reflection with readable paragraphs rather than turning commit bullets into a changelog. These are different drafts, not a cross-posting toggle.

Human review checkpoint

The author should check every shipped/in-progress label, version, link, and claimed outcome. Remove customer clues, exploit details, internal hostnames, issue links, and screenshots with sensitive UI. Confirm that the post does not imply measured improvements when the evidence only proves an implementation change.

Then replace generic lessons with the actual decision. Name the option that was rejected, the constraint that drove the choice, or what the team would do differently. Approve the content first. The author should approve publication only after seeing the assembled delivery request.

Deliver through Groniz

Have Codex discover the live connection and schema:

groniz whoami
groniz integrations:list
groniz integrations:settings [integration-id]

The settings response is authoritative for required fields, current limits, supported formats, and available dynamic integration tools. Call only the tools it lists. If media is approved, 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. Publish now or schedule only after that final request receives 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, perform 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, status, scheduled or published time, and platform URL when provided. Open the native post and check account identity, formatting, link preview, media, and timestamp. Compare it with the approved text.

On failure, refresh live settings and check authorization, permissions, required fields, content length, post type, media path, and timezone. Determine whether a timeout still created a post before retrying. Never regenerate the prose merely to fix a delivery field; keep editorial and delivery revisions separate.

Measure the next iteration

Use X or LinkedIn's native metrics and the quality of replies. Track the measures available to the account, such as impressions, engagement, clicks, profile activity, and substantive conversations. Also record whether readers understood the change or asked for missing context.

Compare themes over a series rather than treating one post as proof of the best format or time. Link each result to its evidence digest so later posts can draw on 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.