> /init

/config

# 项目：电商平台
# 技术栈：Node.js + React
# 当前任务：开发用户认证模块
# 安全策略：所有用户输入必须经过 XSS 过滤
# 代码规范：统一使用 ESLint + Prettier

项目设定 → # 项目：XXX
技术栈 → # 技术栈：XXX
安全/质量要求 → # 安全策略：XXX
编码规范 → # 代码规范：XXX
禁止项 → # NEVER DO：XXX

● 在开发用户认证模块时，AI 自动遵循 # 安全策略 规则，对输入进行 XSS 过滤；
● 所有生成的前端组件代码自动符合 # 代码规范 的 ESLint + Prettier 设置；
● 如果触碰 # NEVER DO 条目（如硬编码密钥），AI 会提示修正，避免潜在风险。

# 项目：电商平台
# 技术栈：Node.js + React + PostgreSQL
# 架构：前后端分离，后端 REST API + 前端 SPA
# 部署环境：Docker + Kubernetes，使用 CI/CD 自动化

# 安全策略：
# - 所有用户输入必须经过 XSS & SQL 注入过滤
# - 严禁硬编码密钥或 token
# - 密码存储统一使用 bcrypt（cost=12）
# - HTTPS-only，拒绝明文传输

# 代码规范：
# - 使用 ESLint + Prettier，Airbnb JavaScript 风格
# - 禁止使用 var，统一使用 const/let
# - 函数长度 ≤ 50 行，超过需拆分
# - API 返回统一格式 { code, message, data }

# 测试策略：
# - 单元测试覆盖率 ≥ 80%
# - 使用 Jest + Supertest 进行接口测试
# - 关键路径必须有集成测试

# 性能要求：
# - 单次 API 响应时间 ≤ 200ms
# - 并发连接 1000 时无明显性能下降
# - 数据库查询必须有索引

# NEVER DO：
# - 禁止在生产环境打印 console.log
# - 禁止使用 MD5、SHA1 等弱加密算法
# - 禁止上传含敏感信息的日志

# 优先级策略：
# P0：安全漏洞 → 立即修复
# P1：功能缺陷 → 24h 内修复
# P2：性能问题 → 一周内优化
# P3：体验优化 → 下个版本处理

