athanor
정보
아타노르는 복잡하게 얽히거나 레거시 코드를 체계적으로 최적화되고 구조화된 결과물로 변환하는 4단계 연금술적 프로세스입니다. 이 기술은 점진적인 수정이 실패한 심층 리팩토링 작업(레거시 시스템 현대화나 프로그래밍 패러다임 간 변환 등)을 위해 설계되었습니다. 해당 기술은 분해, 정제, 계몽, 합성 단계를 내장된 검토 체크포인트와 함께 안내합니다.
빠른 설치
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/athanorClaude 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
디자인executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.
requesting-code-review
디자인이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.
connect-mcp-server
디자인이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.
web-cli-teleport
디자인이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.
