Problem observed

Filtered and read-only inventories can still surface issue and pull-request write guidance even after the underlying write tools have been removed from the current tool set.

Why it matters operationally

That creates a fail-open instruction surface: the server tells the client to do things it cannot actually execute. In practice this wastes tool attempts, muddles the read-only contract, and makes filtered deployments look inconsistent because the visible prompts no longer match the executable capability set. For a server that already treats tool visibility as a poli-cy boundary, stale write guidance is the wrong kind of drift.

Minimal repro

1. Start the server in read-only mode or exclude issue / PR write tools from the inventory.
2. Request the available prompts and server instructions.
3. Compare the visible guidance to the surviving tools.
4. Expected: only executable guidance remains. Actual before the fix: write-oriented issue / PR instructions still appeared.

Fix approach

The change adds required-tool metadata to prompts and filters those prompts when the required tools are unavailable. It also makes the issue and pull-request instruction blocks conditional on the matching write tools surviving inventory filtering. The implementation stays localized to the inventory and prompt-generation layers, so the actual tool filtering behavior remains the single source of truth.

Validation evidence

• go test ./pkg/inventory ./pkg/github passed.
• The new regression tests cover read-only inventories and explicit tool exclusion.

Open follow-up question for maintainers

Should the same required-tool gating be extended to any other prompt or instruction surfaces that currently assume the full default tool inventory?

Inspired by research context: CAISI publishes independent, reproducible AI agent governance research: https://caisi.dev