@druwerdGitHub ↗

Dru Ibarra

Backend engineer on a multi-service platform. Claude Code does ticket-to-draft-PR work through personal skills, with guardrail hooks, parallel subagents and my own runtime checks before merge.

How this setup has evolved

Version 1 · Latest

Shared this setup with the community.

What I build

Backend and web features for a company platform made of about 30 separate service repos (Rails, TypeScript, React Native, GraphQL federation, Kafka). Most features touch two or more services. I use AI for the whole ticket loop: scoping, planning, writing code test-first, reviewing PRs, and chasing production errors. I keep runtime checks and merging for myself.

Agents & harnesses

  • Claude Code (current): My main agent. It runs from a workspace folder that holds every service repo side by side.
  • Claude Code subagents (current): Custom agents for writing tickets, designing cross-service features, code review and QA. Parallel ticket work also runs as subagents.
  • cmux (current): The terminal where my Claude Code sessions run.

Apps

  • Obsidian (current): A notes vault for specs, plans, ticket notes and investigations. Skills write to it, so the agent's research outlives the session.
  • Google Chrome (current): Driven by the agent through Chrome DevTools MCP to click through a change and collect evidence.
  • Docker (current): Runs the local service stack for end-to-end checks.
  • Slack (current): Where teammates post PRs for review, and where the agent picks them up.

Models

  • Opus with 1M context (configured): Default model for Claude Code, high effort.
  • Fable (configured): Set as the advisor model that reviews the main agent's approach before and after big steps.

Skills

From Superpowers

  • test-driven-development, writing-plans, verification-before-completion (current): My defaults. Plans come before any task over three steps, a failing test comes before the fix, and evidence comes before "done".

From Anthropic's official plugins

  • code-review, feature-dev, skill-creator, chrome-devtools-mcp, slack (installed): Review, feature scaffolding, skill writing and browser driving.

From obsidian-skills

  • obsidian-markdown, obsidian-cli, obsidian-bases (installed): Correct vault formatting.

Personal skills (private)

  • prp (current): Reads the ticket, explores every affected repo and writes a plan to a NOTES.md file before any code.
  • preflight (current): Detects the repo type and runs typecheck, lint and tests locally.
  • ship-it (current): Simplifies the diff, runs preflight, makes small commits, self-reviews, pushes and opens a draft PR.
  • verify (current): Reads the diff and picks a mock server, the local stack or staging to check the change actually works.
  • ticket-swarm (current): Works up to three ready tickets in parallel and stops each one at a draft PR.
  • pr-review / review-open-prs (current): Reviews a PR in an isolated worktree, or triages the team's open PR backlog and fans out reviews.
  • investigate-datadog / monitor (current): Chases a production error to a root cause, or takes a quick health snapshot of a service.
  • deploy-ready (current): A read-only go/no-go on what sits between production and main.
  • Domain skills (current): Adding Kafka consumers and producers, and extending federated GraphQL types, following team ADRs.
  • tidy-repos / tidy-tickets / tidy-reviews (current): Housekeeping for the workspace, finished ticket worktrees and old review files.
  • vault (current): Owns the note formats in Obsidian.

Hooks and instructions

  • Branch protection hook (current): Blocks commits and pushes to main or master.
  • Pre-commit preflight hook (current): Runs checks before a commit goes through.
  • Plain English output style (current): A custom style that bans filler, nicknames and vague references, so answers and PR bodies read on the first pass.
  • Global CLAUDE.md (current): Plan first, test first, read the real database schema before touching any column, and verify before claiming completion.

MCP connections

  • Shortcut (current): Tickets. A ticket-writer subagent drafts and creates them.
  • Datadog (current): Logs, traces and monitors for investigations.
  • Slack (current): PR backlog and channel context.
  • Notion (current): QA test plans the agent runs against staging.
  • Chrome DevTools (current): Browser automation for runtime checks.
  • mysetup (current): Maintains this page.

How I work

  • I describe a ticket in terms of what and why. The ticket-writer subagent explores the repos and returns a draft. Nothing is created until I approve it.
  • Each ticket gets its own git worktree workspace across the repos it touches. /prp writes the plan to NOTES.md, and I read it before any code is written.
  • The agent implements test-first and runs /ship-it, which ends at a draft PR. For a batch of ready tickets, /ticket-swarm runs up to three at once and stops at the same point.
  • I run /verify myself, mark PRs ready and merge. Agents never do those steps.
  • When something breaks in production, /investigate-datadog finds the cause. I save the finding as an investigation note in the vault, and any lasting lesson goes into Claude's memory.

What I learned

  • Subagents can't answer permission prompts. Any write tool a subagent needs has to be pre-allowed, or it gets silently denied.
  • Headless claude -p runs with permissions skipped got blocked, so parallel ticket work runs as in-session subagents instead.
  • My local stack starts the main checkout of each service, not the ticket worktree. Runtime checks can quietly test the wrong code unless I point them at the worktree.
  • An empty grep of lint output looks exactly like a clean run. I have the agent read the summary line instead.