agent-readiness

# Agent Readiness > An agent's effectiveness in a repo is capped by what the repo lets it verify. Score the affordances, not the code quality. This skill **measures and remediates affordances**. It may create a scaffold (an `AGENTS.md`, an `ARCHITECTURE.md`) only when the repo's own evidence fills it enough to pass the signal, then hands the prose to the owning skill (`vd:docs`, `vd:skill-creator`). It never writes the architecture narrative, and never refactors code to raise a score (`vd:simplify --aggressive`; `vd:scout` for locating code). ## Hard rules 1. **Identical repo, identical output.** Score on committed evidence. Prefer existence checks over deep semantic analysis, order signals by id, and cap each rationale at ~500 characters. Record an `as_of` date and score every date-relative clause against it, run runnable checks in the repo's declared environment rather than against whatever the host happens to have installed, and treat missing API access as a fallback to static config evidence - never as non-applicability. Live measurements (CI durations, status APIs) are reported as observations and never change a score. A score that drifts with the host, the clock, or a token's permissions is not a property of the repo. **One signal is explicitly weaker:** `service_dependencies_documented` matches config keys to services by name, so `references/signals.md` marks it `determinism: narrowed` and requires the collected list verbatim in the rationale. That caveat is named ...