---
description: "? 智能创建MR - 自动分析变更并生成规范的分支和提交"
---
# ? 智能创建 Merge Request
分析代码变更，自动生成分支名和提交信息，创建MR。
## ? 变更分析
### Git状态和分支信息
!`git status --porcelain && echo "--- Current Branch ---" && git branch --show-current && echo "--- Remote ---" && git remote -v | head -1`
### 变更概览
!`git diff --cached --stat 2>/dev/null || git diff --stat`
### 提交历史参考
!`git log --oneline -3 --format="%s"`
### 变更详情
!`git diff --cached --name-status 2>/dev/null || git diff --name-status | head -20`
### 关键变更内容
!`git diff --cached -U2 2>/dev/null || git diff -U2 | head -100`
### 未跟踪文件
!`git ls-files --others --exclude-standard | grep -E '\.(ts|js|json|md|yml|yaml)$' | head -5`
## ? 执行策略
### 分支命名规范
- `feat/描述` - 新功能
- `fix/描述` - 修复问题  
- `refactor/描述` - 重构
- `docs/描述` - 文档
- `chore/描述` - 构建/工具
### 提交信息规范
遵循 [Conventional Commits](https://www.conventionalcommits.org/)：
```
type(scope): description
feat(agent-cli): 添加新命令
fix(agent-cli): 修复内存泄漏
docs(agent-cli): 更新安装说明
```
## 注意事项
1. **不要使用 gh CLI**
2. **首次代码推送后，命令日志里面会有一个创建 MR 的链接**
3. **依赖库信息、代码文件名、接口名、类名等敏感信息不要提醒在更新CHANGELOG.md中**
## ? 自动化流程
1. **执行构建验证**（确保代码质量）
2. **分析变更类型和范围**
3. **创建合适分支**（如在主分支）
4. **检查并更新 docs 目录的相关文档** !!重要
5. **更新CHANGELOG.md**（添加到未发布版本，避免透露代码细节）!!重要
6. **生成规范提交信息**
7. **暂存并所有提交变更（git add .）**
8. **推送到远程**
9. **open 命令打开MR页面，等待合并**
---
**开始智能MR创建...**

---
description: "? 智能发版 - 自动更新版本号和changelog，执行构建验证并创建发版MR"
argument-hint: "[custom-prompt]"
---
# ? 智能发版流程
分析变更历史，自动更新版本号和changelog，执行构建验证并创建发版MR。
## ? 发版信息收集
### 工作区和分支状态
!`git status --porcelain && echo "--- Current Branch ---" && git branch --show-current && echo "--- Remote Status ---" && git fetch origin && git status -uno`
### 当前版本信息
!`echo "Package.json version:" && jq -r '.publishConfig.customPackage.version // .version'package.json`
### Changelog结构检查
!`echo "Current CHANGELOG.md:" && head -20 CHANGELOG.md 2>/dev/null || echo "CHANGELOG.md 不存在"`
### 最近提交历史
!`git log --oneline -10 --format="%s"`
### 未发布变更检查
!`grep -n "未发布" CHANGELOG.md | head -5 || echo "无未发布标记"`
## ? 发版策略
### 版本号规则
遵循 [语义化版本](https://semver.org/lang/zh-CN/) 规范：
- `major.minor.patch` - 主版本.次版本.修订版本
- **Major**: 破坏性变更 (BREAKING CHANGE)
- **Minor**: 新功能 (feat)  
- **Patch**: 修复和改进 (fix, docs, chore等)
### 分支命名规范
- `publish/codebuddy-code-v{版本号}` - 发版分支
- 例如: `publish/codebuddy-code-v1.0.12`
## ? 自动化流程
1. **执行构建验证**（确保代码质量）
2. **分析变更类型确定版本号**
3. **创建发版分支**（如在主分支）
4. **更新package.json版本号**（改 publishConfig.customPackage.version 这个字段的版本号）
5. **更新CHANGELOG.md**（移除"未发布"标记，添加发布日期）
6. **生成发版提交信息**
7. **暂存并所有提交变更（git add .）**
8. **推送到远程**
9. **open 命令打开MR页面，等待合并**
### 构建验证步骤
```bash
npm run build     # 构建验证（包含lint检查）
npm run test      # 测试验证（如存在）
```
### 额外补充说明
$1  !!IMPORTANT
---
**开始智能发版流程...**

目标：实现用户登录功能，前端使用 LoginForm 组件，后端调用 user.js 中的登录 API。

参考资料：
- 登录流程图：@assets/login-flow.png
- API 文档：@docs/api-spec.md
- 前端组件：@src/components/LoginForm.tsx
- 后端接口：@src/api/user.js

git diff | codebuddy -p "请检查这段改动，并提出改进代码质量或重构建议"

tail -n 100 /var/log/system.log \   | grep -E "ERROR|WARN" \   | codebuddy -p "分析日志，找出错误和警告，并生成排查步骤"

head -n 500 data.csv \   | codebuddy -p "统计每列的均值、最大值和最小值，并提供可视化建议"

---
name: architect-reviewer
description: 审查代码变更以确保架构一致性与模式遵循。在任何结构性变更、新服务或 API 修改后应主动使用。确保遵循 SOLID 原则、合理分层与可维护性。
model: glm-4.0
---

你是一名专注于维护架构完整性的资深软件架构师。你的职责是从架构视角审查代码变更，确保与既定的模式和原则保持一致。

## 核心职责

1. **模式遵循**：验证代码是否遵循既定的架构模式
2. **SOLID 合规**：检查是否存在违反 SOLID 原则的情况
3. **依赖分析**：确保依赖方向正确，且不存在循环依赖
4. **抽象层级**：确认抽象层级适当，避免过度设计
5. **前瞻性**：识别潜在的扩展性或可维护性问题

## 审查流程

1. 将变更映射到整体架构中
2. 识别被跨越的架构边界
3. 检查与现有模式的一致性
4. 评估对系统模块化的影响
5. 在需要时提出架构改进建议

## 关注领域

- 服务边界与职责
- 组件之间的数据流与耦合
- 与领域驱动设计的一致性（如适用）
- 架构决策对性能的影响
- 安全边界与数据校验点

## 输出格式

请提供包含以下内容的结构化审查：

- 架构影响评估（高/中/低）
- 模式合规性检查清单
- 发现的具体违规项（如有）
- 建议的重构方案（如需）
- 变更的长期影响

请牢记：优秀的架构应当促进变更。标记任何会让未来变更更困难的因素。