Wholesale AI Champions Claude Code playbook
← Champions

Brian Thomason

Windows · .NET / Azure · Platform Tooling · Infrastructure Graphs

MCPs

Seven connected, roughly ordered by how often I reach for them:

  • Azure DevOps — work items, pipelines, build logs, PRs. The single most-used MCP in my day because everything on Platform Team flows through ADO boards and YAML pipelines.
  • GitHub — code search across the org, reading file contents from branches I don’t have cloned, PR reviews. Faster than cloning a repo just to grep one file.
  • Platform Graph — our dependency graph over 400+ repos, apps, resource groups, and Azure resources. I use it for impact analysis before cross-repo changes, ownership lookups, and tracing the blast radius of shared template edits. Hosted on Azure Container Apps — the mcp__platform-graph__* tools are the ones I built.
  • Slack — searching past conversations and channel context without switching windows. Particularly useful when I need to find a decision that was made in a thread three weeks ago.
  • Cloudflare — managing Pages and Workers for platform portals. We have both NonProd and Prod accounts connected.
  • Enzo — Carvana’s internal knowledge base MCP. Good for looking up company-specific patterns and standards.
  • Cloud DB — database queries via Entra ID auth. OAuth-gated, so it prompts for login on first use each session.

I also have Playwright wired up in my team repo for browser automation when I need to verify a portal change end-to-end.

Install commands for the shared ones live on the MCPs page.

Plugins

Six from the Wholesale Marketplace, one from the official marketplace:

  • adesa-workflow — full PBI lifecycle plugin with skills for feature breakdown, story pickup, cross-repo execution, verification, and PR creation. Available but I mostly use the project-local /work-pbi skill instead (see Workflow below).
  • platform — ACA migrations, pipeline generation, Dockerfile scaffolding, SQL/PostgreSQL diagnostics and tuning, App Insights queries, and pipeline run monitoring. The Swiss army knife for infrastructure work — and the plugin I lean on hardest after /work-pbi kicks things off.
  • ws-atlas — Wholesale Atlas. Maps 376 repositories, 58 applications, and 14 teams into a queryable knowledge base. When someone asks “who owns this?” or “what calls this service?”, this is where I start.
  • new-sandbox-app — deploying sandbox container apps, diagnosing startup failures, managing secrets.
  • find-skill — searching installed and marketplace skills by keyword. Useful when I know a capability exists but can’t remember which plugin owns it.
  • biweekly-update — generates the Pathfinder bi-weekly “what’s new” post by scanning git history across both Claude Marketplaces.
  • skill-creator (official) — building, testing, and benchmarking new skills. I use this when developing skills for the platform or ws-atlas plugins.

Workflow

My home base is the Wholesale-Platform-Team repo. It has a CLAUDE.md with team conventions, a .mcp.json pointing at the platform graph and Slack MCPs, and a set of project-local skills and agents I’ve built for the team’s workflow.

Project-local skills (in .claude/skills/)

  • /create-pbi — create an Azure DevOps Product Backlog Item with the right area path, iteration, and fields pre-filled for Platform Team.
  • /refine-pbi — take a rough PBI and flesh out acceptance criteria, description, and sizing.
  • /work-pbi — the workhorse. Pull a PBI, create a feature branch, and start implementation. This skill does a lot — it fetches the work item from ADO, reads the acceptance criteria, resolves which repos are involved, clones what’s needed, creates feature branches, and gets to work. Most of my sessions start here.
  • /review-pr — structured PR review with platform-specific checks (YAML validator task present, -rc suffix on pipeline names, catalog-info.yaml updated).
  • /slack-pr-watcher — monitor Slack for PR review requests and surface them.
  • /catalog-yaml-templates — inventory and catalog yaml-templates usage across consumer repos.

Project-local agents (in .claude/agents/)

  • cross-repo-planner — plans changes that span multiple repos by querying the platform graph for dependencies and generating a sequenced execution plan.
  • dependency-auditor — audits a repo’s dependency tree for staleness, circular dependencies, and orphaned references.
  • repo-scout — lightweight reconnaissance agent for quickly profiling an unfamiliar repo.

A typical session

  1. Open Claude Code in C:\Github\Wholesale-Platform-Team.
  2. Run /work-pbi with a PBI number — it fetches the work item from ADO, reads the acceptance criteria, figures out which repos are involved, creates feature branches, and starts implementing.
  3. If the change spans repos, the platform graph MCP tells me the blast radius before anything gets touched. I’ll spawn a cross-repo-planner agent to build the execution plan.
  4. Once the code is pushed, I use the platform plugin skills to watch pipeline runs, pull build logs, and iterate on failures — fixing issues and re-triggering builds without leaving the terminal.
  5. After CI is green, I open PRs via gh CLI or the GitHub MCP, each linked to the ADO PBI via AB#<id>, and monitor for Copilot review comments.

What I’ve stopped doing

  • Cloning repos just to search them. The GitHub MCP’s get_file_contents and search_code tools plus the platform graph handle 90% of cross-repo research without touching the filesystem.
  • Manual dependency tracing. Before the platform graph existed, I’d spend 30 minutes tracing which repos consume a shared template. Now it’s one impact_analysis call.
  • Switching to a browser for ADO. Between the ADO MCP and the /create-pbi skill, I rarely open the ADO web UI except for board views.
  • Watching pipeline runs in a browser tab. The platform plugin’s pipeline monitoring skills pull build status and logs directly, so I iterate on failures in the same session where I wrote the code.

Why this works for me

I maintain tooling for ~400 production applications across 14 teams. The common thread in everything above is not leaving the terminal to gather context. The platform graph, ADO MCP, and project-local skills exist because my work is almost never “change one file in one repo” — it’s “change a shared template and verify that 47 consumers still build.” That requires dependency data, pipeline status, and cross-repo coordination in the same session where I’m writing the code.

The /work-pbi → implement → platform plugin pipeline loop is where most of my time goes. The skill pulls the PBI, I work the problem, push the code, and then the platform skills let me watch the pipeline, read the failure logs, fix the issue, and re-run — all without switching windows. That tight feedback loop is the single biggest productivity gain in my setup.