vishnu-bhaga
Acerca de
La habilidad vishnu-bhaga se centra en preservar el estado de un sistema funcional y el conocimiento verificado frente a la deriva, la expansión del alcance o la pérdida de contexto. Impone coherencia y estabiliza enfoques operativos, garantizando la continuidad durante los cambios. Los desarrolladores deben utilizarla para anclar decisiones antes de modificar un sistema, después de un cambio disruptivo o en sesiones largas donde el contexto anterior pueda haberse comprimido.
Instalación rápida
Claude Code
Recomendadonpx 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-bhagaCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
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
Repositorio GitHub
Habilidades relacionadas
executing-plans
DiseñoUtilice la habilidad executing-plans cuando tenga un plan de implementación completo para ejecutar en lotes controlados con puntos de revisión. Esta habilidad carga y revisa críticamente el plan, luego ejecuta tareas en pequeños lotes (por defecto 3 tareas) mientras reporta el progreso entre cada lote para la revisión del arquitecto. Esto asegura una implementación sistemática con puntos de control de calidad integrados.
requesting-code-review
DiseñoEsta habilidad despacha un subagente revisor de código para analizar los cambios en el código frente a los requisitos antes de proceder. Debe usarse después de completar tareas, implementar funciones principales o antes de fusionar con la rama principal. La revisión ayuda a detectar problemas de forma temprana al comparar la implementación actual con el plan original.
connect-mcp-server
DiseñoEsta habilidad proporciona una guía integral para que los desarrolladores conecten servidores MCP a Claude Code mediante transportes HTTP, stdio o SSE. Cubre la instalación, configuración, autenticación y seguridad para integrar servicios externos como GitHub, Notion y APIs personalizadas. Úsala al configurar integraciones MCP, al configurar herramientas externas o al trabajar con el Protocolo de Contexto del Modelo de Claude.
web-cli-teleport
DiseñoEsta habilidad ayuda a los desarrolladores a elegir entre las interfaces web y CLI de Claude Code mediante el análisis de tareas, y luego permite la teletransportación fluida de sesiones entre estos entornos. Optimiza el flujo de trabajo gestionando el estado y el contexto de la sesión al cambiar entre web, CLI o móvil. Úsala para proyectos complejos que requieren diferentes herramientas en varias etapas.
