athanor
À propos
Athanor est un processus alchimique en quatre étapes qui transforme systématiquement du code désordonné ou hérité en une production optimisée et bien structurée. Il est conçu pour les tâches de refonte approfondie là où les corrections incrémentales ont échoué, comme la modernisation de systèmes hérités ou la conversion entre paradigmes de programmation. La compétence vous guide à travers les étapes de décomposition, de purification, d'illumination et de synthèse, avec des points de contrôle intégrés pour la revue.
Installation rapide
Claude Code
Recommandénpx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/athanorCopiez et collez cette commande dans Claude Code pour installer cette compétence
Documentation
Athanor
4-stage alchemical transmutation — decompose prima materia → purify essence → illuminate target form → synthesize refined. Athanor = furnace maintaining steady heat all stages.
Use When
- Transform legacy → modern well-structured
- Refactor deeply tangled modules where incremental fixes keep failing
- Convert paradigm (procedural → functional, monolith → modular)
- Process raw messy data → clean analytical datasets
- Simpler refactoring stalled + full-cycle transformation needed
In
- Required: Material (file paths, module names, data srcs)
- Required: Desired end state (target architecture, paradigm, format)
- Optional: Known constraints (preserve API, can't change DB schema, etc.)
- Optional: Prior failed attempts + why stalled
Do
Step 1: Nigredo — Decomposition
Break prima materia into constituent elements. Nothing sacred; everything cataloged.
- Inventory completely:
- Every fn, class, module, data entity
- All deps (imports, calls, data flows)
- Hidden coupling (shared globals, implicit state, side effects)
- Surface hidden assumptions:
- Undocumented behaviors code relies on?
- Err conditions silently swallowed?
- Ordering deps exist?
- Catalog anti-patterns + tech debt:
- God objects, circular deps, copy-paste duplication
- Dead code paths, unreachable branches, vestigial features
- Hardcoded values, magic numbers, embedded config
- Produce Nigredo Inventory: structured catalog of every element + dep + assumption + anti-pattern
→ Complete unflinching inventory. Should feel uncomfortable — if not, decomposition not thorough. Every hidden assumption now explicit.
If err: Material too large → decompose by module boundary + each module separate athanor run. Deps too tangled to map → grep/Grep trace actual call sites not docs.
Step 2: Meditate — Calcination Checkpoint
Run meditate → clear assumptions accumulated during nigredo.
- Set aside nigredo inventory + clear mental ctx
- Anchor on transformation goal stated in Inputs
- Observe nigredo biases — decomposition made certain approaches seem inevitable?
- Label premature solution ideas "tangent" + return to goal
→ Clear unbiased state → eval material no anchoring to current form. Goal feels fresh not constrained by what was found.
If err: Nigredo findings keep pulling attention (particularly bad anti-pattern, clever hack tempting to preserve) → write down + explicitly set aside. Proceed only when goal clearer than current form.
Step 3: Albedo — Purification
Separate essential from accidental. Strip everything not serving target form.
- From nigredo inventory classify each:
- Essential: Core business logic, irreplaceable algos, critical data transformations
- Accidental: Framework boilerplate, workarounds for old bugs, compat shims
- Toxic: Anti-patterns, security vulnerabilities, dead code
- Extract essential into isolation:
- Pull core logic from framework wrappers
- Separate data transformation from I/O
- Extract interfaces from impls
- Remove toxic entirely — doc what removed + why
- Accidental → determine if equivalents exist in target form
- Produce Albedo Extract: purified essential logic + clean interfaces
→ Set of pure isolated fns/modules representing core value. Each piece testable in isolation. Extract significantly smaller than original.
If err: Essential + accidental too intertwined → introduce seam pts (interfaces) first. Material resists purification → may need dissolve-form before athanor continues.
Step 4: Heal — Purification Assessment
Run heal → assess purification thorough.
- Triage albedo extract: anything still carrying toxic residue?
- Check drift: purification drifted from transformation goal?
- Assess completeness: all essential accounted for, or discarded prematurely?
- Rebalance: restore essential elements incorrectly classified as accidental
→ Confidence that albedo extract complete + clean + ready for illumination. No essential logic lost; no toxic patterns remain.
If err: Assessment reveals significant gaps → return Step 3 w/ specific gaps ID'd. No proceed to citrinitas w/ incomplete material.
Step 5: Citrinitas — Illumination
See target form. Map purified elements → optimal structure.
- Pattern recognition: which design patterns serve purified:
- Data flow suggests pipes/filters, event sourcing, CQRS?
- Interfaces suggest strategy, adapter, facade?
- Module structure suggests hexagonal, layered, micro-kernel?
- Design target architecture:
- Map each essential → new location
- Define interfaces between components
- Specify data flow through new structure
- ID what must be new (no equivalent in original):
- New abstractions unifying duplicated logic
- New interfaces replacing implicit coupling
- New err handling replacing silent failures
- Produce Citrinitas Blueprint: complete mapping albedo extract → target form
→ Clear detailed blueprint, every essential has home + every interface defined. Should feel inevitable — given purified elements, structure = natural fit.
If err: Multi valid architectures compete → eval each vs Input constraints. No clear winner → prefer simplest + doc alternatives as future options.
Step 6: Meditate — Pre-Synthesis Checkpoint
Run meditate → prep for final synthesis.
- Clear analytical ctx from citrinitas
- Anchor on citrinitas blueprint as synthesis guide
- Observe anxiety about transformation — anything rushed?
- Confirm readiness: blueprint clear + material purified + constraints known
→ Calm clarity about what to build. Synthesis should be execution, not design.
If err: Doubt persists about blueprint → revisit Step 5 w/ specific concerns. Better refine blueprint than begin synthesis w/ uncertainty.
Step 7: Rubedo — Synthesis
Compose purified elements → target form. Philosopher's stone: working + optimized code.
- Build new structure per citrinitas blueprint:
- Create files, modules, interfaces as specified
- Migrate each essential to new location
- Impl new abstractions + interfaces
- Wire components:
- Connect data flows as designed
- Impl err propagation through new paths
- Config dep injection or module loading
- Verify synthesis:
- Each component works in isolation? (unit tests)
- Components compose correctly? (integration tests)
- Full system produces same out as original? (regression tests)
- Remove scaffolding:
- Delete temp compat shims
- Remove migration aids
- Clean up remaining refs to old structure
- Produce Rubedo Out: transmuted code, fully functional in new form
→ Working code measurably better than original: fewer lines, clearer structure, better test coverage, fewer deps. Transformation complete + old form can be retired.
If err: Synthesis reveals gaps in blueprint → no patch → return Step 5 (citrinitas) revise design. Individual components fail → isolate + fix before full integration. Rubedo must not produce half-transformed chimera.
Check
- Nigredo inventory complete (all elements, deps, assumptions cataloged)
- Meditate checkpoint passed between nigredo/albedo (assumptions cleared)
- Albedo extract contains only essential + clean interfaces
- Heal assessment confirms purification completeness
- Citrinitas blueprint maps every essential → target form
- Meditate checkpoint passed between citrinitas/rubedo (ready for synthesis)
- Rubedo out passes regression tests vs original behavior
- Rubedo out measurably improved (complexity, coupling, test coverage)
- No toxic elements survived → final out
- Transformation constraints from Inputs satisfied
Traps
- Skip nigredo depth: Rushing decomposition → hidden coupling surfaces during synthesis. Invest fully in inventory.
- Preserve accidental complexity: Attachment to clever workarounds or "it works, don't touch it" code. Not essential → goes.
- Skip meditate checkpoints: Cognitive momentum from 1 stage biases next. Pauses structural, not optional.
- Blueprint-less synthesis: Starting code pre-citrinitas complete → patchwork not transmutation.
- Incomplete regression testing: Rubedo must reproduce original behavior. Untested paths break silently.
- Scope creep during citrinitas: Illumination reveals opportunities beyond original goal. Note but don't pursue — athanor serves stated transformation not hypothetical ideal.
→
transmute— lighter-weight transformation for single fns or small moduleschrysopoeia— value extraction + optimization (base code → gold)meditate— meta-cognitive clearing used as stage-gate checkpointsheal— subsystem assessment used for purification validationdissolve-form— material too rigid for athanor → dissolve firstadapt-architecture— complementary approach for system-level migration patternsreview-software-architecture— post-synthesis architecture review
Dépôt GitHub
Compétences associées
executing-plans
DesignUtilisez la compétence executing-plans lorsque vous disposez d'un plan de mise en œuvre complet à exécuter par lots contrôlés avec des points de contrôle de revue. Elle charge et examine le plan de manière critique, puis exécute les tâches par petits lots (3 tâches par défaut) tout en rapportant la progression entre chaque lot pour une revue par l'architecte. Cela garantit une mise en œuvre systématique avec des points de contrôle de qualité intégrés.
requesting-code-review
DesignCette compétence délègue un sous-agent réviseur de code pour analyser les modifications apportées au code par rapport aux exigences avant de poursuivre. Elle doit être utilisée après avoir terminé des tâches, implémenté des fonctionnalités majeures, ou avant une fusion vers la branche principale. La revue aide à détecter précocement les problèmes en comparant l'implémentation actuelle avec le plan initial.
connect-mcp-server
DesignCette compétence fournit un guide complet permettant aux développeurs de connecter des serveurs MCP à Claude Code via les transports HTTP, stdio ou SSE. Elle couvre l'installation, la configuration, l'authentification et la sécurité pour intégrer des services externes tels que GitHub, Notion et des API personnalisées. Utilisez-la lors de la configuration d'intégrations MCP, de la configuration d'outils externes ou du travail avec le Protocole de Contexte de Modèle de Claude.
web-cli-teleport
DesignCette compétence aide les développeurs à choisir entre les interfaces Web et CLI de Claude Code en fonction de l'analyse des tâches, puis permet une téléportation transparente des sessions entre ces environnements. Elle optimise le flux de travail en gérant l'état et le contexte de la session lors du passage entre le web, la CLI ou le mobile. Utilisez-la pour des projets complexes nécessitant différents outils à diverses étapes.
