From Architect to Shipper: Why I Built the SDLC Plugin

Architecture is my DNA. Guiding technical teams, shaping systems, drawing the line between “this scales” and “this becomes tomorrow’s incident” — that’s the work I love. It’s also the work I want to do faster. Not because perfection is the destination — I know it isn’t — but because the journey toward it is what keeps the work interesting.

That tension between loving the role and wanting to move faster is the whole story behind the SDLC Plugin.

Before AI: the fun part was the front of the funnel

For years, the exciting work happened before a single line of code was written. Understanding the problem, shaping the architecture, deciding which invariants matter — that was the creative part. Once the plan was solid, writing the code felt more like transcription. Necessary, but not the reason I got into this.

That meant the parts of my day I enjoyed most were bounded by the parts I enjoyed least: the long stretch between “the design is clear” and “the thing is shipped.”

AI development: superpowers, then new blockers

When AI-assisted development matured, it genuinely felt like getting superpowers. The transcription gap collapsed. Designs that used to take a week to implement could be realized in hours.

But superpowers come with new problems. Once the act of typing code stopped being the bottleneck, a different set of blockers came into focus:

Micro-management of the assistant — stopping every few minutes to nudge, correct, or re-scope.
Repetitive workflows — commits, reviews, PRs, version bumps, changelog entries, the same sequence of steps on every change.
Context loss between steps — rebuilding the same mental model over and over because the tooling didn’t carry it forward.

The time I used to lose to writing code, I started losing to orchestrating it. Different bottleneck, same outcome: still not close enough to continuous delivery.

Why a plugin, and why now

I didn’t want to solve this with more discipline or more documentation. I wanted the tooling to absorb the repetitive parts so my attention could stay where it’s actually valuable — understanding the task, providing context, planning the delivery, and tightening the quality gates.

That’s what the SDLC Plugin is for.

What the plugin does

The plugin is a set of skills and workflow automations built on top of Claude Code. In short:

Skills for the daily grind — planning, committing, reviewing, PR creation, versioning, received-review handling. The repetitive steps become one-shot invocations with sensible defaults.
Project-level configuration — the skills adapt to how your project works, so they aren’t blocked by conventions they can’t guess. Your review dimensions, your PR template, your guardrails.
End-to-end workflow via ship — instead of running each step manually, ship chains plan → execute → commit → review → fix → version → PR into a single flow. You focus on what to build; the plugin handles how to get it delivered.
OpenSpec compatibility — specs drive plans, plans drive execution, execution maps back to specs. Spec-driven development as a first-class citizen, not an afterthought.

The underlying bet

The bet is simple: in an AI-assisted world, the valuable work is understanding the task, providing context, planning the delivery, and evolving the quality gates. Everything else is mechanical, and mechanical work should be automated until it disappears.

Continuous delivery has always been about shrinking the gap between “we decided” and “it’s in production.” The SDLC Plugin is my attempt at shrinking that gap one more time — for myself first, and for anyone else who feels the same pull between loving the design work and wanting to ship faster.

If that resonates, take a look: github.com/rnagrodzki/sdlc-marketplace.