Shiva Bhaga

Controlled destruction and dissolution of stale patterns, outdated assumptions, and accumulated noise — clearing the ground so new growth can emerge.

When to Use

• Context has accumulated stale assumptions that are silently distorting reasoning
• A previous approach has failed and the temptation is to patch rather than discard
• The conversation has grown long and earlier decisions may no longer serve the current goal
• Dead code, abandoned plans, or zombie tasks are creating noise and confusion
• Before a major pivot — clearing must precede creation
• When attachment to a particular approach is preventing consideration of alternatives

Inputs

• Required: Current conversation state or project context (available implicitly)
• Optional: Specific target for dissolution (e.g., "this approach isn't working," "clear all assumptions about the database layer")
• Optional: Scope boundary — what must be preserved through the destruction

Procedure

Step 1: Identify What Must End

Survey the current state and mark what is stale, broken, or no longer serving the goal.

Dissolution Triage:
+---------------------+---------------------------+------------------------+
| Category            | Symptoms                  | Action                 |
+---------------------+---------------------------+------------------------+
| Stale Assumptions   | Decisions made early that | List and re-evaluate   |
|                     | no longer match current   | each against current   |
|                     | understanding             | reality                |
+---------------------+---------------------------+------------------------+
| Failed Approaches   | Approaches attempted and  | Acknowledge failure    |
|                     | abandoned but still       | explicitly; release    |
|                     | influencing thinking      | the sunk cost          |
+---------------------+---------------------------+------------------------+
| Accumulated Noise   | Context, variables, or    | Identify and mark for  |
|                     | plans that are no longer  | removal                |
|                     | referenced or relevant    |                        |
+---------------------+---------------------------+------------------------+
| Attachment Points   | "We already decided..."   | Question whether the   |
|                     | beliefs that resist       | decision still holds   |
|                     | re-examination            |                        |
+---------------------+---------------------------+------------------------+
| Zombie Artifacts    | Code, tasks, or plans     | Delete or archive;     |
|                     | that exist but serve no   | do not leave in limbo  |
|                     | current purpose           |                        |
+---------------------+---------------------------+------------------------+

1. Scan each category honestly — resistance to examining a category is itself a signal
2. For each item found, ask: "If I were starting fresh right now, would I create this?"
3. If the answer is no, mark it for dissolution

Expected: A clear inventory of what needs to be released, with specific items in each category.

On failure: If nothing seems stale, the assessment may be too shallow. Pick the oldest decision in the current context and justify it from scratch — if the justification feels forced, it is a candidate for dissolution.

Step 2: Establish the Preservation Boundary

Not everything should be destroyed. Identify what must survive the clearing.

1. Core requirements: What did the user actually ask for? This survives.
2. Verified knowledge: Facts confirmed through tool use (file reads, test results) survive.
3. User preferences: Explicitly stated preferences and constraints survive.
4. Working components: Code or approaches that are demonstrably functioning survive.

Draw the boundary: everything inside is preserved, everything outside is subject to dissolution.

Expected: A clear distinction between what is kept and what is released.

On failure: If the boundary is unclear, ask: "What would I need to reconstruct if I started this task from scratch?" The answer defines the preservation boundary.

Step 3: Dissolve with Intention

Execute the dissolution — not as abandonment but as intentional clearing.

1. For each marked item, release it explicitly:
   • Stale assumption: "I assumed X, but current evidence shows Y. Releasing X."
   • Failed approach: "Approach A was attempted and did not work because Z. Releasing attachment to A."
   • Noise: "Variable/plan/context Q is no longer relevant. Removing from consideration."
2. Do not justify or defend what is being dissolved — the point is release, not analysis
3. If dissolving a large body of accumulated context, summarize what was dissolved and why in one sentence
4. Clear the workspace: if applicable, close abandoned files, reset mental model, acknowledge the clean slate

Expected: A lighter, cleaner context with stale elements removed. The remaining context should feel accurate and current.

On failure: If dissolution feels incomplete — some released items keep influencing thinking — name them again explicitly. "I notice I am still reasoning as if X is true. X was dissolved. Proceeding without X."

Step 4: Sit in the Void

After destruction, resist the urge to immediately rebuild. The space between destruction and creation has value.

1. Acknowledge the cleared space: "The following has been dissolved: [list]"
2. Note what remains: "What survives: [list]"
3. Resist premature reconstruction — do not immediately propose a replacement for what was dissolved
4. Allow the cleared space to inform what comes next
5. The void is not emptiness — it is potential. The next step (creation via

   brahma-bhaga

   or preservation via

   vishnu-bhaga

   ) emerges from this space

Expected: A moment of clarity between the old and the new. The next direction becomes apparent from what remains rather than being forced.

On failure: If the void feels uncomfortable and there is a strong pull to immediately rebuild, that urgency is itself a signal — it may indicate attachment to the dissolved pattern. Sit longer. The right next step will emerge.

Validation

• Stale assumptions were identified and explicitly released
• Failed approaches were acknowledged without defensiveness
• Accumulated noise was cleared from the working context
• The preservation boundary was established before dissolution
• Core requirements and user preferences were preserved
• The cleared space was acknowledged before moving to creation

Common Pitfalls

• Destroying too much: Dissolution without a preservation boundary destroys working components along with stale ones. Always draw the boundary first
• Destroying too little: Polite dissolution that "releases" things while still letting them influence reasoning. True dissolution requires actually letting go
• Skipping the void: Rushing from destruction to creation without sitting in the cleared space produces a recreation of the old pattern with superficial changes
• Performing destruction: Going through the motions of clearing without actually updating the internal model. If the same assumptions reappear in the next response, dissolution was performative
• Destruction as avoidance: Using dissolution to escape a difficult problem rather than to clear genuine staleness. If the problem persists after clearing, it was not the stale context — it was the problem itself

Related Skills

• brahma-bhaga

  — creation follows destruction; after clearing, new patterns emerge from the void

• vishnu-bhaga

  — preservation complements destruction; what survives dissolution is sustained

• heal

  — subsystem assessment may reveal what needs dissolution before healing can proceed

• meditate

  — clearing context noise before dissolution prevents reactive over-destruction

• dissolve-form

  — the morphic equivalent for architectural dismantling with imaginal disc preservation