MCP HubMCP Hub
Retour aux compétences

shift-camouflage

pjt222
Mis à jour 2 days ago
8 vues
17
2
17
Voir sur GitHub
Développementapi

À propos

Cette compétence permet la création d'API adaptatives et polymorphes qui présentent différentes interfaces selon le contexte environnemental, à la manière d'une seiche modifiant son apparence. Elle réduit les surfaces d'attaque et permet le feature flagging en altérant dynamiquement la couche de surface exposée sans modifier la logique centrale. Utilisez-la pour des comportements sensibles au contexte, des déploiements progressifs et pour masquer les modèles du système à différents observateurs.

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/shift-camouflage

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation

Shift Camouflage

Adaptive surface transform — polymorphic interfaces, context-aware behavior, dynamic presentation. Cuttlefish chromatophores. Surface adapts → env, core stable. Reduces attack surface + optimizes diverse observer interaction.

Use When

  • Diff interfaces → diff consumers (API ver, multi-tenant, role-based)
  • Reduce attack surface → expose only what observer needs
  • Feature flags, progressive rollout, A/B at interface
  • Adapt behavior → env context w/o core change
  • Protect internal arch from external coupling (observers couple surface, not structure)
  • Complement adapt-architecture when surface enough, deep transform unneeded

In

  • Required: System whose surface adapts
  • Required: Observers + diff interface needs
  • Optional: Current interface design + limits
  • Optional: Threat model (hide what from whom?)
  • Optional: Feature flag | progressive rollout infra
  • Optional: Perf constraints (dynamic surface gen has overhead)

Do

Step 1: Map Observer Landscape

Who interacts + what each needs to see.

  1. Catalog observers:
    • External (end users, API consumers, partners)
    • Internal services (microservices, bg jobs, admin tools)
    • Adversaries (attackers, scrapers, competitors)
    • Regulators (auditors, compliance)
  2. Per observer:
    • Need to see (req surface)
    • Should not see (hidden)
    • Expect to see (compat surface — may differ from need)
    • How interact (protocol, freq, sensitivity)
  3. Build observer-surface matrix:
Observer-Surface Matrix:
┌──────────────┬────────────────────────┬─────────────────┬──────────────┐
│ Observer     │ Required Surface       │ Hidden Surface  │ Threat Level │
├──────────────┼────────────────────────┼─────────────────┼──────────────┤
│ End users    │ Public API v2, UI      │ Internal APIs,  │ Low          │
│              │                        │ admin endpoints │              │
├──────────────┼────────────────────────┼─────────────────┼──────────────┤
│ Partner API  │ Partner API, webhooks  │ Internal logic, │ Medium       │
│              │                        │ user data       │              │
├──────────────┼────────────────────────┼─────────────────┼──────────────┤
│ Admin tools  │ Full API, debug        │ Raw data store  │ Low          │
│              │ endpoints              │ access          │              │
├──────────────┼────────────────────────┼─────────────────┼──────────────┤
│ Adversaries  │ Nothing (minimal)      │ Everything      │ High         │
│              │                        │ possible        │              │
└──────────────┴────────────────────────┴─────────────────┴──────────────┘

Got: Complete observer landscape w/ surface reqs. Drives all camouflage design.

If err: Incomplete obs ID → start two extremes (most privileged: admin; most restricted: adversary). Design surfaces, interpolate between.

Step 2: Design Chromatophore Mapping

Map observer context → surface presentation. "Chromatophore" layer.

  1. Context signals:
    • Auth identity → privilege
    • Origin → geo, network, app
    • Feature flags → enable/disable
    • Time/phase → deploy stage, biz hours, maint
    • Load/health → degraded mode → reduced surface
  2. Surface gen rules. Per context combo, elements are:
    • Visible: in res/interface
    • Hidden: excluded entirely (errs reveal nothing)
    • Transformed: present but modified for observer (diff schema, simpler data)
    • Decoy: deliberately misleading for adversarial contexts
  3. Implement chromatophore layer:
    • Thin middleware/proxy between core + observers
    • Eval context signals each req
    • Apply surface config
    • Never modify core behavior — only filter + transform surface
