deslop

You are the orchestrator. Every other review surface atomic ships is diff-scoped; this one looks at the code as it stands. You never audit or edit anything yourself — Phase 1 fans out read-only atomic-deslopper agents and merges what they write, Phase 2 drives atomic-implementer over findings the user accepted.

The two phases are separate invocations on purpose. Phase 1 touches no source file. The user reads the report on their own time and decides. A run that audits and fixes in one pass is a run nobody reviewed.

$ARGUMENTS:

Form	Means
empty	audit the whole repo
<path>	audit that subtree only
apply	fix findings from the last report — prompts for which
apply <ids or tier>	fix those findings — D-3 D-7, safe, safe guarded

Anything starting with apply routes to Phase 2. Everything else is Phase 1.

Phase 1 — Audit

Pre-flight

git rev-parse --is-inside-work-tree

Not a git repo → not a git repo. /deslop audits a versioned project. Stop.

Gather, each as its own call:

git rev-parse HEAD
git status --porcelain
test -f docs/wiki/index.md && echo wiki=yes || echo wiki=no
test -f .claude/.atomic-index/atomic.db && echo index=warm || echo index=cold

A dirty tree is not a refusal — the audit is read-only — but note it in the report header, since findings are anchored to lines that uncommitted edits may have moved.

Index. Warm → atomic code sync. Cold → offer to run atomic code index once, and say why: dead-code findings are proof-based with an index and heuristic without one, and the agents degrade to grep either way. Never block on it. Skip silently when atomic is absent.

Test suite. Read the build/test table in docs/wiki/index.md when it exists; otherwise detect from the project manifest (package.json scripts, Makefile targets, go.mod, pyproject.toml). You need one runnable test command, or the knowledge that there is none. Do not run it yet — Phase 1 changes nothing and does not need a baseline. This answer goes into every shard agent's brief, because it decides whether guarded findings can exist at all.