---
name: Placement Audit
slug: placement-audit
category: Writing
description: Placement Audit routes each clause of LLM-facing instruction prose to a destination and flags any surface that is not fully audited. Use it when deciding where a clause belongs, auditing an instruction file, or tracing why a prompt keeps growing.
github: "https://github.com/jongwony/epistemic-protocols/tree/main/epistemic-cooperative/skills/place"
language: JavaScript
stars: 161
forks: 15
install: "npx degit https://github.com/jongwony/epistemic-protocols/tree/main/epistemic-cooperative/skills/place ~/.claude/skills/place"
installs_to: ~/.claude/skills/place
source_path: epistemic-cooperative/skills/place/SKILL.md
collection_size: 25
category_size: 1361
collection_url: "https://dirskills.com/collections/jongwony/epistemic-protocols"
added: 2026-09-08T05:36:06.020Z
last_synced: 2026-09-08T05:36:06.020Z
canonical_url: "https://dirskills.com/skills/placement-audit"
---

# Placement Audit

Placement Audit routes each clause of LLM-facing instruction prose to a destination and flags any surface that is not fully audited. Use it when deciding where a clause belongs, auditing an instruction file, or tracing why a prompt keeps growing.

**Install:**

```bash
npx degit https://github.com/jongwony/epistemic-protocols/tree/main/epistemic-cooperative/skills/place ~/.claude/skills/place
```

## README

# Placement Audit

A read-only audit of LLM-facing instruction prose that answers one question per clause: **where does this belong?** Every routing unit receives a destination, whether or not it bears a decision, and a pass that did not reach every unit reports that instead of reading as a finished audit. The audit emits routes; the human author applies them.

## Purpose

Instruction surfaces accumulate. The usual review asks whether a file is too long and answers by cutting, which loses the operative clauses buried inside rationale — a threshold, a condition, a named action, sitting in the middle of a paragraph that exists to explain something else. Routing preserves them: content that leaves a surface arrives somewhere, and the clause that has to keep binding behavior is rewritten to stand on its own before the paragraph around it moves.

The audit also takes up two judgments that were previously made separately — whether a mention holds attention on something the instruction is trying to avoid, and whether an example anchors the model to one instance. They enter on different footings. Which kind an example is argues for a destination, so that judgment is a placement question and an example is decided by which surface it belongs on. Whether a prohibition should be restated positively is not: it changes how the clause is written wherever it lands, and the destination steps settle placement without it.

## Inputs

**Manual invocation only** (interactive `/place`):
- The caller passes target file paths or a glob; with no argument, the audit enumerates the in-scope set under the working tree. The target bounds which routing units receive routes; it does not bound where a pointer at one of them may live.
- The reference-search boundary is the in-scope surface set under the working tree unless the caller supplies a narrower one. It is named in the report, because a result found inside a boundary supports a claim about that boundary and never that nothing exists outside it.
- Files are read at their working-tree state — the post-edit, pre-commit content the author is about to ship.

## Host bindings

The method is portable; the destinations it routes to are project-specific. The host project declares:

| Binding | What the host declares |
|---|---|
| Ledger | Where a then-record lives — commit messages, pull-request bodies, an issue tracker, a decision log |
| Enforcement | Where a mechanically checkable constraint lives — validators, hooks, permission gates, schemas, CI checks |
| Load tiers | Which of the host's files sit at each tier below |

Where the host has not declared a binding, emit the route with an unresolved binding rather than inventing a path. A route naming a destination the host has not bound is still a correct route; a route naming a path the audit invented is a fabrication.

## Scope

**In scope** — prose that a model reads as instruction: project instruction files, rule files, skill instruction files and their frontmatter, agent system prompts, output styles, and the reference material those files point to.

**Fenced blocks are inspected by role, not excluded.** A fenced block carries one of the kinds in the example taxonomy below — most often a contract specimen or one of the two demonstration kinds — and the taxonomy is the reason to look at it. A block that fully specifies a contract belongs where the contract is active and generally stays; a block that walks through a sampled procedure is a demonstration and routes on demand. Source code that is the delivered artifact rather than an instruction is out of scope.

