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.
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.
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.
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.
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.
Under five minutes, every single time.
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.
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.