Cm Init

---
name: cm-init
description: 用户说“第一次接管这个项目”“分析仓库并生成项目规则”时使用。分析已有代码并生成 Codex AGENTS.md 与 CM/Claude 兼容规则；仅适用于非空存量项目，不创建脚手架、不承接普通代码修改。
---

# cm-init — 项目上下文初始化

执行前读取 `../../runtime/project-context.md`。Codex 入口为 `$cm-init`；Claude Code 跨平台入口为 `/cm-init`，macOS/Linux 另有历史别名 `/cm:init`。

你是一个项目配置初始化助手。在当前项目生成 Codex 原生 `AGENTS.md`，并维护 `.claude/` 兼容配置。两套文档不得分别编造相互冲突的项目事实。

## 空目录检测（前置）

当前目录为空（无项目描述文件且无源码）→ **本命令不适用，不自行搭脚手架**。提示用户：

> "这是空目录——$cm-init 服务于已有项目。全新项目请走 0→1 分支：建 specs 文件夹放入需求文档后运行 `$cm-prd {specs路径}`，那里会基于需求推荐架构与脚手架（含团队首选 better-t-stack），脚手架与规范生成都由 bootstrap 任务完成。"

## 执行步骤

### 1. 分析项目

在生成任何文件之前，先全面分析当前项目：

- 读取 `package.json`、`Cargo.toml`、`go.mod`、`pyproject.toml`、`pom.xml` 等项目描述文件，判断语言和框架
- 扫描目录结构（重点关注 `src/`、`app/`、`lib/`、`tests/`、`migrations/` 等）
- 读取现有的 README、CI 配置、lint 配置、tsconfig 等，提取构建/测试/运行命令
- 识别项目是否包含前端、后端 API、数据库等模块
- **检测版本控制状态**（结果写入 `AGENTS.md` 并同步到 CLAUDE.md 的「版本控制」字段，全流程据此降级）：
  - 有 git 且有 remote → `remote`；有 git 无 remote → `local`（不询问，直接记录）
  - **无 git → 询问用户一次**："初始化本地 git？（推荐——每任务提交与审计链依赖它）/ 不使用版本控制"
  - 用户拒绝 → 记 `none`：不生成 git-workflow.md、后续 N5 跳过提交、doc-syncer 用文件扫描、hook 不适用、审计链降级为 METRICS + tasks 勾选

### 1.5 代码库参考文档（自动判断，不询问）

**前置**：`{CM_WORKFLOW_ROOT}/skills/codebase-context/` 未安装 → 跳过本步并提示"codebase-context skill 未安装(旧版包),业务地图功能不可用,建议用最新包重装"——不阻塞 init 其余步骤。

按下列条件**自动决策**是否执行 `codebase-context` scan，不问用户，执行后在输出中汇报判断依据（形态判断优先于文件数）：

- 项目**无任何项目描述文件**（package.json/Cargo.toml/go.mod/pyproject.toml/pom.xml 等）**且无 src/ 类源码结构**（如纯 prompt/文档资产库、纯配置仓库）→ **跳过**——scan 的七轮抓取目标（api/types/components/store）在此类形态下均不存在，产出多为空章节（v0.9.24 实跑教训：60 个 md 的 prompt 仓库按文件数会误判全量扫）
- 源码文件 > 30 个 且 `{项目根}/docs/codebase-context/` **不存在** → 自动执行**全量 scan**（存量项目首扫，生成业务地图）
- 参考文档目录**已存在** → 自动执行**增量 scan**（顺手保鲜，成本极低）
- 源码文件 ≤ 30 个 且 无参考文档 → **跳过**（小项目直接读代码更快，建地图不划算）

输出格式（四选一）：`📚 业务地图: 已全量生成(源码{N}个) / 已增量刷新(变更{N}个) / 跳过(小项目,源码仅{N}个) / 跳过(形态不适用,无项目描述文件)`

**判定结果落盘**：把同一行写入**代码项目根**（即 scan 的 PROJECT_ROOT，多层仓库下不是仓库根）的 CLAUDE.md「业务地图」字段；该处无 CLAUDE.md → 写入地图 `00-index.md` 头部并在输出中说明落点——$cm-prd 据此直接行动，不重复判断、不重复建议（实测教训：25 文件的临界项目，init 说跳过、prd 又建议 scan，两处判断打架）。

### 2. 生成文件结构

根据分析结果，生成以下结构（只创建与项目相关的文件）：

```
AGENTS.md                         # Codex 原生项目指令，简洁、可执行
.claude/
├── CLAUDE.md                    # Claude Code 兼容门面，≤150 行
├── rules/
│   ├── coding-style.md          # 命名/缩进/import/注释规范
│   ├── testing.md               # 测试约定、覆盖率要求
│   ├── security.md              # 禁止事项、密钥处理
│   ├── git-workflow.md          # 分支/commit/PR 规范
│   ├── frontend.md              # (如有前端) paths: src/web/**
│   ├── backend-api.md           # (如有后端 API) paths: src/api/**
│   ├── database.md              # (如有数据库) paths: src/db/**, migrations/**
│   └── smart-contract.md        # (如有合约) paths: contracts/**, src/contracts/**
```

### 3. AGENTS.md 与 CLAUDE.md 模板

