aoilisted

# Govern work with AOI This is a user-scope, cross-project skill. Project-specific paths, architecture, tool flows, evidence requirements, and exclusions belong in that project's `AGENTS.md`, `aoi.toml`, and current source/docs—not in this skill. AOI is a cooperative procedural guardrail for authority, exact claims, evidence, checkpoints, jobs, and bounded delegation. It is not a filesystem sandbox. ## Establish the project and executable 1. Find the exact Git worktree root. 2. Read every applicable `AGENTS.md`. 3. Read `aoi.toml`, `.aoi/POLICY.md`, and the short `.aoi/INDEX.md` when present. 4. Run `aoi --version`, `aoi status --json`, and `aoi chief-status --json`. 5. If project hooks use an absolute `.../bin/aoi-codex-hook`, prefer the sibling `.../bin/aoi` and confirm its version. Do not mix PATH, hook, or wrapper installations against one live state tree. Read-only explanation and inspection need no AOI task. Before a material edit, external launch, evidence write, process stop, merge, or other state change, resume or create exactly one task. If a project still documents an older project-local harness/wrapper, do not use it automatically. Prefer the installed AOI CLI; treat the wrapper as a migration/history surface unless the project explicitly proves it remains the authoritative interface. ## Chief and session fencing Only one root session may own lifecycle mutations. If a hook supplies a valid session/task mapping, resume it: ```bash aoi resume --ses