Capability scan

Projects acquire needs faster than anyone re-checks what exists to meet them. A skill that would have saved a week is worth nothing if nobody looked for it after month one.

This scan looks. It never installs. Installation is a PM decision — an auto-installed skill is unreviewed third-party instructions injected into every agent's context, which is a supply-chain decision, not a convenience.

When it runs

At startup, the Scrum Master checks whether the project changed since the last scan:

1. .git/capability-scan-needed exists (written by the post-commit hook), or
2. the newest commit is newer than the last_scanned date in .agentic/capabilities.md

Either condition triggers a scan. At most one scan per session — a scan spawns searches and costs real money; the marker is cleared as soon as the scan completes, whatever it found.

If neither condition holds, say nothing and get on with the work.

1. Derive the project's capability needs

Do not search generic terms. Read the project first and derive 5-8 concrete needs from what it actually is:

• CLAUDE.md / AGENTS.md, the profile, and the design docs — stated domain, stack, and integrations
• Dependency manifests (requirements.txt, package.json, pyproject.toml) — the real stack, not the aspirational one
• docs/operations/ and the setback log — where this project actually bleeds
• The external services it talks to — every OAuth setup doc is an integration

Each need becomes a search query. "calendar scheduling" beats "productivity".

2. Search the skills registry

npx --yes skills find "<query>"
npx --yes skills find --owner <owner>     # to explore a promising source

Quality bar — apply it, do not just report hits:

A low-install skill from an unknown author is not a find — recommending it transfers risk to the PM while looking like diligence. Say plainly when a category has nothing worth installing; that is a real result.

Also check whether the framework's own skills already cover the need better, because they are tuned to this project and a generic skill will not be.

3. Search the MCP / API landscape

Scan for DEVELOPMENT-PROCESS servers only. Two kinds of MCP exist and only one is this scan's business:

Recommending a product-integration MCP here is a scope error: it is a feature the product needs, not a capability the team is missing. Note it as a build dependency if it surfaces, and move on.

The size limit is a real constraint

3-5 servers maximum. Every connected server's tool schemas occupy every agent's context and measurably dilute focus. Three is the sweet spot. A scan that recommends eight servers has made the agents worse.

Prefer per-role assignment over global: give the dev agents the repo and docs servers, the UX and QA agents the browser server, and the deliberating council none. This keeps each agent under the limit while the team as a whole covers more, and it matches the least-privilege capability matrix.

Check per harness

An MCP configured on one harness does not reach agents on another:

Report per-harness, not globally — "we have GitHub" is misleading if only one of three harnesses can see it, and the agents that needed it may be on the other two.

4. Write the report

Write .agentic/capabilities.md using the structure in the existing file. Required for every recommendation: name, install count, source, why this project specifically, and the install command — never run it.

Include a Not recommended section with reasons. It is as valuable as the recommendations and it stops the next scan from re-surfacing the same rejects.

Set last_scanned and delete .git/capability-scan-needed.

5. Surface at the next gate

New recommendations go to the PM at the next gate, not as an interruption. A capability scan is never urgent enough to escalate.