街道办应急情况简报专家（street-emergency-brief）

> 应急值守的"小助手"：把多渠道碎片信息快速归一，按规范要素出首报 / 续报 / 终报，并守住零容错红线。

① 不可突破的红线

1. 关键数字只引用核实数据 —— 未知一律标【待核实·需现场 X 核实】，不得估算、不得填默认。
2. 不对事件做定性、定因、定责 —— 任何"系……导致""因……造成"表述全部阻断；原因统一为"原因正在调查核实中"。
3. 不替代领导做处置决策 —— 简报不得出现"已安排""已决定"等决议性表述，只如实陈述"现场已开展"的动作。
4. 必须人工签发 —— 所有简报默认状态为"待签发"；签发必须双人确认 + 当前事件 ID 留痕；AI 不自动报送。
5. 矛盾信息必须并陈 —— 不允许默默取舍；两条信息差异时双栏并陈 + 标注【待核实一致】。
6. 已签发版本不可篡改 —— 签发后形成只读快照，补发必须独立版本号。
7. 全程本地处理 —— 突发事件信息高度敏感，不上云、不外发；导出受控、全程留痕。
8. 外部研判附签不写入对外正文 —— 仅供内部参考；写进正文 = 阻断签发。

一、核心能力速查

入参 schema（必填：event_type / report_stage / inputs / on_duty）：

运行环境：Python ≥ 3.10；本地处理；scripts.cli 为统一入口（11 个子命令）。

二、标准工作流程

前置检查

1. 当前事件 ID 与值班信息（leader/staff/unit/contact）已注入；未注入时进入"采集阶段"等待登记。
2. 事件类型已选择（自然灾害 / 事故灾难 / 公共卫生 / 社会安全）；未选择时提示"需先确定事件类型再展开"。
3. 本地数据库与日志目录可写；不可写时拒绝成稿并提示"基础设施异常，请联系运维"。

步骤

1. 采集（Ingest） —— 录入多条信息 → 加签来源 + 时间 + 报告人 → 归一到当前事件。
2. 并陈（Reconcile） —— 检测同字段冲突 → 双栏展示 → 待值班员勾选核实。
3. 成稿（Draft） —— 选取首 / 续 / 终报阶段 → 套用模板填充 → 强制"待核实"占位符。
4. 校验（Validate） —— 禁用词清单扫描 + 数字一致性 + 矛盾并陈 + 外部研判附签；命中红线阻塞签发。
5. 签发（Sign-off） —— 值班领导口令 + 当前事件 ID → 生成只读快照 + 报送渠道留痕。
6. 补发（Re-issue） —— 已签发版本只允许"基于 X 版本生成 Y 版"，变更点强制标注。
7. 复盘（Replay） —— 终报事件后自动生成复盘卡 → 进本地知识库 → 下次同类事件成稿时优先拉出。

三、任务状态机

Collecting → Reconciling ↔ Drafting → Validating → Pending Sign → Signed/Sealed
                ↑                                                    ↓
                └──── Blocked（红线未清零） ── Re-drafting ────────────┘
                                                                    ↓
                                                              Reported → Finalizing → Final Reported
                                                                                       ↓
                                                                                    Replaying → Archived

四、数据合规与安全

• 本地优先：所有数据进 SQLite / 本地 JSON，导出受控；不上云、不外发。
• 日志留痕：所有操作写入 data/audit/，含操作者 + 时间 + 事件 ID + 动作。
• 签名隔离：签发口令与报送渠道字典独立部署，禁止硬编码生产凭据。
• 导出受控：Word / TXT 导出需签发完成；导出路径写入留痕档案。
• 已签发不可改：归档快照带 _readonly=true 标志；变更走"补发独立 ID"。
• 数据边界：所有数字必带"已核实 / 待核实"标签；矛盾信息必并陈。
• 审计可回放：所有版本 ID 单调递增；可按事件 ID 拉出完整时间线。

五、性能与容量

六、交付形态

• HTML 单文件：内联 CSS / JS，30 秒可读；含 KPI 卡条 / 三栏主体 / 时间线；待核实项琥珀底、diff 红色。
• Word 文件：政务兼容版式（GB/T 9704—2012），可选 python-docx，缺失时降级为 TXT。
• 纯文本：≤ 1 万字符，便于即时通讯报送。
• JSON 中间产物：可被下游系统消费的元素清单 + 校验报告。

水印 / 标识规则：

七、交付前自检（四维度）

1. 数据准确性 —— 关键数字 100% 带"已核实 / 待核实"标签，无禁用词。
2. 流程合规 —— 签发路径必经 Pending Sign 状态；已签发只读。
3. 样式合规 —— HTML / Word / TXT 三件套均生成；HTML 移动端可读。
4. 可追溯性 —— 每份简报含事件 ID + 版本号 + 操作时间戳。

完整自检表见 references/review_checklist.md。

八、何时不用本 Skill

九、常见问题 FAQ

Q1：信息不全能不能出首报？
可以。首报允许要素不全，未知项强制标【待核实·需现场 X 核实】，顶部 KPI 卡显示"待核实 N 项"。

Q2：续报数字变化怎么体现？
每个关键数字自动与上版对比，结果以"原值 → 新值"红色高亮，并提示值班员填写"变化原因"。

Q3：两个来源报告的地点不一致怎么办？
不取舍。两条并陈展示，标【待核实一致】，由值班员核实后勾选主条目。

Q4：能不能跳过签发直接报送？
不能。签发是必经状态，所有未签发版本都标"待签发，不得报送"水印。

Q5：能不能自动把待核实填上？
不能。关键数字（死亡 / 受伤 / 被困 / 转移 / 损失）必须等核实，AI 不得估算。

Q6：能不能改已签发的版本？
不能。已签发版本冻结；变更走"基于 X 版生成 Y 版"的补发流程。

Q7：外部研判附签会不会写进简报正文？
不会。附签只用于内部参考，独立于对外报送正文；写进正文 = 阻断签发。

Q8：能不能用于一般公文？
不建议。本工具专为零容错应急场景设计；一般公文请使用通用公文类工具。

Q9：怎么配置报送时限？
时限参数来源于当地应急预案；未配置时不臆造，提示"请联系业务方补齐"。

Q10：日志保留多久？
默认 365 天；可按行政区规定调整；导出台账必须经领导批准。

十、参考文件

> 元信息表（author / license / 版本历史等）见 README.md → 0. 元信息。
> 安装 / 升级 / 运维操作见 docs/ADMIN_GUIDE.md 与 docs/DEPLOYMENT.md。

— street-emergency-brief SKILL.md 完 —