Dmytro Gaivoronsky

🇺🇦 🇺🇸 Engineering leader & builder. 25+ yrs in tech including Google, AWS, and Meta.

3 minute read

I’ve been building Claude Code skills since November, one friction point at a time. A task I did twice became a command. A command I kept tweaking became a skill.

I went through my session logs and pulled usage numbers. For each skill I’m showing two stats: the percentage of active Claude days where I used it at least once, and the raw invocation count over the last four weeks.

I also use community skills, particularly Obra’s superpowers for brainstorming, TDD, debugging, and code review. Awesome Claude Code has a growing list if you want to browse what’s out there. But the ones below are mine. I built my first one back in November and kept going.

Heavy traffic

These three account for the majority of my skill invocations.

oneshot (32% of days, 78 last month)

Takes a detailed implementation plan, analyzes the task graph, breaks it into waves of parallel work, dispatches sub-agents to implement each task, runs a two-stage code review (spec compliance + code quality) between waves, validates with linters and tests, commits, creates a draft PR, monitors CI, and addresses CodeRabbit feedback.

The orchestrator is a thin lead agent that never runs commands itself. It dispatches everything. This keeps its context window clean across multi-wave implementations.

babysit-pr (25% of days, 93 last month)

The complement to oneshot. Once a PR exists, babysit-pr takes over. Gathers CI status, CodeRabbit feedback, CodeQL findings, and coverage reports in parallel. Fixes lint errors, type issues, missing test coverage, legitimate review findings. Loops until all required checks pass. I talked about this feedback loop in where the work goes when agents arrive.

It evaluates each automated review comment rather than blindly implementing all of them. Pushes back on nitpicks, fixes real issues, skips subjective style preferences.

cleanup-worktree (24% of days, 17 last month)

Removes a finished git worktree and deletes the branch. Verifies the branch is actually merged, checks for uncommitted work, asks before doing anything destructive.

Moderate traffic

wt (5% of days, 34 last month)

Created three weeks ago, so the day-percentage is misleading.

The counterpart to cleanup-worktree. Creates a new worktree, stashes any in-progress changes (including untracked files), pops them in the new directory, runs post-creation setup. Enforces a session rule: all subsequent work stays inside the worktree so the agent doesn’t accidentally edit files in the main repo. I track parallel sessions with topic summaries in my tmux status line, so knowing which worktree I’m in matters.

rebase (8% of days, 1 last month)

Rebases the current feature branch on origin/main and force-pushes with --force-with-lease. Validates you’re not on the default branch, checks for uncommitted changes, aborts cleanly on conflicts. Usage spiked in January and dropped off since.

Low traffic

Low invocations here doesn’t mean low value. Some of these are one-time-per-repo tools by design.

bootstrap-quality (5% of days, 13 last month)

Takes a working prototype and adds production-grade quality infrastructure: pre-commit hooks for linting, formatting, secrets detection, and SAST via Semgrep. CI workflow with a sentinel pattern. Test coverage thresholds. Cyclomatic complexity gates via Lizard. GitHub branch protection rulesets. Dependabot with auto-merge for minor and patch updates. Supply chain security review. Release Please for semantic versioning. README with badges.

Interactive 11-phase setup. Detects what exists (Go? TypeScript? Python?), asks preferences, executes. Used on 8 repos, once each.

cleanup-all-worktrees (6% of days, 10 last month)

Batch version of cleanup-worktree. Run from the main repo, it scans all branches with worktrees, checks each for merged PRs with no unpushed work, and deletes the safe ones. Periodic housekeeping when worktrees accumulate.

oneshot-team (4% of days, 7 last month)

Evolution of oneshot with persistent agent teams instead of ephemeral sub-agents. Implementers and reviewers retain context across waves, message each other directly, self-claim tasks from a shared list. Trade-off is token cost: each teammate is a full Claude instance for the duration of the plan. Still experimental.

What’s not on this list

Plenty. Each project has its own skills that live in the repo’s .claude/ directory. I have project-specific skills for speckit (spec-driven development), blog writing, and various domain workflows. I also rely heavily on community plugins, particularly Obra’s superpowers for brainstorming, TDD, systematic debugging, and code review.

If any of these sound useful, let me know. Happy to share the source.

Cheers.

Updated:

Comments

You May Also Enjoy

Reducing Attack Surface for AI Agents: Process-Scoped Credentials

6 minute read

Run env in your terminal. Everything you see there, your AI agent can see too. Claude Code, Cursor, Codex, Windsurf, whatever you use. These tools run as processes on your machine with the same permissions as your shell. If you have AWS_SECRET_ACCESS_KEY in your .zshrc, the agent has it. If you have a .env file with database credentials, the agent can read it. If you exported a Stripe API key three months ago and forgot about it, the agent still knows. This isn’t a bug. It’s how processes work on Unix.

iTerm2 Badges for Claude Code: Know Which Repo You’re In

3 minute read

I wrote about session topic summaries a month ago. That plugin generates a one-liner describing what each Claude Code session is doing and sticks it in the tmux status line. It works. I still use it. But there’s a simpler question I need answered faster: which repo is this? When I have four or five Claude sessions open across different projects, the session topic tells me what I’m doing but not where. I kept glancing at tmux panes, reading the topic, then mentally mapping it back to a repository. That’s one step too many.

I Built an MCP Server for Mountaineers.org

3 minute read

I’ve been a member of The Mountaineers for a few years now. I’ve taken a few courses, climbed a few peaks, gone on a bunch of activities, and made a few friends. At some point I also started building little tools around the site: a Chrome extension that syncs my activity history, a CLI for PeakBagger, and a Claude Code plugin that pulls route beta from a few places. Same itch every time: I want the data without clicking through five tabs. The missing piece was letting an AI assistant query mountaineers.org directly. A lot of that site is public for anyone to browse. MCP just turns those pages into structured results so Claude/Codex can answer questions like “what scrambles are on the calendar?” If you’re a Mountaineers member, the same idea gets more useful: you can ask about your own registrations, activity history, and course enrollments.

Where the Work Goes When Agents Arrive

7 minute read

A friend dropped this in our Slack the other day about Steve Yegge’s Gas Town: I think Gas Town is directionally correct but you have to admit also unhinged in a bunch of ways. I can’t help but be attracted to the absolute gonzo yolo mentality that birthed it, but I wouldn’t want to live there. It’s been rattling around in my head since. He’s right on both counts. And I say that as someone who actually lives there. The main thing I keep noticing isn’t the tools. It’s where the work goes. Over the last six months living in Gas Town, the biggest shift hasn’t been speed, it’s attention. This post is about how that attention moves upstream into design and guardrails, and how the feedback loops change once you stop reading every line.