--- 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 decision and the request authorizes follow-up actions. Otherwise report the blocker without mutation. Source implementation that conflicts with a locked decision is escalated to the source side, not repaired by changing the tree. - No findings means report the exact audited SHA, scope, validator result, and evidence coverage. Do not claim correctness outside the inspected scope. One pull request or merge request carries one coherent finding group. Do not turn a broad audit into a tree-wide rewrite or a bundle of unrelated domain changes. ## Mutation Boundary Audit owns discovery, evidence classification, and action selection. It does not own a second authoring policy or PR/MR verdict workflow. Never edit `owners` without explicit human authority, approve a pull request or merge request created from this audit, merge, change repository governance, create a new CLI surface, or claim scheduled execution. A GitHub tree PR continues through `context-tree-review`. A GitLab tree MR also continues through `context-tree-review`, but Audit leaves it draft so that run remains read-only. Create every review request with the matching forge. After creating or reusing a GitLab draft MR, run `first-tree gitlab follow `. Audit never creates a Reviewer Chat, marks either artifact ready, publishes a verdict, approves it, repairs it, or merges it. ## Completion Report Report the repository, binding branch, exact audited SHA, scope, validator result, findings grouped by confidence and action, artifacts actually created, snapshot cleanup result, and any decision that blocks the next step. State explicitly when the run was report-only or freshness could not be confirmed.