Generate Response Plan

Skill: generate-response-plan

Generates an incident response plan for Phase 5 — Launch. Supports Technical, Operational, and Business incident types. Classifies severity from PM description, reads project context files, and produces a structured response-plan-{id}.md. Mode B: agent prepares a draft, PM reviews and approves.

Triggers

Russian: «инцидент», «план реагирования», «произошёл инцидент», «сбой системы», «критическая ошибка», «проблема при запуске», «составь план реагирования», «что делать при инциденте» English: "incident response plan", "incident occurred", "system down", "generate response plan", "launch incident", "critical bug response", "production issue"

Language Detection

• Request in Russian → template response-plan-ru.md, responses in Russian
• Otherwise → template response-plan-en.md, responses in English

Input

Output

Incident ID format: INC-YYYYMMDD-NNN (sequential within the project). File name example: response-plan-INC-20260425-001.md

Instructions

Step 1 — Guard-rail and Gather Incident Data

Guard-rail — verify request type. If the request is about incident management methodology in general, not a specific incident in a running project → respond: "generate-response-plan creates an incident response plan for a specific incident in Phase 5 (Launch). Describe what happened in your project — I'll generate the plan." Do not start the workflow.

Ask PM to describe the incident if not provided in the request: "To generate the response plan, tell me:

1. What happened? (brief description)
2. When was it detected?
3. What is affected? (system, process, users)"

Do not proceed to Step 2 until the PM provides at least a brief incident description.

Step 2 — Classify Incident Type and Severity

Determine incident type from description:

If the description contains indicators of multiple types → use the primary type (most impactful). If type is unclear → ask: "Is this primarily a technical failure, an operational issue, or a business-level problem?"

Determine severity from description:

If severity cannot be determined from description → ask: "How would you rate the severity?

• Critical — system down / project blocked
• High — major degradation / at risk
• Medium — partial impact, workaround exists
• Low — minor, no immediate threat"

Step 3 — Gather Context from Project Files

Read project-state.md to obtain:

• Project name
• Current phase

Read 02-planning/resource-plan.md (if available) → extract team roles and names for the Response Team section. Read 01-initiation/stakeholder-map.md (if available) → extract Approver/Sponsor contacts for the Escalation Path. Read 01-initiation/risk-register.md (if available) → check if the incident matches a registered risk; if yes, note the risk ID. Read 02-planning/project-plan.md (if available) → extract current milestone/deadline to assess timeline impact.

If files are unavailable: continue with PM-provided data and placeholder values. Notify in chat: "[Filename] not found — the corresponding section will use placeholders. Fill in manually after saving."

Generate Incident ID:

• Scan 03-execution/ for existing response-plan-*.md files.
• Increment the sequence number: if no files exist → 001; if files exist → next number.
• Format: INC-{YYYYMMDD}-{NNN} using today's date.

Step 4 — Build the Response Plan

Load the template corresponding to the detected language:

• Russian → templates/response-plan-ru.md
• English → templates/response-plan-en.md

Populate the template:

Incident overview (§1):

• INCIDENT_ID — generated in Step 3
• PROJECT_NAME, DATE_REPORTED, REPORTED_BY, SEVERITY, INCIDENT_TYPE — from Step 2 and PM data
• Incident description — PM's description, normalized to 2–4 clear sentences

Impact assessment (§2):

• Fill AFFECTED_SYSTEMS, AFFECTED_PROCESSES from description
• AFFECTED_USERS — from stakeholder-map or PM's data
• Project blocked: Yes if Critical; otherwise infer from description
• SEVERITY_RATIONALE — 1–2 sentences explaining the severity classification

Response team (§3):

• PM_NAME — from project-state.md or resource-plan.md
• Technical Lead, Business Owner — from resource-plan.md if available; otherwise [TBD]
• Incident Lead — default to PM if no dedicated role; adjust if PM specifies someone else

Root cause analysis (§4):

• PROBABLE_CAUSE — based on PM's description; prefix with "Initial assessment:" if uncertain
• CONTRIBUTING_FACTORS — list 2–3 inferred factors; mark speculative ones with "(preliminary)"
• KNOWN_RISK — check risk-register.md result from Step 3

Action plan (§5):

• Generate 3–5 actions appropriate for the incident type and severity:
  • Technical: isolate → diagnose → fix → verify → restore service
  • Operational: identify blocker → escalate → reallocate resources → resume process
  • Business: assess scope → brief stakeholders → define response → execute corrective action
• Assign owners from team data if available; otherwise [OWNER]
• Set deadlines: Critical → hours, High → same day, Medium/Low → days; use [TIME] if unknown

Resolution timeline (§6):

• Fill "Incident detected" with the time from PM
• Set target times based on severity: Critical — resolution within 4–8h, High — within 24h, Medium — within 3 days

Escalation path (§7):

• Fill contacts from stakeholder-map.md if available; otherwise keep placeholders
• Adjust thresholds if PM specifies escalation policy

Communication plan (§8):

• Identify 3–4 key stakeholder groups from stakeholder-map.md or comm-plan.md
• Define what to communicate at each stage: immediate notification, status update, closure
• Set "Sender" to PM by default
• Method: reference comm-plan.md channels if available; otherwise Email/Call

Post-incident tasks (§9):

• Keep the 4 standard tasks from template
• Add project-specific tasks if PM mentions them

Step 5 — Show Draft to PM

Output to chat:

• One-line summary: "Incident response plan INC-{ID} — {TYPE}, severity: {SEVERITY}"
• Sections §1 (Incident Description) and §2 (Impact Assessment) as preview

Ask: "Draft is ready. Would you like to:

1. Save as is → I will create the file.
2. Adjust severity, type, or description → specify changes.
3. Update team or escalation contacts → provide the data."

Do not create the file until PM responds.

Step 6 — Save File and Update State

1. Create response-plan-{INCIDENT_ID}.md in {project}/03-execution/.
2. Update project-state.md: add artifact record → status draft.
3. Write to logs/log.md: {DATE}: generate-response-plan — created 03-execution/response-plan-{INCIDENT_ID}.md, type: {TYPE}, severity: {SEVERITY}
4. Output to chat:
   • "File saved: 03-execution/response-plan-{INCIDENT_ID}.md"
   • Next step: "Response plan is ready. Review actions in §5 and confirm assignments with the team. After the incident is resolved, update §6 (timeline actuals) and §9 (post-incident tasks) in the file."

Templates

Dependencies

Reads (optional):

• project-state.md — project name, current phase
• 02-planning/resource-plan.md — team roles and contacts
• 01-initiation/stakeholder-map.md — escalation and communication contacts
• 01-initiation/risk-register.md — registered risks for cross-reference
• 02-planning/project-plan.md — milestones and timeline impact assessment

Passes data to:

• send-email — for external stakeholder notifications per §8 (Communication Plan), autonomy level per comm-plan.md

Constraints

• Mode B: PM reviews the draft before the file is created
• Requires at least a brief incident description from PM to start; does not generate a plan from empty input
• One incident per invocation; multiple incidents → separate skill calls, each with its own INC-ID
• Does not modify risk-register.md or project-plan.md — those are updated manually by PM post-incident
• Does not trigger send-email automatically — PM initiates notifications from §8 manually or by calling send-email
• Fallback if all project files are unavailable: generates a template-based plan with PM-provided data and placeholders
• Severity and type classification is explicit — agent states its reasoning and asks for confirmation if uncertain