Chromatophore Architecture:
┌──────────────────────────────────────────────────────┐
│ Observer Request                                      │
│        │                                              │
│        ↓                                              │
│ ┌─────────────────┐                                   │
│ │ Context Extract  │ ← Auth, origin, flags, time      │
│ └────────┬────────┘                                   │
│          ↓                                            │
│ ┌─────────────────┐                                   │
│ │ Surface Select   │ ← Observer-surface matrix lookup  │
│ └────────┬────────┘                                   │
│          ↓                                            │
│ ┌─────────────────┐                                   │
│ │ Core System      │ ← Processes request normally      │
│ └────────┬────────┘                                   │
│          ↓                                            │
│ ┌─────────────────┐                                   │
│ │ Surface Filter   │ ← Remove/transform/add elements   │
│ └────────┬────────┘                                   │
│          ↓                                            │
│ Observer Response (adapted surface)                    │
└──────────────────────────────────────────────────────┘

Got: Mapping translates observer context → surface config. Explicit, auditable, separate from core.

If err: Too complex → simplify to role-based: 3-5 profiles (public, partner, admin, internal, minimal). Map every observer → one.

Step 3: Behavioral Polymorphism

Behavior adapts to context, not just surface.

  1. Context-dep behaviors:
    • Res detail (verbose admin, minimal public)
    • Rate limit (generous partners, strict unknown)
    • Err msgs (detail internal, generic external)
    • Data freshness (real-time premium, cached std)
    • Feature avail (full beta, stable-only general)
  2. Variants:
    • Each = complete tested path
    • Context → which variant runs
    • Variants share core, differ in presentation + policy
  3. Feature flag integration:
    • Flags control active variants
    • Progressive rollout: % of observers, increase over time
    • Circuit breakers: auto-revert safe behavior on err

Got: Behavior adapts → context. Same core → appropriate res for diff audiences. Flags → progressive rollout.

If err: Too many code paths → consolidate pipeline: core → policy layer → presentation layer. Polymorphism in policy + presentation only, core singular.

Step 4: Reduce Attack Surface

Minimize what adversaries observe + interact w/.

  1. Least surface:
    • Each observer sees only what needed
    • Unauth observers see min possible
    • Errs never leak internals (no stack traces, paths, vers)
  2. Active reduction:
    • Remove default pages, headers, endpoints revealing tech stack
    • Randomize non-essential res chars (timing jitter, header order)
    • Disable unused endpoints entirely (off, not hidden)
  3. Pattern disruption:
    • Vary res chars → defeat fingerprint
    • Controlled unpredictability in non-functional aspects
    • Functional behavior deterministic, surface chars vary
  4. Recon monitoring:
    • Detect req patterns probing hidden surface (enum attacks)
    • Alert repeated access to nonexistent endpoints (path fuzz)
    • Track + correlate recon across sessions (see defend-colony)

Got: Min attack surface. Adversaries can't ID stack, internals, hidden caps. Recon detected + tracked.

If err: Reduction breaks legit consumers → matrix incomplete. Review Step 1, update. Randomization issues → reduce to non-functional only (timing, headers), keep functional res deterministic.

Step 5: Surface Coherence

Dynamic surface stays consistent, debuggable, maintainable.

  1. Testing:
    • Each profile explicit (admin sees admin? public sees public?)
    • Transitions (context changes mid-session?)
    • Failure modes (chromatophore layer fails → what surface?)
  2. Docs:
    • Each profile + config
    • Context signals + effects
    • Sync w/ actual behavior (test docs vs reality)
  3. Debug:
    • Admin/debug mode → which profile active + why
    • Logs → which config applied per req
    • Replay req through specific profile
  4. Evolution:
    • Add: appropriate profiles, test, deploy
    • Remove: deprecation warning, then remove
    • Change: flag controlled, progressive rollout

