Every feature exists for
one reason: fewer blockers.

Repo Standards Enforcement

Agents can't navigate chaos. If every project has a different structure, different scripts, different CI config — every project requires hand-holding. That hand-holding is what keeps you serialised.

Consistency solves this. The enforcement skill applies portfolio-wide templates to any repo:

• Standardised Makefile with identical targets across all repos
• Unified CI pipeline templates (GitHub Actions)
• Linter configs for every supported language
• Coverage config with monotonically-increasing thresholds
• Dev container configs for consistent environments
• Language-specific .gitignore templates
• CLAUDE.md injected into every repo so agents know the rules

Drop an agent into any project and it already knows how to run, test, and ship — no setup, no babysitting. That's what makes twenty projects manageable instead of twenty separate headaches.

Automated Quality Gates

Agents don't hand you rough drafts. They fight through quality gates the entire way. There is no soft-fail mode.

• Lint — format violations tank the pipeline
• Type check — strict mode, no any escapes
• Code format — enforced by CI, not just recommended
• Unit tests — must pass; no skipping
• Integration tests — end-to-end verification
• Coverage thresholds — monotonically increasing, never regress
• CI pipeline — GitHub Actions gate before merge

By the time code reaches you, it has passed every automated check. You're the final gate — reviewing for intent, architecture, and edge cases. Not checking whether the tests pass.

PMO Dashboard

Your control panel. It scans every repo under ~/Documents/Code/, gathers status from git and the GitHub API, and generates a self-contained HTML report that refreshes automatically every few minutes. No server. No login. No cloud.

Per-repo it collects:

• Uncommitted file count
• Current branch name and push/pull status
• Last commit date and message
• Open PRs — with a fallback to any open PR if branch differs
• CI status via gh CLI
• Latest GitHub release tag

You're not context-switching into each repo to figure out what's happening. The dashboard tells you. You decide where to direct attention. That's minimal cognitive load.

Parallel Agents, One Working Tree

Got a monolith or multi-service codebase that can't be split up? Multiple agents work the same repo at the same time — one checkout, one branch, no extra copies on disk.

Git worktrees are banned. Agents reliably wreck them — orphaned trees, detached HEADs, branches stranded on disk. Agent PMO coordinates concurrency at the file level instead, through Too Many Cooks (TMC) — an MCP server every agent in the workspace connects to. They all see the same live picture, so before an agent touches a file it claims it, and every other agent sees that claim in real time.

TMC exposes five tools: register, lock (advisory file locks), message (direct or broadcast), plan (shared intent), and status — all pushed to every connected agent in real time, no polling.

• One working tree, one feature branch — no worktrees, no stray copies
• Register on connect: descriptive name, intent, files to touch
• Lock files before editing — never edit a locked file
• Broadcast plans before starting; check messages as you go
• Release locks when done — conflicts are prevented up front, not merged away after

Learn more at the Too Many Cooks website, or watch agents coordinate live in the VS Code extension.

Spec-Driven Traceability

When 20 agents are building across 20 projects simultaneously, you need to know exactly what was built, why it was built, and where to find the tests that prove it works. Spec IDs are the answer.

Every spec section gets a unique ID: [AUTH-LOGIN], [AUTH-TOKEN-VERIFY], [CI-COVERAGE]. These IDs become the connective tissue of the entire system:

• Spec sections define requirements: [AUTH-LOGIN] User Authentication
• Code declares what it implements: // Implements [AUTH-LOGIN]
• Tests declare what they verify: // Tests for [AUTH-LOGIN]
• PRs list the spec IDs they address in the description
• Plans reference spec IDs in their TODO checklists

Because IDs are plain text, a simple grep answers any traceability question: what tests cover a spec, what's untested, what a PR delivered, and whether any spec IDs are orphaned.