スキル一覧に戻る

shift-camouflage

pjt222
更新日 2 days ago
7 閲覧
17
2
17
GitHubで表示
開発api

について

このスキルは、環境コンテキストに基づいて異なるインターフェースを提示する適応的でポリモーフィックなAPIを実現します。これは、イカが外見を変えるのと同様の仕組みです。コアロジックを変更することなく、露出する表面層を動的に変更することで、攻撃対象領域を縮小し、機能フラグを有効化します。コンテキストを考慮した動作、段階的なロールアウト、異なる観察者からのシステムパターンの隠蔽にご利用ください。

クイックインストール

Claude Code

推奨
メイン
npx skills add pjt222/agent-almanac -a claude-code
プラグインコマンド代替
/plugin add https://github.com/pjt222/agent-almanac
Git クローン代替
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/shift-camouflage

このコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします

ドキュメント

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

GitHub リポジトリ

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

関連スキル

qmd

開発

qmdは、BM25、ベクトル埋め込み、およびリランキングを組み合わせたハイブリッド検索を用いて、ローカルファイルのインデックス作成と検索を可能にするローカル検索・インデックス作成CLIツールです。コマンドラインでの使用と、Claudeとの統合のためのMCP(Model Context Protocol)モードの両方をサポートしています。このツールは埋め込みにOllamaを使用し、インデックスをローカルに保存するため、ターミナルから直接ドキュメントやコードベースを検索するのに最適です。

スキルを見る

subagent-driven-development

開発

このスキルは、各独立したタスクに対して新規のサブエージェントを起動し、タスク間でコードレビューを実施しながら実装計画を実行します。レビュープロセスを通じて品質基準を維持しつつ、迅速な反復を可能にします。同一セッション内で主に独立したタスクに取り組む際に本スキルをご利用いただくことで、組み込まれた品質チェックを伴う継続的な進捗を確保できます。

スキルを見る

mcporter

開発

mcporterスキルは、開発者がClaudeから直接Model Context Protocol(MCP)サーバーを管理および呼び出せるようにします。このスキルは、利用可能なサーバーの一覧表示、引数を指定したツールの呼び出し、認証およびデーモンのライフサイクル管理を行うコマンドを提供します。開発ワークフローにおいてMCPサーバーの機能を統合およびテストする際に、このスキルをご利用ください。

スキルを見る

adk-deployment-specialist

開発

このスキルは、A2Aプロトコルを使用してVertex AI ADKエージェントをデプロイおよびオーケストレーションし、AgentCardの発見、タスク送信、およびコード実行サンドボックスやメモリバンクなどのサポートツールを管理します。Python、Java、またはGoで、順次、並列、またはループのオーケストレーションパターンを用いたマルチエージェントシステムの構築を可能にします。Google Cloud上でADKエージェントのデプロイやエージェントワークフローのオーケストレーションを求められた際にご利用ください。

スキルを見る