audit-content
The guide lives at ${CLAUDE_SKILL_DIR}/guide/. Read
${CLAUDE_SKILL_DIR}/guide/PROCEDURE.md and follow it exactly, step by step.
On this platform, step 0's capabilities map to:
- Ask and wait — the
AskUserQuestion tool, for disambiguating the target (step 1)
and confirming fixes (step 5). For a plain yes/no or open question, asking directly in
a message and waiting for the reply also satisfies this.
- Structured reporting — the
ReportFindings tool, called once with every finding,
most severe first. There is no verification stage to survive, so verdict stays
unset; an empty list is a valid call. For each finding: category is the checklist
category as a kebab-case slug (unused-irrelevant, redundant-repeated,
conflicting, misleading-wrong, unclear-poorly-worded); short_summary is the
compressed plain-language hook; summary is one plain sentence stating what's
wrong, front-loaded, with jargon glossed inline on first use; failure_scenario
is the short, plain-language cost to a reader of leaving it as-is.
- Diff/preview — the
Edit tool's own diff view for local files; for content that
lives elsewhere (a Jira ticket, a Confluence page, a PR description), show the
proposed before/after as text before calling that platform's own update mechanism
(editJiraIssue, updateConfluencePage, gh pr edit, etc.).
Step 2's sources (guide/SOURCES.md) map to these concrete mechanisms:
| Source |
Concrete mechanism |
| Something already in the session |
Re-read it from the conversation directly |
| The system clipboard |
pbpaste via the Bash tool |
| A link |
The WebFetch tool |
| A local file |
The Read tool |
| A set of related documents |
find/ls via the Bash tool to enumerate the set, then the Read tool on every file in it — not a sample |
| A GitHub PR/issue and its comments |
The gh CLI via the Bash tool (gh pr view, gh issue view, gh api .../comments) |
| A Jira ticket |
mcp__atlassian__getJiraIssue and related Atlassian MCP tools |
| A Confluence page |
mcp__atlassian__getConfluencePage and related Atlassian MCP tools |
| An artifact already published in this session |
The Artifact tool, action read |
| The agent's own not-yet-sent draft |
The draft text itself, before it is sent |
Input: $ARGUMENTS is the target named in the user's own words that
PROCEDURE.md step 1 refers to.
Do not summarise guide/PROCEDURE.md or guide/CHECKLIST.md from memory. Read them.
1---2name: audit-content3description: Audit content — a draft, a Jira ticket, a skill, a code comment, a message, a PR description, or a whole directory or guide read as one set — for unused, irrelevant, unnecessary, redundant, repeated, conflicting, misleading, wrong, unclear, or poorly worded material. Figures out what to audit from what is already in the session, or from the clipboard, a link, a file, a set of related files, a GitHub PR/issue, a Jira ticket, or a Confluence page, asking for confirmation when the target is ambiguous. Reports every finding, then fixes only what is confirmed. Invoke manually.4---56# audit-content78The guide lives at `${CLAUDE_SKILL_DIR}/guide/`. Read9`${CLAUDE_SKILL_DIR}/guide/PROCEDURE.md` and follow it exactly, step by step.1011On this platform, step 0's capabilities map to:1213- **Ask and wait** — the `AskUserQuestion` tool, for disambiguating the target (step 1)14 and confirming fixes (step 5). For a plain yes/no or open question, asking directly in15 a message and waiting for the reply also satisfies this.16- **Structured reporting** — the `ReportFindings` tool, called once with every finding,17 most severe first. There is no verification stage to survive, so `verdict` stays18 unset; an empty list is a valid call. For each finding: `category` is the checklist19 category as a kebab-case slug (`unused-irrelevant`, `redundant-repeated`,20 `conflicting`, `misleading-wrong`, `unclear-poorly-worded`); `short_summary` is the21 compressed plain-language hook; `summary` is one plain sentence stating what's22 wrong, front-loaded, with jargon glossed inline on first use; `failure_scenario`23 is the short, plain-language cost to a reader of leaving it as-is.24- **Diff/preview** — the `Edit` tool's own diff view for local files; for content that25 lives elsewhere (a Jira ticket, a Confluence page, a PR description), show the26 proposed before/after as text before calling that platform's own update mechanism27 (`editJiraIssue`, `updateConfluencePage`, `gh pr edit`, etc.).2829Step 2's sources (`guide/SOURCES.md`) map to these concrete mechanisms:3031| Source | Concrete mechanism |32| --- | --- |33| Something already in the session | Re-read it from the conversation directly |34| The system clipboard | `pbpaste` via the Bash tool |35| A link | The `WebFetch` tool |36| A local file | The `Read` tool |37| A set of related documents | `find`/`ls` via the Bash tool to enumerate the set, then the `Read` tool on every file in it — not a sample |38| A GitHub PR/issue and its comments | The `gh` CLI via the Bash tool (`gh pr view`, `gh issue view`, `gh api .../comments`) |39| A Jira ticket | `mcp__atlassian__getJiraIssue` and related Atlassian MCP tools |40| A Confluence page | `mcp__atlassian__getConfluencePage` and related Atlassian MCP tools |41| An artifact already published in this session | The `Artifact` tool, action `read` |42| The agent's own not-yet-sent draft | The draft text itself, before it is sent |4344**Input:** `$ARGUMENTS` is the target named in the user's own words that45`PROCEDURE.md` step 1 refers to.4647Do not summarise `guide/PROCEDURE.md` or `guide/CHECKLIST.md` from memory. Read them.
norraVarg