Yesterday’s post walked through automating a content pipeline with GitHub Actions and Issues. The idea: a daily scheduled job scans recent commits and closed issues across several repos, filters out the noise, and opens what’s left as GitHub issues labeled stage:mined. One of those issues looks something like this:

Title: [content] feat: add SovereigntyProfile to Layer 0
Body:
  ## Source
  Commit `abc1234` in `waaseyaa/framework`
  ## Content Seed
  feat: add SovereigntyProfile to Layer 0
  ## Suggested Type
  text-post

Those issues are raw material. You curate them into drafts, produce the copy, and publish. That surfacing step is what the rest of this post calls mining. This post is about what happened the first time I actually ran that pipeline. The short version: it works, but the first real run turned up three problems no amount of planning could have caught. Here are the three fixes and the meta-lesson underneath them.

Day One Output: 20 Issues, Too Much Noise

The mining workflow fired on schedule and opened 20 stage:mined issues overnight, pulled from three repos. Good news: the pipeline saw everything it was supposed to see. Bad news: “everything” is not the same as “a usable drafting queue.” The first run had more noise than I expected, and it had noise the filter couldn’t see.

Fix 1: Tighten the Mining Filter

Even with the v1 noise filter, too many low-signal commits made it through. Things like fix: align FileRepositoryInterface usage with Waaseyaa\Media\File contract matter for the codebase and are boring as standalone posts. The first fix was to extend the exclude regex in content-mine.yml:

COMMITS=$(gh api "repos/$REPO/commits?since=$SINCE&per_page=50" \
  --jq '.[] | select(.commit.message | test("^(Merge |chore|docs|fix typo|bump|update dep|Bump |fix:.*([Pp]hp[Ss]tan|namespace|alignment|placeholder|phpunit|mock|ignore|typo))"; "i") | not) | {sha: .sha[0:7], message: (.commit.message | split("\n") | .[0]), date: .commit.author.date}' \
  2>/dev/null || echo "")

The new patterns (phpstan, namespace, alignment, placeholder, phpunit, mock, ignore, typo) catch categories of real work nobody wants to read about. A minimum message length of 25 characters cuts drive-by fixes. Fewer mined issues per run, and the ones that survive sit closer to “actually postable.” That handled the mechanical noise. The next problem was harder because no regex could see it.

Fix 2: Merge-in-Curation

Filters are a blunt instrument. They cannot tell that eight separate commits all belong to the same post. On day one, the Giiken project alone produced eight mined issues: scaffold, entity types, RBAC, ingestion, wiki schema, query layer, plus two support commits. Every one of them was a valid feature commit. Together they were one post. No filter was going to catch that. Only a human reading them side by side could say “these are a story.”

So curation got a new action: merge into target. Instead of picking one winner and closing the rest, you pick a canonical issue, roll the seeds from the others into its body, and close the sources. The target ends up carrying a combined seed (the whole story), and the sub-issues get a skipped label and a closed state.

The curation skill now runs like this:

→ Approve (move to stage:curated)
→ Skip   (close with skipped label)
→ Merge  (pick target, combine seeds, close sources)
→ Edit   (adjust seed, type, or channels before approving)

Running that over the 20 mined issues collapsed them to 4 curated posts: one about the pipeline itself, one about the Giiken project, one about a governance protocol suite in the framework, and one about a specific Symfony refactor. Signal up, count down. Two fixes done. The third was the embarrassing one.

Fix 3: Put the Blog First

The v1 production step went straight from a curated issue to Facebook, X, and LinkedIn copy. That read fine in the design doc. It fell apart the first time I tried to run it, because every one of those social posts had a placeholder where the URL should go. The URL had to point at a blog post. The blog post did not exist yet.

So I rewrote the /content-produce skill — a Claude Code workflow that turns queue issues into drafts. The new flow:

flowchart TD
    A[stage:curated issue] --> B[Draft Hugo post<br/>draft: true]
    B --> C[Draft social copy<br/>docs/social/slug.md]
    C --> D[Commit both to blog repo]
    D --> E{Human review}
    E -->|Flip draft: false| F[GitHub Actions deploys]
    F --> G[/content-pipeline/]
    G --> H[Buffer API → X, LinkedIn, Facebook]

The human controls publication. The skill commits drafts only and never flips draft: false. Once I flip the flag and push, GitHub Actions deploys the post, and a separate /content-pipeline skill handles the Buffer API for social distribution. Each step has one job. This post you’re reading is the first one produced by the new flow.

Why Content Pipelines Need Continuous Refinement

You cannot design a content pipeline in the abstract. You ship v1, run it against one day of real input, and watch it lie to you. Then you fix the specific lies. That loop is the work.

Three days ago this pipeline did not exist. Two days ago it was a spec. Yesterday it shipped. Today it is already different. None of the three fixes in this post were things I could have known up front. They came from running the thing, staring at the output, and asking “what is this queue actually trying to tell me?”

If you are building your own version of this, expect the same arc. Your v1 will have noise you cannot see yet. Your first curation session will reveal merges a filter could not find. And your production step will probably be backwards, because writing the fun part first (the tweets) is more tempting than writing the part that does the work (the blog post). The refinement is not a sign something went wrong. It is the point.

Baamaapii

