CODING-PATTERNS SuperSkill v2.0

Триггеры: "рефакторинг", "код ревью", "дебаг", "архитектура", "паттерн", "performance", "bulletproof"

WHEN TO USE

• Starting a feature → size it first (S/M/L)
• Debugging a bug → 6-step protocol
• Code review → multi-agent pattern
• Refactoring → extract/rename/simplify rules
• Context getting large → 40% rule

DECISION TREE

1-2 files changed?   → S: Lightweight (no spec, just code + test)
3-10 files?          → M: Research → Spec → Plan → Implement → Review
10+ files?           → L: Full pipeline with handoffs between stages
Context > 40%?       → /compact now, /clear between stages
Stuck on bug?        → Reproduce → Isolate → Understand → Fix → Verify

KEY ACTIONS

1. Feature Development (Medium Size)

1. Research: Explore agents + WebSearch → thoughts/research/topic.md → /clear
2. Spec: inputs, outputs, edge cases → specs/feature-spec.md → /clear
3. Plan: phases, file groups, dependency order → plans/feature-plan.md → /clear
4. Implement Phase 1 → Self-audit → Tests → Phase 2 → ...
5. Integration test all phases
6. Final review + commit

2. Debugging Protocol (6 Steps)

1. REPRODUCE — minimal test case that triggers the bug
2. ISOLATE   — git bisect or binary comment-out
3. UNDERSTAND — read error stack top-down, check assumptions
4. FIX       — minimal change addressing ROOT CAUSE
5. VERIFY    — run fix + add regression test
6. DOCUMENT  — comment if non-obvious

3. Code Review (Multi-Agent)

Agent 1-2: CLAUDE.md compliance check
Agent 3:   Bug scan in changed lines
Agent 4:   Git blame context analysis
Rule: only post issues with confidence >= 80

4. Refactoring Rules

EXTRACT  — repeated logic used >= 3 times → function/component
RENAME   — grep all usages, update imports, run tests
DEAD CODE — tsc --noUnusedLocals, eslint no-unused-vars
SIMPLIFY — early returns to reduce nesting, remove unnecessary abstractions

5. Handoff Between Stages

# progress/<task>-handoff.md
## What was done
## Key decisions
## Open questions
## Next steps
## Files changed

ARCHITECTURE PATTERNS (when to pick)

Repository pattern   → need to swap data layer (testing, migration)
Service layer        → business logic shared across HTTP/CLI/queue
Event-driven         → decouple producers from consumers
CQRS                 → complex domain with different read/write models
Feature flags        → trunk-based dev, gradual rollout

PERFORMANCE QUICK WINS

Bundle:   lazy(() => import()), manual chunks for vendor/heavy libs
Images:   width/height, lazy, WebP/AVIF, placeholder blur
Runtime:  useMemo for expensive compute, virtual scroll for 100+ items
DB:       select_related / prefetch, bulk operations, proper indexes
Vitals:   LCP < 2.5s, INP < 200ms, CLS < 0.1

CHECKLIST

• [ ] Size assessed → correct mode (S/M/L)
• [ ] Research done before implementation
• [ ] Self-audit after each phase
• [ ] Tests pass (unit + integration)
• [ ] No N+1 queries
• [ ] Dead code removed
• [ ] Context managed (compact/clear as needed)

ANTI-PATTERNS

1. Coding before understanding the problem (research first)
2. Big-bang changes without phased plan
3. Ignoring context window limits (40% rule)
4. Reviewing own code without structured checklist
5. Premature abstraction (extract at 3+ uses, not 1)