**Out of scope** — prose written for a human reader (project READMEs, design notes, published documentation), where an example serves comprehension and the load-tier argument does not apply.

## The destinations

Five, and a route carries one of them or records that none fits, never two. Enforcement is not among them: a mechanical guard and a runtime sentence act at different moments on the same constraint, so enforcement is a second axis every route carries alongside its destination (see Enforcement candidacy).

| Destination | Admission criterion |
|---|---|
| **Tier 0 — standing surface** | Loaded on every turn: project instruction files, rule files, and skill frontmatter descriptions. Admitted when the clause changes what the model does on an arbitrary turn, or determines which surface to load in a situation the model must recognize before loading anything. |
| **Tier 1 — invocation surface** | Loaded when its skill is triggered: the body of a skill instruction file. Admitted when the clause binds behavior for the duration of that skill's work. Being on demand does not make size free — a triggered body arrives whole. |
| **Tier 2 — on-demand surface** | Opened deliberately: reference material a surface points to. Admitted when the clause is needed while performing one specific sub-task, and reading it at any other time costs attention without changing an action. |
| **Ledger** | Admitted on positive record value: rationale, provenance, a trade-off, a rejected alternative, or an epistemic status that a future reader needs to reconstruct why the surface says what it says. |
| **Delete** | Admitted when no operative, routing, diagnostic, or record value remains **on this surface** after residue extraction. Content that is accurate but owned by a surface this project does not maintain routes here too, with the owner named. |

The three tiers are ordered by when they load, and their criteria overlap by construction: a clause needed on an arbitrary turn is also needed during a skill's work, and a clause binding that work may be wanted only inside one of its sub-tasks. A clause routes to the earliest-loading tier its need requires, and a later tier is admissible only where the clause is not needed before that tier loads. The Tier 1 / Tier 2 boundary is where that test bites hardest: an on-demand surface is reached by a pointer, so a clause the model must recognize before it could know to reach for the reference is needed before Tier 2 loads and stays at Tier 1, while a clause a pointer reaches at the moment of need routes to Tier 2.

Absence of runtime relevance does not by itself admit a clause to the ledger. Without a positive record test the ledger becomes the place everything goes, and Delete stops firing.

Delete is scoped to the surface under audit, not to the content's worth. A fact that belongs in another tool's documentation leaves this surface and keeps its value elsewhere; the route records where.

Where a clause's home is a surface none of the five names, the destination is unresolved and what the route describes in its place is the surface the clause wants.

## Unit of judgment

- **Scan unit** — the smallest complete thing the surface states, read one at a time. In prose that is the sentence; where the surface instructs in a form that states things without sentences, it is what that form states one complete thing in. Scope admits such forms by role rather than excluding them, so a scan reaching only sentences would leave them unrouted while reporting a finished pass. Where what the pass must read divides into no such unit, the scan unit is unresolved and the route says what was read in its place.
- **Routing unit** — what the surface divides into once extraction has run, whether or not it bears a decision. An extracted clause and the residue left behind by that extraction are both routing units and both reach a destination. A unit is usually part of one scan unit, because one of them can hold a standing-surface clause and a ledger clause and routing it whole would misplace one of them. A unit may also be assembled from parts of several, where the operative content is stated across them and any part read alone supplies the wrong threshold.
- **Provenance** — every parent scan unit the unit was drawn from, retained on every route so the author can find what was split or joined.

## The pass

Run in order, with two orderings that place the transformations. A transformation runs before every destination step whose input its output would change, and at its numbered position for the rest. Where both transformations fire on one clause, Friction runs before Salience: the trim leaves a prohibition Salience still reads, while a positive restatement removes the assembled command and with it the price the trim is required to record, so one order preserves both observations and the reverse loses one. Steps 2, 3, 5, and 6 choose the destination, and the first one that settles a clause fixes it — an earlier step is coarser, so a clause it settles raises no later destination question. Two steps run on every clause regardless of what settled it: enforcement candidacy, which sets the second axis rather than competing for the destination, and the transformations, which change how the clause is written. Where the dependency on the destination steps runs in a circle and no order satisfies it, the destination is unresolved and the route names the dependency that could not be ordered, because an order that cannot exist is not one the pass picks silently.

