vishnu-bhaga
À propos
La compétence vishnu-bhaga se concentre sur la préservation de l'état d'un système fonctionnel et des connaissances vérifiées contre la dérive, l'élargissement du périmètre ou la perte de contexte. Elle impose la cohérence et stabilise les approches opérationnelles, garantissant la continuité pendant les changements. Les développeurs doivent l'utiliser pour ancrer les décisions avant de modifier un système, après un changement perturbateur, ou lors de longues sessions où le contexte antérieur peut être comprimé.
Installation rapide
Claude Code
Recommandé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/vishnu-bhagaCopiez et collez cette commande dans Claude Code pour installer cette compétence
Documentation
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
Dépôt GitHub
Compétences associées
executing-plans
DesignUtilisez la compétence executing-plans lorsque vous disposez d'un plan de mise en œuvre complet à exécuter par lots contrôlés avec des points de contrôle de revue. Elle charge et examine le plan de manière critique, puis exécute les tâches par petits lots (3 tâches par défaut) tout en rapportant la progression entre chaque lot pour une revue par l'architecte. Cela garantit une mise en œuvre systématique avec des points de contrôle de qualité intégrés.
requesting-code-review
DesignCette compétence délègue un sous-agent réviseur de code pour analyser les modifications apportées au code par rapport aux exigences avant de poursuivre. Elle doit être utilisée après avoir terminé des tâches, implémenté des fonctionnalités majeures, ou avant une fusion vers la branche principale. La revue aide à détecter précocement les problèmes en comparant l'implémentation actuelle avec le plan initial.
connect-mcp-server
DesignCette compétence fournit un guide complet permettant aux développeurs de connecter des serveurs MCP à Claude Code via les transports HTTP, stdio ou SSE. Elle couvre l'installation, la configuration, l'authentification et la sécurité pour intégrer des services externes tels que GitHub, Notion et des API personnalisées. Utilisez-la lors de la configuration d'intégrations MCP, de la configuration d'outils externes ou du travail avec le Protocole de Contexte de Modèle de Claude.
web-cli-teleport
DesignCette compétence aide les développeurs à choisir entre les interfaces Web et CLI de Claude Code en fonction de l'analyse des tâches, puis permet une téléportation transparente des sessions entre ces environnements. Elle optimise le flux de travail en gérant l'état et le contexte de la session lors du passage entre le web, la CLI ou le mobile. Utilisez-la pour des projets complexes nécessitant différents outils à diverses étapes.
