메뉴
需求工程 — 在任何创造性工作之前使用。通过协作对话收集需求、系统性验证、产出可作为设计和开发基准的需求文档。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
派遣 build-error-resolver 修复构建/类型/依赖/配置错误，不建 session
中文版 Java / Spring Boot 工程规约与代码 Review 标准。覆盖 Jakarta Validation 参数校验、空安全工具类、常量与枚举、Lombok/POJO、异常与日志、安全、MySQL/ORM、并发、单元测试、工程分层与 Review 清单。当用中文进行 Java/Spring Boot 代码生成、改造或 Review 时加载。
Generates Spring Boot 3.x configurations, creates REST controllers, implements Spring Security 6 authentication flows, sets up Spring Data JPA or MyBatis-Plus data access, and configures reactive WebFlux endpoints. Use when building Spring Boot 3.x applications, microservices, or reactive Java applications; invoke for Spring Data JPA, MyBatis-Plus, Spring Security 6, WebFlux, Spring Cloud integration, Java REST API design, or Microservices Java architecture.
Use when designing new high-level system architecture, reviewing existing designs, or making architectural decisions. Invoke to create architecture diagrams, write Architecture Decision Records (ADRs), evaluate technology trade-offs, design component interactions, and plan for scalability. Use for system design, architecture review, microservices structuring, ADR authoring, scalability planning, and infrastructure pattern selection — distinct from code-level design patterns or database-only design tasks.
Builds security-focused full-stack web applications by implementing integrated frontend and backend components with layered security at every level. Covers the complete stack from database to UI, enforcing auth, input validation, output encoding, and parameterized queries across all layers. Use when implementing features across frontend and backend, building REST APIs with corresponding UI, connecting frontend components to backend endpoints, creating end-to-end data flows from database to UI, or implementing CRUD operations with UI forms. Distinct from frontend-only, backend-only, or API-only skills in that it simultaneously addresses all three perspectives—Frontend, Backend, and Security—within a single implementation workflow. Invoke for full-stack feature work, web app development, authenticated API routes with views, microservices, real-time features, monorepo architecture, or technology selection decisions.
Optimizes database queries and improves performance across PostgreSQL and MySQL systems. Use when investigating slow queries, analyzing execution plans, or optimizing database performance. Invoke for index design, query rewrites, configuration tuning, partitioning strategies, lock contention resolution.
| name | requirement-engineering |
| description | 需求工程 — 在任何创造性工作之前使用。通过协作对话收集需求、系统性验证、产出可作为设计和开发基准的需求文档。 |
把模糊想法转化为完整、无歧义、可验证的需求文档。包含两个阶段：收集（brainstorming）和验证（validation）。
只负责"要做什么"，不负责"怎么做"——技术方案在
architecture-designer/writing-plans完成。
# 建 session（若尚未创建）
node scripts/orchestration/session.cjs init <任务名>
# 需求文档写入 .orchestration/<session>/architect/requirements.md
# 验证结论追加到同文件；通过后进入方案设计 phase
.orchestration/<session>/architect/requirements.md# [功能名] 需求文档
## 背景与目的
为什么做？解决什么问题？
## 用户场景
- 场景 1：作为 [角色]，我希望 [行为]，以便 [价值]
## 功能需求（每条可验证）
- [ ] FR-1：[具体描述 + 通过/不通过标准]
## 约束条件
- 性能 / 兼容性 / 安全要求
## 非功能需求
- ...
## 范围排除（不做什么）
- ...
## 成功标准
- ...
对收集到的需求逐条验证，不通过不得进入设计。
| 维度 | 检查项 |
|---|---|
| 完整性 | 每场景有对应 FR？异常/非功能需求齐全？范围排除明确？ |
| 可行性 | 技术可实现？时间合理？与现有系统兼容？ |
| 无歧义性 | 每条只有一种理解？数值/行为边界明确（"快速"→"200ms 内"）？ |
| 一致性 | 条目间有矛盾？约束冲突？优先级清晰？ |
| 可验证性 | 有明确通过/不通过标准？ |
---
## 需求验证结论
**验证日期**：YYYY-MM-DD
**结论**：通过 / 有条件通过 / 不通过
- [x] 完整性 / 可行性 / 无歧义性 / 一致性 / 可验证性：通过
### 发现的问题（如有）
1. [问题] → [修正方案]
### 修改记录
- [修改内容]
| 信号 | 行动 |
|---|---|
| 开始讨论技术方案 | 技术方案属于设计阶段，打住 |
| 用户说"直接做吧" | 先完成最小需求文档 |
| 需求描述了多个独立系统 | 先帮用户拆解为子项目 |
| 需求中有"待定""之后再说" | 现在确定或标记为明确的开放问题 |
| 需求可以被两种方式理解 | 选定一种并明确 |
| 需求之间有矛盾 | 与用户澄清并修正 |
| 想跳过用户确认 | 用户确认是必须的门禁 |
| 想跳过验证直接设计 | 不允许 |
architecture-designer / writing-plans 的核心输入