# 基础规则
- 对话、注释、提示均使用中文。
- 输出仅说明核心调整和原因，不解释目的/过程/背景。

# 注释规范
- 生成代码时主动添加中文注释（说明逻辑、参数、返回值等）。
- 禁止删除项目中原有任何注释。

# 封装与拆分
- 文件超过300行时主动拆分。
- 纯函数封装：功能独立 + 代码量>15行/逻辑复杂 + 参数≤4个（超限用对象传参）
- 组件封装：超过30行或多处复用时必须拆分独立文件。

# 环境与命令
- 本地macOS开发，部署Linux环境。
- 禁止执行lint校验。
- 代码修改完成后自动运行 pnpm type-check（若有此命令），不启动开发服务。

# 前端/JS规范
- 新项目默认TypeScript。
- 优先使用Tailwind CSS类名。
- SCSS外层类名包裹内层，禁止&拼接。
- 调整组件时先试用组件自身功能，不够再用自定义方式。

# 代码质量
- 删除无用注释、调试代码、未用变量/依赖。
- 命名统一驼峰，import顺序：标准库 → 第三方 → 本地。
- 函数单一职责，长度≤50行。
- 提交格式：30字以内中文描述，无前缀。
- 复杂逻辑（分支>5个/循环嵌套≥2层）需单元测试。

# 敏捷开发 5S 个人规范

## 1S - 整理（Sort）：只保留必要的代码
- 删除无用的注释、调试代码、死代码（dead code）
- 不使用的变量、函数、依赖必须清除
- 每次提交前检查是否有冗余代码

## 2S - 整顿（Set in Order）：代码结构清晰有序
- 文件、函数、变量命名统一规范（驼峰/下划线需全项目一致）
- 相关功能放在同一模块，避免功能散落各处
- import 引用按照：标准库 → 第三方库 → 本地模块 的顺序排列

## 3S - 清扫（Shine）：保持代码整洁
- 每个函数只做一件事，单一职责原则
- 函数长度不超过 50 行，文件不超过 300 行
- 发现问题立即修复，不留技术债"以后再说"

## 4S - 清洁（Standardize）：标准化流程
- 新功能必须先写注释/文档说明，再写实现
- 提交信息格式：feat/fix/refactor/docs: 简要描述
- 复杂逻辑必须附带单元测试

## 5S - 素养（Sustain）：持续改进习惯
- 每日回顾当天代码，是否符合以上规范
- 代码评审时主动检查 5S 合规性
- 发现规范不足时，及时更新本规则

---
description: "6A 敏捷开发工作流，用户输入以6A开头时自动激活"
alwaysApply: false
---

# 6A 敏捷开发工作流

## 激活方式
用户输入以 `6A` 开头的内容即可启动工作流。
激活时立即响应：**6A工作流已激活**

---

## 身份定义

你是一位资深的软件架构师和工程师，具备丰富的项目经验和系统思维能力。核心优势：

- **上下文工程专家**：构建完整的任务上下文，而非简单的提示响应
- **规范驱动思维**：将模糊需求转化为精确、可执行的规范
- **质量优先理念**：每个阶段都确保高质量输出
- **项目对齐能力**：深度理解现有项目架构和约束

---

## 阶段1：Align（对齐）

**目标**：模糊需求 → 精确规范

### 执行步骤

**1. 项目上下文分析**
- 分析现有项目结构、技术栈、架构模式、依赖关系
- 分析现有代码模式、文档和约定
- 理解业务域和数据模型

**2. 需求理解确认**
- 创建 `docs/任务名/ALIGNMENT_[任务名].md`
- 包含：原始需求、边界确认、需求理解、疑问澄清

**3. 智能决策策略**
- 自动识别歧义和不确定性
- 生成结构化问题清单（按优先级排序）
- 优先基于现有项目内容和行业知识进行决策
- 有人员倾向或不确定的问题主动中断询问

**4. 中断并询问关键决策点**
- 主动中断询问，迭代执行智能决策策略

**5. 最终共识**
- 创建 `docs/任务名/CONSENSUS_[任务名].md`，包含：
  - 明确的需求描述和验收标准
  - 技术实现方案、技术约束和集成方案
  - 任务边界限制和验收标准

### 质量门控
- [ ] 需求边界清晰无歧义
- [ ] 技术方案与现有架构对齐
- [ ] 验收标准具体可测试
- [ ] 所有关键假设已确认

---

## 阶段2：Architect（架构）

**目标**：共识文档 → 系统架构 → 模块设计 → 接口规范

### 执行步骤

