War room protocol
Skill Amey-Thakur/AI-SKILLS/skills/big-tech-processes/war-room-protocol
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill war-room-protocolAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Run a war room for a live incident with defined roles, a steady cadence, a decision log, and explicit stand-down criteria. Use when a high-severity outage or crisis needs coordinated response across teams and the improvised version is descending into chaos.
SKILL.md
3.0 KB, as published. Nobody here has run it
War room protocol
A war room concentrates the people and authority to end a crisis into one channel with one commander. Without protocol it becomes a crowded room where twenty engineers narrate the same graph, no one owns the next action, and the decisions that mattered are lost the moment the page clears. The protocol exists to make coordination faster than the incident.
Method
- Name an incident commander first, before any debugging. The commander runs the response, not the keyboard: they assign work, hold the timeline, and are the single point of decision. Everyone else defers to them on priority. If two people think they are in charge, no one is.
- Fill the three other roles explicitly. An operations lead who drives the technical fix, a scribe who owns the log, and a communications lead who updates status page and stakeholders. Say the names out loud in the channel so the room knows who does what.
- Set a fixed sync cadence and hold it. Every 15 or 30 minutes by severity, the commander calls a checkpoint: current impact, what changed, next action, next check-in time. Between syncs people work, they do not narrate. The cadence is what stops the endless scroll of unstructured chatter.
- Keep a running decision log with timestamps. The scribe records every decision, who made it, why, and what was ruled out. "14:32 rolled back deploy 4471, error rate flat, ruling out config" is a log entry. This is your real-time record for the postmortem and your defense against relitigating a call at hour three.
- Separate mitigation from root cause, and chase mitigation first. Stop the bleeding: roll back, fail over, shed load, flip the flag. The fix that explains why can wait until users are served again. A war room that debugs before it mitigates is optimizing the wrong clock.
- Declare stand-down against written criteria. Impact resolved, metrics back in normal range for a defined window, no active mitigations holding it up by hand. The commander calls it, names the postmortem owner and date, and closes the channel. An incident that never formally ends never gets learned from.
Signals
- Can any participant name the incident commander without scrolling up?
- Does the decision log let someone joining at hour two catch up in two minutes?
- Is stand-down a stated threshold, or a slow fade as people drift off?
Boundaries
This covers running the live response, not the retrospective that follows: route the after-action to a postmortem skill, which owns blameless analysis and follow-up tracking. Severity thresholds and paging policy are company convention; match your on-call runbook rather than inventing a scale mid-crisis.