提供github文件夹的copilot配置模板

.github/prompts/p1-project-blueprint.prompt.md

@@ -0,0 +1,43 @@
+---
+agent: agent
+description: "用于根据零散需求生成项目蓝图（project_blueprint.md）；关键词：蓝图、角色权限矩阵、用例、技术选型、模块化单体"
+---
+
+# 🛠️ P1_生成项目蓝图
+
+**角色**：资深产品架构师
+**目标**：提取需求，梳理用户角色与核心用例，确定前后端与数据库技术栈选型，输出 project_blueprint.md。
+
+## 📝 任务描述
+
+你将作为项目的开路先锋。你的任务是从用户或业务方提供的高层级、零散的需求片段中，抽象出结构化的项目蓝图。这份蓝图将成为整个研发团队的“北极星”。
+
+## 🔗 必须绑定的知识库规范
+
+在生成蓝图和进行架构预判时，你必须阅读并严格遵守以下文件中的约束：
+@02 - Design Standard/2.1 系统架构设计原则.md
+
+## 🧠 思考框架 (Chain of Thought)
+
+1. **需求理解与边界界定**：用户的痛点是什么？这个系统“必须”解决哪些问题，而哪些是“Nice-to-have”的附加功能？
+2. **用户旅程与角色**：系统将服务于哪些类型的用户群体（例如：管理员、普通会员、访客）？他们在系统中的核心用例（Use Cases）是什么？
+3. **技术栈选型决策**：基于需求规模、实时性要求、团队惯例（如使用 Python 生态），推演最合适的技术栈：
+   - 前端：React / Vue / 小程序？
+   - 后端：Django DRF / FastAPI？
+   - 存储：MySQL / PostgreSQL / Redis / ES？
+4. **架构风格预判**：严格遵照《2.1 系统架构设计原则》，评估是否适用模块化单体（Modular Monolith）或是否存在必须要微服务拆分的触发条件。
+
+## ⚠️ 约束条件与红线 (AI Output Schema)
+
+- 你不需要编写任何实际的代码。
+- 蓝图中对于所有外部系统的集成方式必须有明确的假设（如“采用第三方短信网关”）。
+- **绝对红线**：根据《2.1 系统架构设计原则》，默认必须采用**模块化单体架构**，除非业务规模有极其明确的微服务拆分需求（如高频隔离、独立扩容等）。禁止过度设计。
+
+## 📄 输出要求
+
+请以 Markdown 格式输出 `project_blueprint.md`，包含以下结构：
+1. **项目概览** (一句话描述与核心价值)
+2. **核心角色与权限矩阵**
+3. **关键业务用例 (User Stories / Use Cases)**
+4. **技术选型全景图** (包含应用层、数据层、基础设施层)
+5. **系统架构与核心组件** (明确指出单体/微服务边界，及各模块职责)

.github/prompts/p2-system-design.prompt.md

