项目指令文件

在项目根目录放一个 .atomcode.md,可以把项目的技术栈、约定和偏好固化下来,AtomCode 启动时会自动把它注入系统提示,避免每次对话都要重复说一遍规则。

为什么需要它

设想这个常见场景:你的团队统一使用 Composition API,禁止 Options API。每次让 AtomCode 写新组件,你都得提醒一句"用 Composition API"。有了 .atomcode.md,这类偏好会自动带进每一次对话。

文件位置

• 默认路径:项目根目录下的 .atomcode.md
• AtomCode 从当前工作目录向上逐级查找,直到找到或到达 $HOME
• 如果该文件不存在,系统提示中自然不会出现相关内容

示例

# Project Instructions

这是一个 Vue 3 + TypeScript 项目,使用 Pinia 做状态管理、
Tailwind 做样式、Vitest 做单元测试。

## 约定

- 组件一律使用 `<script setup lang="ts">` 风格的 Composition API
- 样式只写 Tailwind,不写内联 style 和单独的 .css 文件
- 所有 API 调用走 `src/services/*`,不在组件里直接 fetch
- 状态统一放进 Pinia store,组件内部不保留派生的全局状态

## 常用命令

- 启动开发:`pnpm dev`
- 类型检查:`pnpm typecheck`
- 测试:`pnpm test`
- 构建:`pnpm build`

## 注意事项

- 不要修改 `src/generated/*`,那是从 OpenAPI 自动生成的
- 测试覆盖率要求在 80% 以上,新增模块必须带单元测试

写好 .atomcode.md 的几条经验

• 只写"和一般情况不一样"的部分 —— 通用最佳实践模型自己懂,不用在这里重复。
• 给出命令,而不是描述 —— "跑测试用 pnpm test",而不是"请运行单元测试"。
• 用祈使句 —— "使用 X"、"不要 Y",避免模棱两可的"建议"、"尽量"。
• 列出禁区 —— 哪些文件 / 目录不能动,点名就好。模型的顺从性很高。
• 控制长度 —— 每一行都会吃 token,保持在 30-80 行以内通常就够用了。

与 CLAUDE.md / GEMINI.md 的关系

如果你在同一个项目里也用 Claude Code 或 Gemini CLI,它们各自有自己的指令文件:

• Claude Code → CLAUDE.md
• Gemini CLI → GEMINI.md
• AtomCode → .atomcode.md

三者互不冲突。你可以分别维护,也可以让 .atomcode.md 通过链接或者简单 include 指向 CLAUDE.md 保持一致。

下一步

• Skills 扩展 —— 把可复用流程进一步抽象成命令
• Headless 与 Daemon —— headless 模式下 .atomcode.md 同样生效