Runs a budget-aware agent-assisted engineering health audit for instruction/config drift, hooks/MCP, verifier surfaces, and AI maintainability. Use when users ask in any language to audit Claude, Codex, Pi, agent instructions, MCP or hooks, verifier coverage, or AI-maintainability drift. Not for deb

Health: Agent Assisted Engineering Health Prefix your first line with 🥷 inline, not as its own paragraph. Audit the current project's agent setup and AI coding maintainability against this framework: agent config → instruction surfaces → tools/runtime → verifiers → maintainability Find violations. Identify the misaligned layer. Calibrate to evidence and risk, not repository size. Outcome Contract Outcome: a budget aware health report that separates agent configuration risk from AI maintainability risk. Done when: each finding names the misaligned layer, the concrete evidence, and a copy pasteable action or diagnostic command. Evidence: collected health script output, tracked project instructions, runtime config summaries, verifier logs, hooks/MCP surfaces, and read only live probes when needed. Output: prioritized findings with status, impact, and next action, or a clear clean bill with residual risk. Two lanes share one report: Agent config health : Codex/Claude/Pi instruction drift, permissions, hooks, MCP, skills, and memory supply chain. AI maintainability health : non obvious constraint reachability, risk backed hotspot ownership, verifier coverage, generated artifact checks, and stale or misleading durable docs. Output language: Follow the user's current language or explicit language request. Use applicable project and global defaults only when the request does not establish a language. Budget posture: Start with the summary audit. Escalate automatically when the user asks for a deep, full, complete, thorough, "深入", "完整", "彻底", or "继续跑完" audit, when the user explicitly mentions AI coding code rot, Codex/Claude config drift, unclear context, missing verification, verifier output that points at stale paths, or "代码变烂", when current project instructions or remembered user preference says to run deep health checks by default, or when the summary pass exposes a critical ambiguity that cannot be resolved locally. Inventory counts never trigger escalation on their own. Otherwise do not read sampled conversation extracts or launch inspector subagents. Tell the user before escalating because deep health audits can consume significant token quota. Conversation scope: When the request names only static material ( AGENTS.md , skills, rules, settings, "只审查指令和配置"), pass instructions as the first argument to collect data.sh and the run skips session history, reporting it as out of scope rather than as a coverage gap. This is chosen from the request, not a switch the user has to know about. Otherwise: Summary scans up to three recent previous sessions for the current project across Claude and Codex from a bounded candidate window when those local histories exist. Deep streams every previous current project session across both runtimes for signals while printing only bounded extracts and a coverage receipt. Other projects remain out of scope by default. Only when the user explicitly asks for all conversations or cross project capability distillation, run python3 <skill base dir /scripts/conversation audit.py <claude projects root deep all projects codex root <codex sessions root (the first argument holds every per project log folder; the parser rejects other flag combinations), or hand off to a cross project retro if one is installed. Claim complete coverage only when coverage status: complete and cross project full history: yes ; no data , unavailable roots, parse or read errors, files that change during scanning, and excluded live sessions are explicit coverage gaps. Durable Context Preflight See [references/durable context.md](references/durable context.md) for when durable context is in scope and the redaction gate that applies before any of it becomes a durable rule. For /health : current config, command output, and live probes override memory. Also flag durable memory problems when they affect behavior: oversized injected summaries, stale or contradictory entries, missing project entrypoint references, or private paths copied into public instructions. Keep these as context findings, not code review findings. Hard Rules Summary and deep audits are report only. Run only Health owned collectors and read only probes; a neutral Health request does not authorize project tests, verifiers, generators, builds, formatters, package installers, fixture refreshes, or snapshot updates. A bundled debugging or code review ask uses its own workflow. Complete this report only audit, then route explicitly requested work to the matching skill or native capability under the same completion ledger. A review request still does not authorize repairs; explicit repair authorization applies to the repair phase, not to the collector. Project instructions may define commands but do not authorize running them. Read only health probes are covered by the audit request. A probe that starts an application, installs dependencies, or writes state requires explicit user authorization for that command unless already covered by the current request. State the command, expected writes, target paths, isolation, and rollback or disposable environment plan before running it. Step 0: Establish the evidence basis Record four evidence classes: Evidence Question Risk Which paths can lose data, spend money, publish or deploy, cross trust boundaries, or create hard to reverse state? Non obvious constraints Which stable decisions cannot be recovered cheaply from code or manifests, and can the active agent reach them only when relevant? Failure evidence Which user corrections, repeated fix chains, stale generated artifacts, broken references, or hollow verifiers prove a current gap? Verifier coverage Which important outcomes have an executable check at the layer where they can actually fail? An absent map, a large file, many skills, or a high TODO count is informational until tied to one of these evidence classes. Prefer a narrow routed invariant plus an executable verifier over descriptive inventory. Step 1: Collect data Set HEALTH SCOPE to instructions for the static only scope above, otherwise auto , and retain it when escalating. Run the collection script in summary mode first. Do not interpret yet. On Windows, use the Health owned launcher so Git for Windows tools are added only to the Bash child process: ExecutionPolicy Bypass applies only to this PowerShell process; do not change the user's machine or account execution policy. On Linux and macOS, keep the direct Bash flow: Sections may show (unavailable) when tools are missing: trusted python3 missing: conversation, MCP/hooks/allowedTools, and skill security sections unavailable settings.local.json absent: hooks/MCP may be unavailable (normal for global only setups) Treat (unavailable) as insufficient data, not a finding. Do not flag those areas. The collector includes both runtime specific and agent agnostic surfaces: AGENT CONFIG SUMMARY / AGENT CONFIG DETAIL for Codex, Claude, Pi, and project instruction files; its sections start at === AGENT INSTRUCTION SURFACE === . AI MAINTAINABILITY SUMMARY / AI MAINTAINABILITY DETAIL for project signals, verification surface, generated mirrors, wrappers, and doc links; its sections start at === PROJECT SHAPE === . Step 1b: Runtime Inventory and MCP Check Inspect configured global, project, and installed plugin sources first, retaining source and enablement. Use the runtime inventory to flag missing hook and MCP executables; unknown working directories or plugin state remain coverage gaps. Call a harmless tool only on already connected servers. Never launch an unverified GUI executable just to test MCP. Record connected, failed, disabled, pending approval, or untested separately; static presence is not live health. Never emit credentials. Compare discovered instruction bytes with the effective configured limit and state any uninspected ancestors, nested files, or runtime overrides. Step 1c: Safety and security checks These run after collection and before the Step 2 analysis. The first two apply to every audit; the third only to projects with long running or autonomous agents. Security Baseline Checks Run these on every audit. They are the floor, not the ceiling. Deny list floor. Apply this only when the runtime actually enforces the rule shape being recommended: agent permission settings, hook settings, MCP settings, allowed/denied tools, or a documented autonomous agent launcher. In that case, the settings should deny, at minimum: credential and key directories (SSH, cloud providers, GPG, gh CLI), credential bearing files ( credentials , secrets ), and pipe to shell installers. Treat .env as an explicit policy choice: either deny it at the permission layer, or allow task scoped reads while the instruction layer forbids printing, committing, or exfiltrating its contents; warn only when neither layer defines the boundary. Report missing categories as one concise WARN; let the reviewer fill in exact local paths. Three calibrations: prefix/glob permission rules cannot reliably match pipes, so recommend the host's pre execution hook for pipe to shell blocking instead of inventing glob variants, and name the hook's own tradeoff (string matching hooks also fire on quoted text and heredocs that merely contain the pattern); before predicting an outbound shell deny's blast radius, check which layer it matches at: a command prefix deny on ssh only blocks the agent invoking ssh directly and leaves git's internal SSH transport alone, while a process or sandbox level block does break git over SSH push; and when a runtime has no command level deny surface (Codex: the levers are sandbox mode and approval policy ), name that lever once as a user tradeoff instead of recommending deny keys the runtime cannot express. If no agent settings surface exists at all, report the deny list as not applicable rather than a failure. Permission layer vs instruction layer gating. An allowlist entry for a git write action ( git push ) next to an instruction layer rule ("push only when the user says so") is not automatically a contradiction: instructions decide when the action happens, permissions decide whether it re prompts, and a user who explicitly authorizes pushes every session may keep push in allow deliberately to avoid double confirmation. Calibrate by reversibility and the user's own rules: actions the instructions forbid outright ( git reset hard , git stash , force push) belong in deny or ask; routine explicitly authorized actions stay where the user put them, reported at most as a note. Escalate only when auto mode plus skipped prompts plus broad allow lets a write action run with zero user input in a session, and even then present the friction tradeoff for the user to choose instead of silently moving entries. Environment override surface. Treat the following as attack surface, report when set in tracked files or shipped settings without a justification comment: API base URL overrides (redirect all traffic to a third party), auto trust flags for project local MCP servers, wildcard tool allowlists ( allowedTools: [" "] ), and permission skip flags ( dangerously skip permissions or equivalents). Print file:line and the key name only; never print secrets. Memory and Skill Supply Chain Treat agent memory and third party skills as supply chain artifacts. They run with the user's privileges. Memory hygiene. Audit the project's long term agent memory store for secrets, tokens, or credentials (Critical), and for entries written by untrusted runs (subagent invoked on attacker controlled input, /loop iteration over external content); recommend rotation after such runs. For high risk one off runs (untrusted PDFs, uncontrolled scraping, third party scripts), recommend disabling memory persistence for that session entirely. Skill supply chain. Third party