本文へ移動
cccskills
無料GitHub で公開

codexkit-crisis-communication

Draft crisis communication packages including holding statements, stakeholder updates, Q&A documents, and internal briefs. Follows ICS (Incident Command System) communication principles. Use during PR crises, data breaches, product recalls, or any event requiring rapid coordinated messaging.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md5.8 KB
  • agents/openai.yaml176 B

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Crisis Communication

When to Use

  • During a PR crisis, data breach, or security incident
  • When a product issue affects customers at scale
  • When media attention or social media escalation requires response
  • When a compliance violation or legal issue needs external communication

Procedure

Step 1 — Severity Assessment

LevelCriteriaResponse TimeApproval
CriticalPublic safety, data breach, regulatory< 1 hourCEO + Legal
HighMajor service disruption, media coverage< 4 hoursVP + Comms
MediumNotable customer impact, social media trending< 24 hoursDirector + Comms
LowMinor issue, limited audience< 48 hoursComms team

Step 2 — Fact Gathering

Before writing anything, document what is known:

CategoryDetails
What happened?[Factual description — no speculation]
When?[Timeline of events]
Who is affected?[Customers, employees, partners — numbers]
What caused it?[Known root cause, or "under investigation"]
What actions taken?[Steps already taken to address]
What's next?[Planned actions and timeline]

Rule: Only communicate confirmed facts. Never speculate.

Step 3 — Holding Statement

Draft the initial public response (use within first hour):

[Company] is aware of [brief description of incident].
We are actively investigating and have taken immediate steps to [action taken].
[Affected parties] may experience [specific impact].
We will provide an update by [specific time].
For questions, contact [channel].

Principles:

  • Acknowledge the situation
  • Show empathy for those affected
  • State what you're doing about it
  • Commit to a specific update time
  • Provide a contact channel

Step 4 — Q&A Document

Prepare answers for anticipated questions:

QuestionAnswerApproved by
How many users are affected?[Specific number or range]Legal
Is my data safe?[Honest, specific answer]Security + Legal
What should I do?[Clear action steps]Product
Will this happen again?[Prevention measures]Engineering
Will you compensate affected users?[Policy decision]Executive

Step 5 — Stakeholder-Specific Messages

AudienceChannelToneKey Message
CustomersEmail, in-appEmpathetic, transparentImpact + what we're doing + what you should do
EmployeesAll-hands, SlackHonest, calmWhat happened + talking points + don't speculate publicly
MediaPress releaseProfessional, factualStatement + background + contact
RegulatorsFormal letterCompliant, detailedFull disclosure per requirements
Board / investorsDirect callStrategicImpact assessment + response + outlook

Step 6 — Update Cadence

PhaseFrequencyChannel
First 24 hoursEvery 2–4 hoursStatus page, social media
Day 2–3Every 8–12 hoursEmail, blog
Day 4–7DailyBlog, status page
Post-resolutionFinal update + postmortemBlog, email

Inputs

InputRequiredFormat
Incident descriptionYesWhat happened
Affected partiesYesWho and how many
Known factsYesConfirmed information only
Actions takenYesWhat has been done so far
Legal review statusRecommendedHas legal approved messaging?

Output

## Crisis Communication Package — [Incident Name]

### Severity: High | Status: Active
**Incident Lead:** [Name] | **Comms Lead:** [Name]

### Holding Statement
[Ready-to-publish statement]

### Q&A
[Prepared answers for 10–15 anticipated questions]

### Stakeholder Messages
[Customized message per audience]

### Update Schedule
[When and where next updates will be published]

Definition of Done

  • Severity assessed and response timeline set
  • Facts separated from speculation
  • Holding statement drafted within response window
  • Q&A covers top 10 anticipated questions
  • Messages tailored per stakeholder group
  • Update cadence committed and communicated

Quality Criteria

  • All placeholder sections are filled with domain-specific content
  • Structure follows the relevant industry standard or framework
  • Language matches target audience (technical / executive / legal)
  • Output is ready for review — not a rough draft requiring major rework

Verification (4C)

CheckQuestion
CorrectnessDoes the draft structure follow the stated framework or industry standard?
CompletenessAre all required sections present with substantive (not placeholder) content?
Context-fitDoes tone, detail level, and terminology match the intended audience?
ConsequenceIf sent to the intended recipient without further editing, what would fail?

Edge Cases

  • No existing template for this type — Use the closest available template and document all customizations made.
  • Stakeholder requirements conflict — Flag conflicts explicitly in the draft. Do not silently choose one requirement over another.
  • Output required in multiple formats — Produce the canonical format first, then derive others. Note any formatting limitations.

Changelog

  • v1.0.0 — Initial release

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Design rigorous A/B test plans with hypothesis, sample size calculation, Minimum Detectable Effect (MDE), randomization strategy, and decision rules. Includes guardrail metrics and rollout playbook. Use when planning product experiments, conversion optimization, or data-driven feature decisions.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月11日 更新

Review REST and GraphQL API designs for consistency, usability, and best practices. Covers naming conventions, versioning strategy, error format, pagination, authentication patterns, and breaking change detection. Use when reviewing API specs, designing new APIs, or auditing existing endpoints.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月11日 更新

Write Architecture Decision Records (ADRs) following the Michael Nygard format. Captures context, options considered, decision rationale, and consequences. Use when making technology choices, framework selections, or any architectural decision that future developers need to understand.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月11日 更新

Assess organizational readiness for financial audits (internal or external). Map assertions to account balances, check evidence completeness, score readiness using a Red/Amber/Green framework, and generate a remediation timeline. Aligned with SOX, IFRS, and GAAP audit standards. Use before scheduled audits or when preparing for first-time compliance.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月11日 更新

Design safe recurring Codex automations with clear prompts, outputs, schedules, and gating rules.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月11日 更新

Refine Product Backlog Items to meet INVEST criteria. Write User Stories with Acceptance Criteria in Given/When/Then format, estimate with Story Points, and flag dependencies. Use before sprint planning when backlog items need grooming. Do not use to prioritize the backlog — that is the Product Owner's decision.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月11日 更新

hoavdc のスキルをすべて見る

このスキルの問題を報告する