Claude Project Manager

The same four questions as every engagement

Which outcome

Lower costs

Which metric

Hours spent per repository deciding whether to continue, archive or delete it

Today's baseline

Not measured yet

60-day target

Not measured yet

What was built, and why

Repositories accumulate faster than they’re retired

• Different technologies in every repository: a useful audit has to recognize a Terraform module, a Next.js application, and a bare script folder on their own terms.
• Inconsistent project state: some repositories are actively maintained, some are finished and stable, some were abandoned mid-feature.
• Continue-or-retire is a real decision with a real cost of being wrong: recommending deletion for something the owner still uses is worse than being conservative.
• Specialized technical assessment doesn't belong in one generalist pass: security posture, cloud/IaC footprint and test coverage are different kinds of expertise.
• The audit itself must not be the risk: a tool reading third-party repository content must not act on anything it finds there.

An orchestration model, not one large prompt

Discover, audit, review, classify, then - only if asked - configure

Seven agents. One boundary.

Read-only agents (no Write/Edit tool, run in plan mode):

Safety is architectural, not aspirational

• Read-only analysis: six agents hold no Write/Edit tool and run under permissionMode: plan.
• Write-capable configuration is architecturally isolated in a separate agent, never invoked as part of an audit.
• No automatic deletion, no automatic archiving, no silent modification - every classification is documented as a recommendation.
• No invented evidence - every agent names what it could not determine rather than filling the gap with a guess.
• No inferred user intent - where a classification depends on the owner's intent, the result is NEEDS-INVESTIGATION with the specific question, not a guess dressed up as fact.
• Validated against real repositories, not only described.

Real findings from real verification runs

• An asynchronous-delegation bug: the first end-to-end orchestration run showed the orchestrator handing back a report before a delegate had returned, producing no classification. Fixed by requiring synchronous delegation.
• An unsatisfiable instruction: the orchestrator was originally told to write its report to a file despite holding no Write tool. Fixed by returning the report as text.
• Read-only agents that weren't fully read-only: verification caught a scratch-file write and a network call by agents meant to be read-only. Both are now explicitly forbidden in every read-only agent's instructions.
• A duplicated CI trigger and a non-gating smoke check, found by the testing specialist on a real repository, with file-and-line evidence.
• A rendering defect and documentation/code drift, found by the architecture specialist on the same repository.
• A classification self-consistency bug: a report labeled DELETE-CANDIDATE while its own Missing Information section named the owner's intent as the deciding factor. Fixed by reordering the output template and requiring the two to agree.
• A live reproduction of that same boundary issue on a real local repository, followed by a live confirmation - in an isolated process - that the fix produces the correct NEEDS-INVESTIGATION result.

Validated against real repositories

• Plugin structure validated (marketplace manifest, plugin manifest, agents directory, skills directory).
• Every agent run at least once end-to-end against a real repository.
• Fresh-user installation exercised from an empty Claude Code configuration, for both the plugin route and a direct-deploy script.
• Read-only behavior verified as a filesystem and git-state invariant: a target repository's git history and a hash of every tracked file's contents were identical before and after an audit.
• Classification regression-tested by hand across repeated runs on the same borderline repository, which motivated an ordered decision procedure.

What it’s actually built with

What changed during development

• Project-scope agent definitions don't reuse across repositories - packaging as a Claude Code plugin let the same seven agents install once and apply to any repository, not just the one containing the definitions.
• "Read-only" has to be verified at the filesystem and network level, not assumed from the prompt.
• Classification ambiguity is a design problem, not a prompting problem: an evaluation order and an explicit rule for the one boundary that depends on unknowable owner intent fixed what tighter wording alone didn't.
• A fix isn't verified until it's exercised in a genuinely fresh, isolated process - an already-running session keeps the agent definitions it loaded at start.
• Isolated, fresh-user installation testing catches what testing against an already-configured environment doesn't.

Future work - not current functionality

• Automated golden-fixture regression tests, replacing the current hand-run specifications.
• Richer, structured portfolio reporting alongside the current text report.
• Additional specialized reviewers, added only when a real recurring need is demonstrated.
• Optional, explicitly-invoked online checks, kept separate from the default offline audit.
• Report persistence and formatting as a separate, human-invoked step.