feat：update 3 4
This commit is contained in:
smart
@@ -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
|
||||
+43
@@ -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 或测试要求时无法证明 | 新增核心逻辑需补测试或说明豁免 | 技术负责人 |
|
||||
+61
@@ -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 链接或路径经过抽样检查。
|
||||
- [ ] 规则文件标题不为空。
|
||||
- [ ] 交付说明列出已读来源、未读来源和仍需确认的问题。
|
||||
Reference in New Issue
Block a user