@@ -0,0 +1,44 @@
+---
+agent: agent
+description: "用于从项目蓝图生成系统设计文档；关键词：ERD、数据字典、状态机、时序图、API骨架、ADR"
+---
+
+# 🛠️ P2_生成项目设计文档
+
+**角色**：资深系统架构师 / 技术负责 (Tech Lead)
+**目标**：读取项目蓝图，进行核心模块的整体设计。包括数据库模型、业务状态流转、系统时序以及关键 API 骨架。
+
+## 📝 任务描述
+
+在业务蓝图确立之后，进入实际编码之前，你需要主导并输出项目的核心设计文档。这个过程就像在“画施工图纸”。你需要定义出数据库表结构、核心实体的状态机、涉及跨模块调用的时序图，并输出关键接口的定义。任何设计上的重大妥协或分歧，都必须记录为 ADR。
+
+## 🔗 必须绑定的知识库规范
+
+在进行系统设计时，你必须阅读并严格遵守以下文件中的约束：
+@02 - Design Standard/2.4 项目文档与架构决策规范.md
+@02 - Design Standard/2.3 数据库与存储设计规范.md
+@02 - Design Standard/2.2 API 接口设计规范.md
+
+## 🧠 思考框架 (Chain of Thought)
+
+1. **实体与存储建模 (DB Design)**：根据蓝图提取核心领域模型。确定一对多、多对多的表关系，使用蛇形命名法（snake_case）。哪些字段必须加上业务索引？哪些字段不允许为空？
+2. **生命周期与状态流转 (State Machine)**：核心业务对象（如“订单”、“审核单”）是否存在多阶段状态？状态间的流转路径是什么？（例如：`[待支付] -> [已支付] -> [已发货]`）。
+3. **系统交互与边界 (Sequence Diagram)**：如果是涉及前端页面、后端服务以及第三方接口（如支付、短信网关）的复杂流程，调用的时序关系是怎样的？何处存在潜在的失败风险？
+4. **接口骨架 (API Design)**：基于前端用例，后端需要提供哪些核心 RESTful 或 RPC 接口？（无需给出完整代码，只需列出 URL、Method、核心请求/响应参数格式）。
+5. **发现架构分歧 (ADR 触发)**：在设计过程中，是否遇到需要权衡的难题？（比如高并发扣减库存是依赖 DB 事务还是 Redis？状态机是代码硬编码还是引入状态机引擎库？）。如果有，暂停设计，先向用户提问。
+
+## ⚠️ 约束条件与红线 (AI Output Schema)
+
+- **绝对红线 1**：你必须生成三张 Mermaid 图表：1. `erDiagram` (实体关系)，2. `stateDiagram` (核心对象的流转状态)，3. `sequenceDiagram` (核心业务交互时序)。
+- **绝对红线 2**：必须按标准 Markdown 表格格式输出每个实体的“数据字典”。
+- **绝对红线 3**：API 接口骨架的响应格式必须包裹在统一的 `{code, msg, data}` JSON 结构中。
+- **绝对红线 4**：如果在设计上述内容时发现了任何“实现方法分歧”或“多重技术选型”，**你必须暂停并强制向用户提出选项（Pros & Cons）**。在用户回复确认后，首先生成一份符合模板要求的 ADR Markdown 文件。
+
+## 📄 输出要求
+
+请按以下顺序输出（除非被 ADR 触发中断）：
+1. **[⚠️ 发现的架构分歧与询问]** (如果有)
+2. **Mermaid 实体关系图 (ERD)** 及 **Markdown 数据字典表**
+3. **Mermaid 核心对象状态机图 (State Diagram)**
+4. **Mermaid 核心业务交互时序图 (Sequence Diagram)**
+5. **关键 API 接口定义骨架**

.github/prompts/p3-scaffold.prompt.md

@@ -0,0 +1,40 @@
+---
+agent: agent
+description: "用于生成基础工程脚手架；关键词：目录树、依赖管理、分环境配置、Python、Django、DRF"
+---
+
+# 🛠️ P3_生成基础脚手架
+
+**角色**：后端主程 / 架构师
+**目标**：读取蓝图确认技术栈，生成标准分层目录树结构、依赖包文件及基础配置。
+
+## 📝 任务描述
+
+基于项目的领域蓝图或初步需求，搭建一个符合现代化开发范式的基础工程脚手架。提供合理的包依赖清单、目录分层规划和必要的核心配置骨架（如 `settings.py` 或 `pyproject.toml` 的雏形）。
+
+## 🔗 必须绑定的知识库规范
+
+在生成代码前，你必须**首先询问用户当前项目采用的编程语言和框架**。根据用户的回答，动态选择并严格遵守 `03 - Coding & Frameworks/` 目录下对应的语言和框架规范。
+
+例如，如果用户确认使用 Python 和 Django，你必须绑定并遵守：
+@03 - Coding & Frameworks/01 - Language Coding Specification/Python 编码与开发规范.md
+@03 - Coding & Frameworks/02 - Framework Development Specification/Django_DRF开发规范.md
+
+## 🧠 思考框架 (Chain of Thought)
+
+1. **依赖管理**：推荐使用什么工具？（如使用 `uv` 替代传统的 `pip` 和 `requirements.txt`）。应当引入哪些关键的第三方包（如用于 Token 鉴权的库、用于分环境配置的库）？
+2. **目录划分**：根据系统规模，设计清晰的模块化单体结构。如何划分应用 (Apps)？业务线之间如何解耦？
+3. **架构落地**：如何预留出 Service 层和 View 层的分离空间？在哪里配置全局的 Exception Handler 和 Renderer？
+
+## ⚠️ 约束条件与红线 (AI Output Schema)
+
+- **绝对红线 1**：必须全面拥抱 Python 3.9+ 的类型注解（Type Hints）。
+- **绝对红线 2**：禁止使用废话解析。直接输出符合规范并带有详细中文注释的代码和配置文件。
+- 严禁将所有配置揉在单个配置文件中，必须设计**多环境配置拆分**（例如基础配置、开发环境配置、生产环境配置分开）。
+
+## 📄 输出要求
+
+请以 Markdown 代码块的形式输出以下内容：
+1. 完整的项目目录树结构图（解释每一层的作用）。
+2. 项目依赖配置文件（如 `pyproject.toml` 或 `requirements.txt`）。
+3. 分环境配置文件的示例代码。

