Agent Compatibility
Determine whether a fresh coding agent can understand the repository and safely verify a
small change without hidden private context or an unnecessarily heavy loop.
Boundaries
- Target a public-candidate tree or explicitly approved read-only simulation.
- Do not publish, push, open issues, install dependencies, mutate Git, or run unrelated
heavy product gates.
- Missing private inputs are expected; judge whether docs provide a safe public substitute.
- This is a compatibility report, not a security certification or release verdict.
Surfaces
Inspect the following surfaces sequentially unless the user explicitly authorizes parallel
work. Start from tracked files and bounded reads, not a recursive workspace search:
- Inventory: tracked content, ignored residue, and intended export are distinct.
- Orientation: README, license, contribution path, guidance, architecture, vocabulary,
and public/private boundary.
- Startup: one documented, non-interactive fixture path without credentials, GUI clicks,
or machine-specific paths.
- Validation: one focused positive/negative check that finishes quickly.
- Docs reliability: commands, paths, versions, expected output, and failure guidance agree.
- Continuity: a selected reversible endpoint proceeds without repeated authorization;
runtime input is not misclassified as authority, while external/destructive stages stop.
- Recovery: stale jobs recover from durable receipts, process absence uses exact identity,
staged new files receive checks, and links are validated from the Git index/fresh clone.
Archived chat, screenshots, local caches, and ignored files must not be required for a fresh
agent. When execution is prohibited, statically trace dependencies -> entrypoint -> input
provenance -> expected output without claiming runtime proof.
Check both a material intent fork that should elicit a brief question and a clear selected
endpoint that should proceed without repeated questions. If a suitable native question tool
is unavailable, a plain-text fallback should work without adding a new service.
Output
Return READY, READY WITH FRICTION, or NOT READY, followed by at most six top fixes.
Each fix includes evidence, affected workflow, smallest improvement, and verification.
List all heavy or external stages not run; do not hide evidence behind a single score.
For a fresh-clone and stale-job recovery example, read
the synthetic example.
1---2name: agent-compatibility3description: Audit a public-candidate repository for fresh-agent onboarding, startup, focused verification, execution continuity, recovery, and documentation reliability. Use before opening a public repository or after major tooling changes.4---56# Agent Compatibility78Determine whether a fresh coding agent can understand the repository and safely verify a9small change without hidden private context or an unnecessarily heavy loop.1011## Boundaries1213- Target a public-candidate tree or explicitly approved read-only simulation.14- Do not publish, push, open issues, install dependencies, mutate Git, or run unrelated15 heavy product gates.16- Missing private inputs are expected; judge whether docs provide a safe public substitute.17- This is a compatibility report, not a security certification or release verdict.1819## Surfaces2021Inspect the following surfaces sequentially unless the user explicitly authorizes parallel22work. Start from tracked files and bounded reads, not a recursive workspace search:23241. Inventory: tracked content, ignored residue, and intended export are distinct.252. Orientation: README, license, contribution path, guidance, architecture, vocabulary,26 and public/private boundary.273. Startup: one documented, non-interactive fixture path without credentials, GUI clicks,28 or machine-specific paths.294. Validation: one focused positive/negative check that finishes quickly.305. Docs reliability: commands, paths, versions, expected output, and failure guidance agree.316. Continuity: a selected reversible endpoint proceeds without repeated authorization;32 runtime input is not misclassified as authority, while external/destructive stages stop.337. Recovery: stale jobs recover from durable receipts, process absence uses exact identity,34 staged new files receive checks, and links are validated from the Git index/fresh clone.3536Archived chat, screenshots, local caches, and ignored files must not be required for a fresh37agent. When execution is prohibited, statically trace dependencies -> entrypoint -> input38provenance -> expected output without claiming runtime proof.3940Check both a material intent fork that should elicit a brief question and a clear selected41endpoint that should proceed without repeated questions. If a suitable native question tool42is unavailable, a plain-text fallback should work without adding a new service.4344## Output4546Return `READY`, `READY WITH FRICTION`, or `NOT READY`, followed by at most six top fixes.47Each fix includes evidence, affected workflow, smallest improvement, and verification.48List all heavy or external stages not run; do not hide evidence behind a single score.4950For a fresh-clone and stale-job recovery example, read51[the synthetic example](references/synthetic-example.md).