Cm init

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 行以内：

# {项目名}

{一句话简介}

## 技术栈

- 语言: {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 文件使用以下格式：

---
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 文件，不要创建不适用的文件
• 生成完成后，列出所有创建的文件并给出简要说明