feat:update 3 4
This commit is contained in:
+125
@@ -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.
|
||||
Reference in New Issue
Block a user