Menú
Go 后端需求分析：功能边界、验收标准、领域模型、API 契约、数据一致性规则、非功能需求、交付风险。在技术设计或编码前使用。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional 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 — 跨服务或长期架构决策（可选）