Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
if path points to existing code:
MODE = "map" → Analyze and redesign
else if .claude/plans/ has active plan:
MODE = "create" → Create types from plan
else:
ERROR: Need either existing code path or plan
Step 0: Load Expert Guidance
Before starting either mode, read these canon skills and apply their principles throughout:
If a skill file doesn't exist (not installed in this project), skip it and continue.
List loaded experts in EXPERTS_LOADED. In EXPERT_DECISIONS, show each specific structural decision an expert drove.
Step 0b: Learn From Past Mistakes
Read both lessons files if they exist:
.claude/universal-lessons.md — universal patterns (ships with skills, applies to all projects)
.claude/lessons.md — project-specific patterns (accumulated from this project's runs)
Apply relevant lessons to your structural design:
DESIGN entries → avoid these architectural mistakes in your target state
LOGIC entries → design types/interfaces that make these bug patterns impossible (e.g., validated newtypes instead of raw strings for paths/names)
AI_SMELL entries → do not create speculative types/interfaces without consumers; avoid over-decomposition
If a file doesn't exist, skip it and continue.
Step 0c: Load Quality Contracts
Read .claude/rubric/contracts.md. This defines 7 abstract types for boundary enforcement. Use them during boundary analysis in both modes.
## Architecture: [target]
CURRENT_STATE:
┌─────────────┐ ┌─────────────┐
│ UserService │────▶│ AuthStore │
│ │ │ │
│ - getUser() │ │ - token │
│ - saveUser()│ │ - validate()│
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ User │ │ Session │
│ (interface) │ │ (interface) │
└─────────────┘ └─────────────┘
DEPENDENCIES:
- UserService → AuthStore (tight coupling)
- UserService → User (data)
- AuthStore → Session (data)
ISSUES_FOUND:
- [issue]: [why it matters]
PURITY_CHECK:
- [module]: pure ✓ | impure ✗ (calls [I/O function] directly)
For each impure module: can business logic be extracted into pure functions
that take data and return data, with I/O pushed to callers?
Step 2: Apply Canon Wisdom
Review against principles from the masters:
Principle
Check
Data-first
Are data structures driving the design?
Composition
Inheritance depth > 2? Refactor to composition.
Single responsibility
Does each class do one thing?
Interface segregation
Are interfaces minimal?
Dependency inversion
Depend on abstractions, not concretions?
Pure core / impure shell
Is business logic free of I/O? Core functions should take data and return data — no direct calls to filesystem, network, or database. I/O belongs in a thin outer layer that calls the pure core. If a function both computes and persists, split it.
Impossible states
Can invalid states be represented?
Quality contracts
Are boundaries enforced with validated types, or do raw strings pass through?
