القائمة
Go 后端需求分析：功能边界、验收标准、领域模型、API 契约、数据一致性规则、非功能需求、交付风险。在技术设计或编码前使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
一键综合分析加密货币。通过并行子代理采集价格、新闻情绪、赛道对比、市场环境、项目基本面五个维度，交叉分析后输出 HTML 报告（含24小时行情和7日趋势）。触发词：分析BTC、analyze ETH、比特币怎么样、SOL值得买吗。
一键综合分析某只股票/公司。通过并行子代理同时采集股价、新闻舆论、行业对比、市场环境、公司官网五个维度的数据，然后在主线程进行交叉分析、因果归因和趋势预测，输出标准化 HTML 分析报告（含当日行情和7日趋势）。触发词：分析XX股票、analyze TICKER、XX怎么样、XX值得买吗。支持A股、港股和美股。
深度学习一本书。通过并行子代理采集章节结构、背景要点、问题影响、解决方案、术语索引、延伸阅读六个维度，交叉分析后输出 Markdown 深度学习笔记。触发词：分析XX这本书、学习XX、读书笔记XX、book analysis。
Expert Go backend code reviewer specializing in microservices, GORM/DAL patterns, dependency injection, and resource management. Focuses on logic correctness, goroutine leak detection, and Go-specific best practices for production-grade services.
Go 后端技术设计：包边界、handler-service-repository 分层、API 契约、存储设计、事务、一致性、可观测性、发布策略与 ADR 权衡。需求稳定后使用。
Fetches RSS feeds from 90 top Hacker News blogs (curated by Karpathy), uses Claude to score and filter articles, and generates a daily digest in Markdown with Chinese-translated titles, category grouping, trend highlights, and visual statistics. Use when user mentions 'daily digest', 'RSS digest', 'blog digest', 'AI blogs', 'tech news summary', or asks to run /digest command. Trigger command: /digest.
| name | go-backend-requirement-analysis |
| description | Go 后端需求分析：功能边界、验收标准、领域模型、API 契约、数据一致性规则、非功能需求、交付风险。在技术设计或编码前使用。 |
| allowed-tools | Read, Bash, Glob, Grep |
| disable-model-invocation | true |
| context | fork |
在技术设计或编码前使用，适用于涉及后端功能、API、异步任务、存储变更或服务集成的需求。
按优先级获取需求内容：
ls -t $(find . -maxdepth 3 \( -name "*prd*" -o -name "*requirement*" -o -name "*需求*" \) -name "*.md" 2>/dev/null) 2>/dev/null | head -5
若自动发现到多个候选文件，列出并让用户确认。若未找到任何文件，提示用户描述需求或提供文档路径。
提取以下信息：
如果用户描述模糊，做最小安全假设并标注为「假设」。
EARS 结构化：将需求改写为结构化句式，消除歧义：
| 句式 | 适用场景 | 示例 |
|---|---|---|
| When [事件], the system shall [行为] | 事件触发型 | When 用户提交订单，系统应扣减库存 |
| While [状态], the system shall [行为] | 持续状态型 | While 支付待处理，系统应禁止取消 |
| If [条件], then the system shall [行为] | 条件分支型 | If 超出配额，系统应返回 429 并附 retry-after |
| The system shall [行为] | 无条件约束 | 系统应对 PII 字段静态加密 |
每条核心需求至少用一种 EARS 句式表达。
始终分析以下维度：
在产出需求文档之前，验证以下三项可行性：
数据可用性
接口可行性
依赖就绪度
使用以下结构：
# 需求分析
## 核心结论
> **结论**：[一句话说明需求是否可行、主要约束、推荐的 MVP 范围]
>
> **关键风险**：[最高优先级的 1-3 个风险]
>
> **建议行动**：[下一步最重要的决策或确认项]
## 需求追溯表
| Req# | 需求描述 | 优先级 | 来源/假设 | 验收标准编号 |
|------|----------|--------|-----------|-------------|
| R1 | | Must | 用户明确 | AC1, AC2 |
| R2 | | Should | 假设 | AC3 |
## 目标
## 范围内
## 范围外
## 参与方与依赖
## 领域模型
## API 或事件契约
## 业务规则
## 非功能需求
## 验收标准
| AC# | 场景 | 前置条件 | 操作 | 预期结果 | 可验证 |
|-----|------|----------|------|----------|--------|
| AC1 | | | | | ✅/⚠️/❌ |
> 可验证标注：✅ 数据和接口已就绪 | ⚠️ 需前置工作 | ❌ 当前不可验证（列入待确认项）
## 风险与待确认项
好的验收标准应具备：
必须包含以下路径：
references/checklist.md需求分析完成后，在对话末尾告知用户可选的后续步骤，等待用户明确指示后再继续，不得自动进入下一阶段：
/go-backend-technical-design — 组件与接口设计/go-backend-architecture — 跨服务或长期架构决策（可选）