Got: Maintainable, testable, documented system. Dynamic ≠ undebuggable.

If err: Debug nightmare → add transparency: trace header (admin/debug only) → which profile applied + which signals decided.

Check

  • Observer landscape mapped w/ surface reqs
  • Chromatophore translates context → surface config
  • Behavioral polymorphism adapts to context
  • Attack surface min for adversaries
  • Each profile explicit tested
  • Failure mode → safe default (minimal)
  • Debug/admin can inspect active config
  • Docs match behavior

Traps

  • Complexity explosion: Too many profiles + variations. Max 3-5 profiles.
  • Core contamination: Surface logic leaks into core. Chromatophore = separate. If-statements about observer type in core code → arch wrong.
  • Obscurity alone: Surface reduction = defense-in-depth, not auth/authz replacement. Hidden endpoint still needs authn+authz.
  • Inconsistent surfaces: A sees v1, B sees v2, supposed same. Test explicit, matrix authoritative.
  • Failure surface: Chromatophore fails → what does observer see? Default must be safe (minimal), not open (full).

  • assess-form — surface adaptation may resolve form pressure w/o deep transform
  • adapt-architecture — deep structural change when surface insufficient
  • repair-damage — surface can mask damage during repair (caution — don't hide real probs)
  • defend-colony — attack surface reduction = defense layer
  • coordinate-swarm — context-aware in distributed needs coordinated surface
  • configure-api-gateway — API gateways implement chromatophore in practice
  • deploy-to-kubernetes — k8s svc + ingress enable network-level surface control

Dépôt GitHub

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

Compétences associées

qmd

Développement

qmd est un outil CLI de recherche et d'indexation locale qui permet aux développeurs d'indexer et de rechercher dans des fichiers locaux en utilisant une recherche hybride combinant BM25, des embeddings vectoriels et du reranking. Il prend en charge à la fois une utilisation en ligne de commande et un mode MCP (Model Context Protocol) pour l'intégration avec Claude. L'outil utilise Ollama pour les embeddings et stocke les index localement, ce qui le rend idéal pour rechercher dans de la documentation ou des bases de code directement depuis le terminal.

Voir la compétence

subagent-driven-development

Développement

Cette compétence exécute des plans de mise en œuvre en déployant un nouveau sous-agent pour chaque tâche indépendante, avec une revue de code entre les tâches. Elle permet une itération rapide tout en maintenant des contrôles de qualité grâce à ce processus de revue. Utilisez-la lorsque vous travaillez sur des tâches principalement indépendantes au sein d'une même session pour assurer une progression continue avec des vérifications de qualité intégrées.

Voir la compétence

mcporter

Développement

La compétence mcporter permet aux développeurs de gérer et d'appeler des serveurs Model Context Protocol (MCP) directement depuis Claude. Elle fournit des commandes pour lister les serveurs disponibles, appeler leurs outils avec des arguments, et gérer l'authentification ainsi que le cycle de vie du démon. Utilisez cette compétence pour intégrer et tester les fonctionnalités des serveurs MCP dans votre flux de travail de développement.

Voir la compétence

adk-deployment-specialist

Développement

Cette compétence déploie et orchestre des agents Vertex AI ADK en utilisant le protocole A2A, gérant la découverte d'AgentCard, la soumission de tâches, et prenant en charge des outils tels que le bac à sable d'exécution de code et la banque de mémoire. Elle permet de construire des systèmes multi-agents avec des modèles d'orchestration séquentiels, parallèles ou en boucle en Python, Java ou Go. Utilisez-la lorsqu'on vous demande de déployer des agents ADK ou d'orchestrer des flux de travail d'agents sur Google Cloud.

Voir la compétence