athanor
关于
Athanor is a four-stage alchemical process that systematically transforms tangled or legacy code into optimized, well-structured output. It is designed for deep refactoring tasks where incremental fixes have failed, such as modernizing legacy systems or converting between programming paradigms. The skill guides you through decomposition, purification, illumination, and synthesis stages with built-in checkpoints for review.
快速安装
Claude Code
推荐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/athanor在 Claude Code 中复制并粘贴此命令以安装该技能
技能文档
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
GitHub 仓库
相关推荐技能
executing-plans
设计该Skill用于当开发者提供完整实施计划时,以受控批次方式执行代码实现。它会先审阅计划并提出疑问,然后分批次执行任务(默认每批3个任务),并在批次间暂停等待审查。关键特性包括分批次执行、内置检查点和架构师审查机制,确保复杂系统实现的可控性。
requesting-code-review
设计该Skill可在完成任务、实现主要功能或合并代码前自动调度代码审查子代理,确保实现符合需求和计划。它支持通过指定git SHA范围进行精准的代码变更审查,帮助开发者在关键节点及时发现潜在问题。核心原则是"早审查、勤审查",适用于开发流程的各个关键阶段。
connect-mcp-server
设计这个Skill指导开发者如何将MCP服务器连接到Claude Code,支持HTTP、stdio和SSE三种传输协议。它涵盖了从安装配置到认证安全的完整流程,适用于集成GitHub、Notion、数据库等外部服务。当开发者需要添加集成、配置外部工具或提及MCP相关功能时,这个Skill能提供实用的操作指南。
web-cli-teleport
设计该Skill帮助开发者根据任务特性选择Claude Code的Web或CLI界面,并指导如何在两种环境间无缝迁移会话。它能分析任务复杂度、迭代需求等要素,推荐最优工作界面和工作流。关键特性包括会话状态管理、环境切换指导和上下文优化建议。
