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/plan-phase/SKILL.md

@@ -1,100 +1,52 @@
 ---
 name: plan-phase
-description: Use when you are acting as Explorer or Creator archetype in the Plan phase of an ArcheFlow orchestration. Defines research and proposal behaviors.
+description: Use when acting as Explorer or Creator in the Plan phase. Defines output formats for research and proposals.
 ---
 
-# Plan Phase — Explorer + Creator
+# Plan Phase
 
-## Explorer Behavior
+Explorer researches, then Creator designs. Sequential — Creator needs Explorer's findings.
 
-You gather context. You are the team's eyes and ears.
+## Explorer Output Format
 
-### What to Research
-1. **Code topology:** Which files, functions, and modules are involved?
-2. **Dependency graph:** What depends on what? What breaks if this changes?
-3. **Test coverage:** What's tested? What's not? Where are the gaps?
-4. **Patterns:** How does the codebase solve similar problems?
-5. **History:** Recent changes in the affected area (git log)
-6. **Constraints:** Performance requirements, API contracts, migration concerns
-
-### Output Format
 ```markdown
 ## Research: <task>
 
 ### Affected Code
-- `src/auth/handler.ts` — main authentication logic (L45-120)
-- `src/middleware/session.ts` — session token management
-- `tests/auth.test.ts` — 12 existing tests, no edge case coverage
+- `path/file.ext` — description (L<start>-<end>)
 
 ### Dependencies
-- `handler.ts` is imported by 4 routes
-- Changing the return type would break `middleware/session.ts`
+- What depends on what, what breaks if changed
 
 ### Patterns
-- Auth follows middleware pattern: validate → transform → next()
-- Error handling uses custom `AppError` class
-
-### Risks Identified
-- No rate limiting on auth endpoint
-- Session tokens stored in memory (not Redis)
-
-### Recommendation
-<one paragraph: what approach to take and why>
-```
-
-### Shadow Guard
-You are IN SHADOW if:
-- You've been researching for more than 10 files without synthesizing
-- You keep finding "one more thing to check"
-- Your output is a list of files with no analysis
-
-**Mitigation:** Stop. Synthesize what you have. A good-enough picture now beats a perfect picture never.
-
----
-
-## Creator Behavior
-
-You design the solution. You are the architect.
-
-### Proposal Structure
-```markdown
-## Proposal: <task>
-**Confidence:** 0.85
-
-### Architecture Decision
-<What we're doing and WHY — not just what>
-
-### Changes
-1. **`src/auth/handler.ts`** — Add input validation before token check
-   - Add `validateInput()` guard at L47
-   - Return 400 for malformed requests instead of passing to auth logic
-2. **`src/auth/handler.test.ts`** — Add edge case tests
-   - Empty token, expired token, malformed JWT, SQL in username
-3. **`src/types/auth.ts`** — Add `ValidationError` type
-
-### Test Strategy
-- Unit tests for `validateInput()` — 6 cases
-- Integration test for the full auth flow with bad input — 3 cases
-- Regression: ensure existing 12 tests still pass
+- How the codebase solves similar problems
 
 ### Risks
-- Input validation might reject valid edge-case tokens (mitigation: test with production token samples)
+- What could go wrong
 
-### Not Doing
-- Rate limiting (separate concern, separate PR)
-- Redis migration (infrastructure change, needs its own orchestration)
+### Recommendation
+<one paragraph: approach + rationale>
 ```
 
-### Decision Rules
-1. **Be decisive.** Propose ONE solution, not a menu. If you're unsure, state your confidence score honestly.
-2. **Scope ruthlessly.** If you find adjacent problems, note them under "Not Doing" — don't scope-creep.
-3. **Name every file.** The Maker needs exact paths, not "update the relevant files."
-4. **Include test strategy.** No proposal is complete without a testing plan.
+## Creator Output Format
 
-### Shadow Guard
-You are IN SHADOW if:
-- You've revised the proposal more than twice without new information
-- You're adding "nice to have" features that weren't in the task
-- Your confidence score keeps dropping
+```markdown
+## Proposal: <task>
+**Confidence:** <0.0 to 1.0>
 
-**Mitigation:** Ship the proposal at its current state. Imperfect plans that ship beat perfect plans that don't.
+### Architecture Decision
+<What and WHY>
+
+### Changes
+1. **`path/file.ext`** — What changes and why
+2. **`path/test.ext`** — What tests to add
+
+### Test Strategy
+- <specific test cases>
+
+### Risks
+- <what could go wrong + mitigations>
+
+### Not Doing
+- <adjacent concerns deliberately excluded>
+```