/context-tree-audit

name: context-tree-audit
description: Audit stored normal content on the bound Context Tree's actual binding branch when a human explicitly asks to audit the whole tree, a domain, or specific normal paths for drift, contradictions, duplication, density, metadata, placement, or relationship problems. Do not use for ordinary task reads, source-backed writes, Context Tree PR/MR reviews, or empty-tree setup.

Context Tree Audit

Purpose

Audit a stable snapshot of stored normal content on the bound Context Tree's actual binding branch and route each evidence-backed finding to the smallest safe follow-up.

The workspace-generated `AGENTS.md` / `CLAUDE.md` Context Tree Policy is the only content-policy and authority baseline. Apply it directly; do not recreate its definitions or rules in this skill. If the policy or binding is missing, stop and report the environment gap.

Trigger Boundary

Use this skill only when a human explicitly asks for a broad stored-tree audit or names a domain or set of normal paths to audit. This trigger is exclusive: do not run `first-tree-read` first and expand a task-scoped read into an audit.

Do not use this workflow for a concrete source artifact that should be written to the tree, a Context Tree pull request or merge request review, ordinary task context, or an empty-tree setup. Those remain owned by their dedicated skills.

Choose the execution mode from the request:

• **Report-only (default):** a request to audit, inspect, or report grants

read-only authority. Perform no commit, push, pull request, merge request, issue, tracked ask, or other external mutation; report findings and recommended routes in the completion response.

• **Maintenance:** select this only when the human explicitly asks to maintain,

fix, or create follow-up artifacts. Mutation authority extends only to the requested artifact kinds. High-confidence local findings may produce one focused artifact per coherent finding group. Nothing is merged automatically.

Stable Snapshot

1. Read `.first-tree/workspace.json` and the generated Tree Location section. Resolve the bound tree checkout, upstream, and actual binding branch. Use the branch declared in Tree Location; never assume `main` or substitute the checkout's current branch. Fail closed on a missing binding, repository mismatch, or ambiguous branch. 2. From the bound checkout, inspect `first-tree tree tree --help` before using its current selectors. 3. Fetch the bound upstream branch and resolve its exact remote HEAD SHA. If freshness cannot be confirmed because of network, permission, or remote identity failure, do not claim a current audit and do not create a semantic fix. 4. Create a uniquely named, agent-owned detached worktree at that exact SHA. Never switch or edit the main tree checkout and never reuse an unowned path. 5. Report the repository, branch, exact SHA, requested scope, and execution mode. Keep all discovery reads fixed to this snapshot. 6. In the registered, clean detached worktree, run the selected `first-tree tree tree --no-pull ...` command and confirm its HEAD is still the exact audited SHA. Never resolve the audit scope from the mutable main checkout after the snapshot exists. 7. In the detached worktree, run `first-tree tree verify --json` before any semantic node read. Record validator failures as mechanical findings and do not hide them inside semantic conclusions. 8. If validation passes, read only the scoped normal nodes plus the minimum parent, sibling, relationship, and source evidence needed to judge them under the generated policy. 9. Remove the detached worktree through `git worktree remove` when finished. Never use `--force`; a dirty snapshot is an integrity failure.

Audit Workflow

Check the requested scope for stale or contradictory claims, duplicated canonical truth, misplaced decisions, misleading metadata or relationships, excessive density, and source-boundary violations. Do not treat model suspicion as evidence.

Each finding must contain:

• `path`: the exact normal node or relationship;
• `policy`: the generated-policy rule that applies;
• `claim`: the current claim and concrete problem;
• `evidence`: verifiable current source, configuration, validator output,

human decision, or related canonical normal content;

• `confidence`: `mechanical`, `strong`, `uncertain`, or `human-authority`;
• `action`: report, focused tree PR/MR, issue or draft proposal, tracked human

ask, or source-code escalation.

Tree history and forge discussion may help locate evidence, but delivery history does not become normal-node prose. Apply the generated policy's code-versus-tree drift authority exactly; never turn an authority conflict into an automatic normal-content rewrite.

Finding Routing

• In Report-only mode, record every finding and its recommended route in the

response, including authority conflicts. Do not create an issue, proposal, tracked ask, branch, commit, pull request, or merge request.

• A local mechanical or strong semantic finding may become one small tree

PR/MR in Maintenance mode only after it becomes a concrete audit source artifact. Include the audited SHA and scope, exact finding group, current evidence, canonical-placement judgment, and risk. Then load `first-tree-write`; that skill rechecks freshness and owns target selection, drafting, verification, worktree, and PR/MR discipline. Every Audit-originated tree PR/MR is created as a draft and remains draft when Audit and Writer finish. Audit never edits the tree directly.

• Weak, broad, or cross-domain evidence does not change normal truth. Report it

or, when Maintenance explicitly authorizes it, create a focused issue or draft proposal that names the missing evidence.

• In Maintenance mode, ownership, human-authority, or locked-decision conflicts

use a tracked human ask only when the next step genuinely depends on that decisi