feat：update 3 4

2026-07-02 10:04:32 +08:00
parent 604e7e68d7
commit 2fd8fc1f66
224 changed files with 12369 additions and 9 deletions
@@ -0,0 +1,125 @@
+---
+name: generate-project-constraints
+description: Use when a user needs to extract project-specific AI coding constraints, team rules, repository rules, .trae rules, Cursor rules, CLAUDE.md/AGENTS.md content, or reusable rules/checklists from an existing software project, including projects without README or explicit instruction files.
+---
+
+# Generate Project Constraints
+
+## Core Principle
+
+Generate constraints from evidence, not preference. Treat instruction files as optional inputs: if they exist, read them first; if not, use code-only mode and infer cautiously from config, source patterns, tests, CI, and runtime behavior.
+
+Every output rule must be labeled as `硬约束`, `观察性约束`, or `待确认约束`, and every non-obvious rule must cite source paths.
+
+## Evidence Order
+
+Read available sources in this order:
+
+1. Explicit instructions: `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.trae/rules`, `.cursor/rules`, `.cursorrules`, `README*`, `CONTRIBUTING*`, team docs.
+2. Build/runtime manifests: `package.json`, lockfiles, `pom.xml`, `build.gradle`, `.env*`, `application*.yml`, Docker files, compose files.
+3. Quality gates: ESLint, Prettier, Stylelint, Checkstyle, Spotless, PMD, Jest/Vitest/JUnit/Playwright configs, CI workflows.
+4. Source patterns: API layer, response wrappers, auth/permission flow, routing, state management, controller/service/repository or mapper layers, error handling, audit/logging.
+5. Existing examples: representative modules that already implement the pattern requested by the user.
+
+If a source category is absent, record it in `缺失证据`, then continue. Never block only because `README.md`, `CLAUDE.md`, or `AGENTS.md` is missing.
+
+## Constraint Levels
+
+| Level | Use When | Wording |
+| --- | --- | --- |
+| `硬约束` | Directly proven by config, build files, CI, runtime settings, or explicit team docs | `必须` / `禁止` |
+| `观察性约束` | Repeated pattern appears in existing code but no written rule exists | `默认采用` / `优先复用` |
+| `待确认约束` | Needed for delivery but not provable from the repo | `需团队确认` |
+
+Do not upgrade an observed pattern into a hard rule unless a source explicitly requires it.
+
+## Workflow
+
+1. Define scope: target repo path, output path, desired rule categories, and whether the user wants installable Skill assets or plain rules.
+2. Inventory sources with fast shell commands such as `rg --files`, `find`, `sed`, and focused `rg` searches.
+3. Extract facts into an evidence table: source path, observed fact, affected area, confidence, and candidate rule.
+4. Normalize candidate rules into the output contract below.
+5. Validate each rule against at least one source path or mark it `待确认约束`.
+6. Write rules and checklists. Prefer small files such as `rules/backend.md`, `rules/frontend.md`, `rules/security.md`, `rules/testing.md`, `rules/delivery.md`.
+7. Run verification: placeholder scan, broken-path spot checks, and a final pass that every hard/observed rule has evidence.
+
+## Output Contract
+
+When the user asks to generate constraints, produce these artifacts unless they request a lighter output:
+
+```text
+ai-dev-assets/
+├── rules/
+│   ├── global.md
+│   ├── frontend.md
+│   ├── backend.md
+│   ├── security.md
+│   ├── testing.md
+│   └── delivery.md
+├── templates/
+│   └── 项目约束提取表.template.md
+└── checklists/
+    └── 项目约束验收清单.md
+```
+
+Each rule file should use this structure:
+
+```md
+## 规则名称
+
+- 级别：硬约束 | 观察性约束 | 待确认约束
+- 适用场景：
+- 必须：
+- 禁止：
+- 来源证据：
+- 验收方式：
+- 迁移说明：
+```
+
+Use `assets/项目约束提取表.template.md` and `assets/项目约束验收清单.md` as copyable starting points when helpful.
+
+## Code-Only Mode
+
+Use this when no explicit instruction files exist.
+
+Required behavior:
+
+- State that explicit project docs were not found.
+- Build constraints from manifests, configs, CI, tests, and repeated source patterns.
+- Label all pattern-derived rules as `观察性约束`.
+- Create a `待确认约束` section for business delivery rules that the repo cannot prove, such as review gates, branch policy, audit requirements, test minimums, and release process.
+
+Good wording:
+
+```md
+本项目未发现 `AGENTS.md`、`CLAUDE.md`、`.trae/rules` 或 `README.md` 中的明确 AI 协作规则。以下约束来自配置文件和源码模式；未能由仓库证明的内容已标记为待确认。
+```
+
+## JeecgBoot Example
+
+For the training case only, JeecgBoot evidence can generate rules such as:
+
+- `硬约束`: backend uses `Result<T>` response wrapper, from backend `CLAUDE.md`.
+- `硬约束`: frontend uses `defHttp` and backend menu permission mode, from frontend `CLAUDE.md`.
+- `硬约束`: backend modification blocks require `update-begin` / `update-end`, from backend `CLAUDE.md`.
+- `观察性约束`: business features should follow existing controller/service/mapper layering after verifying representative modules.
+
+Keep these examples out of generic outputs unless the target project is JeecgBoot or explicitly similar.
+
+## Quality Gates
+
+Before claiming completion:
+
+- List generated files.
+- Scan generated files for unfinished placeholders, dummy names, and empty headings.
+- Check hard and observed constraints cite source paths.
+- Confirm missing evidence is not silently converted into rules.
+- Report which sources were read and which rule categories remain `待确认`.
+
+## Common Mistakes
+
+- Do not require `CLAUDE.md`, `AGENTS.md`, or `README.md` to exist.
+- Do not turn general best practices into project rules without evidence.
+- Do not merge business constraints, technical constraints, and delivery constraints into one vague list.
+- Do not omit verification steps; rules are useful only if a learner or team can check them.
+- Do not copy JeecgBoot-specific constraints into unrelated projects.
@@ -0,0 +1,7 @@
+interface:
+  display_name: "项目约束生成"
+  short_description: "从项目证据提取可执行规则、模板和验收清单"
+  default_prompt: "Use $generate-project-constraints to extract project-specific AI coding constraints, rules, and checklists from this repository."
+
+policy:
+  allow_implicit_invocation: true
@@ -0,0 +1,43 @@
+# 项目约束提取表
+
+## 项目信息
+
+| 字段 | 内容 |
+| --- | --- |
+| 项目名称 |  |
+| 项目路径 |  |
+| 提取日期 |  |
+| 提取人 |  |
+| 目标输出 | rules / prompts / checklists / Skill |
+
+## 证据扫描记录
+
+| 证据类型 | 文件或目录 | 是否存在 | 关键发现 | 备注 |
+| --- | --- | --- | --- | --- |
+| 显式规则 | AGENTS.md / CLAUDE.md / .trae/rules / .cursor/rules |  |  |  |
+| 项目说明 | README / CONTRIBUTING / docs |  |  |  |
+| 后端构建 | pom.xml / build.gradle / settings.gradle |  |  |  |
+| 前端构建 | package.json / lockfile / vite.config / tsconfig |  |  |  |
+| 运行配置 | .env / application.yml / Dockerfile / compose |  |  |  |
+| 质量工具 | ESLint / Prettier / Checkstyle / CI / test config |  |  |  |
+| 源码模式 | API / Controller / Service / Router / Store |  |  |  |
+| 权限与安全 | auth / permission / role / route guard / interceptor |  |  |  |
+| 数据与迁移 | schema / migration / mapper / repository |  |  |  |
+
+## 候选约束
+
+| 编号 | 分类 | 约束内容 | 级别 | 来源证据 | 影响范围 | 验收方式 | 迁移说明 |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| C-001 | global / frontend / backend / security / testing / delivery |  | 硬约束 / 观察性约束 / 待确认约束 |  |  |  |  |
+
+## 缺失证据
+
+| 缺失项 | 影响 | 处理方式 |
+| --- | --- | --- |
+|  |  | 标记为待确认 / 询问团队 / 暂不生成规则 |
+
+## 待团队确认
+
+| 问题 | 为什么需要确认 | 建议默认值 | 决策人 |
+| --- | --- | --- | --- |
+| 是否强制单测 | 仓库未发现 CI 或测试要求时无法证明 | 新增核心逻辑需补测试或说明豁免 | 技术负责人 |
@@ -0,0 +1,61 @@
+# 项目约束生成 Prompt
+
+请为下面项目生成可复用的 AI 开发约束资产。
+
+## 项目输入
+
+- 项目路径：
+- 输出路径：
+- 目标项目类型：
+- 是否需要生成 rules：
+- 是否需要生成 checklist：
+- 是否需要生成 Skill：
+
+## 执行要求
+
+1. 先扫描项目中是否存在显式规则文件，例如 `AGENTS.md`、`CLAUDE.md`、`.trae/rules`、`.cursor/rules`、`README.md`、`CONTRIBUTING.md`。
+2. 如果不存在显式规则文件，不要停止，进入 code-only 模式。
+3. 从构建配置、运行配置、源码模式、测试配置、CI 配置中提取约束。
+4. 每条约束必须标注为：
+   - `硬约束`：由配置、CI、构建或显式规则直接证明。
+   - `观察性约束`：由多个源码样例归纳，但没有显式规则。
+   - `待确认约束`：项目无法证明，但交付前必须团队确认。
+5. 每条硬约束和观察性约束必须标注来源路径。
+6. 不要把通用最佳实践当成项目事实。
+7. 不要把某个项目的专用规则复制到另一个项目。
+
+## 输出格式
+
+请生成：
+
+```text
+rules/global.md
+rules/frontend.md
+rules/backend.md
+rules/security.md
+rules/testing.md
+rules/delivery.md
+templates/项目约束提取表.template.md
+checklists/项目约束验收清单.md
+```
+
+每条规则使用：
+
+```md
+## 规则名称
+
+- 级别：
+- 适用场景：
+- 必须：
+- 禁止：
+- 来源证据：
+- 验收方式：
+- 迁移说明：
+```
+
+最后输出：
+
+- 已读来源。
+- 缺失证据。
+- 待确认问题。
+- 不能迁移到其他项目的项目特有约束。
@@ -0,0 +1,44 @@
+# 项目约束验收清单
+
+## 基础完整性
+
+- [ ] 已列出目标项目路径和输出路径。
+- [ ] 已说明是否发现显式规则文件。
+- [ ] 已记录缺失证据，没有因为缺失 README / CLAUDE.md / AGENTS.md 而停止。
+- [ ] 已区分 `硬约束`、`观察性约束`、`待确认约束`。
+- [ ] 每条硬约束都有明确来源路径。
+- [ ] 每条观察性约束至少有一个代表性源码样例。
+- [ ] 每条待确认约束都写明需要谁确认。
+
+## 规则质量
+
+- [ ] 规则包含适用场景。
+- [ ] 规则包含必须做什么。
+- [ ] 规则包含禁止做什么，或说明没有禁止项。
+- [ ] 规则包含验收方式。
+- [ ] 规则包含迁移说明，说明换项目时能否复用。
+- [ ] 规则没有把通用最佳实践冒充为项目事实。
+- [ ] 规则没有把某个单一代码样例冒充为全项目硬约束。
+
+## 覆盖范围
+
+- [ ] global 约束覆盖项目理解、证据引用、事实/推断区分。
+- [ ] frontend 约束覆盖包管理器、框架、路径别名、API 层、路由和状态管理。
+- [ ] backend 约束覆盖语言版本、框架、分层、响应结构、异常和数据访问。
+- [ ] security 约束覆盖认证、权限、敏感信息、数据范围和接口防护。
+- [ ] testing 约束覆盖已有测试工具、运行命令和缺失测试时的处理。
+- [ ] delivery 约束覆盖计划、Review、验收记录、发布或交付要求。
+
+## 可复用性
+
+- [ ] JeecgBoot 等项目特有规则没有写进通用规则。
+- [ ] 每条规则都标注了“可直接复用 / 需重新扫描 / 不可迁移”。
+- [ ] 换项目时必须重新扫描的内容已经列出。
+- [ ] 可以从本清单反推出生成步骤。
+
+## 交付检查
+
+- [ ] 生成文件中没有未完成占位符、示例假名或空标题。
+- [ ] Markdown 链接或路径经过抽样检查。
+- [ ] 规则文件标题不为空。
+- [ ] 交付说明列出已读来源、未读来源和仍需确认的问题。