AGENTS.md

Code Review Rules

• Failure means package instructions in skills/*/SKILL.md, agents/*/AGENT.md, or commands/*/COMMAND.md contradict their bundled scripts/references and make the documented workflow fail or take an unauthorized action.
• Failure means a package description routes a concrete request to the wrong package or excludes an intended invocation; demonstrate the conflicting trigger and workflow rather than guessing from a name.
• Failure means scripts/generate_manifest.py, scripts/generate_adapters.py, or scripts/build_router_index.py drops or misrepresents package metadata, required supporting files, or history-derived routing evidence; identify the affected package/host/request.
• Respect CI coverage: package.yml checks manifest drift and regenerates/validates adapters, but does not compare committed adapters for drift; router-index.yml rebuilds on main/schedule/manual dispatch, not as a PR synchronization gate. Report semantic generator defects or demonstrated adapter drift at their source, not duplicate manifest/frontmatter/reference/eval-schema gate errors.
• Do not report style, formatting, naming nits, or diagnostics already enforced by Ruff, mypy --strict, ESLint, or tsc within their configured scopes in .github/workflows/tests.yml and extensions/package.json; speculative hardening is not a finding.
• Review PR-introduced failures only. Tag unchanged-code issues Pre-existing without requesting a fix; do not repeat findings already raised on an earlier commit of the same PR unless the attempted fix introduces a distinct failure.
• Paths to skip for line-by-line review: generated manifest.yaml and adapters/**; review canonical package definitions and generator logic instead. Generated-output comparisons may support a source-level finding.
• Lockfiles (uv.lock, extensions/bun.lock) stay in scope for dependency changes: flag packages added or version-changed without a matching change in pyproject.toml or extensions/package.json; do not review them line by line.
• Every finding must name file:line, the concrete failing scenario and consequence, and the bug class so the author can fix every instance; tag it Important, Nit, or Pre-existing. A suggestive identifier alone is not evidence.
• Start the summary with the count of Important findings; when there are no actionable findings, say plainly: "Nothing to fix."
• Keep completion criteria, templates, and eval rubrics conditional on the selected workflow branch: stop, rejection, zero-candidate, and small/no-plan paths must not require artifacts or continuation that their own instructions forbid.