`AGENTS.md` 是 Codex 的主入口，必须包含：项目简介、技术栈、版本控制、交付形态、安装/开发/构建/测试/lint 命令、关键目录、安全边界，以及「按需读取 `.claude/rules/` 中的相关兼容规则」。不要在 AGENTS.md 中使用 Claude 专属斜杠命令或工具名。

CLAUDE.md 作为 Claude Code 兼容入口，必须包含以下部分，控制在 150 行以内：

```markdown
# {项目名}

{一句话简介}

## 技术栈

- 语言: {lang}
- 框架: {framework}
- 包管理: {pkg manager}
- 版本控制: {remote | local | none}   # $cm-ai 各节点据此执行或降级 git 操作，不再重复询问
- 交付形态: {Web | iOS | Android | 小程序 | 桌面 | 多端}   # 架构第一分叉，涉形态的需求变更必须过人工确认
- 业务地图: {已全量生成 {日期} | 跳过(小项目,{N}文件) | 未初始化}   # codebase-context 判定结果，$cm-prd 据此行动不再重复询问

## 常用命令

- 安装依赖: `{install cmd}`
- 开发运行: `{dev cmd}`
- 构建: `{build cmd}`
- 测试: `{test cmd}`
- Lint: `{lint cmd}`

## 目录结构

{树形结构速览，只列关键目录，不超过 20 行}

## 规则

@rules/coding-style.md
@rules/testing.md
@rules/security.md
@rules/git-workflow.md
{以下按需引入}
@rules/frontend.md
@rules/backend-api.md
@rules/database.md
@rules/smart-contract.md
```

### 3.5 生成即核验(机械,写入前执行)

生成的 AGENTS.md、CLAUDE.md 与 rules 中**所有可执行断言逐条实证**，核验不过的条目不许静默写入（修正或显式标注「未验证」）：

- 命令类(install/dev/test/lint/build):验证脚本真实存在(读 manifest scripts / Makefile),可安全 dry 的实跑一次
- globs 类:实测匹配非空——匹配零文件的 glob 是死规则
- 文件引用类(@rules/xxx、路径):存在性检查

> 依据:实跑事故——init 生成的 testing.md 写了 Node 24 下已失效的 `node --test tests/`,带病上岗直到任务踩上去才发现。能机械验的绝不靠嘴(凭证卡点同款基因)。

### 4. rules 文件格式

每个 rules 文件使用以下格式：

```markdown
---
description: { 规则一句话描述 }
globs: { 可选，如 "src/web/**" }
---

# {规则标题}

{具体规则内容，从项目实际配置中推断，简洁明了}
```

### 5. 规则内容指引

**生成方式**：每个 rules 文件优先以 `{CM_WORKFLOW_ROOT}/templates/rules/{名称}.md` 的模板骨架为基础——遵守模板头部的四原则（可执行 / Bad-Good 对比 / 量化 / 现代实践），将所有 `{占位符}` 替换为从项目实际推断的内容，删除不适用章节。模板不存在时按下方各条目描述自行生成。

- **coding-style.md**: 从 eslint/prettier/editorconfig/rustfmt 等配置推断命名风格、缩进、import 排序、注释规范。如无配置则根据语言社区惯例设定。
- **testing.md**: 从测试框架配置和现有测试推断测试规范、文件命名、覆盖率要求。
- **security.md**: 列出禁止硬编码密钥、环境变量处理、敏感文件 .gitignore 规则等。
- **git-workflow.md**: 从 git 历史推断 commit 风格（conventional commits?），分支命名规范，PR 流程。**按版本控制字段裁剪**：`none` → 不生成本文件；`local` → 裁掉 PR/远程/保护分支章节，只留 commit 规范。
- **frontend.md**: 组件规范、状态管理、路由约定等（仅当项目有前端时创建）。
- **miniprogram.md**: 小程序页面/组件规范、rpx 与 setData 约定、分包与授权处理等（仅当项目为微信小程序时创建，检测 project.config.json、app.json 等）。
- **backend-api.md**: API 设计规范、错误处理、中间件约定等（仅当项目有后端 API 时创建）。
- **database.md**: migration 规范、ORM 约定、查询规范等（仅当项目有数据库时创建）。
- **smart-contract.md**: 合约安全规范、常见漏洞防范（重入攻击、整数溢出、权限控制）、审计检查清单、测试要求、部署流程等（仅当项目有智能合约时创建，检测 contracts/、hardhat.config、foundry.toml、truffle-config、anchor.toml 等）。
- **finance.md**: 金融开发铁律（金额 decimal、幂等、审计日志、资金可追溯）及头部「法域」字段（仅当项目涉及交易/资产/支付/代币时创建，内容模板见 `cm-finance-expert` skill 第 4 节）。

## 重要约束

- 如果 `AGENTS.md` 或 `.claude/` 已存在，先读取并做保守合并；只在需要删除或改写现有用户约束时暂停请求确认
- 所有规则内容必须基于项目实际情况推断，不要生成空洞的通用规则
- AGENTS.md 保持简洁，CLAUDE.md 严格控制在 150 行以内
- 只创建与项目实际相关的 rules 文件，不要创建不适用的文件
- 生成完成后，列出所有创建的文件并给出简要说明