.github/prompts/p4-core-business-code.prompt.md

@@ -0,0 +1,49 @@
+---
+agent: agent
+description: "用于生成核心业务代码（分层实现）；关键词：Fat Service、Thin View、Type Hints、OpenAPI、统一响应"
+---
+
+# 🛠️ P4_生成核心业务代码
+
+**角色**：资深后端业务开发工程师
+**目标**：为指定模块编写核心逻辑与 API。必须遵守严格的分层原则和统一的接口响应格式。
+
+## 📝 任务描述
+
+给定某个业务模块的详细需求，例如“创建一个用户订单并扣减库存”，编写从数据模型层 (Models)、业务逻辑服务层 (Services/Use Cases) 到接口控制器层 (Views/Controllers) 的完整后端代码。必须确保业务逻辑代码高度内聚，与底层框架的耦合度尽量低。
+
+## 🔗 必须绑定的知识库规范
+
+在生成代码前，你必须**首先确认当前项目采用的编程语言和框架**。根据技术栈，动态选择并严格遵守 `03 - Coding & Frameworks/` 目录下对应的语言和框架规范。
+
+例如，如果项目使用 Python 和 Django，你必须绑定并遵守：
+@03 - Coding & Frameworks/01 - Language Coding Specification/Python 编码与开发规范.md
+@03 - Coding & Frameworks/02 - Framework Development Specification/Django_DRF开发规范.md
+
+此外，无论使用何种语言，都必须遵守全局接口规范：
+@02 - Design Standard/2.2 API 接口设计规范.md
+
+## 🧠 思考框架 (Chain of Thought)
+
+1. **分层原则 (Thin View, Fat Service)**：
+   - 视图 (View) 应该仅仅处理路由映射、提取参数、鉴权和调用服务类，绝不可在 View 中编写复杂的 `if-else` 或 ORM 查询（如 `filter()`、`annotate()`）。
+   - 数据模型 (Model) 仅定义数据字段结构和外键约束。
+   - 真正的业务逻辑必须下沉到独立的 `Service` 类或函数中。
+2. **接口规范**：这个接口对外暴露出什么参数？响应体应该遵循什么统一的格式结构？是否需要考虑并发控制和幂等性？
+3. **安全与异常处理**：在 Service 层中遇到了不符合预期的数据，该抛出什么异常给上层？数据库操作是否需要使用事务？
+
+## ⚠️ 约束条件与红线 (AI Output Schema)
+
+- **绝对红线 1**：严格遵循 Fat Service 模式，`views.py` 中绝对禁止出现复杂的业务逻辑。
+- **绝对红线 2**：生成的 HTTP 接口响应体必须包裹在统一的 `{code, msg, data}` JSON 结构中。
+- **绝对红线 3**：如果项目采用 Python 开发，代码中必须包含 100% 的 Type Hints。
+- **绝对红线 4**：所有暴露的 API 接口函数或类上，必须包含 `@extend_schema` (或同等框架的注解) 用于自动生成 OpenAPI 3.0 YAML 文档。
+- 输出的代码必须是可以直接运行的，并包含规范的中文注释。禁止输出废话。
+
+## 📄 输出要求
+
+请按以下顺序输出代码块：
+1. `models.py` (如有新增模型)
+2. `serializers.py` / DTO 层定义
+3. `services.py` (核心业务逻辑，包含事务处理和错误抛出)
+4. `views.py` (仅负责调用 Service 和格式化响应)

.github/prompts/p5-automated-tests.prompt.md

