菜单
从原始需求素材（PRD、会议纪要、设计文档等）提炼结构化开发需求文档。通过三层模板（意图层/边界层/关联层）和五条逻辑校验规则，生成逻辑自洽的需求文档，暴露缺失和矛盾。触发词："提炼需求"、"结构化需求"、"需求文档"、"需求整理"、"refine requirement"。适用于 AI Coding Agent 开发前的需求整理，也适用于人类开发者审查和完善需求。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Fetch any URL and convert to markdown using baoyu-fetch CLI (Chrome CDP with site-specific adapters). Built-in adapters for X/Twitter, YouTube transcripts, Hacker News threads, and generic pages via Defuddle. Handles login/CAPTCHA via interaction wait modes. Use when user wants to save a webpage as markdown.
E2E testing for local web applications — constraint-first, execution-driven structure: iron rules, 5-stage execution flow with inline principles, artifact specification. Use this skill whenever the user wants to test a local web app, validate UI behavior, walk through multi-step user flows, mock API responses for testing, debug E2E test failures, capture screenshots, or understand E2E testing best practices. Triggers on: "test this web app", "E2E test", "UI test", "browser test", "验证 UI", "测试页面", "写个测试", "mock API", "端到端测试", "自动化测试", "帮我测一下", "test the login", "checkout flow", "registration flow", "dashboard test", or any mention of localhost testing, form validation, flow verification, or E2E debugging.
Generate and maintain business knowledge documents from codebase. Supports ingest (create/update docs) and lint (detect inconsistency and fix) operations. Triggers: 业务知识地图、生成业务文档、ingest domain knowledge、lint 业务知识、docify.
E2E testing methodology for local web applications — 21 principles across 5 domains (testing philosophy, data & mock, UI interaction, diagnosis & debugging, reporting). Pure methodology: no tool commands, no project conventions — teaches the agent how to think, not what to do. Use this skill whenever the user wants to test a local web app, validate UI behavior, walk through multi-step user flows, mock API responses for testing, debug E2E test failures, capture screenshots, or understand E2E testing best practices. Triggers on: "test this web app", "E2E test", "UI test", "browser test", "验证 UI", "测试页面", "写个测试", "mock API", "端到端测试", "自动化测试", "帮我测一下", "test the login", "checkout flow", "registration flow", "dashboard test", or any mention of localhost testing, form validation, flow verification, or E2E debugging.
高质量知识写作技能，创作精炼优雅，图文并茂的 Markdown 学习文章。 **当用户想要学习、研究或理解任何主题时，始终使用此技能。** 作为经验丰富的知识写作者—— 深度研究材料，识别核心概念与关系，撰写简洁、精准、有洞见的文章。 触发语（中文）："帮我学习 X"、"我想了解 X"、"研究 X"、"学习这个"、"总结"、"解释 X"、"消化这个"、"帮我深入理解" 触发语（英文）："help me learn"、"I want to understand"、"study this"、"summarize"、"teach me about" 特点：Markdown 输出配优雅图表（Mermaid/SVG/ASCII），自适应主题结构，高层写作原则， 视觉风格预览选择，内置去 AI 味处理，支持中英文输出。
为任何项目（前端或后端）生成专业测试策略和高质量测试代码。当用户描述功能、UI、验收标准，或要求编写测试、创建测试用例、添加测试覆盖、验证功能时，使用此技能。当用户分享需求并希望通过测试验证，或粘贴代码问'该如何测试'时，也触发此技能。即使用户未明确说'测试'，只要意图明显是验证行为或质量保障，就应使用此技能。
| name | requirement-refiner |
| description | 从原始需求素材（PRD、会议纪要、设计文档等）提炼结构化开发需求文档。通过三层模板（意图层/边界层/关联层）和五条逻辑校验规则，生成逻辑自洽的需求文档，暴露缺失和矛盾。触发词："提炼需求"、"结构化需求"、"需求文档"、"需求整理"、"refine requirement"。适用于 AI Coding Agent 开发前的需求整理，也适用于人类开发者审查和完善需求。 |
将模糊、零散的需求素材转化为结构化、逻辑自洽的开发需求文档。
Agent 开发出错有三类根因，对应三个元维度：
| 失败类型 | 元维度 | 回答的核心问题 |
|---|---|---|
| 不知道做什么 | 意图层 | 要解决什么问题？为谁？成功标准？ |
| 不知道不做什么 | 边界层 | 做什么？不做什么？约束条件？ |
| 理解自相矛盾 | 关联层 | 各部分如何关联？数据/状态如何流转？ |
10 个必填字段，每个字段的存在都有推导依据。详细定义和示例见 template.md。
意图层 ─── 问题陈述
├── 用户与场景
└── 成功标准
边界层 ─── 功能范围
├── 显式排除
├── 约束条件
└── 异常与边界情况
关联层 ─── 数据模型 [前端：API 响应结构 + 组件 state]
├── 状态流转 [前端：UI 状态机（加载/成功/失败）]
├── 交互流程 [前端：用户操作 → 界面响应链路]
└── 依赖关系 [前端：API 端点 + 设计系统组件 + 路由]
字段名是通用的，不同角色填充的内容类型不同。前端开发者看到关联层字段时，直接按方括号内的提示理解即可。不相关的字段填「不适用：[原因]」。
⚠️ 待确认运行 5 条逻辑校验规则：
| 规则 | 检查什么 |
|---|---|
| 实体覆盖 | 数据模型的每个实体，在功能范围中是否都有对应操作？ |
| 状态闭环 | 状态流转中每个终态是否可达？每个状态是否有出口？ |
| 流程-状态对齐 | 交互流程的每步操作，在状态流转中是否有对应转换？ |
| 排除一致性 | 显式排除的功能，是否与功能范围或约束条件矛盾？ |
| 异常-功能覆盖 | 功能范围的每个功能，是否都考虑了异常情况？ |
校验结果标记：
❌ 矛盾 — 字段间逻辑不一致，附具体矛盾描述⚠️ 待确认 — 字段缺失或信息不足，附补充建议交互模式：非阻塞式。所有 ⚠️ 和 ❌ 项及其建议写入输出文档，用户事后审查决定是否采纳。
生成结构化开发需求文档，格式如下：
# [需求名称] — 开发需求文档
## 意图层
### 问题陈述
[内容或 ⚠️ 待确认]
### 用户与场景
[内容或 ⚠️ 待确认]
### 成功标准
[内容或 ⚠️ 待确认]
## 边界层
### 功能范围
[内容或 ⚠️ 待确认]
### 显式排除
[内容或 ⚠️ 待确认]
### 约束条件
[内容或 ⚠️ 待确认]
### 异常与边界情况
[内容或 ⚠️ 待确认]
## 关联层
### 数据模型
[内容或 ⚠️ 待确认]
### 状态流转
[内容或 ⚠️ 待确认]
### 交互流程
[内容或 ⚠️ 待确认]
### 依赖关系
[内容或 ⚠️ 待确认]
## 校验结果
### ❌ 矛盾
- [矛盾描述及建议修复方向]
### ⚠️ 待确认
- [缺失项及补充建议]
## 信息溯源表
| 字段 | 来源文档 | 来源段落/位置 |
|------|---------|-------------|
| 问题陈述 | [文档名] | [段落] |
| ... | ... | ... |
字段粒度自适应：模板只定义 10 个必填字段，字段内部子结构由 Agent 根据需求规模决定。简单需求用一段文字即可，复杂需求可展开为实体关系图、状态机图等。
⚠️ 待确认不是失败：原始需求不完整是常态。目标不是强行填充每个字段，而是把缺失变成显性知识。
关联层允许「不适用」：关联层的字段（数据模型、状态流转、交互流程、依赖关系）对纯 UI 展示或无状态需求可能不相关。此时填写「不适用：[原因]」而非强行填充或标记 ⚠️。「不适用」是确认性的判断，不是缺失。
信息溯源：每个字段标注来源，方便用户追溯和验证提取的准确性。
按层校验，条件适配：填完一层后校验层内一致性，全部填完后执行跨层校验。当「状态流转」字段标记为「不适用」时，跳过「状态闭环」和「流程-状态对齐」校验，仅执行其余 3 条。
聚焦业务需求，技术上下文由项目文档提供：本模板只承载业务需求的结构化。技术栈、项目结构、代码风格等技术上下文应由项目的 AGENTS.md / CLAUDE.md 等文档提供，不在此文档范围内。Agent 开发时应同时参考本需求文档和项目技术文档。