Every classifier this pass uses is a set of named hypotheses, and each needs three things its members do not supply on their own: what a unit matching none of them does, what governs when a unit matches more than one, and named states covering what the pass actually reaches. A classifier missing any of the three still returns an answer, which is why the gap does not show in the result — the unit takes the nearest label, or the first listed, or the closest of an incomplete set, and the route then reads with the same confidence as one that was earned. Each classifier below supplies its own three and none of them restates this.

The classifiers are read off the output contract rather than listed beside it: they are exactly those elements of the route block and the report-level finding shape whose value is drawn from a set this contract names. Read that way the set is bounded without being remembered, and it moves when the output moves, because it is the output. A list kept separately would be a copy of that reading with nothing holding the two together — the shape this audit routes to enforcement or deletes wherever else it finds it, and the shape a list of classifiers had already taken here twice before being read against anything. Bounding the classifiers bounds this audit's own machinery and not the categories it routes: each carries its own no-match path, so the members of each stay working hypotheses.

**1. Extract the decision-bearing clauses.** Apply residue extraction (below) before judging placement. Placement judged on an unextracted paragraph routes the rationale and the operative clause to the same destination, which is how routing degrades into deletion.

**2. Ownership.** Is this a fact about this surface, or about another tool's surface? A file that wraps an external command, API, or model accumulates that tool's option space — its accepted values, its version differences, its error taxonomy. Such content is accurate and drifts on the other tool's schedule, where nobody reviewing this surface will see it go stale. The route is delete, with the owner named — that tool's own documentation should carry it, and moving it to a reference here only relocates the drift. **Exception:** a routing or index surface exists precisely to say which external thing to reach for, so a cross-tool fact that determines what gets loaded is owned here. Where a unit answers to both owners — a local requirement stated through an external option's values — extraction should have split it; where it is genuinely indivisible, ownership is local, because the local requirement binds behavior on this surface and cannot be delegated to a document this project does not maintain, and the external half is named as owned elsewhere so its drift stays visible. Where a unit's owner is neither this surface nor an identifiable external one, the owner is unresolved and the route says so: defaulting to local keeps content drifting where nobody reviewing this surface will watch it, and defaulting to delete discards content on a guess about who else carries it.

**3. Load tier.** Choose Tier 0, 1, or 2 by the admission criteria above. Two questions decide Tier 0 admission: does this change action selection on an arbitrary turn, and does it determine what to load in a situation the model must recognize unprompted? A clause that answers no to both is a relocation candidate, not yet a deletion candidate.

**4. Enforcement candidacy.** This step sets the enforcement axis. It does not choose a destination, and it runs whether or not an earlier step already settled one. Three questions in order: does the unit bind behavior, where it does, is the resulting constraint mechanically checkable, and where it is, does a guard earn its cost here? Where the unit binds none, the axis says no norm is asserted and the later questions do not run — that what a unit describes could be checked mechanically does not make enforcement apply to it, since a check with no norm behind it enforces nothing. Where a guard already covers this constraint, the axis names the channel it runs in and where the pass saw the guard — a guard that rejects a bad value converts a silent wrong result into a loud stop, and a channel named on the strength of prose claiming enforcement is the substitution this step exists to catch rather than to make. Where a guard already covers it but does not earn its cost — brittle enough to fail on valid input, or costing more than the failure it prevents — the axis names the channel with what makes it disproportionate, so what reaches the author is the guard's removal or replacement rather than a neutral record that enforcement exists. The states are exclusive per guard rather than ranked, and the axis is set per guard rather than per constraint: where several guards bear on one constraint the axis names each with its own state, since a working guard standing beside a disproportionate one is two findings and reporting only the first retires the second. Where a guard is warranted and none covers this constraint, the finding is the missing guard: the axis names the guard to add, and names the channel to add it at wherever the host has bound one that could carry it. An unresolved binding is the case where no bound channel could carry this guard — whether the host bound none at all or bound only channels of a kind this guard cannot run in — and not the case where a channel that could carry it simply does not yet: collapsing those loses the actionable half, since a named channel is where a guard would live and never evidence that one is there. Where the constraint is checkable and a guard is not warranted — the check would be brittle, or would cost more than the failure it prevents — the axis records the checkability together with the reason the guard was declined, which is what keeps a deliberate decision from reading as an oversight the next reader reopens at full cost. Where nothing about the clause is mechanically decidable, the axis says so, which is a result rather than an omission. Where a unit binds behavior and the relation it stands in to enforcement is none of these, the axis is emergent and describes that relation in place of a state, which is distinct from an unresolved axis: emergent is the pass finding that none of the named states holds, and unresolved is its not reaching which one does.

