vishnu-bhaga
О программе
Навык vishnu-bhaga ориентирован на сохранение состояния рабочей системы и проверенных знаний, защищая их от дрейфа, расползания функциональности или потери контекста. Он обеспечивает согласованность и стабилизирует рабочие подходы, гарантируя преемственность в процессе изменений. Разработчикам следует использовать его для фиксации решений перед модификацией системы, после разрушительных изменений или во время длительных сессий, где ранний контекст может быть сжат.
Быстрая установка
Claude Code
Рекомендуется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-bhagaСкопируйте и вставьте эту команду в Claude Code для установки этого навыка
Документация
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 репозиторий
Похожие навыки
executing-plans
ДизайнИспользуйте навык executing-plans, когда у вас есть полный план реализации для выполнения контролируемыми партиями с контрольными точками проверки. Он загружает и критически анализирует план, затем выполняет задачи небольшими партиями (по умолчанию 3 задачи), сообщая о прогрессе между каждой партией для проверки архитектором. Это обеспечивает систематическую реализацию со встроенными контрольными точками проверки качества.
requesting-code-review
ДизайнЭтот навык запускает суб-агента для ревью кода, который анализирует изменения в коде на соответствие требованиям перед дальнейшими действиями. Его следует использовать после завершения задач, реализации крупных функций или перед слиянием с основной веткой. Ревью помогает выявить проблемы на ранней стадии, сравнивая текущую реализацию с исходным планом.
connect-mcp-server
ДизайнЭтот навык предоставляет разработчикам подробное руководство по подключению серверов MCP к Claude Code с использованием транспортов HTTP, stdio или SSE. Он охватывает установку, конфигурацию, аутентификацию и безопасность для интеграции внешних сервисов, таких как GitHub, Notion и пользовательские API. Используйте его при настройке интеграций MCP, конфигурации внешних инструментов или работе с Model Context Protocol от Claude.
web-cli-teleport
ДизайнЭтот навык помогает разработчикам выбирать между веб-интерфейсом Claude Code и CLI на основе анализа задачи, а также обеспечивает бесшовное перемещение сессий между этими средами. Он оптимизирует рабочий процесс, управляя состоянием и контекстом сессии при переключении между веб-интерфейсом, CLI или мобильным приложением. Используйте его для сложных проектов, требующих различных инструментов на разных этапах работы.
