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
  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 <mr-url>`. 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.