refactor(skills): convert 16 user-invoked skills to commands

I converted 16 user-invoked skills to commands. Skills cost ~150-300 tokens each per session for descriptions the model uses to auto-route. Commands cost nothing until you type the slash. These 16 are workflows I always trigger deliberately. The auto-routing wasn't earning its keep. This reclaims ~4-5k tokens per session.

Nine skills stayed where auto-routing genuinely helps: debug, root-cause-trace, five-whys, add-tests, frontend-design, humanizer, playwright-js, playwright-py, and pairwise-tests. Pairwise-tests stays a skill because its helper files don't fit a single-file command shape.

For arch-decide, I preserved the upstream MIT LICENSE alongside the command at .claude/commands/arch-decide.LICENSE so attribution stays intact.

1 files changed, 0 insertions, 54 deletions

diff --git a/respond-to-review/SKILL.md b/respond-to-review/SKILL.md
deleted file mode 100644
index 3508fa5..0000000
--- a/respond-to-review/SKILL.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# /respond-to-review — Evaluate and Implement Code Review Feedback
-
-Evaluate code review feedback technically before implementing. Verify suggestions against the actual codebase — don't implement blindly.
-
-## Usage
-
-```
-/respond-to-review [PR_NUMBER]
-```
-
-If no PR number is given, check the current branch's open PR for pending review comments.
-
-## Instructions
-
-### 1. Gather the Feedback
-
-- Fetch review comments using `gh api repos/{owner}/{repo}/pulls/{number}/comments` (for inline review comments) and `gh api repos/{owner}/{repo}/issues/{number}/comments` (for top-level PR conversation comments)
-- Read each comment in full. Group related comments — reviewers often raise connected issues across multiple comments.
-
-### 2. Evaluate Each Item
-
-For each review comment, before implementing anything:
-
-1. **Restate the suggestion in your own words** — make sure you understand what's being asked. If you can't restate it clearly, ask for clarification before touching code.
-2. **Verify against the codebase** — check whether the reviewer's premise is correct. Reviewers sometimes misread code, miss context, or reference outdated patterns. Read the actual code they're commenting on.
-3. **Check YAGNI** — if the reviewer suggests a "more proper" or "more robust" implementation, grep the codebase for actual usage. If nothing uses the suggested pattern today, flag it: "This would add complexity without current consumers. Should we defer until there's a concrete need?"
-4. **Assess the suggestion** — categorize as:
-   - **Correct and actionable** — implement it
-   - **Correct but out of scope** — acknowledge and create a follow-up issue
-   - **Debatable** — present your reasoning and ask for the reviewer's perspective
-   - **Incorrect** — explain why with evidence (file paths, test results, documentation)
-
-### 3. Respond
-
-- Lead with technical substance, not agreement
-- If you disagree, explain why with code references — not opinion
-- If you're unsure, say so and ask a specific question
-- Never implement a suggestion you don't understand
-
-### 4. Implement
-
-- Address simple fixes first, complex ones after
-- Test each change individually — don't batch unrelated fixes into one commit
-- Run the full test suite after all changes
-- Commit with conventional messages referencing the review: `fix: Address review — [description]`
-
-### 5. Report
-
-- Summarize what was implemented, what was deferred, and what needs discussion
-- Link any follow-up issues created for out-of-scope suggestions
-
-## Content scope
-
-Output this skill produces that gets committed or shared with the team must follow the *Content scope for public artifacts* rule in [`commits.md`](../claude-rules/commits.md): no local paths, no private repo names, no personal tooling references.