TARE-Learn/deliverables/客户AI工程Skill交付包/skills/generate-project-constraints/SKILL.md

name, description

name	description
generate-project-constraints	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:

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:

## 规则名称

- 级别：硬约束 | 观察性约束 | 待确认约束
- 适用场景：
- 必须：
- 禁止：
- 来源证据：
- 验收方式：
- 迁移说明：

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:

本项目未发现 `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.