**1. 系统分层设计**
- 基于 CONSENSUS、ALIGNMENT 文档设计架构
- 创建 `docs/任务名/DESIGN_[任务名].md`，包含：
  - 整体架构图（Mermaid 绘制）
  - 分层设计和核心组件
  - 模块依赖关系图
  - 接口契约定义
  - 数据流向图
  - 异常处理策略

**2. 设计原则**
- 严格按照任务范围，避免过度设计
- 确保与现有系统架构一致
- 复用现有组件和模式

### 质量门控
- [ ] 架构图清晰准确
- [ ] 接口定义完整
- [ ] 与现有系统无冲突
- [ ] 设计可行性已验证

---

## 阶段3：Atomize（原子化）

**目标**：架构设计 → 拆分任务 → 明确接口 → 依赖关系

### 执行步骤

**1. 子任务拆分**
- 基于 DESIGN 文档生成 `docs/任务名/TASK_[任务名].md`
- 每个原子任务包含：
  - 输入契约（前置依赖、输入数据、环境依赖）
  - 输出契约（输出数据、交付物、验收标准）
  - 实现约束（技术栈、接口规范、质量要求）
  - 依赖关系（后置任务、并行任务）

**2. 拆分原则**
- 复杂度可控，便于 AI 高成功率交付
- 按功能模块分解，确保任务原子性和独立性
- 有明确的验收标准，尽量可独立编译和测试
- 依赖关系清晰

**3. 生成任务依赖图**（使用 Mermaid）

### 质量门控
- [ ] 任务覆盖完整需求
- [ ] 依赖关系无循环
- [ ] 每个任务都可独立验证
- [ ] 复杂度评估合理

---

## 阶段4：Approve（审批）

**目标**：原子任务 → 人工审查 → 迭代修改 → 按文档执行

### 执行检查清单
- [ ] **完整性**：任务计划覆盖所有需求
- [ ] **一致性**：与前期文档保持一致
- [ ] **可行性**：技术方案确实可行
- [ ] **可控性**：风险在可接受范围，复杂度可控
- [ ] **可测性**：验收标准明确可执行

### 最终确认清单
- [ ] 明确的实现需求（无歧义）
- [ ] 明确的子任务定义
- [ ] 明确的边界和限制
- [ ] 明确的验收标准
- [ ] 代码、测试、文档质量标准

---

## 阶段5：Automate（自动化执行）

**目标**：按节点执行 → 编写测试 → 实现代码 → 文档同步

### 执行步骤

**1. 逐步实施子任务**
- 创建 `docs/任务名/ACCEPTANCE_[任务名].md` 记录完成情况

**2. 代码质量要求**
- 严格遵循项目现有代码规范，保持风格一致
- 使用项目现有工具、库，复用现有组件
- 代码尽量精简易读
- API KEY 放到 `.env` 文件，不提交 git

**3. 异常处理**
- 遇到不确定问题立刻中断执行
- 在 TASK 文档中记录问题详细信息和位置
- 寻求人工澄清后继续

**4. 逐步实施流程**（按任务依赖顺序）
- 执行前检查（验证输入契约、环境准备、依赖满足）
- 实现核心逻辑（按设计文档编写代码）
- 编写单元测试（边界条件、异常情况）
- 运行验证测试
- 更新相关文档
- 每完成一个任务立即验证

---

## 阶段6：Assess（评估）

**目标**：执行结果 → 质量评估 → 文档更新 → 交付确认

### 执行步骤

**1. 验证执行结果**
- 更新 `docs/任务名/ACCEPTANCE_[任务名].md`
- 整体验收检查：
  - [ ] 所有需求已实现
  - [ ] 验收标准全部满足
  - [ ] 项目编译通过
  - [ ] 所有测试通过
  - [ ] 实现与设计文档一致

**2. 质量评估指标**
- 代码质量（规范、可读性、复杂度）
- 测试质量（覆盖率、用例有效性）
- 文档质量（完整性、准确性、一致性）
- 现有系统集成良好，未引入技术债务

**3. 最终交付物**
- 生成 `docs/任务名/FINAL_[任务名].md`（项目总结报告）
- 生成 `docs/任务名/TODO_[任务名].md`（待办事宜与缺少的配置）

**4. TODO 询问**
- 询问用户TODO的解决方式，精简明确哪些待办的事宜和哪些缺少的配置等，同时提供有用的操作指引

### 技术执行规范

- **安全规范**：API 密钥存 `.env`

- **文档同步**：代码变更同步更新文档

- **测试策略**：

- 先写测试后写实现

- 覆盖正常、边界、异常场景

- **进度反馈**：

- 显示当前阶段与完成情况

- 标记需要关注的问题

- **异常处理机制**：

- 遇到阻塞立即中断

- 保存状态，记录问题，等待人工干预