Adversarial scenarios
Skill lzx-Bill/Project-Factory-Core/.agents/skills/adversarial-scenarios
Docs-first project incubation with 34 composable AI Agent skills—from idea and requirements to architecture, acceptance, and implementation handoff.
npx -y skills add lzx-Bill/Project-Factory-Core --skill adversarial-scenariosAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 21 days oldThe repository was created 21 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.
- 0 stars0 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
Use when deriving failure modes and edge cases from requirements — "adversarial scenarios", "failure mode", "edge case derivation", "what-if analysis", "对抗性场景", "失效路径", "逆向推导". This skill reverse-engineers failure paths from happy-path user stories, identifying operations that break user expectations. Use after requirements-spec and before architecture-decisions.
SKILL.md
6.8 KB, as published. Nobody here has run it
Adversarial Scenarios
通过逆向推导,从正常用户路径中找到最不符合直觉的失效路径。
When to Use
- 需求文档完成后,需要推导功能分支和异常场景
- 架构设计前,需要识别关键的风险路径
- 安全设计前,需要知道哪些路径一旦失效影响最大
- 任何时候需要"如果坏了怎么坏"的系统思考
NOT When to Use
- 正常功能路径已经清晰,不需要推导
- 项目是 greenfield,核心功能尚未定义
- 已有完整的 FMEA 或故障树分析
Input
| 来源 | 内容 |
|---|---|
| user-stories.md | 用户故事(正常路径) |
| assumptions.md | 项目假设(约束条件) |
| system-design.md | 系统架构(用于识别组件边界) |
Output Schema
| 文件 | 类型 | 说明 |
|---|---|---|
wiki/03-architecture/threat-scenarios.md | 对抗性场景文档 | 失效路径清单、影响分析 |
Minimum Viable Output
- 至少 5 个对抗性场景
- 每个场景的触发条件、失效路径、影响程度
- 至少 2 个需要架构层面响应的场景
Complete Output
- 完整对抗性场景清单(覆盖所有核心 US)
- 每个场景的详细失效路径描述
- 影响程度和可能性评级
- 对应的架构响应(需要改设计 vs. 记录风险 vs. 可接受)
- 测试用例映射(每个场景对应至少一个测试用例)
Dependencies
| 类型 | 说明 |
|---|---|
| 前置 | requirements-spec(user stories 已输出) |
| 前置 | assumptions-tracking(假设清单已输出) |
| 后置 | architecture-decisions(对抗性场景作为架构约束) |
| 依赖读取 | user-stories.md、assumptions.md |
Procedure
Phase 1: 提取核心功能路径
从 user-stories 中提取所有"正常路径"——用户预期怎么用这个功能。
## 核心功能路径清单
从每个 US 中提取:
| US-ID | 功能 | 正常路径 | 用户预期结果 |
|-------|------|---------|------------|
| US-001 | 提交业务记录 | 打开页面 → 填写信息 → 提交 → 显示成功 | 记录被保存并可再次查询 |
Phase 2: 逆向推导 — "如果坏了,怎么坏?"
对每个正常路径,问三个通用问题:
问题 A(角色反转):用户会不会故意绕过这个流程?
问题 B(边界踩踏):在流程的哪个节点踩进去会引发意外?
问题 C(依赖断裂):这个功能依赖什么?这个依赖消失会怎样?
然后问一个项目相关问题:
问题 D(换位):如果我是这个产品最不满意的用户,我会怎么滥用它?
Phase 3: 场景推导模板
使用以下模板系统化推导:
## 对抗性场景模板
### 场景命名:`<功能>_<失效方式>`
- **所属 US**:[正常路径的 US-ID]
- **触发条件**:[什么动作/输入/时间触发这个失效]
- **失效路径**:
1. [步骤1]
2. [步骤2]
3. [步骤3]
- **用户预期 vs 实际结果**:
- 预期:[用户以为会怎样]
- 实际:[实际发生了什么]
- **影响程度**:🔴 高 / 🟡 中 / 🟢 低
- **可能性**:🔴 高 / 🟡 中 / 🟢 低
### 影响程度评级标准
| 等级 | 标准 | 示例 |
|------|------|------|
| 🔴 高 | 用户数据丢失/泄露、或核心业务流程完全中断 | 业务记录全部丢失、用户账号被劫持 |
| 🟡 中 | 部分功能失效或性能显著下降,用户体验受损 | 搜索结果丢失 50%、签到通知延迟发送 |
| 🟢 低 | 轻微问题,不影响核心功能,有 workaround | 界面显示轻微错位、非关键通知发送慢 |
### 可能性评级标准
| 等级 | 标准 | 判定依据 |
|------|------|---------|
| 🔴 高 | 在正常或轻度异常使用下很容易触发 | 用户操作失误、网络波动、单机故障 |
| 🟡 中 | 需要特定条件或较难遇到 | 并发竞争、大数据量边界、第三方服务异常 |
| 🟢 低 | 极端条件或多重故障叠加才会发生 | 数据中心级故障、全部依赖同时不可用 |
- **架构响应**:
- 需改设计:[需要架构层面修改]
- 记录风险:[不影响当前架构,记录]
- 可接受:[故意设计的降级行为]
Phase 4: 分类整理
将所有场景按影响程度分类:
## 对抗性场景矩阵
### 🔴 高影响 × 🔴 高可能性(必须解决)
| 场景 | 失效路径 | 建议架构响应 |
|------|---------|------------|
| | | |
### 🔴 高影响 × 🟢 低可能性(记录风险)
| 场景 | 失效路径 | 建议架构响应 |
|------|---------|------------|
| | | |
### 🟢 低影响 × 🔴 高可能性(可接受或简单修复)
| 场景 | 失效路径 | 建议架构响应 |
|------|---------|------------|
| | | |
Phase 5: 映射到测试用例
每个高影响场景必须至少对应一个测试用例:
## 测试用例映射
| 场景 ID | 对应测试用例 | 测试类型 |
|---------|------------|---------|
| AS-001 | TC-xxx: [描述] | Unit/Integration/E2E |
通用对抗性问题清单
以下问题适用于任何项目,触发项目相关的具体场景:
| # | 问题 | 推导方向 |
|---|---|---|
| 1 | 如果用户重复这个操作 100 次,会怎样? | 资源泄漏、状态累积 |
| 2 | 如果用户在操作过程中强制退出,会怎样? | 中断处理、数据一致性 |
| 3 | 如果依赖服务/模块不可用,会怎样? | 降级策略、超时处理 |
| 4 | 如果用户输入完全不符合预期,会怎样? | 输入校验、错误提示 |
| 5 | 如果两个用户同时做同一件事,会怎样? | 并发控制、数据竞争 |
| 6 | 如果数据被篡改(非攻击),会怎样? | 校验机制、备份恢复 |
Target Pages
<项目根目录>/wiki/03-architecture/threat-scenarios.md
Changelog
| 日期 | 变更 | 原因 |
|---|---|---|
| 2026-07-15 | 示例改为领域无关的业务记录场景 | 避免示例成为隐含需求 |
| 2026-04-30 | 修复:新增影响程度评级标准表(🔴高/🟡中/🟢低,含判定标准和示例);新增可能性评级标准表(🔴高/🟡中/🟢低,含判定依据) | 影响程度和可能性评级无明确定义标准 |
| 2026-04-30 | 新建 skill | 对抗性场景推导是识别架构风险的关键,需要独立 skill |