asp-case-zh

ASP Case

当用户要以 case 为中心开展 SOC 工作时，使用这个 skill。 Case 是 ASP 中的核心调查对象，一个 Case 会挂载一个或多个 Alert, 一个 Alert 挂载一个或多个 Artifact,所以用户通常调查过程只操作 Case。

适用场景

• 用户给出一个 case ID，希望查看、分诊或快速总结。
• 用户希望按状态、严重级别、置信度、verdict、correlation UID、标题或标签查找 case。
• 用户想查看 case 的讨论上下文。
• 用户想更新 case 工作流字段或 AI 分析字段。
• 用户想把 enrichment 或结构化分析附加到 case。
• 用户想把外部 ticket 记录附加到 case。

运行规则

• 总结 case 数据时要服务于行动判断，而不是输出原始 schema。
• 保持 case 作为用户的主要视图。只有在能帮助回答 case 问题时，才拉取相关告警、讨论。

补充信息

• rowid 为每条 case 记录的UUID,用于数据关联. case_id 是每条 case 记录人类可读的唯一ID

决策流程

1. 如果用户提供了具体 case ID，或说要“open”“show”“review”“summarize”某个 case，调用 list_cases(case_id=<id>, limit=1)。
2. 如果用户想看讨论历史或分析上下文，在取回 case 后调用 get_case_discussions。
3. 如果用户要查找、浏览或对比 case，使用 list_cases。
4. 如果用户要修改 status、verdict、severity 或 AI 字段，使用 update_case。
5. 如果用户要更新 case 但没提供 case ID，询问 case ID。
6. 如果用户给出了多个过滤条件，只应用 ASP 直接支持的部分，并明确说明不支持的过滤条件。
7. 如果用户要把 enrichment 或结构化分析附加到 case，使用 asp-enrichment-zh skill。
8. 如果用户要把外部 ticket 附加到 case，使用 asp-ticket-zh skill。

SOP

审查单个 Case

1. 如果用户要求审查、分析或查看 case 详情，调用 list_cases(case_id=<id>, limit=1, lazy_load=false) 获取完整关联数据（alerts、enrichments、tickets）。
2. 如果只需要快速查看 case 基本信息，调用 list_cases(case_id=<id>, limit=1) 即可。
3. 如果结果为空，直接说明找不到该 case。
4. 如果用户想看分析上下文，调用 get_case_discussions(case_id)。
5. 只展示与用户请求最相关的部分。
6. 只有在确实影响用户目标时，才强调缺失字段或可疑字段。

首选回复结构：

• Case：case ID、标题、严重级别、状态、verdict、confidence、priority、category。
• Timeline：创建、acknowledged、closed，以及存在时的 start/end。
• Key Alerts：只列最相关的告警，不默认列全。
• Discussions：仅在相关时给出关键分析或系统讨论点。
• Analyst / AI Notes：在相关时给出 comment、summary 和 AI 字段。

当用户问“发生了什么”或“帮我理解这个 case”时，先给一段简短分析性总结，再给结构化细节。

列出 Case

1. 提取支持的过滤字段：case_id、status、severity、confidence、verdict、correlation_uid、title、tags、limit。
2. 如果用户给出逗号分隔或自然语言列表，在调用 MCP 前先规范化。
3. 调用 list_cases。
4. 解析返回的 JSON 字符串。
5. 以紧凑对比视图呈现。
6. 如果结果很多，建议下一步最有价值的过滤条件，而不是直接倾倒大量结果。

首选回复结构：

Case ID	Title	Severity	Status	Verdict	Confidence	Priority	Updated

然后在需要时补一句简短解释，例如：

• “Most matching cases are still in progress.”
• “High-severity cases are concentrated in one category.”
• “No matching cases were found.”

更新 Case

1. 要求提供 case_id。
2. 只提取用户明确要求修改的字段。
3. 在调用 MCP 前校验请求里的枚举值。
4. 仅携带变更字段调用 update_case。
5. 如果结果为 None，说明找不到该 case。
6. 用简短变更记录风格确认更新结果。
7. 如果用户可能还要核实结果，建议重新获取 case。

常见可更新字段：

• severity
• status
• verdict
• severity_ai
• confidence_ai
• attack_stage_ai
• comment_ai
• summary_ai

首选回复结构：

• Updated case：case ID 或返回的 rowid
• Changed fields：只列实际提交的字段

澄清规则

• 只有在缺失时才询问 case_id。
• 只有当请求值无法清晰映射到 ASP 枚举时，才要求用户澄清。
• 如果用户要求“close”“resolve”或“mark suspicious”，在意图明确时可以直接映射到对应 status 或 verdict。
• 如果用户给出的是广义审查请求，比如“show recent important cases”，先从 list_cases 开始，不要强迫用户先选操作。

输出规则

• 保持简洁。
• 除非用户明确要求，否则不要输出原始 JSON。
• 优先使用面向分析师的措辞，而不是 schema 措辞。
• 表格保持精简；当匹配很多时，展示最有价值的子集并说明总量。
• 如果一次审查用了多个 MCP 调用，要把结果合并成一个连贯的 case 叙事，而不是逐个调用回显。
• 明确指出阻塞项：case 不存在、不支持的过滤条件、无效枚举值。

失败处理

• 如果 case 不存在，直接说明。
• 如果过滤无结果，直接说明并建议最可能有用的收敛方式。
• 如果更新目标不明确，只问一个聚焦问题，不要猜测。