Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/sponticelli/gamedev-claude-pluginsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/sponticelli/gamedev-claude-plugins/incident-response)<a href="https://agentmods.dev/commands/sponticelli/gamedev-claude-plugins/incident-response"><img src="https://agentmods.dev/badge/commands/sponticelli/gamedev-claude-plugins/incident-response/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/sponticelli/gamedev-claude-plugins/incident-response"><img src="https://agentmods.dev/badge/commands/sponticelli/gamedev-claude-plugins/incident-response.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00008 | $0.01429 |
| Opus 5 | $0.00004 | $0.00714 |
| Sonnet 5 | $0.00002 | $0.00286 |
| Haiku 4.5 | $0.00001 | $0.00143 |
Grade A, and why
incident-response scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 278 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Incident Response Playbook Generator
Generate a comprehensive incident response playbook for game operations.
Context Gathering
Before generating, understand:
Game Context
- Game type (live-service, multiplayer requirements)
- Critical systems (matchmaking, economy, progression)
- Player communication channels
- Revenue sensitivity
Team Context
- Team structure and time zones
- On-call rotation exists?
- Communication tools (Slack, Discord, PagerDuty)
Output Format
# Incident Response Playbook: [Game Name]
## Severity Definitions
| Severity | Description | Response Time | Examples |
|----------|-------------|---------------|----------|
| SEV1 | Complete outage, data loss | < 15 min | Server down, exploit active |
| SEV2 | Major feature broken | < 1 hour | Matchmaking down, purchases failing |
| SEV3 | Significant degradation | < 4 hours | High latency, minor feature broken |
| SEV4 | Minor issue | Next business day | UI bug, cosmetic issue |
---
## Incident Command Structure
### Roles During Incident
| Role | Responsibility |
|------|----------------|
| **Incident Commander (IC)** | Coordinates response, makes decisions |
| **Technical Lead** | Diagnoses and fixes the issue |
| **Communications Lead** | Updates players and stakeholders |
| **Scribe** | Documents timeline and actions |
### Escalation Path
On-Call Engineer ↓ (10 min no response) Team Lead ↓ (SEV1/SEV2) Engineering Manager ↓ (SEV1 > 1 hour) Director/VP
---
## Response Procedures
### SEV1: Critical Incident
#### Initial Response (0-15 min)
1. [ ] Acknowledge alert
2. [ ] Create incident channel: #incident-[date]-[brief]
3. [ ] Assign Incident Commander
4. [ ] Post initial status: "Investigating [symptom]"
5. [ ] Update status page to "Investigating"
#### Diagnosis (15-30 min)
1. [ ] Identify affected systems
2. [ ] Check recent deployments
3. [ ] Review error logs and metrics
4. [ ] Determine blast radius
5. [ ] Post findings to incident channel
#### Mitigation (30 min - 2h)
1. [ ] Decide: Rollback vs Fix Forward
2. [ ] Execute mitigation
3. [ ] Verify mitigation working
4. [ ] Update status: "Monitoring fix"
5. [ ] Communicate ETA to players
#### Resolution
1. [ ] Confirm issue resolved
2. [ ] Update status page: "Resolved"
3. [ ] Post player communication
4. [ ] Schedule postmortem (within 48h)
---
### SEV2: Major Incident
#### Initial Response (0-30 min)
1. [ ] Acknowledge and assess
2. [ ] Notify team lead
3. [ ] Create incident thread
4. [ ] Begin investigation
#### Resolution
1. [ ] Diagnose root cause
2. [ ] Implement fix
3. [ ] Verify resolution
4. [ ] Document for postmortem
---
## Common Scenarios
### Scenario: Server Outage
**Symptoms:** Players cannot connect, matchmaking fails
**Initial Checks:**
- Server health metrics
- Recent deployments
- Cloud provider status
- Network connectivity
**Common Causes:**
- Failed deployment
- Resource exhaustion
- Cloud provider incident
- DDoS attack
**Mitigation Options:**
1. Rollback recent deployment
2. Scale up resources
3. Failover to backup region
4. Enable DDoS protection
---
### Scenario: Database Performance
**Symptoms:** High latency, timeouts, failed queries
**Initial Checks:**
- Query performance
- Connection pool status
- Disk I/O
- Lock contention
**Common Causes:**
- Slow query
- Connection leak
- Disk full
- Missing index
**Mitigation Options:**
1. Kill problematic queries
2. Restart connection pools
3. Add capacity
4. Enable query result caching
---
### Scenario: Economy Exploit
**Symptoms:** Unusual currency generation, negative balances
**Initial Checks:**
- Transaction logs
- Player reports
- Unusual patterns
- Recent changes
**Immediate Actions:**
1. Disable affected feature
2. Identify affected accounts
3. Assess damage scope
4. Plan remediation
---
### Scenario: Authentication Failure
**Symptoms:** Players cannot log in
**Initial Checks:**
- Auth service health
- OAuth provider status
- Token validation
- Session storage
**Mitigation Options:**
1. Failover auth provider
2. Extend token expiry
3. Enable emergency bypass
4. Restart auth services
---
## Communication Templates
### Initial Acknowledgment
We're aware of an issue affecting [feature/service] and are investigating. We'll provide updates as we learn more.
### Status Update
Update on [issue]: We've identified [cause] and are [action being taken]. Estimated resolution: [time].
### Resolution Notice
The issue affecting [feature/service] has been resolved. [Brief explanation]. Thank you for your patience.
### Compensation Announcement
To thank you for your patience during [issue], all players will receive [compensation]. Check your [inbox/mail] in the next [time].
---
## Post-Incident
### Postmortem Template
```markdown
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 278 lines · 8 tokens per session scan A a29ad5e601c8
incident-response is a command published in the GitHub repository sponticelli/gamedev-claude-plugins (15 stars, last pushed 8mo ago), licensed MIT. It adds 8 tokens to every session and 1,429 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.