defend-colony
정보
이 스킬은 면역 반응 패턴에서 영감을 받아, 분산 시스템이나 조직에서 계층적이고 집단적인 방어 체계를 구현하기 위한 프레임워크를 제공합니다. 경보 신호, 역할 동원 및 정의된 단계적 확대 체계를 통해 위협에 비례하는 대응을 가능하게 하여 과잉 또는 과소 대응을 방지합니다. 이를 통해 단일 장애점이 존재하지 않는 확장 가능한 다중 방어 체계의 사고 처리를 설계할 수 있습니다.
빠른 설치
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/defend-colonyClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Defend Colony
Implement layered collective defense for distributed systems, teams, or organizations — using alarm signaling, role mobilization, proportional response, and immune memory patterns inspired by social insect colony defense and biological immune systems.
When to Use
- Designing defense-in-depth for distributed systems where no single guardian can cover all threats
- Building incident response processes that scale with threat severity
- Protecting a system where individual components cannot defend themselves alone
- Current defense is either over-reactive (every alert triggers full mobilization) or under-reactive (threats go unnoticed until damage is done)
- Building organizational resilience where teams must self-organize in response to incidents
- Complementing
coordinate-swarmwith specific threat-response coordination patterns
Inputs
- Required: Description of the colony (system, organization, team) to be defended
- Required: Known threat categories (attacks, failures, competitors, environmental risks)
- Optional: Current defense mechanisms and their failure modes
- Optional: Available defender types and their capabilities
- Optional: Acceptable response latency per threat tier
- Optional: Post-incident recovery requirements
Procedure
Step 1: Map the Threat Landscape and Defense Perimeter
Identify what needs defending, from what, and where the perimeter lies.
- Define the colony's critical assets:
- What must be protected at all costs? (core data, production systems, key people)
- What can sustain temporary damage? (staging environments, non-critical services)
- What is expendable under extreme threat? (caches, replicas, non-essential features)
- Classify threats by type and severity:
- Probes: low-level reconnaissance or testing (port scans, repeated failed logins)
- Incursions: active boundary violations (unauthorized access, injection attempts)
- Infestations: persistent threats already inside the perimeter (compromised nodes, insider threats)
- Existential: threats to the colony's survival (data corruption, catastrophic failure, DDoS)
- Map the defense perimeter:
- Outer perimeter: first detection opportunity (firewalls, rate limits, monitoring)
- Inner perimeter: critical asset boundaries (access controls, encryption, isolation)
- Core: last-resort defenses (backups, kill switches, circuit breakers)
Got: A clear map of assets (prioritized), threats (classified by severity), and defense perimeters (layered). This map guides all subsequent defense design.
If fail: If the threat landscape feels overwhelming, start with the top 3 critical assets and the top 3 threat types. Perfect coverage is less important than coverage of what matters most. If perimeter boundaries are unclear, default to "trust nothing, verify everything" (zero-trust posture) and define boundaries as you observe actual traffic patterns.
Step 2: Design the Alarm Signaling Network
Build the communication system that detects threats and propagates alerts.
- Deploy sentinels at each defense layer:
- Outer sentinels: lightweight, high-sensitivity detectors (may produce false positives)
- Inner sentinels: heavier, high-specificity detectors (fewer false positives, slower)
- Core sentinels: critical asset monitors (zero tolerance for missed threats)
- Define alarm signals with graduated intensity:
- Yellow: anomaly detected, increased monitoring, no mobilization
- Orange: confirmed threat pattern, local defenders mobilize, scouts investigate
- Red: active breach or severe threat, full defense mobilization, non-essential activity paused
- Black: existential threat, all resources to defense, sacrifice expendable assets if needed
- Implement alarm propagation:
- Local: sentinels alert nearby defenders directly
- Regional: sentinel clusters aggregate signals and escalate if threshold is met
- Colony-wide: regional escalation triggers broadcast alarm
- Each propagation step adds confirmation — a single sentinel cannot trigger colony-wide alarm
- Build in alarm fatigue prevention:
- Auto-suppress repeated identical alarms (dedup with time window)
- Require escalation to be confirmed by independent sentinels
- Track alarm-to-threat ratio — if false positive rate exceeds 50%, recalibrate sentinels
Alarm Propagation:
┌──────────────────────────────────────────────────────────┐
│ Sentinel detects anomaly ──→ Yellow alert (local) │
│ │ │
│ ↓ (confirmed by 2nd sentinel) │
│ Orange alert ──→ Local defenders mobilize │
│ │ │
│ ↓ (pattern matches known threat + 3rd sentinel) │
│ Red alert ──→ Full defense mobilization │
│ │ │
│ ↓ (critical asset under active attack) │
│ Black alert ──→ All resources to defense, circuit break │
└──────────────────────────────────────────────────────────┘
Got: A graduated alarm system where threat severity determines response intensity. Multiple independent sentinel confirmations prevent single-point false alarms. Alarm fatigue is managed through deduplication and calibration.
If fail: If the alarm system produces too many false positives, raise sentinel thresholds or require more confirmations before escalation. If threats slip through undetected, add sentinels at the penetrated layer or lower detection thresholds. If alarm propagation is too slow, reduce the confirmation requirements — but accept higher false positive rate as the tradeoff.
Step 3: Mobilize Role-Based Defenders
Assign defense roles and mobilization protocols proportional to threat level.
- Define defender roles:
- Sentinels: detection specialists (always active, low resource cost)
- Guards: first responders (idle until mobilized, fast response)
- Soldiers: heavy defenders (expensive to mobilize, high capability)
- Healers: damage repair and recovery specialists (see
repair-damage) - Messengers: coordinate defense across colony regions
- Map roles to alert levels:
- Yellow: sentinels increase monitoring frequency, guards on standby
- Orange: guards mobilize to threat location, soldiers on standby
- Red: soldiers mobilize, non-essential workers reassigned to defense
- Black: all roles to defense, colony activities suspended
- Implement proportional response:
- Never deploy soldiers for a probe (wasteful and reveals capabilities)
- Never rely only on sentinels against an incursion (insufficient response)
- Match the response to the threat tier — escalate if the current tier fails, de-escalate when the threat recedes
- Role transition protocol:
- Workers can become guards (temporary upskilling for emergency)
- Guards can become soldiers (sustained threat requires heavier response)
- After threat passes, reverse transitions restore normal operations
Got: A defense force that scales with threat severity. Normal operations use minimal defense resources. Under threat, the colony can rapidly mobilize proportional defense without over-reacting or under-reacting.
If fail: If mobilization is too slow, pre-position guards closer to known threat vectors. If mobilization is too expensive, reduce the permanent guard force and rely more on worker-to-guard transitions. If role confusion occurs during mobilization, simplify to 3 roles (detect, respond, recover) instead of 5.
Step 4: Execute Immune Memory and Adaptation
Learn from each threat encounter to improve future defense.
- After each incident, create a threat signature:
- Attack pattern (how the threat was detected)
- Attack vector (where it entered)
- Effective response (what stopped it)
- Failed response (what didn't work)
- Store signatures in the colony's immune memory:
- Fast-lookup pattern library for sentinels
- Updated defender playbooks with known-effective responses
- Flagged false-positive patterns to reduce future alarm fatigue
- Implement adaptive immunity:
- New threat signatures are propagated to all sentinels (colony-wide learning)
- Sentinels that detected the threat get priority updates (local learning)
- Periodic review culls outdated signatures (threats that no longer apply)
- Stress test the immune memory:
- Re-simulate past threats periodically to verify defenses still work
- Red team exercises introduce novel threats to test adaptation
- Measure detection time for known vs. unknown threats
Got: A defense system that gets stronger with each encounter. Known threats are detected faster and responded to more effectively. Novel threats are handled by the graduated alarm system, and their resolution adds to the immune memory.
If fail: If immune memory grows too large and slows detection, prioritize signatures by frequency and severity, archiving rare/minor threats. If the defense becomes too specialized against known threats and misses novel ones, maintain a "general patrol" function that doesn't rely on pattern matching — pure anomaly detection as the baseline.
Step 5: Coordinate Post-Incident Recovery
Transition from defense mode back to normal operations with damage repair and resilience improvement.
- Threat elimination verification:
- Confirm the threat is neutralized (not just suppressed)
- Scan for secondary threats that may have entered during the primary incident
- Verify no compromised agents remain active
- Damage assessment:
- Catalog what was damaged, degraded, or lost
- Prioritize repair by criticality (core assets first)
- Estimate recovery time and resources needed
- Recovery execution:
- Deploy healers to damaged areas (see
repair-damagefor detailed recovery) - Restore services in priority order
- Maintain elevated sentinel activity during recovery (vulnerable period)
- Deploy healers to damaged areas (see
- De-escalation protocol:
- Step down alert levels gradually (Red → Orange → Yellow → Normal)
- Return reassigned workers to their primary roles
- Stand down soldiers and return guards to patrol
- Post-incident review within 24 hours while memory is fresh
Got: A smooth transition from defense to recovery to normal operations. Elevated monitoring during recovery catches secondary threats. The post-incident review feeds learnings into immune memory.
If fail: If recovery is too slow, pre-build recovery playbooks for the most likely damage scenarios. If secondary threats emerge during recovery, the de-escalation was too aggressive — maintain higher alert levels for longer. If post-incident review is skipped (common under time pressure), schedule it as a non-negotiable calendar event.
Validation
- Critical assets are identified and prioritized
- Threats are classified by type and severity
- Defense perimeter has multiple layers with sentinels at each
- Alarm signaling has graduated levels with multi-sentinel confirmation
- Defender roles are defined with mobilization mapped to alert levels
- Proportional response prevents over- and under-reaction
- Immune memory captures and applies lessons from each incident
- Post-incident recovery protocol restores normal operations safely
Pitfalls
- Maginot Line defense: Over-investing in a single defense layer while leaving others unprotected. Defense must be layered — any single layer can be breached
- Alert fatigue: Too many alarms with too few real threats degrades defender attention. Calibrate sentinels ruthlessly; a missed false positive is cheaper than a missed real threat
- Symmetric response: Responding to every threat with the same intensity wastes resources and reveals your full capabilities. Match response to threat — escalate only when needed
- No immune memory: Defending against the same threat type repeatedly without learning is expensive and fragile. Every incident must update the colony's defense knowledge
- Permanent war footing: Sustained high-alert operations exhaust defenders and degrade normal colony function. De-escalate deliberately when the threat passes
Related Skills
coordinate-swarm— foundational coordination patterns that support alarm signaling and mobilizationbuild-consensus— rapid consensus for collective defense decisions under time pressurescale-colony— defense systems must scale with colony growthrepair-damage— morphic skill for regenerative recovery after defense incidentsconfigure-alerting-rules— practical alerting configuration that implements alarm signaling patternsconduct-post-mortem— structured post-incident analysis for feeding immune memory
GitHub 저장소
연관 스킬
content-collections
메타이 스킬은 콘텐츠 콜렉션(Content Collections)을 위한 프로덕션 검증된 설정을 제공합니다. 콘텐츠 콜렉션은 Markdown/MDX 파일을 Zod 검증이 포함된 타입 안전한 데이터 콜렉션으로 변환해주는 TypeScript 최우선 도구입니다. 블로그, 문서 사이트 또는 콘텐츠 중심의 Vite + React 애플리케이션을 구축할 때 타입 안전성과 자동 콘텐츠 검증을 보장하기 위해 사용하세요. Vite 플러그인 구성과 MDX 컴파일부터 배포 최적화 및 스키마 검증에 이르기까지 모든 것을 다룹니다.
polymarket
메타이 스킬은 개발자들이 Polymarket 예측 시장 플랫폼을 활용한 애플리케이션을 구축할 수 있도록 지원하며, 거래 및 시장 데이터를 위한 API 통합 기능을 포함합니다. 또한 WebSocket을 통한 실시간 데이터 스트리밍을 제공하여 실시간 거래와 시장 활동을 모니터링할 수 있습니다. 이를 통해 거래 전략을 구현하거나 실시간 시장 업데이트를 처리하는 도구를 생성하는 데 활용할 수 있습니다.
creating-opencode-plugins
메타이 스킬은 개발자들이 명령어, 파일, LSP 작업 등 25개 이상의 이벤트 유형에 연결되는 OpenCode 플러그인을 만들 수 있도록 돕습니다. JavaScript/TypeScript 모듈을 위한 플러그인 구조, 이벤트 API 명세, 구현 패턴을 제공합니다. OpenCode AI 어시스턴트의 라이프사이클을 사용자 정의 이벤트 기반 로직으로 가로채거나, 모니터링하거나, 확장해야 할 때 사용하세요.
sglang
메타SGLang은 RadixAttention 프리픽스 캐싱을 활용하여 JSON, 정규식, 에이전트 워크플로우를 위한 고속 구조화 생성에 특화된 고성능 LLM 서빙 프레임워크입니다. 특히 반복되는 프리픽스가 있는 작업에서 상당히 빠른 추론 속도를 제공하여 복잡한 구조화 출력 및 다중 턴 대화에 이상적입니다. 제약 디코딩이 필요하거나 광범위한 프리픽스 공유가 있는 애플리케이션을 구축할 때는 vLLM과 같은 대안보다 SGLang을 선택하십시오.
