refactor: trim phase skills to reduce token waste

- check-phase: 831 → 204 words (remove protocol duplication with agents)
- plan-phase: 521 → 143 words (keep output formats, drop behavioral text)
- do-phase: 408 → 113 words (keep output format + critical commit rule)
- Total plugin: 9830 → 8269 words (~2000 tokens saved)

skills/check-phase/SKILL.md

@@ -1,134 +1,24 @@
 ---
 name: check-phase
-description: Use when you are acting as Guardian, Skeptic, Sage, or Trickster archetype in the Check phase. Defines review protocols and approval criteria.
+description: Use when you are acting as Guardian, Skeptic, Sage, or Trickster archetype in the Check phase. Defines shared review rules and output format.
 ---
 
-# Check Phase — Review Protocols
+# Check Phase
 
-Multiple reviewers examine the Maker's implementation in parallel. Each has a specific lens.
+Multiple reviewers examine the Maker's implementation in parallel. Each agent definition has its specific protocol — this skill defines the shared rules.
 
-## General Review Rules
+## Shared Rules
 
-1. **Read the proposal first.** You're reviewing against the intended design, not inventing new requirements.
-2. **Read the actual code changes.** Use `git diff` on the Maker's branch. Don't review based on descriptions alone.
+1. **Read the proposal first.** Review against the intended design, not invented requirements.
+2. **Read the actual code.** Use `git diff` on the Maker's branch. Don't review descriptions alone.
 3. **Each finding needs:** Location (file:line), severity, description, suggested fix.
-4. **Severity levels:**
-   - **CRITICAL** — Must fix. Security vulnerability, data loss, breaking change. Blocks approval.
-   - **WARNING** — Should fix. Degraded quality, missing edge case, poor pattern. Doesn't block alone.
-   - **INFO** — Nice to have. Style, documentation, minor improvement. Never blocks.
-5. **Output a clear verdict:** `APPROVED` or `REJECTED` with rationale.
+4. **Severity:**
+   - **CRITICAL** — Must fix. Blocks approval.
+   - **WARNING** — Should fix. Doesn't block alone.
+   - **INFO** — Nice to have. Never blocks.
+5. **Clear verdict:** `APPROVED` or `REJECTED` with rationale.
 
----
-
-## Guardian Protocol — Risk Assessment
-
-Your lens: **Can this hurt us?**
-
-### Check For
-- **Security:** Injection (SQL, XSS, command), auth bypass, data exposure, insecure defaults
-- **Reliability:** Unhandled errors, race conditions, resource leaks, timeout handling
-- **Breaking changes:** API contract violations, schema incompatibility, removed functionality
-- **Dependencies:** New deps with known vulns, version conflicts, license issues
-
-### Approval Criteria
-- Zero CRITICAL findings → APPROVED
-- Any CRITICAL finding → REJECTED (must fix before merge)
-
-### Shadow Guard
-You are IN SHADOW (paranoia) if:
-- Every finding is CRITICAL
-- You're blocking on theoretical risks with no realistic attack vector
-- You've rejected 3+ proposals without suggesting a viable alternative
-
-**Mitigation:** Ask yourself: "Would a senior engineer at a well-run company block this PR?" If the answer is "probably not," downgrade to WARNING.
-
----
-
-## Skeptic Protocol — Assumption Challenge
-
-Your lens: **What if we're wrong?**
-
-### Challenge
-- **Design assumptions:** "The proposal assumes X — but what if Y?"
-- **Untested scenarios:** "This handles happy path but not Z"
-- **Alternatives not considered:** "Did we evaluate approach B?"
-- **Scalability:** "This works for 100 users — what about 100,000?"
-
-### Rules
-- Every challenge MUST include a suggested alternative or mitigation
-- "This might not work" without an alternative is not constructive
-- Limit to 3-5 challenges — focus on the most impactful ones
-
-### Approval Criteria
-- No challenges with CRITICAL impact on correctness → APPROVED
-- Fundamental design flaw identified → REJECTED with alternative
-
-### Shadow Guard
-You are IN SHADOW (paralysis) if:
-- You've listed more than 7 challenges
-- None of your challenges include alternatives
-- You're questioning requirements that are outside the task scope
-
-**Mitigation:** Rank your challenges by impact. Keep the top 3. Delete the rest.
-
----
-
-## Sage Protocol — Quality Review
-
-Your lens: **Is this good engineering?**
-
-### Evaluate
-- **Code quality:** Readability, naming, complexity, DRY without over-abstraction
-- **Test quality:** Are tests meaningful? Do they test behavior, not implementation?
-- **Consistency:** Does this follow the codebase's existing patterns?
-- **Simplicity:** Is this the simplest solution that works? Over-engineering is a defect.
-- **Documentation:** Does the change need docs? Are existing docs now stale?
-
-### Approval Criteria
-- Code is readable, tested, and consistent → APPROVED
-- Significant quality issues → REJECTED with specific fixes
-
-### Shadow Guard
-You are IN SHADOW (bloat) if:
-- Your review is longer than the code change
-- You're suggesting documentation for self-evident code
-- You're requesting refactors unrelated to the task
-
-**Mitigation:** Limit your review to issues that affect maintainability in the next 6 months. Everything else is noise.
-
----
-
-## Trickster Protocol — Adversarial Testing
-
-Your lens: **How do I break this?**
-
-### Attack Vectors
-- **Input:** Empty, null, huge, negative, special characters, unicode, SQL, HTML
-- **Boundaries:** Zero, one, max, max+1, negative max
-- **Concurrency:** Simultaneous requests, duplicate submissions, stale state
-- **Failure modes:** Network timeout, disk full, dependency down, permission denied
-- **State:** Interrupted operations, partial writes, corrupt cache
-
-### Rules
-- Every attack must be reproducible (provide specific input/scenario)
-- Report what happened vs. what should have happened
-- If you can't break it after 5 attempts, approve it — the code is resilient enough
-
-### Approval Criteria
-- No exploitable vulnerabilities found → APPROVED
-- Found a way to cause incorrect behavior → REJECTED with reproduction steps
-
-### Shadow Guard
-You are IN SHADOW (chaos) if:
-- You're modifying code instead of testing it
-- You're breaking things outside the scope of the changes
-- Your "tests" are actually sabotage with no constructive purpose
-
-**Mitigation:** You test the changes, not the entire system. Stay in scope.
-
----
-
-## Consolidated Review Output
+## Consolidated Output
 
 After all reviewers finish, compile:
 
@@ -136,19 +26,18 @@ After all reviewers finish, compile:
 ## Check Phase Results — Cycle N
 
 ### Guardian: APPROVED
-- WARNING: Missing rate limit on new endpoint (src/auth/handler.ts:52)
+- WARNING: Missing rate limit (src/auth/handler.ts:52)
 
 ### Skeptic: APPROVED
-- INFO: Consider caching validated tokens (perf improvement, not blocking)
+- INFO: Consider caching validated tokens
 
 ### Sage: APPROVED
 - WARNING: Test names could be more descriptive
 
 ### Trickster: REJECTED
-- CRITICAL: Empty string input bypasses validation (src/auth/handler.ts:48)
+- CRITICAL: Empty string bypasses validation (src/auth/handler.ts:48)
   Reproduction: POST /auth with `{"token": ""}`
-  Expected: 400 Bad Request
-  Actual: 500 Internal Server Error
+  Expected: 400 | Actual: 500
 
 ### Verdict: REJECTED — 1 critical finding
 → Feed back to Plan phase for cycle N+1