MCP HubMCP Hub
Retour aux compétences

vishnu-bhaga

pjt222
Mis à jour 2 days ago
6 vues
17
2
17
Voir sur GitHub
Designaidesign

À 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é
Principal
npx skills add pjt222/agent-almanac -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternatif
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/vishnu-bhaga

Copiez 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              |
+---------------------+---------------------------+------------------------+
  1. Per category → list verified+working items
  2. Note verify method → how know true?
  3. 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.

  1. Scope creep: Task expanding past agreed?
  2. Ctx drift: Earlier facts overwritten by recent (wrong?) reasoning?
  3. Opt pressure: Urge to improve adequate?
  4. External: Env changed (files modified, tools gone)?
  5. 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.

  1. 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
  2. Scope boundary: Scope creep → restate agreed scope:
    • "Agreed scope: [orig req]. Current within/outside boundary."
  3. Change resistance: Working code under opt pressure:
    • "Component working+tested. No changes unless user req."
  4. State snapshot: Compression risk → mental checkpoint:
    • Summarize: done, remaining, key decisions
  5. 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.

  1. Pre-action check: "Threatens preservation inventory?"
  2. Yes → alt approach achieves goal w/o disturb
  3. Disturbance unavoidable → acknowledge explicitly + update inventory
  4. Periodic re-verify preserved items → esp. after complex ops
  5. 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 sustains
  • brahma-bhaga — creation builds on preserved foundation; new from stable ground
  • heal — subsystem assess reveals genuinely functional vs superficially stable
  • observe — neutral observation detects drift before threats stability
  • awareness — Cooper color codes → perturbation detection

Dépôt GitHub

pjt222/agent-almanac
Chemin: i18n/caveman-ultra/skills/vishnu-bhaga
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Compétences associées

executing-plans

Design

Utilisez 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.

Voir la compétence

requesting-code-review

Design

Cette 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.

Voir la compétence

connect-mcp-server

Design

Cette 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.

Voir la compétence

web-cli-teleport

Design

Cette 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.

Voir la compétence