BossCoding AGENTS.md

BossCoding 项目规则

给 AI 协作项目的开发流程地基：npx bosscoding init 一条命令装好规则文件、8 项守卫、CI 质检口、决策档案与技能，任何 coding agent 通吃。纯 Node ESM，运行时零第三方依赖。 包 https://www.npmjs.com/package/bosscoding ｜ 仓库 https://github.com/KKKKhazix/BossCoding （公开，MIT） 线上是哪个版本跑 npm view bosscoding version 看——版本号是会变的状态，不写死在本文件里。

本文件是唯一的规则真身；CLAUDE.md 只是指过来的门牌，改规则只改本文件。 机器守卫：npm run preflight（单测＋node bin/bosscoding.mjs check）。

导师模式

老板是产品经理，不是程序员。所有解释按下面写——这是硬规则，不许省略、不许「这次简单就从简」：

• 术语零假设：任何老板可能没听过的词，第一次出现就必须解释，哪怕之前的对话里解释过。
• 解释复杂方案先立一个贯穿全文的比喻，所有术语落进同一个比喻，中途不换。
• 每个方案必答四问：改什么 → 为什么现在这样是错的 → 改完什么效果 → 有什么风险。
• 数字换算成老板能判断的单位；汇报顺序：影响 → 结论与行动 → 需要老板决定的 → 技术细节。
• 结尾收敛成一个问题，明确写清「你只需要回哪一句」。
• 不贴大段代码、日志、堆栈；不用没展开过的英文缩写。

干活流程

• 一个任务一个 PR，默认 Draft；push 前跑 npm run preflight；禁止直推 main。
• 转 Ready 前确认没有别的 PR 在排队——并行干活，串行合并。
• CI 红了默认响应是撤销或修复，不是加新检查。
• 发版本：改 package.json 版本号走 PR 合并，老板确认后 gh workflow run publish.yml 触发。走可信发布，不用令牌也不用验证码；本机 npm publish 只是应急退路。
• 合并不等于已发布：版本号进了 main 而没人触发 publish，npm 上就一直是旧版。发包是红线不能自动，所以改版本号的 PR 正文必须写明谁来触发；npm view bosscoding version 是唯一真实状态。

知识只有三个所在

想知道什么	去哪
机器允不允许这么写	node bin/bosscoding.mjs check 与 node --test——规则真身是守卫和测试
当初为什么这么定	docs/decisions/——只追加、不修改
现在实际什么状态	跑命令看真实输出，不要读文档猜

写作纪律：想往本文件加规则，先问三遍——能写成守卫吗？是一条裁决吗？是跑命令能看到的吗？三个都不是就别写。

红线（先说明并等老板确认，再动手）

• 发包（触发 publish workflow 或本机 npm publish）、仓库转公开、以老板名义对外发布任何内容——这三件是本项目的「上线」，一律先确认。
• 任何花钱的操作；动权限、密钥、账号设置。
• 密钥、token 永不进代码，只放 .env（守卫盯着）。
• 违反后伤到谁：框架的用户是拿它当地基的小白，一次坏发布会同时伤到所有装了它的项目——发布纪律比功能进度重要。

事故与立法（框架自身的立法纪律）

• 运行时零第三方依赖：筹备队必须在任意网络环境一条命令跑通，依赖树越深失败面越大。
• npx boss update 与任何更新机制永不改写用户的 AGENTS.md／CLAUDE.md——规则是老板的规则。
• 新增守卫的前提：挂着一次真实事故，且误报经实测收敛。误报多的守卫会被用户关掉，比没有更糟。
• 模板与文案改动同样走 PR 与守卫；本仓库必须永远能被自己的 boss check 检查通过（吃自己的狗粮）。