vishnu-bhaga
Über
Die vishnu-bhaga-Fähigkeit konzentriert sich darauf, den Zustand eines funktionierenden Systems und verifiziertes Wissen vor Drift, Scope Creep oder Kontextverlust zu bewahren. Sie erzwingt Konsistenz und stabilisiert funktionierende Ansätze, um Kontinuität während Änderungen sicherzustellen. Entwickler sollten sie nutzen, um Entscheidungen zu verankern, bevor sie ein System ändern, nach einer disruptiven Änderung oder in langen Sitzungen, in denen früherer Kontext komprimiert sein könnte.
Schnellinstallation
Claude Code
Empfohlennpx 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/vishnu-bhagaKopieren Sie diesen Befehl und fügen Sie ihn in Claude Code ein, um diese Fähigkeit zu installieren
Dokumentation
Vishnu Bhaga
Preserve what works → anchor verified knowledge → hold consistency under perturbation → block needless change.
Use When
- Working approach → scope creep|premature opt threat
- Ctx drift → stale assumptions overwriting verified
- Parallel concerns → pressure to change stable
- Post
shiva-bhaga→ protect survivors during rebuild - Long sess → ctx compression → lose verified decisions
- Pre-change → sys currently functioning
In
- Required: Working state|verified knowledge (implicit)
- Optional: Threat ("scope creep", "compression near")
- Optional: MEMORY.md + project files (
Read)
Do
Step 1: Inventory
ID functional + verified before protect.
Preservation Inventory:
+---------------------+---------------------------+------------------------+
| Category | Verification Method | Anchoring Action |
+---------------------+---------------------------+------------------------+
| Verified Facts | Confirmed via tool use | Record source and |
| | (file reads, test runs, | timestamp; do not |
| | API responses) | re-derive |
+---------------------+---------------------------+------------------------+
| Working Code | Tests pass, behavior | Do not refactor unless |
| | confirmed, user approved | explicitly requested |
+---------------------+---------------------------+------------------------+
| User Requirements | Explicitly stated by | Quote directly; do not |
| | the user in this session | paraphrase or infer |
+---------------------+---------------------------+------------------------+
| Agreed Decisions | Decisions made and | Reference the decision |
| | confirmed during this | point; do not revisit |
| | session | without new evidence |
+---------------------+---------------------------+------------------------+
| Environmental State | File paths, configs, | Verify before assuming |
| | tool availability | unchanged |
+---------------------+---------------------------+------------------------+
- Per category → list verified+working items
- Note verify method → how know true?
- No verify → not preserved → assumption (maybe
shiva-bhaga)
Got: Concrete inventory verified+working w/ evidence.
If err: Sparse inventory = signal. Run heal to re-ground before preserving unverified.
Step 2: ID Perturbation
Name forces threatening stable state.
- Scope creep: Task expanding past agreed?
- Ctx drift: Earlier facts overwritten by recent (wrong?) reasoning?
- Opt pressure: Urge to improve adequate?
- External: Env changed (files modified, tools gone)?
- Compression: Near ctx limits → early decisions lost?
Per source: real threat or anticipated?
Got: Named sources w/ severity (active vs anticipated).
If err: No sources apparent → preservation may not need → consider brahma-bhaga (creation) or continue.
Step 3: Anchor
Apply technique per threat.
- Mem anchor: Critical facts at drift risk → restate explicitly:
- "Established fact: [X], verified by [method] at [point]"
- Persistent mem available → write durable to MEMORY.md
- Scope boundary: Scope creep → restate agreed scope:
- "Agreed scope: [orig req]. Current within/outside boundary."
- Change resistance: Working code under opt pressure:
- "Component working+tested. No changes unless user req."
- State snapshot: Compression risk → mental checkpoint:
- Summarize: done, remaining, key decisions
- Env verify: External changes → recheck before proceed:
- Re-read critical files vs relying on earlier reads
Got: Each threat → specific anchor. Stable state explicitly protected.
If err: Anchoring excessive → protecting all equally → prioritize. One thing must not change? Protect first.
Step 4: Sustain
Preservation not passive → ongoing attention.
- Pre-action check: "Threatens preservation inventory?"
- Yes → alt approach achieves goal w/o disturb
- Disturbance unavoidable → acknowledge explicitly + update inventory
- Periodic re-verify preserved items → esp. after complex ops
- Task done → confirm preserved intact
Got: Working state survives intact. Changes only where needed, no disrupt.
If err: Preserved item changed → assess damage now. Broke something → revert. Neutral change → update inventory. No stale inventory.
Check
- Working state inventoried w/ verify evidence
- Perturbation sources ID'd + assessed
- Anchors applied per real threat
- Scope boundaries held throughout
- Preserved items re-verified after
Traps
- Assumptions as facts: Only verified deserves protect. Unverified-as-fact = false stability
- Over-preserve: Protect all equally → blocks needed change. Selective: protect works, release fails
- Passive: Assume stable w/o verify. Drift constant → ongoing attention
- Block legit change: User req change to working → overrides preservation
- Stale inventory: Update as new info arrives. Reflect current, not creation-time
→
shiva-bhaga— destruction precedes preservation; survivors → Vishnu sustainsbrahma-bhaga— creation builds on preserved foundation; new from stable groundheal— subsystem assess reveals genuinely functional vs superficially stableobserve— neutral observation detects drift before threats stabilityawareness— Cooper color codes → perturbation detection
GitHub Repository
Verwandte Skills
executing-plans
DesignVerwenden Sie die Fähigkeit "executing-plans", wenn Sie einen vollständigen Implementierungsplan zur Ausführung in kontrollierten Batches mit Überprüfungspunkten vorliegen haben. Sie lädt den Plan und überprüft ihn kritisch, führt dann Aufgaben in kleinen Batches (standardmäßig 3 Aufgaben) aus und meldet den Fortschritt zwischen jedem Batch zur Überprüfung durch den Architekten. Dies gewährleistet eine systematische Implementierung mit integrierten Qualitätskontrollpunkten.
requesting-code-review
DesignDiese Fähigkeit sendet einen Unteragenten für Code-Review, um Codeänderungen anhand der Anforderungen zu analysieren, bevor fortgefahren wird. Sie sollte nach dem Abschließen von Aufgaben, der Implementierung größerer Funktionen oder vor dem Zusammenführen in den Hauptzweig verwendet werden. Die Überprüfung hilft dabei, Probleme frühzeitig zu erkennen, indem die aktuelle Implementierung mit dem ursprünglichen Plan verglichen wird.
connect-mcp-server
DesignDiese Fähigkeit bietet Entwicklern eine umfassende Anleitung, um MCP-Server über HTTP-, stdio- oder SSE-Transports mit Claude Code zu verbinden. Sie behandelt Installation, Konfiguration, Authentifizierung und Sicherheit für die Integration externer Dienste wie GitHub, Notion und benutzerdefinierter APIs. Nutzen Sie sie beim Einrichten von MCP-Integrationen, bei der Konfiguration externer Tools oder bei der Arbeit mit Claude's Model Context Protocol.
web-cli-teleport
DesignDiese Fähigkeit unterstützt Entwickler bei der Wahl zwischen Claude Code Web- und CLI-Schnittstellen basierend auf Aufgabenanalysen und ermöglicht nahtloses Session-Teleporting zwischen diesen Umgebungen. Sie optimiert den Workflow, indem sie den Sitzungsstatus und Kontext beim Wechsel zwischen Web, CLI oder Mobilgeräten verwaltet. Nutzen Sie sie für komplexe Projekte, die in verschiedenen Phasen unterschiedliche Werkzeuge erfordern.
