feat(scope-guard): deliver the request, not the problem behind it

Two incidents in one session: a permanent CLI subcommand invented for a migration that runs exactly once, deleted again on demand; and `git add -A` twice sweeping local operator config into a bundle it had nothing to do with.

scope-guard states the test — which sentence of the request asks for this? No sentence, no artifact — and three rules under it: no permanent scaffolding for a one-off need, path-scope every `git add`, and report an adjacent defect in one line instead of quietly fixing it into someone elses commit.

commit-next draws the same line where staging actually happens. Step 4 is now the only place that stages: never to run a lint or a test, and always path-scoped, because `git add -A` collects work that was never part of the bundle.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

skills/commit-next/SKILL.md

@@ -23,7 +23,13 @@ description: >
    audit first, then `git commit --no-verify`, exact staging index only).
 4. Group the remaining uncommitted changes into logical bundles (one
    concern per bundle: same failure class, same mechanism, or same role)
-   and stage the next one; never mix concerns to save a commit.
+   and stage the next one; never mix concerns to save a commit. Staging
+   happens here and nowhere else: never stage merely to run a lint or a
+   test. Repository checks that enumerate through `git ls-files` already
+   see tracked, modified files and read the worktree; only an untracked
+   NEW file needs `git add` to become visible. Path-scope every `git add`
+   to the bundle — `git add -A` sweeps up the operator's own edits and
+   their local config.
 5. For the newly staged bundle run the explain skill (what the changes do
    and how the pieces interact, file:line-anchored) followed by the
    confidence skill (fix confidence, break risk, evidence, residuals).

skills/scope-guard/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: scope-guard
+description: >
+  Deliver exactly what was asked and nothing more. Trigger on every task that
+  creates files, commands, or commits, and on autonomous runs where no one is
+  reviewing each step. Also when the operator asks why something exists that
+  they never requested. Portable across projects.
+---
+
+The requested scope is the deliverable. A problem you noticed behind the
+request is not an invitation to solve it.
+
+Before creating anything the request did not name, answer one question: which
+sentence of the request asks for this? No sentence, no artifact.
+
+1. No permanent scaffolding for a one-off need. A migration you run once needs
+   a throwaway script, not a CLI subcommand that ships forever. Do the thing,
+   then delete the scaffolding.
+2. Path-scope every `git add`. Never `-A`, never `.`. The operator's tree
+   carries their own edits and their local config, and sweeping those into
+   your bundle makes them undo your work by hand.
+3. An adjacent defect gets reported in one line, not fixed — unless it blocks
+   the request. Fixing it quietly puts an unreviewed change in someone else's
+   commit.
+
+When something genuinely seems missing, say so in one sentence and finish the
+requested scope anyway. Widening the scope is the operator's call.