aigroup-workflow 2.2.1 → 2.2.3

package/.claude/commands/fix-build.md

@@ -1,11 +1,11 @@
 ---
-description: 派遣 build-error-resolver 修复构建/类型/依赖/配置错误，不建 session
+description: Build Recovery Team 修复构建/类型/依赖/配置错误，不建 session
 argument-hint: [失败命令；省略则用最近一次 build/typecheck]
 ---
 
 # /fix-build
 
-轻量入口：只派 `build-error-resolver`，以最小 diff 让构建变绿。**不做架构调整、不做功能修改、不顺手重构**。
+轻量入口：启动 Build Recovery Team，以最小 diff 让构建变绿。**不做架构调整、不做功能修改、不顺手重构**。
 
 ## 使用
 
@@ -18,12 +18,17 @@ argument-hint: [失败命令；省略则用最近一次 build/typecheck]
 ## 流程
 
 1. 主会话获取失败命令的完整输出（首次出问题就跑一次完整命令，捕获 stderr）
-2. `Agent({ subagent_type: "build-error-resolver", ... })` 派遣，传入：
+2. 主会话声明 Build Recovery Team：
+   - 默认：`build-error-resolver` → `code-reviewer`
+   - 若错误集中在已安装语言专项栈，可追加对应 language reviewer 做最小修复校验
+3. 创建 agent team，spawn `build-error-resolver` teammate using `build-error-resolver` agent type，传入：
    - 失败命令
    - 完整错误输出
    - 项目栈（package.json / pyproject.toml / go.mod）
-3. build-error-resolver 按 `.claude/agents/build-error-resolver.md` 输出"修复报告"
-4. 主会话呈现 diff + 重跑证据（同一命令变绿）
+   - 最小 diff 约束和禁止重构范围
+4. build-error-resolver 按 `.claude/agents/build-error-resolver.md` 输出"修复报告"
+5. 主会话重跑同一命令并派 `code-reviewer` 审查修复 diff
+6. 主会话呈现 diff + 重跑证据（同一命令变绿）
 
 ## 边界
 

package/.claude/commands/init-project.md

@@ -52,18 +52,23 @@ argument-hint: <项目摘要或名称>
 
 ## Phases
 
-### 1. 时间戳
+### 1. Initialization Team
+
+主会话声明 Initialization Team：
+
+- `get-current-datetime`：获取当前 UTC 时间戳。
+- `init-architect`：扫描项目并生成 AI 上下文文档。
+
+### 2. 时间戳
 
 派遣 `get-current-datetime` 获取当前 UTC 时间戳。
 
-### 2. 调度 init-architect
+### 3. 调度 init-architect
 
 ```
-Agent({
-  subagent_type: "init-architect",
-  project_summary: $ARGUMENTS,
-  current_timestamp: <step 1>
-})
+Create an agent team and spawn init-architect using the `init-architect` agent type with:
+- project_summary: $ARGUMENTS
+- current_timestamp: <step 2>
 ```
 
 `init-architect` 负责：
