xmwork/.claude/commands/team-bug-fix.md at e5e5f939eebf4a39ca5a371ee4797787e5d5119e

Files

T

gongzhiyong e5e5f939ee feat: 13 specialist agents + 3 team orchestration commands + az CLI + read-everywhere perms

Agents (10 new, total 13):
- python-fastapi-expert   — chat-gw / xiaoshou / CloudCost / kb-chat-python
- nestjs-expert           — gongdan backend
- react-frontend-expert   — xiaoshou/gongdan/casdoor web
- mcp-tools-architect     — chat-gw tool registry + auth pipeline
- celery-worker-expert    — CloudCost async tasks + beat
- security-auditor        — OWASP + secrets + auth (read-only)
- test-engineer           — coverage + flaky + e2e
- ci-cd-engineer          — 6 repos GitHub Actions
- azure-aca-expert        — ACA + Bicep + Key Vault
- docs-writer             — README / API / runbook

Team orchestration commands:
- /team-feature   — brainstorm → architect → split → parallel impl → QA
- /team-bug-fix   — triage → RCA → fix → regression test → review
- /team-refactor  — scope → test-first → batch → verify

Infrastructure:
- Dockerfile: add Azure CLI (native apt package)
- docker-compose.yml: mount ~/.azure and ~/.config/gh (read-only)
- scripts/enter.sh: banner showing agents/commands on start
- scripts/install-plugins.sh: helper to install superpowers/OMC/agent-browser

Permissions (.claude/settings.json):
- Full read access: az, gh, kubectl, psql SELECT, redis GET/KEYS/INFO
- Controlled write: gh pr create/comment, git push origin (not main)
- Hard deny: az */update|create|delete, gh pr merge, git push --force,
  alembic downgrade, kubectl apply/delete, sudo, rm -rf /

Docs:
- CLAUDE.md: new 'Agent 团队' + '权限模型' sections
- README.md: full agent roster + permission summary

Note: Dockerfile changed — run 'docker compose build' to install Azure CLI

2026-04-24 22:20:13 +08:00

5.2 KiB

Raw Blame History

description, argument-hint

description	argument-hint
Bug 修复的多 agent 编排（triage → reproduce → RCA → fix → test → review）	<bug-description-or-issue-url>

启动 Bug 修复流水线处理：$ARGUMENTS

流水线

Phase 1：Triage（主 Agent 判断）
   ├─ 问题严重度：P0/P1/P2
   ├─ 影响仓库（可能 1-N 个）
   └─ 决定走 "fast lane"（小改动）还是 "full lane"（以下完整流程）

Phase 2：复现
   └─ debugger / tracer（若有 superpowers/OMC）  或主 Agent 直接复现

Phase 3：根因分析（RCA）
   └─ tracer / systematic-debugging 找到真实根因

Phase 4：修复（按仓库派对应专家）
   ├─ python-fastapi-expert
   ├─ nestjs-expert
   ├─ casdoor-specialist
   ├─ react-frontend-expert
   ├─ mcp-tools-architect
   ├─ celery-worker-expert
   └─ lobechat-brand-guardian

Phase 5：回归防护
   └─ test-engineer 写一个会复现原 bug 的测试，在修复前它必须红

Phase 6：审查
   ├─ security-auditor  （该修复是否引入新的安全问题）
   ├─ migration-reviewer（如果涉及 schema 改动）
   └─ code-reviewer      （代码质量 + 副作用）

Phase 7：部署 + 烟测
   └─ azure-aca-expert 评估是否需要 hotfix 部署路径

执行步骤

Step 1：Triage

读取输入（issue URL、错误描述、stack trace）：

# 如果是 GitHub issue URL
gh issue view <url> --json title,body,labels,state

# 如果是生产告警，从描述中提取
#   - 错误信息
#   - 影响范围
#   - 最近的改动

判断严重度：

