How One Engineer's Frustration Turned Our SDLC Into A Plugin

Introduction

Eleven skills, one command, and a quiet shift in how we move work from a Jira ticket to a reviewed pull request.

This story does not start with a model. It starts with an engineer who had had enough. Not enough in the dramatic sense. He was not burning out, and he was not rage-quitting anything. He had simply gotten tired of watching the same thing happen every time someone moved teams or moved on. The institutional knowledge that nobody bothered to document, the small judgment calls that lived only in people's heads, would walk out with them. New people would walk in and slowly rebuild what was lost.

So he sat down one afternoon and wrote eleven of them out.

Eleven skills. Each one was a decision the team made, so often nobody thinks to document it. How do we branch off the main? How we structure a spec before we touch code. What we run before we open a pull request. Which Drupal patterns do we prefer and which ones do we reject? What "ready for review" actually has to look like before a reviewer gets pinged.

Within hours, teammates had adapted the same framework for Mautic. A client team deployed it on their own work the same week. The plugin is now part of how we move every Jira ticket through the system, and the bigger lesson it taught us is the part of the story we want to share.

The Quiet Cost Of Tribal Knowledge

If you have run an engineering team for any length of time, you know this feeling. There is a person on the team who knows how things actually work. They know that a particular module needs a config export before merge. They know which tests in CI are flaky and which are signal. They know to check a specific service before reproducing a bug, because nine times out of ten that is where the issue actually lives.

When that person leaves, you do not lose a person. You lose a quiet operating system.

For a while, the new joiner stumbles. PRs come back with review comments that the previous engineer would have caught before pushing. Specs get written without the constraints that the team had silently been honoring. Estimates get worse for a few sprints because the new person does not know which tickets are usually two-line fixes and which always become epics.

You patch this with documentation. Documentation helps. But documentation also goes stale, and worse, it does not load when you need it. The engineer at 11 pm on a Tuesday, looking at an unfamiliar bug, does not browse the wiki. They guess.

The eleven skills were originally designed to fix that. Not by replacing documentation, but by making the team's actual habits executable.

What The Eleven Skills Actually Do

Each skill is small. Most of them are a few hundred lines of plain English instructions, with a handful of tool calls Claude is allowed to make.

There is a spec-writer skill that takes a Jira ticket description and produces a structured spec with numbered acceptance criteria, test mapping, and the specific Drupal constructs the team prefers. There is a work-on-jira-ticket skill that picks up a ticket key, branches off the main, and runs the whole loop autonomously. There is a validate skill that runs linting, config import, config round-trip checks, Playwright screenshots, and tests after a feature is built. A pr-creator skill assembles the PR description, the test plan, and a risk score. A pr-reviewer skill runs a security checklist and verifies acceptance criteria coverage before merging. A code-quality-fixer skill takes PHPStan or PHPCS errors and patches them. A module-scaffolder skill generates a Drupal module boilerplate, especially for API integrations.

A few of them exist precisely because of past pain. The hotfix skill bypasses the spec-writer for urgent fixes, because we kept reaching for the full loop in moments where it was the wrong call. The onboarding skill auto-detects project values and verifies that the toolchain is wired correctly, because new joiners were burning their first morning configuring things instead of contributing.

None of them are general purpose. Every single one encodes how this specific team builds Drupal projects. That is the point. A general SDLC tool would not know what we mean by "ready for review." These skills do, because we wrote them to know.

What Changed In Day-To-Day Work

The visible change is the command. An engineer types, work on PROJ-1234 and the system handles spec, branch, code generation, validation, tests, and PR creation. The engineer reviews the diff, edits where needed, and approves.

The less visible change is who can move work through the system. A junior engineer who joined the team last month opened their second PR using the same conventions as the senior who has been there for four years. Not because the junior had memorized the conventions. Because the conventions are now in the loop, not in the head.

This shifted how review meetings feel. There are fewer comments about formatting and structure, more comments about logic and intent. The conversation moved up one level. Reviewers focus on the parts of the work that require judgment, because the parts that do not are already handled before they look at the code.

We also stopped losing time to small-format inconsistencies between developers. When Claude produces the spec and the PR description, they look the same regardless of who triggered the run. Reviewers no longer had to mentally re-parse the same information presented in six different ways.

The Adaptation We Did Not Plan For

The bit that surprised us happened within hours of the original engineer pushing the plugin internally.

A teammate who works mostly in Mautic looked at the 11 Drupal-specific skills and thought, "I can do this for our stack." He forked the structure, swapped out the Drupal-specific guardrails for Mautic-specific ones, and shipped his own version the same day. A client team that had been watching us work picked up the pattern and deployed it on their internal codebase the same week.

This is the part we want to highlight, because it teaches the actual lesson.

The skills work because they are written down. The fact that they are written down is what makes them portable. None of the people who adapted the plugin needed to be told how it worked. They read the skills, understood the system's shape, and built their own.

This is what openness looks like in practice. It is not a value statement. It is a habit of writing things down clearly enough that anyone or anything can run with them.

What's Next

We are continuing to engineer skills as patterns emerge. A new one for handling Drupal config schema drift is in review. Another structured release notes system is being trialed. The bar for adding a new skill is simple. If we make the same judgment call more than three times across the team, and someone gets it wrong because they cannot find the previous example, that judgment call belongs in a skill.

We have also started thinking about what happens when this approach scales beyond engineering. The same shape, eleven small skills encoding a team's actual habits, applies to discovery work, to delivery operations, to QA. We are early on those, but the pattern travels.

If your team has a quiet operating system that nobody has written down, we are happy to think through how to surface it. The act of writing it down often turns out to be more valuable than whatever automation you build on top.