Code Trips & Tips

I’ve been using HarnessKit to keep my growing zoo of AI coding agents under control — skills, MCP servers, rules, and configs for Claude Code, Codex, Cursor, and friends, all managed from one place. One agent was conspicuously missing from the lineup, though: Warp, which is where I actually live all day. So I added it.

What it took

HarnessKit’s architecture made this pleasantly boring. Every agent is an adapter — a single Rust file implementing an AgentAdapter trait that declares where the agent keeps its skills, rules, and config files. The scanner, security auditor, deployer, and UI all pick the new agent up from the trait. The bulk of the work was one new ~230-line adapter (tests included) plus some frontend bookkeeping: display names, filter colors, an original mascot, and a row in the README support matrix.

What Warp gets:

• Skills — scanned from ~/.warp/skills/ and the cross-vendor ~/.agents/skills/ (Universal Agent Skills standard), plus .warp/skills/ in projects. Install, enable/disable, audit, and cross-agent deploy all just work.
• Rules — project-level WARP.md (and AGENTS.md) tracked on the agent dashboard.
• Workflows & settings — ~/.warp/workflows/*.yaml and keybindings.yaml.

The interesting wrinkle: MCP

Warp doesn’t keep its MCP server config in a local JSON file the way most agents do — it lives in account-synced internal state, referenced by UUID. There’s simply no file for HarnessKit to manage in place. Rather than pretending otherwise, the adapter declares a new capability flag (supports_mcp_file() = false), the backend rejects cross-agent MCP deploys targeting Warp with a clear error, and the UI shows the deploy button as disabled with a tooltip explaining why. Same story for hooks and plugins, which Warp doesn’t have in the Claude sense.

Honest partial support beats silently writing config files nothing will ever read.

The payoff

$ hk status
  Agents        4 detected (claude · codex · copilot · warp)
  Extensions    187 total (183 skills · 0 mcp · 3 plugins · 1 clis)

All 575 upstream tests pass (the codebase pins invariants like the adapter count and per-agent skill paths in tests — adding an agent forces you to update them, which is exactly the kind of friction you want). For now this lives on a branch in my fork; a PR upstream may follow.

One afternoon, one new agent. Good architecture is when adding the tenth integration is boring.

Merging Upstream

I am planning to submit the PR to the upstream repository, and I’m hoping they’ll accept it.