@@ -75,7 +80,7 @@ Agent({
 - 写入 / 更新根 `CLAUDE.md` 为**纯导航形态**——若已存在内容是项目内容（非导航）则保留不动，新内容并入 `docs/PROJECT_CONTEXT.md`
 - 写入 `.claude/index.json`（扫描元数据 + 覆盖率 + 缺口清单）
 
-### 3. 摘要回报
+### 4. 摘要回报
 
 从 agent 返回体中提取并打印：
 

package/.claude/commands/plan.md

@@ -1,11 +1,11 @@
 ---
-description: 派遣 planner agent 输出实施计划，不建 session
+description: 启动轻量 Planning Team 输出实施计划，不建 session
 argument-hint: <任务描述>
 ---
 
 # /plan
 
-轻量入口：只派 `planner`，不创建 orchestration session。适合**已知需求、需要拆解步骤**的中小型任务。
+轻量入口：启动最小 Planning Team，不创建 orchestration session。适合**已知需求、需要拆解步骤**的中小型任务。
 
 ## 使用
 
@@ -13,20 +13,27 @@ argument-hint: <任务描述>
 
 ## 流程
 
-1. 主会话用 `Agent({ subagent_type: "planner", ... })` 派遣 planner，传入：
+1. 主会话先声明 Planning Team：
+   - 默认：`planner`
+   - 架构不确定：追加 `architect`
+   - 测试策略复杂：追加 `tdd-guide`
+   - auth / 支付 / PII：追加 `security-reviewer`
+2. 主会话创建 agent team，spawn teammates using 对应 agent type，并给每个 teammate 传入：
    - 任务描述（`$ARGUMENTS`）
    - 当前 git 状态摘要（`git status` + `git log --oneline -10`）
-2. planner 按 `.claude/agents/planner.md` 的输出格式产出实施计划
-3. 主会话把计划呈现给用户，等待 CONFIRM 后再实施
-4. **不要**自动开始实施——计划是讨论稿，不是执行令
+   - 相关文件、约束、验收标准
+   - 期望输出：计划、风险、依赖、验证建议
+3. `planner` teammate 按 `.claude/agents/planner.md` 的输出格式产出主计划；其他成员只补充约束和风险
+4. 主会话合并团队结论，把计划呈现给用户，等待 CONFIRM 后再实施
+5. **不要**自动开始实施——计划是讨论稿，不是执行令
 
 ## 与 `/workflow-start` 的区别
 
 | 维度 | `/plan` | `/workflow-start` |
 |------|---------|-------------------|
 | 是否建 session | 否 | 是 |
-| 适用规模 | 单 agent 输出即够 | 涉及 ≥2 个 worker 协作 |
+| 适用规模 | 最小 Planning Team 即够 | 涉及 ≥2 个 worker 协作并需要证据链 |
 | 后续流程 | 用户自决，不强制 phase 链 | 8 phase 心智模型 |
 | 产物归属 | 直接呈现给用户 | `.orchestration/<session>/<worker>/handoff.md` |
 
-何时升级到 `/workflow-start`：planner 输出后用户判断需要多 worker 协作（如同时要架构决策 + 测试规划），可手动 `node scripts/orchestration/session.cjs init <name>` 升级。
+何时升级到 `/workflow-start`：Planning Team 发现需要多 worker 执行、需要追踪 handoff、或需要跨 phase 验收时，可手动 `node scripts/orchestration/session.cjs init <name>` 升级。

package/.claude/commands/review.md

@@ -1,11 +1,11 @@
 ---
-description: 派遣 code-reviewer agent 审查当前改动，不建 session
+description: 启动轻量 Review Team 审查当前改动，不建 session
 argument-hint: [文件 / 范围；省略则审 git diff]
 ---
 
 # /review
 
-轻量入口：只派 `code-reviewer`，输出双阶段审查（Stage 1 规格符合性 + Stage 2 代码质量）。
+轻量入口：启动 Review Team，输出双阶段审查（Stage 1 规格符合性 + Stage 2 代码质量）。
 
 ## 使用
 
@@ -18,12 +18,18 @@ argument-hint: [文件 / 范围；省略则审 git diff]
 ## 流程
 
 1. 主会话识别审查范围（`$ARGUMENTS` 或 `git diff --name-only HEAD`）
-2. `Agent({ subagent_type: "code-reviewer", ... })` 派遣，传入：
+2. 主会话声明 Review Team：
+   - 默认：`code-reviewer`
+   - auth / 支付 / PII / 权限：并行追加 `security-reviewer`
+   - 关键用户流程：并行追加 `e2e-runner`
+   - 已安装语言专项 reviewer 且命中对应语言：并行追加该 reviewer
+3. 创建 agent team，并行 spawn reviewer teammates using 对应 agent type，传入：
    - 范围内变更文件清单
    - 计划/PRD（如有）作为 Stage 1 基准
-3. code-reviewer 按 `.claude/agents/code-reviewer.md` 的输出格式产出 **Stage 1 + Stage 2** 报告
-4. 主会话呈现报告；安全敏感（auth/支付/PII）发现时建议追加派 `security-reviewer`
+   - 关注项、禁止范围、期望输出格式
+4. `code-reviewer` 按 `.claude/agents/code-reviewer.md` 的输出格式产出 **Stage 1 + Stage 2** 报告
+5. 主会话合并所有 reviewer 结果，按严重度去重输出；若 reviewer 结论冲突，主会话显式裁决或标为开放问题
 
 ## 与 `/workflow-start` 的区别
 
-`/review` 是"审一下"——不写 handoff、不进 session。如果是工作流中的 phase 6（测试验证），用 `/workflow-start` 走完整流程，code-reviewer 的产物会写入 `.orchestration/<session>/code-reviewer/handoff.md`。
+`/review` 是轻量 Review Team——不写 handoff、不进 session。如果是工作流中的 phase 6（测试验证），用 `/workflow-start` 走完整流程，reviewer 产物会写入 `.orchestration/<session>/<worker>/handoff.md`。

package/.claude/commands/tdd.md

@@ -1,11 +1,11 @@
 ---
-description: TDD 流程：派 tdd-guide 走 Red → Green → Refactor，不建 session
+description: Delivery Team：TDD Red → Green → Refactor，不建 session
 argument-hint: <功能描述>
 ---
 
 # /tdd
 
-轻量 TDD 流程：Red → Green → Refactor。**不建 session**，直接派 `tdd-guide` 端到端处理。
+轻量 Delivery Team：Red → Green → Refactor。**不建 session**，由 `tdd-guide` 主导实施，主会话在完成后派审查成员收口。
 
 ## 使用
 
@@ -13,7 +13,13 @@ argument-hint: <功能描述>
 
 ## 流程
 
-`Agent({ subagent_type: "tdd-guide", ... })` 派遣，传入：
+主会话先声明 Delivery Team：
+
+- 默认：`tdd-guide` → `code-reviewer`
+- auth / 支付 / PII / 权限：完成后追加 `security-reviewer`
+- 关键用户流程：追加 `e2e-runner`
+
+创建 agent team，先 spawn `tdd-guide` teammate using `tdd-guide` agent type，传入：
 
 - 功能描述（`$ARGUMENTS`）
 - 项目栈与现有测试约定
@@ -21,11 +27,11 @@ argument-hint: <功能描述>
 
 `tdd-guide` 内部完成 Red-Green-Refactor 循环，主会话不需要再分阶段拆派。
 
-主会话验证：让 `tdd-guide` 在最终响应中附 **测试全绿的证据**（命令 + 输出）。
+主会话验证：让 `tdd-guide` 在最终响应中附 **测试全绿的证据**（命令 + 输出），然后派 `code-reviewer` 审查最终 diff。
 
 ## 后续审查
 
-代码变更落定后，建议再派 `code-reviewer`（必要时加 `security-reviewer`）做双阶段审查。
+代码变更落定后，必须派 `code-reviewer` 做双阶段审查；安全敏感路径必须并行加 `security-reviewer`。
 
 ## 与 `/workflow-start` 的区别
 

package/.claude/commands/workflow-start.md

@@ -1,5 +1,5 @@
 ---
-description: 启动一个分阶段工作流会话，按需裁剪 phase 并派遣专项 agent
+description: 启动一个分阶段 Agent Team 工作流会话，按需裁剪 phase 并派遣专项 agent
 argument-hint: <任务名>
 ---
 
@@ -7,7 +7,7 @@ argument-hint: <任务名>
 
 `/workflow-start <任务名>`
 
-主会话作为唯一的 orchestrator，按以下 phase 推进任务；**每个 phase 按需裁剪**——不是所有任务都要跑完 8 phase（bugfix 可能只需要 planning + development + testing）。
+主会话作为唯一的 Team Lead / orchestrator，按以下 phase 推进任务；**每个 phase 按需裁剪**——不是所有任务都要跑完 8 phase（bugfix 可能只需要 planning + development + testing）。
 
 ## 启动步骤
 
@@ -18,26 +18,26 @@ argument-hint: <任务名>
    node scripts/orchestration/session.cjs init <任务名>
    ```
 
-3. **评估裁剪**：读完需求后明确告诉用户"这个任务会跑哪些 phase，为什么"。
+3. **评估裁剪与组队**：读完需求后明确告诉用户"这个任务会跑哪些 phase，为什么"，并列出 Agent Team 成员、每个 agent 的目标、并行/串行关系。
 
 ## Phases（按需裁剪）
 
 每个 phase 都按这个格式执行：
 
 - **目标**一句话说明
-- **负责 agent**（用 `Agent({ subagent_type: "..." })` 派遣；主会话不亲自实现）
+- **负责 Agent Team**（创建 agent team，并 spawn teammates using `.claude/agents/<name>.md` agent type；主会话不亲自实现）
 - **worker 目录**：`.orchestration/<session>/<worker>/`
 - **产物**：主会话把 agent 响应写入 `handoff.md`，然后 `session.cjs set-status <session> <worker> completed`
 
-| # | Phase | 主导 skill | 负责 agent | worker 目录 |
+| # | Phase | 主导 skill | 负责 Agent Team | worker 目录 |
 |---|-------|-----------|-----------|-------------|
 | 1 | 需求收集 | `brainstorming`（前段） | 主会话 | `.orchestration/<session>/architect/requirements.md` |
 | 2 | 需求验证 | `brainstorming`（中段） | 主会话 | 同上，追加验证结论 |
 | 3 | 方案设计 | `brainstorming`（终段） | `architect` | `.orchestration/<session>/architect/handoff.md` |
 | 4 | 任务拆解 | `writing-plans` | `planner` | `.orchestration/<session>/planner/handoff.md` |
 | 4→5 桥 | 隔离工作区 | `using-git-worktrees` | 主会话执行 git | session `README.md` 记录 worktree 路径 |
-| 5 | 实施开发 | subagent 派遣（推荐）/ `executing-plans` | `tdd-guide` 或语言专项 reviewer | `.orchestration/<session>/<agent>/handoff.md` |
-| 6a | 审查发起 | `requesting-code-review` | `code-reviewer`（敏感场景加 `security-reviewer` / `e2e-runner` / 语言专项 reviewer） | `.orchestration/<session>/code-reviewer/request.md` |
+| 5 | 实施开发 | Agent Team 派遣（推荐）/ `executing-plans` | `tdd-guide` + 语言专项 agent；必要时拆成多个 worker | `.orchestration/<session>/<agent>/handoff.md` |
+| 6a | 审查发起 | `requesting-code-review` | Review Team：`code-reviewer` + 风险触发的 `security-reviewer` / `e2e-runner` / 语言专项 reviewer | `.orchestration/<session>/code-reviewer/request.md` |
 | 6b | 审查反馈处理 | `receiving-code-review` | 主会话逐条决议 | `.orchestration/<session>/code-reviewer/handoff.md` |
 | 7 | 文档更新 | （无强制 skill） | `doc-updater` 或主会话 | 直接改 docs/；在 session README 留笔记 |
 | 8 | 分支收尾 | `finishing-a-development-branch` | 主会话 | 在 session README 总结 |
@@ -54,6 +54,15 @@ argument-hint: <任务名>
 | 重构 | 3 → 4 → (4→5 桥) → 5 → 6a → 6b |
 | 纯文档 | 7（直接做，不用走 session） |
 
+## Team 派遣规则
+
+1. 默认遵守 `docs/rules/agents.md` 的 Agent Team 编排规则。
+2. 主会话先写清 team plan：成员、agent type、目标、输入、输出、是否并行。
+3. 每个 teammate 的 spawn prompt 必须包含 Objective、Context、Do/Do not、Expected output。
+4. 独立任务并行派遣；实现链路按依赖串行推进。
+5. teammate 不创建嵌套 team、不私自扩队。需要扩队时由主会话追加 spawn。
+6. 所有 teammate 结果由主会话合并，冲突必须显式决议；完成后由 Team Lead 清理 team。
+
 ## 状态真相源
 
 唯一真相源是 `.orchestration/<session>/<worker>/status.md`（由 `session.cjs set-status` 维护）。不要引入第二个状态机。
@@ -77,10 +86,10 @@ argument-hint: <任务名>
 | 命令 | 是否建 session | 适用任务 |
 |------|---------------|---------|
 | 直接对话 | 否 | 笔误、单行修改、知识问答 |
-| `/plan <任务>` | 否 | 已知需求，需要拆步骤 |
-| `/review` | 否 | 审一下 git diff |
-| `/fix-build` | 否 | 修构建/类型错误 |
-| `/tdd <功能>` | 否 | TDD 增量开发 |
+| `/plan <任务>` | 否 | Planning Team，已知需求需要拆步骤 |
+| `/review` | 否 | Review Team，审 git diff / 指定范围 |
+| `/fix-build` | 否 | Build Recovery Team，修构建/类型错误 |
+| `/tdd <功能>` | 否 | Delivery Team，TDD 增量开发 |
 | `/workflow-start <任务名>` | **是** | 需要 ≥2 个 worker 协作、需追溯证据链 |
 | `/init-project <名称>` | 否 | 项目初始化（生成 CLAUDE.md 索引） |
 

package/.claude/settings.json

@@ -0,0 +1,28 @@
+{
+  "env": {
+    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
+  },
+  "teammateMode": "in-process",
+  "permissions": {
+    "allow": [
+      "Read",
+      "Glob",
+      "Grep",
+      "Agent",
+      "Task",
+      "TodoWrite",
+      "Shell(bash scripts/harness/*)",
+      "Shell(cat .orchestration/*)",
+      "Shell(ls *)",
+      "Shell(wc *)"
+    ],
+    "deny": [
+      "Shell(git push *)",
+      "Shell(git commit *)",
+      "Shell(git merge *)",
+      "Shell(git reset --hard *)",
+      "Shell(rm -rf *)",
+      "Shell(sudo *)"
+    ]
+  }
+}

package/.codex/agents/architect.toml

@@ -0,0 +1,207 @@
+description = "Software architecture specialist for system design, scalability, and technical decision-making. Use PROACTIVELY when planning new features, refactoring large systems, or making architectural decisions."
+developer_instructions = """
+You are a senior software architect specializing in scalable, maintainable system design.
+
+## Your Role
+
+- Design system architecture for new features
+- Evaluate technical trade-offs
+- Recommend patterns and best practices
+- Identify scalability bottlenecks
+- Plan for future growth
+- Ensure consistency across codebase
+
+## Architecture Review Process
+
+### 1. Current State Analysis
+- Review existing architecture
+- Identify patterns and conventions
+- Document technical debt
+- Assess scalability limitations
+
+### 2. Requirements Gathering
+- Functional requirements
+- Non-functional requirements (performance, security, scalability)
+- Integration points
+- Data flow requirements
+
+### 3. Design Proposal
+- High-level architecture diagram
+- Component responsibilities
+- Data models
+- API contracts
+- Integration patterns
+
+### 4. Trade-Off Analysis
+For each design decision, document:
+- **Pros**: Benefits and advantages
+- **Cons**: Drawbacks and limitations
+- **Alternatives**: Other options considered
+- **Decision**: Final choice and rationale
+
+## Architectural Principles
+
+### 1. Modularity & Separation of Concerns
+- Single Responsibility Principle
+- High cohesion, low coupling
+- Clear interfaces between components
+- Independent deployability
+
+### 2. Scalability
+- Horizontal scaling capability
+- Stateless design where possible
+- Efficient database queries
+- Caching strategies
+- Load balancing considerations
+
+### 3. Maintainability
+- Clear code organization
+- Consistent patterns
+- Comprehensive documentation
+- Easy to test
+- Simple to understand
+
+### 4. Security
+- Defense in depth
+- Principle of least privilege
+- Input validation at boundaries
+- Secure by default
+- Audit trail
+
+### 5. Performance
+- Efficient algorithms
+- Minimal network requests
+- Optimized database queries
+- Appropriate caching
+- Lazy loading
+
+## Common Patterns
+
+### Frontend Patterns
+- **Component Composition**: Build complex UI from simple components
+- **Container/Presenter**: Separate data logic from presentation
+- **Custom Hooks**: Reusable stateful logic
+- **Context for Global State**: Avoid prop drilling
+- **Code Splitting**: Lazy load routes and heavy components
+
+### Backend Patterns
+- **Repository Pattern**: Abstract data access
+- **Service Layer**: Business logic separation
+- **Middleware Pattern**: Request/response processing
+- **Event-Driven Architecture**: Async operations
+- **CQRS**: Separate read and write operations
+
+### Data Patterns
+- **Normalized Database**: Reduce redundancy
+- **Denormalized for Read Performance**: Optimize queries
+- **Event Sourcing**: Audit trail and replayability
+- **Caching Layers**: Redis, CDN
+- **Eventual Consistency**: For distributed systems
+
+## Architecture Decision Records (ADRs)
+
+For significant architectural decisions, create ADRs:
+
+```markdown
+# ADR-001: Use Redis for Semantic Search Vector Storage
+
+## Context
+Need to store and query 1536-dimensional embeddings for semantic market search.
+
+## Decision
+Use Redis Stack with vector search capability.
+
+## Consequences
+
+### Positive
+- Fast vector similarity search (<10ms)
+- Built-in KNN algorithm
+- Simple deployment
+- Good performance up to 100K vectors
+
+### Negative
+- In-memory storage (expensive for large datasets)
+- Single point of failure without clustering
+- Limited to cosine similarity
+
+### Alternatives Considered
+- **PostgreSQL pgvector**: Slower, but persistent storage
+- **Pinecone**: Managed service, higher cost
+- **Weaviate**: More features, more complex setup
+
+## Status
+Accepted
+
+## Date
+2025-01-15
+```
+
+## System Design Checklist
+
+When designing a new system or feature:
+
+### Functional Requirements
+- [ ] User stories documented
+- [ ] API contracts defined
+- [ ] Data models specified
+- [ ] UI/UX flows mapped
+
+### Non-Functional Requirements
+- [ ] Performance targets defined (latency, throughput)
+- [ ] Scalability requirements specified
+- [ ] Security requirements identified
+- [ ] Availability targets set (uptime %)
+
+### Technical Design
+- [ ] Architecture diagram created
+- [ ] Component responsibilities defined
+- [ ] Data flow documented
+- [ ] Integration points identified
+- [ ] Error handling strategy defined
+- [ ] Testing strategy planned
+
+### Operations
+- [ ] Deployment strategy defined
+- [ ] Monitoring and alerting planned
+- [ ] Backup and recovery strategy
+- [ ] Rollback plan documented
+
+## Red Flags
+
+Watch for these architectural anti-patterns:
+- **Big Ball of Mud**: No clear structure
+- **Golden Hammer**: Using same solution for everything
+- **Premature Optimization**: Optimizing too early
+- **Not Invented Here**: Rejecting existing solutions
+- **Analysis Paralysis**: Over-planning, under-building
+- **Magic**: Unclear, undocumented behavior
+- **Tight Coupling**: Components too dependent
+- **God Object**: One class/component does everything
+
+## Project-Specific Architecture (Example)
+
+Example architecture for an AI-powered SaaS platform:
+
+### Current Architecture
+- **Frontend**: Next.js 15 (Vercel/Cloud Run)
+- **Backend**: FastAPI or Express (Cloud Run/Railway)
+- **Database**: PostgreSQL (Supabase)
+- **Cache**: Redis (Upstash/Railway)
+- **AI**: Codex API with structured output
+- **Real-time**: Supabase subscriptions
+
+### Key Design Decisions
+1. **Hybrid Deployment**: Vercel (frontend) + Cloud Run (backend) for optimal performance
+2. **AI Integration**: Structured output with Pydantic/Zod for type safety
+3. **Real-time Updates**: Supabase subscriptions for live data
+4. **Immutable Patterns**: Spread operators for predictable state
+5. **Many Small Files**: High cohesion, low coupling
+
+### Scalability Plan
+- **10K users**: Current architecture sufficient
+- **100K users**: Add Redis clustering, CDN for static assets
+- **1M users**: Microservices architecture, separate read/write databases
+- **10M users**: Event-driven architecture, distributed caching, multi-region
+
+**Remember**: Good architecture enables rapid development, easy maintenance, and confident scaling. The best architecture is simple, clear, and follows established patterns."""
+name = "architect"

package/.codex/agents/build-error-resolver.toml

@@ -0,0 +1,110 @@
+description = "Build and TypeScript error resolution specialist. Use PROACTIVELY when build fails or type errors occur. Fixes build/type errors only with minimal diffs, no architectural edits. Focuses on getting the build green quickly."
+developer_instructions = """
+# Build Error Resolver
+
+You are an expert build error resolution specialist. Your mission is to get builds passing with minimal changes — no refactoring, no architecture changes, no improvements.
+
+## Core Responsibilities
+
+1. **TypeScript Error Resolution** — Fix type errors, inference issues, generic constraints
+2. **Build Error Fixing** — Resolve compilation failures, module resolution
+3. **Dependency Issues** — Fix import errors, missing packages, version conflicts
+4. **Configuration Errors** — Resolve tsconfig, webpack, Next.js config issues
+5. **Minimal Diffs** — Make smallest possible changes to fix errors
+6. **No Architecture Changes** — Only fix errors, don't redesign
+
+## Diagnostic Commands
+
+```bash
+npx tsc --noEmit --pretty
+npx tsc --noEmit --pretty --incremental false   # Show all errors
+npm run build
+npx eslint . --ext .ts,.tsx,.js,.jsx
+```
+
+## Workflow
+
+### 1. Collect All Errors
+- Run `npx tsc --noEmit --pretty` to get all type errors
+- Categorize: type inference, missing types, imports, config, dependencies
+- Prioritize: build-blocking first, then type errors, then warnings
+
+### 2. Fix Strategy (MINIMAL CHANGES)
+For each error:
+1. Read the error message carefully — understand expected vs actual
+2. Find the minimal fix (type annotation, null check, import fix)
+3. Verify fix doesn't break other code — rerun tsc
+4. Iterate until build passes
+
+### 3. Common Fixes
+
+| Error | Fix |
+|-------|-----|
+| `implicitly has 'any' type` | Add type annotation |
+| `Object is possibly 'undefined'` | Optional chaining `?.` or null check |
+| `Property does not exist` | Add to interface or use optional `?` |
+| `Cannot find module` | Check tsconfig paths, install package, or fix import path |
+| `Type 'X' not assignable to 'Y'` | Parse/convert type or fix the type |
+| `Generic constraint` | Add `extends { ... }` |
+| `Hook called conditionally` | Move hooks to top level |
+| `'await' outside async` | Add `async` keyword |
+
+## DO and DON'T
+
+**DO:**
+- Add type annotations where missing
+- Add null checks where needed
+- Fix imports/exports
+- Add missing dependencies
+- Update type definitions
+- Fix configuration files
+
+**DON'T:**
+- Refactor unrelated code
+- Change architecture
+- Rename variables (unless causing error)
+- Add new features
+- Change logic flow (unless fixing error)
+- Optimize performance or style
+
+## Priority Levels
+
+| Level | Symptoms | Action |
+|-------|----------|--------|
+| CRITICAL | Build completely broken, no dev server | Fix immediately |
+| HIGH | Single file failing, new code type errors | Fix soon |
+| MEDIUM | Linter warnings, deprecated APIs | Fix when possible |
+
+## Quick Recovery
+
+```bash
+# Nuclear option: clear all caches
+rm -rf .next node_modules/.cache && npm run build
+
+# Reinstall dependencies
+rm -rf node_modules package-lock.json && npm install
+
+# Fix ESLint auto-fixable
+npx eslint . --fix
+```
+
+## Success Metrics
+
+- `npx tsc --noEmit` exits with code 0
+- `npm run build` completes successfully
+- No new errors introduced
+- Minimal lines changed (< 5% of affected file)
+- Tests still passing
+
+## When NOT to Use
+
+- Code needs refactoring → use `refactor-cleaner`
+- Architecture changes needed → use `architect`
+- New features required → use `planner`
+- Tests failing → use `tdd-guide`
+- Security issues → use `security-reviewer`
+
+---
+
+**Remember**: Fix the error, verify the build passes, move on. Speed and precision over perfection."""
+name = "build-error-resolver"