Agent skill
user-story-format
验证User Story格式和质量,检查是否符合As-I-Want-So三要素结构、角色明确、功能具体、价值清晰。适合在编写新US后、准备Sprint Planning前使用,当需要审核US质量时。帮助不熟悉敏捷的PM/BA识别格式问题、模糊角色、缺失价值等常见问题,确保US可理解、可排序、可开发。
Install this agent skill to your Project
npx add-skill https://github.com/tikazyq/agentic-spec-forge/tree/main/AGENTIC_SPEC_FORGE/spec_stage_skill/requirements/user-story-format
SKILL.md
User Story Format Skill
Scope: REQUIREMENTS
版本: 0.1.0(占位)| 创建日期: 2025-11-27
概述
User Story 是敏捷需求的标准格式:
┌─────────────────────────────────────────────────────┐
│ 📋 User Story Template │
├─────────────────────────────────────────────────────┤
│ As a [role] │
│ I want [feature/capability] │
│ So that [benefit/value] │
└─────────────────────────────────────────────────────┘
快速开始
最快的3步使用流程:
-
第1步:确认已有US文档
- 文件位置:
spec/requirements/user_stories.md(或其他.md文件) - 格式要求:每个US需要尝试包含 As-I-Want-So 三段式结构
- 数量建议:至少2-3个US(可以检查更多)
- 文件位置:
-
第2步:一键调用格式检查
- 命令:
>>us_format_check - AI会自动扫描所有US,检查三要素完整性和表述质量
- 检查内容:As(角色明确)/ I Want(功能具体)/ So That(价值清晰)
- ⚠️ 只读检查:不会修改你的US文档
- 命令:
-
第3步:查看检查报告
- 结果显示:对话窗口中直接显示完整报告
- 报告内容:每个US的格式检查 + 质量评分 + 改进建议
- 后续操作:根据报告手动修改US,或使用
>>us_improve获取改进建议
⏱️ 预计耗时:2-3分钟 / 10个US
🆘 遇到问题? 查看下方"格式检查"章节获取详细指导
格式检查
As(角色)
- 角色是否明确定义
- 角色是否来自已识别的用户画像
- 避免使用"用户"这种模糊角色
I Want(功能)
- 功能描述是否具体
- 是否描述行为而非实现
- 是否可理解、无歧义
So That(价值)
- 是否说明业务价值
- 价值是否对角色有意义
- 是否可用于优先级排序
常见问题
❌ 不好的 User Story:
- "作为用户,我想要一个按钮,以便点击"
- "作为管理员,我想要更好的性能"
✅ 好的 User Story:
- "作为注册用户,我想要保存购物车,以便下次登录时继续购物"
- "作为店铺管理员,我想要导出销售报表,以便进行月度业绩分析"
分级检查策略
L1-STREAMLINED
- 检查 3 个核心要素是否存在(As/I Want/So That)
- 快速格式验证(< 5 分钟/US)
- 通过标准:3 项中 2 项通过(≥67%)
L2-BALANCED
- 每要素检查 2-3 个关键点(共 6-9 项)
- 含表述质量评估
- 通过标准:6 项中 5 项通过(≥83%)
L3-RIGOROUS
- 全面检查所有子项(9+ 项)
- 含角色一致性、价值链分析
- 记录改进建议
- 通过标准:9 项中 8 项通过(≥89%)
限制条件
✅ 适用场景
- 已有US文档,需要验证格式正确性
- 编写新User Story后,需要质量自查
- 准备Sprint Planning前,确保US可理解、可排序
- 团队成员互相审查US时,作为标准化检查清单
- 新手学习编写US,不确定格式是否正确
❌ 不适用场景
- 完全没有US文档 → 先使用
interview-to-us从访谈生成US,或使用us_template生成模板 - US内容完全混乱,不是三段式 → 需要重新编写,而非格式检查
- 需要自动修复US而非只检查 → 本SKILL主要是检查,可使用
us_improve获取改进建议 - US已经非常规范,符合所有标准 → 无需检查,避免浪费时间
- 需要检查INVEST原则 → 使用
principle-investSKILL,而非本格式检查
📋 前置条件
- 至少有2-3个User Story(尝试包含As-I-Want-So结构)
- US文档是.md格式,位于
spec/requirements/目录下 - 愿意接受检查建议并手动修改US
- 理解报告中的评分是辅助判断,最终决策由用户做出
- 最好已了解User Story的基本概念(如不了解,查看"常见问题"章节)
>> 命令
>>us_format_check # User Story 格式检查
>>us_improve # 改进 User Story 表述
>>us_template # 生成 User Story 模板
相关 Skills
- 前置: interview-to-us(从访谈生成US), us-enrich-context(丰富场景感)
- 并行: acceptance-criteria(同时编写 AC)
- 验证: principle-invest(INVEST 检查), us-readability-check(可读性检查)
- 后续: vertical-slice(转化为 VS)
TODO: 待细化各角色的 User Story 示例
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
code-review
执行代码审查流程(提交PR→自查→同行审查→反馈修改→合并),覆盖功能正确性、代码质量、测试完整性、安全合规四大维度。当提交Pull Request、进行结对编程、执行代码走查、需要知识共享时使用。支持L1/L2/L3三级审查深度。
code-quality
执行代码质量门禁检查(测试通过→覆盖率→Lint→GOAL追溯→可提交),验证单元测试覆盖率≥80%、集成测试通过率≥95%、代码规范零错误。当完成代码实现、准备提交代码、需要质量验证、进行提交前自检时使用。确保代码可合并。
tdd-cycle
执行 TDD 红绿重构循环(RED→GREEN→REFACTOR→REPEAT),通过先写失败测试、最小代码实现、保持绿色重构的节奏驱动开发。当启动功能开发、需要测试驱动节奏、进行迭代编码、追求高测试覆盖率时使用。提供检查清单和节奏控制。
refactoring
执行代码重构(识别坏味道→选择手法→小步修改→运行测试),在保持外部行为不变前提下改进内部结构。当TDD进入REFACTOR阶段、发现代码坏味道、需要消除重复代码、优化代码结构时使用。支持提取方法、类、参数对象等重构手法。
arch-options-compare
比较多个架构方案(单体/微服务等),从SOLID原则、成本、复杂度等维度评分,生成对比表和推荐方案。当需要向客户解释架构选择或ADR决策时使用。
dev-tech-view-supplement
根据设计补充Dev视角的技术细节(数据库/API/通信协议),帮助Dev快速进入实施。当L1/L2设计缺乏技术细节、或准备向Dev交付前使用。
Didn't find tool you were looking for?