audit skill

commands - audit.md

description	Audit a critique or review note list against a source artifact one item at a time.
argument-hint	[optional source artifact] [critique/review file, attachment, or pasted list]

Use the audit skill.

Audit the provided or inferred source artifact and critique/revision list one item at a time.

Inputs or arguments:

$ARGUMENTS

Follow these constraints:

• Start with the first unresolved item unless I name a specific item.
• At the start of the audit, remind me that I can say next item to move on.
• When the current item is the final item from the provided list, tell me it is the last item.
• Infer the source artifact from the current project when it is omitted and unambiguous; ask me if several plausible files, notes, diffs, or documents exist.
• Accept critique or review items from a file, attachment, or inline pasted text.
• Gather the relevant source context before making a suggestion.
• Discuss only the current item.
• Give an exact before/after revision suggestion with bolded changed spans and matching bullets.
• For code suggestions, use fenced code blocks with marker comments in the before block instead of bolding; do not include marker comments in the after block, and use fenced code blocks in the bullets too.
• Do not edit files unless I explicitly approve the current item.
• Do not move to the next item until I ask.
• Do not use the private analogy/name for the revision format in user-facing discussion.

skills - audit -SKILL.md

name	audit
description	Use when auditing a critique, review note list, or revision list against a source artifact one item at a time, producing exact before/after suggestions and waiting for approval before edits or moving to the next item.

Audit Skill

Use this skill when the user wants to work through a provided critique, review list, review notes, or revision list against a source artifact. The source artifact might be a manuscript, design doc, README, code file, code review notes, pull request diff, proposal, memo, or other editable text. The source and critique list can be provided as file paths, attachments, inline pasted text, or inferred from the current project when unambiguous. The list may be provided all at once, but handle only one item at a time.

Core Workflow

1. Identify the source artifact and the critique/revision list. Filenames are arbitrary; do not require specific names such as manuscript.tex or critique.md.
2. If the source artifact is omitted, infer it from the project only when there is a single obvious target. If several plausible files, notes, diffs, or documents exist, ask the user which one to audit.
3. If the critique list is inline, treat the pasted list as the item source. If it is a file or attachment, read only enough to identify the next item.
4. Start with the first unresolved item unless the user names a specific item.
5. Gather the relevant source text, code, diff, or notes, including enough surrounding context to judge the critique.
6. Discuss only the current item.
7. Do not edit files unless the user explicitly approves the current item.
8. Do not move to the next item until the user explicitly says to continue.
9. At the start of an audit session, remind the user that they can say next item to move to the next critique item.
10. When presenting the final item from the provided list, explicitly tell the user that it is the last item.

Response Format

For each item, start with:

For item N, the main idea is to [quick overall reasoning].

Then give brief reasoning about whether the suggestion is worth doing.

Then provide an exact before/after revision suggestion:

> [before text, with the exact changed span(s) in bold]

> [after text, with the exact replacement span(s) in bold]

- **[exact bold before span]** -> **[exact bold after span]**: [reason]

End with one clear recommendation: revise, do not revise, or optional.

For code, use fenced code blocks instead of blockquotes and bolding. In the before code block, add short marker comments adjacent to the exact changed lines or region. In the after code block, do not include marker comments. Then use bullet items with fenced code blocks for the exact before and after snippets.

Example for code:

```python
lines = [
    "$ " + " ".join(cmd),  # CHANGE: render command safely for logs
    f"returncode: {returncode}",
]
```

```python
lines = [
    "$ " + shlex.join(cmd),
    f"returncode: {returncode}",
]
```

- Before:
  ```python
  "$ " + " ".join(cmd)
  ```
  After:
  ```python
  "$ " + shlex.join(cmd)
  ```
  Reason: preserves argument boundaries in copy-pastable logs.

Exactness Rules

• The text in each bullet must match the bold text in the before/after quotes exactly.
• Do not add, omit, paraphrase, normalize punctuation, or change capitalization in the bullet spans.
• For code suggestions, the bullet code snippets must match the changed code snippets exactly, excluding marker comments used only in the before code block.
• If using ellipses to omit unrelated material, include real adjacent source text around every changed span.
• Avoid showing whole paragraphs unless they clarify the change.
• For deletions, do not use an empty replacement. Prefer bolding a larger before span that includes the deleted language plus adjacent retained text, and an after span showing the retained text after deletion.
• Keep the private name or analogy for this format out of user-facing responses. Refer to it as an exact before/after revision suggestion.

Editing Rules

• If the user approves a change, apply only the approved change.
• After editing, verify the local passage and report the result briefly.
• Preserve unrelated user or worktree changes.
• After applying an approved item, wait for the user to request the next item.