You ship work every day, but most of it never becomes a post. The problem isn’t writing. It’s remembering what you shipped three days ago that was actually worth talking about. This post walks through a content pipeline that mines your GitHub repos daily and queues content ideas as issues, so nothing slips through.

How the Pipeline Works

The system has three moving parts: a GitHub Actions workflow that runs on a cron schedule, an issue template that standardizes the format, and label-based stages that track each idea from raw commit to published post.

flowchart TD
    A[commit lands] --> B[Action mines it]
    B --> C[issue created<br/>stage:mined]
    C --> D[you curate<br/>stage:curated]
    D --> E[produce copy<br/>stage:ready]
    E --> F[distribute]

Every stage is a GitHub label. You always know where each content idea sits, and nothing moves forward without your decision.

The Mining Workflow

The workflow runs daily at 8am ET, scans a list of repos, and creates issues for commits that look like real work.

name: Content Mining

on:
  schedule:
    - cron: '0 12 * * *'
  workflow_dispatch:

permissions:
  issues: write
  contents: read

The workflow_dispatch trigger lets you run it manually when you want to catch up. Permissions are scoped to just what the job needs: reading commits and writing issues.

The core loop iterates over repos and fetches recent commits via the GitHub API:

env:
  GH_TOKEN: ${{ secrets.CROSS_REPO_TOKEN }}
run: |
  SINCE=$(date -u -d '1 day ago' +%Y-%m-%dT%H:%M:%SZ)
  REPOS="waaseyaa/framework waaseyaa/giiken jonesrussell/jonesrussell"

  for REPO in $REPOS; do
    COMMITS=$(gh api "repos/$REPO/commits?since=$SINCE&per_page=50" \
      --jq '.[] | select(.commit.message | test("...filter...") | not) | ...')
  done

The CROSS_REPO_TOKEN is a personal access token with read access to all repos you want to mine. Without it, the workflow can only see public repos.

Filtering Noise

Not every commit is content. The filter regex excludes merge commits, dependency bumps, docs changes, and housekeeping fixes:

test("^(Merge |chore|docs|fix typo|bump|update dep|Bump |fix:.*
  ([Pp]hp[Ss]tan|namespace|alignment|placeholder|phpunit|mock|ignore|typo))"; "i")

This catches the patterns that showed up as noise in practice: PHPStan fixes, namespace alignment, test placeholders. Commits also need a minimum message length of 25 characters to filter out low-context changes like “fix test” or “update readme”.

The filter will evolve. After your first curation pass, you’ll know which patterns your repos produce that aren’t worth posting about. Update the regex and the next run gets cleaner.

Deduplication

Before creating an issue, the workflow checks whether a commit has already been queued:

EXISTING=$(gh issue list --repo jonesrussell/jonesrussell \
  --label "content-queue" --search "$SHA" \
  --json number --jq 'length')
if [ "$EXISTING" != "0" ]; then
  echo "Skipping (already queued): $MSG"
  continue
fi

This prevents duplicate issues when you re-run the workflow manually or when the cron overlaps with a manual trigger.

The Issue Template

Each mined commit becomes an issue with a structured body:

## Source
Commit `abc1234` in `waaseyaa/framework`

## Content Seed
feat(#571): add DomainRouterInterface, EntityTypeLifecycleRouter, SchemaRouter

## Suggested Type
text-post

## Suggested Channels
x, linkedin, facebook

## Generated Artifacts
<!-- To be filled by production skill -->

The “Generated Artifacts” section stays empty until you curate and produce the content. Labels track the stage: stage:mined, stage:curated, stage:ready, stage:distributed.

The Curation Step

Mining is automated. Curation is not. You review each stage:mined issue and decide: approve, skip, merge with another item, or edit the seed. Skipped items get closed with an audit comment explaining why. Approved items move to stage:curated.

This is where judgment lives. A commit that says “feat: Community RBAC policies” might be a standalone post or might merge with two other commits into a broader story about your data model. The pipeline gives you the raw material. You shape it.

Closed Issues as Content Sources

The workflow also scans recently closed issues across your repos:

gh issue list --repo "$REPO" --state closed \
  --json number,title,closedAt,labels \
  --jq ".[] | select(.closedAt > \"$SINCE\") | ..."

Closed issues often represent shipped features with richer context than a commit message. The workflow creates content queue items for those too, with the same deduplication and labeling.

Setting It Up in Your Repos

You need three things:

1. A personal access token (CROSS_REPO_TOKEN) with repo scope, stored as a repository secret
2. The workflow file at .github/workflows/content-mine.yml in whichever repo you want to host the content queue
3. The labels created in that repo: content-queue, stage:mined, stage:curated, stage:ready, stage:distributed, stage:skipped

Create the labels first:

for label in content-queue stage:mined stage:curated stage:ready stage:distributed stage:skipped; do
  gh label create "$label" --repo your-org/your-repo
done

Then add the workflow, update the REPOS list with your repos, and trigger it manually to verify.

What This Doesn’t Do

This pipeline handles discovery, not writing. It won’t draft a blog post or compose a tweet. Those are separate steps that happen after curation, when you know the angle and audience for each piece.

It also won’t decide what’s worth posting. That’s the point. Automated mining with human curation gives you a reliable queue without losing editorial control.

Baamaapii