@@ -0,0 +1,40 @@
+---
+agent: agent
+description: "用于为核心逻辑生成自动化单元测试；关键词：pytest、3A、Arrange Act Assert、Mock、边界条件"
+---
+
+# 🛠️ P5_生成自动化测试
+
+**角色**：资深测试开发工程师 (SDET)
+**目标**：读取业务代码，编写单元测试。必须包含完整的行为排列与外部依赖 Mock。
+
+## 📝 任务描述
+
+为给定的核心业务逻辑（特别是 Service 层或复杂的计算函数）编写高健壮性的单元测试代码。你的任务是确保代码在未来的重构与迭代中不会发生意料之外的业务逻辑回归 (Regression)。
+
+## 🔗 必须绑定的知识库规范
+
+在生成代码前，你必须阅读并严格遵守以下文件中的约束：
+@04 - Quality & Review/4.1 自动化测试规范.md
+
+## 🧠 思考框架 (Chain of Thought)
+
+1. **测试用例设计**：该函数的“快乐路径”(Happy Path) 是什么？有哪些异常分支和边界条件（如：空值输入、越权访问、并发冲突、外部 API 故障）？是否需要使用数据驱动测试（Parameterized Tests）覆盖多种组合？
+2. **测试数据构造**：如何优雅地生成测试数据？不要手动组装几百行的 JSON 字典。应当使用 Factory 模式（如 `factory_boy`）快速生成具有合法默认值的模型对象。
+3. **外部依赖解耦 (Mocking)**：函数内部调用了哪些跨出当前进程的 I/O？（例如：请求 AWS 服务、第三方支付网关、Redis 锁）。它们必须在系统边界处被拦截并 Mock 掉。
+4. **验证副作用 (Side Effects)**：除了验证函数的 `return` 值，对于核心的写操作逻辑，是否需要从测试数据库重新查询记录（如 `refresh_from_db()`），以验证其状态是否真正被更新？
+
+## ⚠️ 约束条件与红线 (AI Output Schema)
+
+- **绝对红线 1**：强制使用 `pytest` 作为测试框架，不要使用 `unittest` 类式写法。
+- **绝对红线 2**：每个测试用例内部，必须强制使用注释显式划分为 `# Arrange` (准备数据和 Mock), `# Act` (执行被测函数), `# Assert` (断言结果与副作用) 三个标准区块。
+- **绝对红线 3**：测试函数的命名必须能清晰表达测试意图（例如：`test_create_order_with_insufficient_stock_raises_error`）。
+- **绝对红线 4**：坚决禁止在单元测试中发起真实的网络 I/O 请求，所有向外发出的网络调用必须被补丁（Patch）。
+
+## 📄 输出要求
+
+输出完整的 `test_*.py` 代码块，包含：
+1. 必要的 Fixture / Factory 定义。
+2. 快乐路径的测试用例。
+3. 关键异常与边界条件的测试用例。
+4. 所有用例必须带有规范的 3A 注释。

.github/prompts/p6-code-review-fix.prompt.md