级别	条件	响应
🔴 P0	生产宕机 / 数据丢失风险 / 安全漏洞	跳过 Phase 1 的"讨论"，直接进 Phase 2
🟠 P1	核心功能坏 / 多用户受影响	走 full lane
🟡 P2	边缘功能 / 少数用户	full lane，不紧急
🟢 P3	体验瑕疵 / nit	fast lane

Step 2：复现

调用 superpowers:systematic-debugging（如已安装）或手动复现：

# 本地复现步骤
cd /workspace/<repo>
# 启动服务
docker compose up -d
# 复现场景
curl ... 或 pytest tests/test_bug_repro.py

必须能稳定复现再进下一步。复现不了 → 可能是 flaky 或环境问题，回 Step 1 重新 triage。

Step 3：RCA（Root Cause Analysis）

调用 tracer 或 systematic-debugging。重点排除：

代码层：最近的 commit 引入？git log --oneline <file> | head -20
数据层：特定数据导致？查异常条目
依赖层：某个依赖升级了？pip list --outdated 或 npm outdated
配置层：环境变量 / Feature flag 变化？
基础设施层：DB / Redis / 外部 API 状态？

禁止：根因未明就改代码。每一次 "我觉得这里应该加个 if" 都是技术债埋雷。

Step 4：修复

派对应的仓库专家。修复必须最小化：

只改导致 bug 的代码
不顺手做 refactor
不顺手改其它"看起来不对"的地方

Step 5：回归测试

派 test-engineer：

先写一个会复现 bug 的测试（在修复之前运行它，必须红 / fail）
应用 Phase 4 的修复
再跑测试，必须绿 / pass
跑全量测试，确认没破坏其它东西

这个测试永久保留在测试集，作为回归防护。

Step 6：多角度审查

同时派 3 个（不同上下文）：

security-auditor：这个修复是否无意间开放了新的攻击面？
migration-reviewer：如果涉及 schema 改动
code-reviewer（若可用）：代码质量、副作用、是否破坏其它功能

任一给 🔴 → 回 Phase 4 改。

Step 7：hotfix 部署评估

派 azure-aca-expert：

是否需要绕过正常 release cycle 做 hotfix？
是否需要回滚到更早 revision？
部署顺序（后端先 / 前端先 / 同时）
部署后的监控指标（哪个 dashboard 看修复效果）

输出

reports/bugfix-<date>-<slug>.md，含：

# Bug Fix Report

## 严重度
🔴 P0 / 🟠 P1 / 🟡 P2 / 🟢 P3

## 复现
- 最小复现步骤
- 影响范围：<用户数 / 请求量>

## 根因
- 真实原因：<代码/数据/依赖/配置/基础设施>
- 证据：<日志片段、git blame、调试记录>
- 为什么之前没发现：<测试覆盖缺失 / 边界条件 / 并发>

## 修复
- 改动：<diff 摘要>
- 关联 PR：<链接>
- 回归测试：<测试文件路径>

## 审查
- security-auditor: ✅ clean
- migration-reviewer: N/A
- code-reviewer: 🟡 2 个 nit 已修

## 部署
- Hotfix 路径：<是/否>
- 预期生效时间：<>
- 监控指标：<>

## 事后行动（Follow-ups）
- [ ] 补关联的测试覆盖（issue #xxx）
- [ ] 更新 on-call runbook（同类告警的处理）
- [ ] 检查其它仓库是否有相同模式的隐藏 bug

红线

❌ 禁止跳过 Step 2 的复现（没复现过的修复不可靠）
❌ 禁止跳过 Step 5 的回归测试（会让同类 bug 再次发生）
❌ 禁止在修复 PR 里夹带 refactor（review 困难、回滚风险）
❌ P0 除外：如果真的是紧急 hotfix，记录 "tech debt: 补测试 + refactor"，合并后立刻补
❌ 禁止 "我改下试试"：没明确根因不改代码

5.2 KiB Raw Blame History Unescape Escape

流水线