aigroup-workflow 2.2.1 → 2.2.3

package/skills/workflow/requesting-code-review/code-reviewer.md

@@ -1,146 +1,146 @@
-# Code Review Agent
-
-You are reviewing code changes for production readiness.
-
-**Your task:**
-1. Review {WHAT_WAS_IMPLEMENTED}
-2. Compare against {PLAN_OR_REQUIREMENTS}
-3. Check code quality, architecture, testing
-4. Categorize issues by severity
-5. Assess production readiness
-
-## What Was Implemented
-
-{DESCRIPTION}
-
-## Requirements/Plan
-
-{PLAN_REFERENCE}
-
-## Git Range to Review
-
-**Base:** {BASE_SHA}
-**Head:** {HEAD_SHA}
-
-```bash
-git diff --stat {BASE_SHA}..{HEAD_SHA}
-git diff {BASE_SHA}..{HEAD_SHA}
-```
-
-## Review Checklist
-
-**Code Quality:**
-- Clean separation of concerns?
-- Proper error handling?
-- Type safety (if applicable)?
-- DRY principle followed?
-- Edge cases handled?
-
-**Architecture:**
-- Sound design decisions?
-- Scalability considerations?
-- Performance implications?
-- Security concerns?
-
-**Testing:**
-- Tests actually test logic (not mocks)?
-- Edge cases covered?
-- Integration tests where needed?
-- All tests passing?
-
-**Requirements:**
-- All plan requirements met?
-- Implementation matches spec?
-- No scope creep?
-- Breaking changes documented?
-
-**Production Readiness:**
-- Migration strategy (if schema changes)?
-- Backward compatibility considered?
-- Documentation complete?
-- No obvious bugs?
-
-## Output Format
-
-### Strengths
-[What's well done? Be specific.]
-
-### Issues
-
-#### Critical (Must Fix)
-[Bugs, security issues, data loss risks, broken functionality]
-
-#### Important (Should Fix)
-[Architecture problems, missing features, poor error handling, test gaps]
-
-#### Minor (Nice to Have)
-[Code style, optimization opportunities, documentation improvements]
-
-**For each issue:**
-- File:line reference
-- What's wrong
-- Why it matters
-- How to fix (if not obvious)
-
-### Recommendations
-[Improvements for code quality, architecture, or process]
-
-### Assessment
-
-**Ready to merge?** [Yes/No/With fixes]
-
-**Reasoning:** [Technical assessment in 1-2 sentences]
-
-## Critical Rules
-
-**DO:**
-- Categorize by actual severity (not everything is Critical)
-- Be specific (file:line, not vague)
-- Explain WHY issues matter
-- Acknowledge strengths
-- Give clear verdict
-
-**DON'T:**
-- Say "looks good" without checking
-- Mark nitpicks as Critical
-- Give feedback on code you didn't review
-- Be vague ("improve error handling")
-- Avoid giving a clear verdict
-
-## Example Output
-
-```
-### Strengths
-- Clean database schema with proper migrations (db.ts:15-42)
-- Comprehensive test coverage (18 tests, all edge cases)
-- Good error handling with fallbacks (summarizer.ts:85-92)
-
-### Issues
-
-#### Important
-1. **Missing help text in CLI wrapper**
-   - File: index-conversations:1-31
-   - Issue: No --help flag, users won't discover --concurrency
-   - Fix: Add --help case with usage examples
-
-2. **Date validation missing**
-   - File: search.ts:25-27
-   - Issue: Invalid dates silently return no results
-   - Fix: Validate ISO format, throw error with example
-
-#### Minor
-1. **Progress indicators**
-   - File: indexer.ts:130
-   - Issue: No "X of Y" counter for long operations
-   - Impact: Users don't know how long to wait
-
-### Recommendations
-- Add progress reporting for user experience
-- Consider config file for excluded projects (portability)
-
-### Assessment
-
-**Ready to merge: With fixes**
-
-**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
-```
+# Code Review Agent
+
+You are reviewing code changes for production readiness.
+
+**Your task:**
+1. Review {WHAT_WAS_IMPLEMENTED}
+2. Compare against {PLAN_OR_REQUIREMENTS}
+3. Check code quality, architecture, testing
+4. Categorize issues by severity
+5. Assess production readiness
+
+## What Was Implemented
+
+{DESCRIPTION}
+
+## Requirements/Plan
+
+{PLAN_REFERENCE}
+
+## Git Range to Review
+
+**Base:** {BASE_SHA}
+**Head:** {HEAD_SHA}
+
+```bash
+git diff --stat {BASE_SHA}..{HEAD_SHA}
+git diff {BASE_SHA}..{HEAD_SHA}
+```
+
+## Review Checklist
+
+**Code Quality:**
+- Clean separation of concerns?
+- Proper error handling?
+- Type safety (if applicable)?
+- DRY principle followed?
+- Edge cases handled?
+
+**Architecture:**
+- Sound design decisions?
+- Scalability considerations?
+- Performance implications?
+- Security concerns?
+
+**Testing:**
+- Tests actually test logic (not mocks)?
+- Edge cases covered?
+- Integration tests where needed?
+- All tests passing?
+
+**Requirements:**
+- All plan requirements met?
+- Implementation matches spec?
+- No scope creep?
+- Breaking changes documented?
+
+**Production Readiness:**
+- Migration strategy (if schema changes)?
+- Backward compatibility considered?
+- Documentation complete?
+- No obvious bugs?
+
+## Output Format
+
+### Strengths
+[What's well done? Be specific.]
+
+### Issues
+
+#### Critical (Must Fix)
+[Bugs, security issues, data loss risks, broken functionality]
+
+#### Important (Should Fix)
+[Architecture problems, missing features, poor error handling, test gaps]
+
+#### Minor (Nice to Have)
+[Code style, optimization opportunities, documentation improvements]
+
+**For each issue:**
+- File:line reference
+- What's wrong
+- Why it matters
+- How to fix (if not obvious)
+
+### Recommendations
+[Improvements for code quality, architecture, or process]
+
+### Assessment
+
+**Ready to merge?** [Yes/No/With fixes]
+
+**Reasoning:** [Technical assessment in 1-2 sentences]
+
+## Critical Rules
+
+**DO:**
+- Categorize by actual severity (not everything is Critical)
+- Be specific (file:line, not vague)
+- Explain WHY issues matter
+- Acknowledge strengths
+- Give clear verdict
+
+**DON'T:**
+- Say "looks good" without checking
+- Mark nitpicks as Critical
+- Give feedback on code you didn't review
+- Be vague ("improve error handling")
+- Avoid giving a clear verdict
+
+## Example Output
+
+```
+### Strengths
+- Clean database schema with proper migrations (db.ts:15-42)
+- Comprehensive test coverage (18 tests, all edge cases)
+- Good error handling with fallbacks (summarizer.ts:85-92)
+
+### Issues
+
+#### Important
+1. **Missing help text in CLI wrapper**
+   - File: index-conversations:1-31
+   - Issue: No --help flag, users won't discover --concurrency
+   - Fix: Add --help case with usage examples
+
+2. **Date validation missing**
+   - File: search.ts:25-27
+   - Issue: Invalid dates silently return no results
+   - Fix: Validate ISO format, throw error with example
+
+#### Minor
+1. **Progress indicators**
+   - File: indexer.ts:130
+   - Issue: No "X of Y" counter for long operations
+   - Impact: Users don't know how long to wait
+
+### Recommendations
+- Add progress reporting for user experience
+- Consider config file for excluded projects (portability)
+
+### Assessment
+
+**Ready to merge: With fixes**
+
+**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
+```

package/skills/workflow/requirement-engineering/SKILL.md

@@ -1,111 +1,111 @@
----
-name: requirement-engineering
-description: 需求工程 — 在任何创造性工作之前使用。通过协作对话收集需求、系统性验证、产出可作为设计和开发基准的需求文档。
----
-
-# 需求工程
-
-把模糊想法转化为完整、无歧义、可验证的需求文档。包含两个阶段：**收集**（brainstorming）和**验证**（validation）。
-
-> 只负责"要做什么"，不负责"怎么做"——技术方案在 `architecture-designer` / `writing-plans` 完成。
-
-## 协调
-
-```bash
-# 建 session（若尚未创建）
-node scripts/orchestration/session.cjs init <任务名>
-# 需求文档写入 .orchestration/<session>/architect/requirements.md
-# 验证结论追加到同文件；通过后进入方案设计 phase
-```
-
-## 阶段 1：收集（brainstorming）
-
-1. **探索项目上下文** — 读 文件、文档、近期提交，了解现状
-2. **逐个提问澄清** — 每条消息**只问一个问题**，优先选择题
-3. **识别用户场景** — 谁用？什么场景？期望什么结果？
-4. **定义功能边界** — 做什么、不做什么、优先级
-5. **撰写需求文档** — 保存到 `.orchestration/<session>/architect/requirements.md`
-
-### 需求文档结构
-
-```markdown
-# [功能名] 需求文档
-
-## 背景与目的
-为什么做？解决什么问题？
-
-## 用户场景
-- 场景 1：作为 [角色]，我希望 [行为]，以便 [价值]
-
-## 功能需求（每条可验证）
-- [ ] FR-1：[具体描述 + 通过/不通过标准]
-
-## 约束条件
-- 性能 / 兼容性 / 安全要求
-
-## 非功能需求
-- ...
-
-## 范围排除（不做什么）
-- ...
-
-## 成功标准
-- ...
-```
-
-## 阶段 2：验证（validation）
-
-对收集到的需求逐条验证，不通过不得进入设计。
-
-| 维度 | 检查项 |
-|------|--------|
-| 完整性 | 每场景有对应 FR？异常/非功能需求齐全？范围排除明确？ |
-| 可行性 | 技术可实现？时间合理？与现有系统兼容？ |
-| 无歧义性 | 每条只有一种理解？数值/行为边界明确（"快速"→"200ms 内"）？ |
-| 一致性 | 条目间有矛盾？约束冲突？优先级清晰？ |
-| 可验证性 | 有明确通过/不通过标准？ |
-
-### 验证结论（追加到需求文档末尾）
-
-```markdown
----
-
-## 需求验证结论
-
-**验证日期**：YYYY-MM-DD
-**结论**：通过 / 有条件通过 / 不通过
-
-- [x] 完整性 / 可行性 / 无歧义性 / 一致性 / 可验证性：通过
-
-### 发现的问题（如有）
-1. [问题] → [修正方案]
-
-### 修改记录
-- [修改内容]
-```
-
-## 铁律
-
-1. 此阶段不做技术方案设计、不选择技术栈、不讨论架构
-2. 每条消息只问一个问题
-3. 每条需求必须可验证（明确通过/不通过标准）
-4. 必须产出需求文档并获得用户确认才能推进
-5. 验证发现的问题必须**现场修正**，不得留到后续阶段
-
-## Red Flags — 停下来
-
-| 信号 | 行动 |
-|------|------|
-| 开始讨论技术方案 | 技术方案属于设计阶段，打住 |
-| 用户说"直接做吧" | 先完成最小需求文档 |
-| 需求描述了多个独立系统 | 先帮用户拆解为子项目 |
-| 需求中有"待定""之后再说" | 现在确定或标记为**明确的开放问题** |
-| 需求可以被两种方式理解 | 选定一种并明确 |
-| 需求之间有矛盾 | 与用户澄清并修正 |
-| 想跳过用户确认 | 用户确认是必须的门禁 |
-| 想跳过验证直接设计 | 不允许 |
-
-## 与其他 skill 的协作
-
-- 若涉及 UI/UX，可派遣对应 design agent 参与需求收集
-- 通过验证的需求文档是 `architecture-designer` / `writing-plans` 的核心输入
+---
+name: requirement-engineering
+description: 需求工程 — 在任何创造性工作之前使用。通过协作对话收集需求、系统性验证、产出可作为设计和开发基准的需求文档。
+---
+
+# 需求工程
+
+把模糊想法转化为完整、无歧义、可验证的需求文档。包含两个阶段：**收集**（brainstorming）和**验证**（validation）。
+
+> 只负责"要做什么"，不负责"怎么做"——技术方案在 `architecture-designer` / `writing-plans` 完成。
+
+## 协调
+
+```bash
+# 建 session（若尚未创建）
+node scripts/orchestration/session.cjs init <任务名>
+# 需求文档写入 .orchestration/<session>/architect/requirements.md
+# 验证结论追加到同文件；通过后进入方案设计 phase
+```
+
+## 阶段 1：收集（brainstorming）
+
+1. **探索项目上下文** — 读 文件、文档、近期提交，了解现状
+2. **逐个提问澄清** — 每条消息**只问一个问题**，优先选择题
+3. **识别用户场景** — 谁用？什么场景？期望什么结果？
+4. **定义功能边界** — 做什么、不做什么、优先级
+5. **撰写需求文档** — 保存到 `.orchestration/<session>/architect/requirements.md`
+
+### 需求文档结构
+
+```markdown
+# [功能名] 需求文档
+
+## 背景与目的
+为什么做？解决什么问题？
+
+## 用户场景
+- 场景 1：作为 [角色]，我希望 [行为]，以便 [价值]
+
+## 功能需求（每条可验证）
+- [ ] FR-1：[具体描述 + 通过/不通过标准]
+
+## 约束条件
+- 性能 / 兼容性 / 安全要求
+
+## 非功能需求
+- ...
+
+## 范围排除（不做什么）
+- ...
+
+## 成功标准
+- ...
+```
+
+## 阶段 2：验证（validation）
+
+对收集到的需求逐条验证，不通过不得进入设计。
+
+| 维度 | 检查项 |
+|------|--------|
+| 完整性 | 每场景有对应 FR？异常/非功能需求齐全？范围排除明确？ |
+| 可行性 | 技术可实现？时间合理？与现有系统兼容？ |
+| 无歧义性 | 每条只有一种理解？数值/行为边界明确（"快速"→"200ms 内"）？ |
+| 一致性 | 条目间有矛盾？约束冲突？优先级清晰？ |
+| 可验证性 | 有明确通过/不通过标准？ |
+
+### 验证结论（追加到需求文档末尾）
+
+```markdown
+---
+
+## 需求验证结论
+
+**验证日期**：YYYY-MM-DD
+**结论**：通过 / 有条件通过 / 不通过
+
+- [x] 完整性 / 可行性 / 无歧义性 / 一致性 / 可验证性：通过
+
+### 发现的问题（如有）
+1. [问题] → [修正方案]
+
+### 修改记录
+- [修改内容]
+```
+
+## 铁律
+
+1. 此阶段不做技术方案设计、不选择技术栈、不讨论架构
+2. 每条消息只问一个问题
+3. 每条需求必须可验证（明确通过/不通过标准）
+4. 必须产出需求文档并获得用户确认才能推进
+5. 验证发现的问题必须**现场修正**，不得留到后续阶段
+
+## Red Flags — 停下来
+
+| 信号 | 行动 |
+|------|------|
+| 开始讨论技术方案 | 技术方案属于设计阶段，打住 |
+| 用户说"直接做吧" | 先完成最小需求文档 |
+| 需求描述了多个独立系统 | 先帮用户拆解为子项目 |
+| 需求中有"待定""之后再说" | 现在确定或标记为**明确的开放问题** |
+| 需求可以被两种方式理解 | 选定一种并明确 |
+| 需求之间有矛盾 | 与用户澄清并修正 |
+| 想跳过用户确认 | 用户确认是必须的门禁 |
+| 想跳过验证直接设计 | 不允许 |
+
+## 与其他 skill 的协作
+
+- 若涉及 UI/UX，可派遣对应 design agent 参与需求收集
+- 通过验证的需求文档是 `architecture-designer` / `writing-plans` 的核心输入