The Problem
Six concurrent projects. Three to five active repositories, including a large monorepo nobody fully holds in their head. As a fractional Technical Program Manager for an Operational Technology (OT) SaaS company, the time intensive parts of the job weren't the hard parts...it was the repetitive ones.
Things like reconstructing a week's worth of commits, Jira changes, and Slack messages into a status update. Or digging through an unfamiliar codebase to trace a root cause. Or especially turning a conversation into a Jira ticket without losing the nuance that made it useful in the first place.
None of it required brilliance. All of it required time, and six concurrent projects don't leave much of that lying around.
Design Constraints
Before writing a single skill, three constraints shaped everything that followed:
- Co-designed, not handed off. Every skill went through the same shaping conversation - generate a first pass, review the full output, revise. Most took one to three revision cycles; a few got rebuilt from scratch because they just didn't work.
- Interconnected, not standalone. A skill that only helps in isolation is a script. The system needed skills that fed each other.
- Human-in-the-loop by design, not by accident. Consent gates before anything gets created. Correction steps before anything ships. The AI drafts; a human decides.
The Solution
Eleven Claude Code skills, organized around the actual shape of the work:
/project-setup launches a project, writing the config every other skill reads. /project-complete closes the project down with a retro, archive, and cleanup.
/research turns a vague question into discrete findings and, when warranted, automatically hands off to /scope, which turns findings into right-sized work items. /create-ticket drafts the Jira issue itself using a simple, easy to read format.
/weekly-gather pulls Jira and GitHub data into a re-runnable briefing; /weekly-update drafts the exec-facing summary from it.
/investigate spawns one agent per finding to trace root cause in parallel rather than digging sequentially. /observability-audit runs an observability posture check across a project, diffing against its own last run so unchanged repos cost nothing to re-check.
/validate-audit exists because /observability-audit doesn't always get it right. It spawns agents specifically to try to disprove the audit's own claims.
How They Connect
The system's actual value isn't any single skill. It's the handoffs:
Outcomes
- 3–5 hours saved per week
- 5–10 hours saved on a single research spike
- Fifteen work items surfaced by one audit run on a codebase with zero prior context
- Ten to fifteen minutes back on every Jira ticket