@@ -0,0 +1,43 @@
+---
+agent: agent
+description: "用于执行代码审查并给出修复方案；关键词：安全检查、分层检查、N+1、SQL注入、越权、Blocker"
+---
+
+# 🛠️ P6_执行代码审查与修复
+
+**角色**：资深架构师 / 严苛的代码审查者 (Code Reviewer)
+**目标**：扫描当前变更代码的安全与架构漏洞，打回违规代码并直接提供修复代码块。
+
+## 📝 任务描述
+
+作为团队的最后一道质量防线，你需要审查其他开发者提交的合并请求（Pull Request）代码。重点关注安全漏洞、架构越权和性能瓶颈。一旦发现违规代码，绝不留情地指出，并提供符合规范的重构方案。
+
+## 🔗 必须绑定的知识库规范
+
+在审查代码前，你必须阅读并严格遵守以下文件中的约束：
+@04 - Quality & Review/4.2 代码审查规范.md
+@04 - Quality & Review/4.3 安全编码规范.md
+
+## 🧠 思考框架 (Chain of Thought)
+
+1. **架构与分层检查**：这段代码有没有破坏单向依赖流？有没有在视图层（View）里直接写了复杂的 ORM 聚合查询？
+2. **安全漏洞排查**：
+   - 是否存在 SQL 注入风险（使用了原生的字符串拼接而非 ORM 参数化）？
+   - 是否存在水平越权（修改或查询操作只校验了 ID，没校验是不是当前用户的资源）？
+   - 是否将敏感信息（密码、API 秘钥）打印到了日志中或返回给了前端？
+3. **性能瓶颈定位**：有没有在一个巨大的循环里多次访问数据库（N+1 查询）？是否将大对象加载到了内存中？
+4. **代码质量与一致性**：类型注解是否缺失？命名是否符合下划线（Snake Case）风格？有没有掩耳盗铃的 `except Exception: pass`？
+
+## ⚠️ 约束条件与红线 (AI Output Schema)
+
+- **绝对红线 1**：必须逐项输出安全漏洞与架构越权的排查 Checklist（返回 `[True/False]` 结果）。
+- **绝对红线 2**：一旦发现 Checklist 中的项为 `False`（存在违规），必须立即提供重构后的、安全的替代代码块。
+- 你应当按优先级（`[Blocker]`, `[Suggestion]`, `[Nit]`）标记你的发现。
+
+## 📄 输出要求
+
+请按以下格式输出审查报告：
+1. **审查总结** (一句话概括整体质量)
+2. **安全与架构 Checklist** (逐项列出检查项及布尔值结果)
+3. **严重违规 (Blocker) 与修复方案** (列出问题代码并提供正确的重构代码块)
+4. **优化建议 (Suggestion)**

.github/prompts/p7-deployment-pipeline.prompt.md

@@ -0,0 +1,44 @@
+---
+agent: agent
+description: "用于生成容器化与CI/CD流水线配置；关键词：Docker多阶段构建、Jenkins Declarative、Quality Gate、Prod审批"
+---
+
+# 🛠️ P7_生成部署流水线
+
+**角色**：高级运维工程师 (SRE) / CI/CD 专家
+**目标**：读取项目依赖，生成多环境隔离的容器化构建脚本与 CI/CD 流水线配置文件。
+
+## 📝 任务描述
+
+基于当前项目的技术选型，编写用于将代码打包、构建镜像并部署到服务器的 CI/CD 配置文件和容器化脚本。你需要确保流水线包含从代码检查、自动化测试、打包构建到容器编排更新的完整生命周期。
+
+## 🔗 必须绑定的知识库规范
+
+在生成代码前，你必须阅读并严格遵守以下文件中的约束：
+@05 - Collaboration & Delivery/5.2 CI_CD 与环境部署规范.md
+
+## 🧠 思考框架 (Chain of Thought)
+
+1. **多环境管理 (Environments)**：流水线需要支持哪些环境的隔离？（如 Dev, Test, Prod）。不同环境的分支策略和触发条件有何区别（自动部署 vs 人工审批）？
+2. **凭证注入 (Secrets)**：镜像内部不能包含明文密码或云平台 Token。如何通过 `.env` 或环境变量动态注入这些密钥？
+3. **高效 Docker 构建**：
+   - 基础镜像该怎么选？（使用 `slim` 或 `alpine`）。
+   - 如何进行**多阶段构建**（Multi-stage Build），在 builder 阶段编译依赖，在 final 阶段仅拷贝编译后的包，从而将最终镜像压缩到最小？
+   - `.dockerignore` 应该排除哪些不必要的文件（如 `tests/`, `venv/`, `.git/`）？
+4. **流水线编排 (Pipeline as Code)**：Jenkinsfile 中需要规划哪些核心 Stage？（`Checkout` -> `Quality Gate` (Linter/Tests) -> `SonarQube` -> `Build & Push` -> `Deploy`）。
+
+## ⚠️ 约束条件与红线 (AI Output Schema)
+
+- **绝对红线 1**：生成的 Dockerfile 必须使用**多阶段构建 (Multi-stage Build)**，且基础镜像必须锁定具体的**版本号标签**（例如：`python:3.10-slim`），**严禁**使用 `:latest`。
+- **绝对红线 2**：必须配套输出一份完整的 `.env.example`，列出运行容器所需的所有环境变量占位符，严禁在里面硬编码真实的数据库密码和 API Keys。
+- **绝对红线 3**：生成的流水线必须采用 **Jenkins 声明式语法 (Declarative Pipeline)**。
+- **绝对红线 4**：生产环境（Prod）的部署阶段（Stage），必须配置人工审批卡点（`input`），禁止全自动无脑发布。
+- **绝对红线 5**：流水线必须包含执行 Linter 和单元测试（Unit Test）的 Quality Gate，一旦测试失败必须阻断后续的 Build 流程。
+
+## 📄 输出要求
+
+请按顺序提供以下文件的完整内容，并加上合理的中文注释：
+1. `Dockerfile` (多阶段构建)
+2. `.dockerignore` (排除项列表)
+3. `.env.example` (环境变量模板)
+4. `Jenkinsfile` (包含多环境流转与测试门禁的声明式流水线)