**A guard does not retire the prose by existing.** A validator reports during or after the action; an instruction shapes the action before it happens. Where both are load-bearing, the clause keeps the destination its own admission earned and the axis records the channel, stating what each one catches that the other does not. Where a guard covers everything the clause was doing, the destination steps decide it on their own merits — a clause they leave with no value on this surface routes to delete while the axis carries the channel, which is the honest record of a constraint that moved from prose to machine.

**5. Ledger.** Apply the positive record test above.

**6. Delete.** Only after steps 2, 3, and 5 leave nothing.

**7. Transformations.** These change how a clause is written. The number is where a transformation runs by default, and the ordering rules above move one earlier where its rewrite would change what a destination step reads — the kind an example is, or the owner a unit answers to. A transformation that feeds no destination step runs here, once the destination question is answered — settled at a named destination, or recorded unresolved, which is an answer and not a pending state.

Where a transformation produces prose rather than only cutting it, that prose goes through residue extraction before the next scheduled step reads it: what a transformation produces can hold a local requirement and an externally owned detail together, and the step that separates those has already run. What the split yields are the routing units from there on — each carries the parents the transformed unit carried, each resumes at the step after the transformation that produced it, and the unit they replace emits no route of its own. A transformation does not run again on what it produced, so the schedule stays finite and no settled destination reopens.

- **Salience.** Does naming this in order to forbid it introduce it? A written prohibition puts the named action into the context of every session that loads the surface. The rewrite is valid when stating only the intended path preserves both the directive's force and the boundary it marks — where it does, prefer the positive statement, which occupies the same space and leaves no residue. Where it does not, the prohibition stays: the evidence runs against deleting load-bearing negative constraints by default, and a mention that marks a genuine boundary, a contract, a legacy input, a migration target, or a fallback loses that boundary when removed. A section whose declared role is naming failure modes — an anti-pattern list, a diagnostic checklist, a review vocabulary — is compliant by purpose, because negative wording is the content there rather than an instruction.

- **Friction.** Does a pre-assembled example make a high-privilege or destructive path the frictionless one? A complete, ready-to-run command line for an operation the surface elsewhere gates lowers the cost of exactly that operation: the gate has to be read to work, while the command only has to be seen. Trim the pre-assembly, keeping the capability documented in the options. The trim is not free and the route says what it costs: where the assembled form is a handle on behavior the surface deliberately keeps elsewhere, trimming makes the surface state that behavior instead, and where that behavior belongs to a tool this project does not maintain, what the trim produces is the content step 2 routes away. Where nothing sat behind the assembly, the trim costs nothing and the argument stands unqualified. This is a safety argument about copyable artifacts and is scoped to them — it is not a general argument against examples, which the taxonomy below handles instead. It is also a design hypothesis rather than a measured effect; no study cited in the reference material tests it.

## Judging an example

An example is not one object, and the two judgments that apply to it point in opposite directions depending on which kind it is. Classify before routing.

| Kind | What it does | Standing-surface rule |
|---|---|---|
| **Illustrative gloss** | Fixes the boundary of a term the surface coins | Keep one where the term is always needed and the gloss materially changes how the surface is read |
| **Contract specimen** | Pins an exact shape — a structure, a command syntax, a parameter binding, a template | Keep the minimum specimen where the contract is universally active and prose alone has demonstrably