shiva-bhaga

# 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

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

**If fail:** 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.

**Got:** A clear distinction between what is kept and what is released.

**If fail:** 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

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

**If fail:** 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

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

**If fail:** 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

## 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