dabigc.com · Field notes of a platform engineer
Case study № 04 · Agentic Engineering

Codifying Agentic Engineering for a Platform Team

How I turned a personal AI-assisted workflow into infrastructure the whole team can install, so we share working patterns instead of each reinventing them.

Role
Principal DevOps Engineer
Organization
HMH Education
Timeframe
Ongoing
Stack
Claude Code · plugin marketplace · git-workflows
Under 5 min
one command to a reviewed, described, tracked PR
5 releases
dogfooded before team rollout
Hundreds
of tests behind it
№ 01 · The Challenge

A personal workflow doesn't scale a team.

AI-assisted engineering made me a lot faster. The problem is that a personal workflow does not scale a team. The PR routine I ran from memory every day is mechanical but easy to get wrong: push the branch, draft a structured description, run review, fix what is real, reply to comments, update Jira, etc. And when every engineer does it a little differently, the team has no shared baseline to improve from.

We had the same problem one level up. We were already writing useful Claude Code plugins and skills, and they sat siloed in personal repos with no way to install, version, or update them.

The goal was to codify the working pattern as infrastructure the whole team could install, so the good version of the workflow becomes the default.

№ 02 · The Approach

Ship a PR in one command.

I built an internal Claude Code plugin marketplace at HMH, following the standard marketplace convention, with CI validation modeled on Anthropic's official plugin repository. It hosts four plugins. I wrote three of them. Teammates add the marketplace once and install plugins from it, and updates flow automatically after that. The flagship plugin, git-workflows, turns the pull request workflow into two skills, two commands, and a hook in v1:

  • ship-pr, one command that runs the entire PR lifecycle. It pushes the branch and drafts a structured description, then runs whichever reviewers the repo supports. Each reviewer self-detects by capability, with no config switch to remember. From there it fixes legitimate findings, replies to comments, refreshes the description after every push, and posts an acceptance-criteria coverage comment back to the linked Jira story.
  • pr-description, which discovers the repo's own PR templates and recommends the best fit from the branch name, the changed paths, and the commits. It fleshes the template out and injects machine context into sentinel-marked regions (HTML comments), so any template keeps its human narrative untouched.
  • a config command that prints every resolved setting alongside its provenance: default, detected, user preference, or team policy. Configuration is an opinion cascade, so it should be legible.
  • a setup command that seeds a repo's pull request templates from a shared profile.
  • a hook that refreshes the PR's diff breakdown automatically on every push.
Component map of the git-workflows plugin: setup and config commands, the ship-pr and pr-description skills, and a push hook all coordinate through shared library helpers, with sentinel-marked regions defining which writer owns which part of the PR bodyComponent map of the git-workflows plugin: setup and config commands, the ship-pr and pr-description skills, and a push hook all coordinate through shared library helpers, with sentinel-marked regions defining which writer owns which part of the PR body
The component map from the plugin's README. Commands and skills lean on shared, tested helpers, and the sentinel contract spells out exactly who may write which region of the PR body. Click to open it full size.

Shipping a PR takes me under five minutes from a finished branch, and the outcome is the same every single time. The description is fleshed out on the repo's own template. Copilot review comments get assessed and answered. The Jira story gets comments with what acceptance criteria the PR covers. And the full agentic context rides along in a collapsed details block at the bottom, where it serves whatever tooling picks the work up next without crowding the engineer reading the description.

Flowchart of a full ship-pr run: preflight checks and hard stops, capability probes for Copilot, Codex, and the tracker, PR creation with a structured description, review evaluation and fixes, a description refresh, Copilot replies, an acceptance-criteria coverage comment on the Jira story, and final verificationFlowchart of a full ship-pr run: preflight checks and hard stops, capability probes for Copilot, Codex, and the tracker, PR creation with a structured description, review evaluation and fixes, a description refresh, Copilot replies, an acceptance-criteria coverage comment on the Jira story, and final verification
The ship-pr flowchart from the plugin's README. Every gate is a capability probe, so one command adapts to whatever the repo supports.

A few principles held the whole thing together:

  • Detection over assumption. Never assume the default branch is main. Read the forge from the remotes.
  • Team opinions packaged as adoptable profiles, so a team's preferences travel with the plugin.
  • Deterministic logic lives in tested scripts, so it runs the same way every time.

I dogfooded the plugin on its own pull request through five releases before asking anyone else to install it. The first real bug it caught was its own: the push hook clobbered the agentic-context block in the very PR description it was supposed to maintain. The fix gave the diff breakdown its own sentinel region, and the contract has held since. Underneath it all sits a test suite hundreds of tests strong over the deterministic script layer, and a CI check that keeps the version pinned consistently everywhere it appears.

№ 03 · The Impact

Under five minutes, every single time.

Under 5 min
one command from a finished branch to a reviewed, described, and tracked PR
5 releases
dogfooded on itself before team rollout
Any repo
the plugin adapts itself by capability detection
Hundreds
of tests behind the workflow the team installs

The marketplace is how the team now shares working patterns: you install a proven one and adapt it to your repo. Prototype on yourself, then codify and publish what works. That loop is becoming the team's playbook for agentic engineering, and git-workflows is its foundation, with the rest of the PR lifecycle still on the roadmap.

№ 04 · Lessons Learned

Dogfooding caught what tests could not.

A workflow becomes a standard when it is easier to install than to improvise. The fastest way to get adoption was to make the good path the path of least resistance.

Our own hook taught us why the sentinel contract matters by breaking it. Machines own the clearly marked regions, humans own the narrative, and any template keeps working.

Dogfooding is the test suite that synthetic tests cannot replace. Every release closed at least one finding that only real use could have surfaced. None of my fixtures would have caught the push-hook bug. Using the thing did.

Want workflows your whole org can leverage?

I build platforms teams rely on to ship. If you need infrastructure at enterprise scale, let's talk.