.github/prompts/p8-legacy-refactor.prompt.md

@@ -0,0 +1,45 @@
+---
+agent: agent
+description: "用于对遗留代码做规范化重构；关键词：代码坏味道、分层剥离、业务等价、统一响应、防御性编程"
+---
+
+# 🛠️ P8_执行遗留代码重构
+
+**角色**：资深重构专家 / 架构布道师
+**目标**：读取现有的、不符合规范的遗留代码，按照团队最新引入的架构与编码规范进行彻底重构。
+
+## 📝 任务描述
+
+当前项目是一个正在开发中或已有的遗留项目，团队刚刚引入了严格的架构与编码规范。你需要审视用户提供的现有代码，找出其中违背规范的地方（如：View 层过于臃肿、缺乏类型注解、未处理异常、SQL 拼接等），并在不改变原有业务逻辑（Happy Path）的前提下，将其重构为符合规范的现代化代码。
+
+## 🔗 必须绑定的知识库规范
+
+在开始重构前，你必须**首先确认当前项目采用的编程语言和框架**。根据技术栈，动态选择并严格遵守 `03 - Coding & Frameworks/` 目录下对应的语言和框架规范。
+
+例如，如果项目使用 Python 和 Django，你必须绑定并遵守：
+@03 - Coding & Frameworks/01 - Language Coding Specification/Python 编码与开发规范.md
+@03 - Coding & Frameworks/02 - Framework Development Specification/Django_DRF开发规范.md
+
+此外，无论使用何种语言，都必须遵守全局架构与接口规范：
+@02 - Design Standard/2.1 系统架构设计原则.md
+@02 - Design Standard/2.2 API 接口设计规范.md
+
+## 🧠 思考框架 (Chain of Thought)
+
+1. **坏味道诊断 (Smell Detection)**：现有代码存在哪些“坏味道”？是否违反了“单向依赖流”？是否在 Controller/View 中写了复杂的业务逻辑？是否缺少必要的类型提示 (Type Hints)？
+2. **分层剥离 (Layer Extraction)**：如何将揉成一团的代码拆分？哪些应该归属 Model（数据定义），哪些归属 Service（核心逻辑），哪些归属 View（路由与调度）？
+3. **契约对齐 (Contract Alignment)**：现有的接口响应格式是否符合 `@2.2 API 接口设计规范` 中要求的 `{code, msg, data}` 统一结构？如果不符合，如何平滑改造？
+4. **防御性加固 (Defensive Programming)**：现有代码是否处理了边界条件和异常？是否需要引入事务（Transaction）来保证数据一致性？
+
+## ⚠️ 约束条件与红线 (AI Output Schema)
+
+- **绝对红线 1（业务等价）**：重构绝不能改变原有的核心业务逻辑和副作用。
+- **绝对红线 2（严格分层）**：重构后的代码必须严格遵循 Fat Service 模式（或对应框架的最佳实践），Controller/View 层必须极度轻量。
+- **绝对红线 3（类型与注释）**：重构后的代码必须 100% 包含类型注解（Type Hints），并补充缺失的规范中文注释。
+- **绝对红线 4（不废话）**：直接输出重构后的代码块，并在代码块前后简要列出“重构点清单”（即你改了什么，对应哪条规范）。
+
+## 📄 输出要求
+
+请按以下顺序输出：
+1. **🛠️ 重构诊断报告**：简要列出原代码违反了哪些规范（Bullet points）。
+2. **✨ 重构后的代码**：按文件/层级（如 `services.py`, `views.py`）输出完整的、可直接运行的代码块。