From agent-almanac
Dismantles rigid system structures and technical debt while preserving essential capabilities (imaginal discs). Use for calcified systems blocking progress, PREPARE/CRITICAL assessments, or before reshaping.
npx claudepluginhub pjt222/agent-almanacThis skill uses the workspace's default tool permissions.
---
Evaluates system's structural form, architecture rigidity, transformation pressures, and change capacity to classify readiness before major changes or health checks.
Decomposes complex systems into atomic components, maps relationships, and reconstructs optimized configurations to identify bottlenecks, failure points, and redesign opportunities. Use for architecture analysis, process simplification, or dependency ripple effects.
Analyzes software architectures using first-principles and SpaceX 5-step methodology to validate decisions, identify technical debt, plan refactoring, and review changes.
Share bugs, ideas, or general feedback.
Perform controlled dismantling of rigid system structures — dissolving calcified architecture, accumulated technical debt, and organizational rigidity while preserving the essential capabilities ("imaginal discs") that will seed the new form.
assess-form) classified the system as PREPARE or CRITICAL (too rigid to transform directly)adapt-architecture when the current form must be softened before it can be reshapedassess-form)In biological metamorphosis, imaginal discs are clusters of cells within the caterpillar that survive dissolution and become the butterfly's organs. Identify the essential capabilities that must survive.
Expected: A clear inventory of capabilities classified as essential (preserve), replaceable (rebuild), or dead (discard). Essential capabilities are extracted into portable form before dissolution begins.
On failure: If imaginal disc identification is uncertain (stakeholders disagree on what's essential), err on the side of preservation. Extract more capabilities than you think you'll need — discarding after dissolution is easy; recovering lost knowledge is often impossible.
Determine the order in which structural elements will be dissolved — outer layers first, core last.
Dissolution Sequence (outside in):
┌─────────────────────────────────────────────────────────────────┐
│ Layer 1: Dead features, unused integrations, orphaned code │
│ → Remove. Nothing depends on these. │
│ │
│ Layer 2: Replaceable UI, standard infrastructure │
│ → Replace with modern equivalents or stubs │
│ │
│ Layer 3: Business logic wrappers, data access layers │
│ → Extract imaginal discs, then dissolve │
│ │
│ Layer 4 (core): Load-bearing structures, data stores │
│ → Dissolve last, with full replacement ready │
└─────────────────────────────────────────────────────────────────┘
Expected: A layer-ordered dissolution sequence where each step is safe (checkpoint verified) and reversible (previous checkpoint is restorable). The most critical components are dissolved last when the team has the most experience and confidence.
On failure: If dependency mapping reveals circular dependencies (A depends on B depends on A), these cycles must be broken before sequenced dissolution is possible. Introduce an interface between A and B, break the cycle, then proceed with the sequence.
Before dissolving rigid structures, excavate and document their actual interfaces — not what's documented, but what's actually in use.
Expected: An empirically-derived interface contract that accurately represents how the system actually communicates, including undocumented behaviors and hidden dependencies.
On failure: If instrumentation is too invasive (impacts performance or requires code changes), sample traffic instead of capturing everything. If the business cycle is too long to wait, use the available data supplemented by stakeholder interviews about "what calls what in which situations."
Systematically remove structural elements while maintaining imaginal disc viability.
Expected: Systematic, verified dissolution of non-essential structure. After each layer, the remaining system is smaller, simpler, and still operational. Imaginal discs are preserved in portable form.
On failure: If dissolution causes cascading failures, the layer ordering is wrong — there are hidden dependencies deeper than expected. Stop, restore, remap dependencies, and re-sequence. If dissolution reveals that an "imaginal disc" is more complex than expected, allocate more extraction time for that capability.
After dissolution, the remaining system should be a minimal viable core plus extracted imaginal discs ready for reconstruction.
adapt-architecture with the minimal core as starting pointExpected: A minimal, maintainable system with clearly documented extracted capabilities. The foundation is clean and ready for reconstruction in whatever form is chosen.
On failure: If the post-dissolution system is less maintainable than expected, some essential structure was dissolved that should have been preserved. Check the imaginal disc inventory — if a critical capability is missing, it may still be recoverable from the archive. If the minimal core is too minimal to operate, some "replaceable tissue" was actually essential — restore it from the checkpoint.
assess-form — prerequisite assessment that identifies rigidity and triggers dissolutionadapt-architecture — the reconstruction skill that follows dissolutionrepair-damage — for systems that need targeted repair rather than full dissolutionbuild-consensus — consensus before major dissolution prevents team fragmentationdecommission-validated-system — formal decommissioning process for regulated systemsconduct-post-mortem — post-mortem analysis shares the investigative rigor of dissolution