一键导入
add-atomic-chat-tool
Add Atomic Chat MCP server so the container agent can call local models served by the Atomic Chat desktop app via its OpenAI-compatible API.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Add Atomic Chat MCP server so the container agent can call local models served by the Atomic Chat desktop app via its OpenAI-compatible API.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
单后端闭环测试执行器(stack-agnostic / project-agnostic)。当一个后端 feature 收尾、需要补 superpowers/spec-kit 开发期 TDD 与契约测试覆盖不了的后端结构性测试缺口时使用:先读项目栈 (package.json / pyproject.toml / go.mod / pom.xml 等)按栈实例化对应工具,再针对实际命中的缺口 RED→GREEN 补测并固化为回归。覆盖四类后端结构性缺口——真库数据层/迁移/事务/约束、鉴权与越权 (BOLA/BFLA)、并发/竞态/限频原子性、韧性/故障注入(重试/超时/降级)。触发词:单后端测试 / 后端缺口补测 / backend testing / 真库测试 / 越权测试 / 并发测试 / 韧性测试 / 后端集成测试 / 后端回归补测。遵循 testing-system-blueprint 蓝本(风险分级 / 可追溯 / 发布门 / 三层节奏),受自愈护栏约束(只写 tests/、断言 不可弱化、禁伪造修复、有界重试、产 PR 人审)。被 test-routing-advisor 在判定"单后端"时调用,也可直接触发。
单前端闭环测试执行器(stack-agnostic / project-agnostic)。当一个前端 feature 收尾、需要补 superpowers/spec-kit 开发期覆盖不了的前端结构性测试缺口时使用:先读项目栈(package.json 或 等价清单)按栈实例化对应成熟工具,再针对实际命中的层 RED→GREEN 补测并固化为回归。与 backend-testing 的根本区别——后端缺口无现成工具需自建("施工队"),前端成熟工具齐全,本 skill 不重新发明工具,只做 三件事:装 + 配 + 把项目的视觉/交互契约翻译成这些工具能跑的断言/规则("装配工 + 监理")。覆盖五层 前端结构性缺口——编译期 lint 门、L0/L1 单测(含 getComputedStyle 断言 token/深色/涨跌色)、a11y + 跨浏览器/响应式、前后端契约 mock、视觉回归。触发词:单前端测试 / 前端缺口补测 / frontend testing / 视觉回归 / a11y 测试 / 跨浏览器测试 / 响应式测试 / token 断言 / 前后端契约 mock / 前端回归补测。 常见地基为零:很多前端 [FE] 任务出参验证只写"手测"、测试运行器/RTL/Playwright 可能完全没装—— 本 skill 第一动作是"识栈→若无测试运行器先立地基",不假设 L0/L1 已就绪。遵循 testing-system-blueprint 蓝本(风险分级 / 可追溯 / 发布门 / 三层节奏),受自愈护栏约束(只写测试不改产品码、断言不可弱化、禁伪造 修复、有界重试、产 PR 人审)。被 test-routing-advisor 在判定"单前端"时调用,也可直接触发。
完整功能链路测试执行器(stack-agnostic / project-agnostic)。当多个 feature 已陆续收尾、 某条**跨多 feature 的端到端旅程(A→B→C)首次贯通**、需要为这条关键旅程织一张端到端安全网时使用: 与前三格根本不同——本格的被测对象**不是给定的,要先从系统结构里【挖掘】出来**。先从三源 (静态代码图 + 运行时 trace + spec 契约)挖出一份**跨多 feature 的通路清单(path inventory)**, 挑 P0 关键旅程,再端到端验证、固化成安全网。覆盖跨多 feature 且含非 UI 跳步(定时任务 / 异步 / 跨通道)的 完整链路;单 feature 内单切片归"局部前后端"第三格,不在这里。两个最独特点:① 被测对象要先被挖掘出来; ② 它是**安全网层**——少而精只盖 P0;**若 bug 首次在这层被发现,说明下层(单后端/单前端/局部前后端)漏测了, 应回补下层**。六步闭环:挖通路+选 P0 → 全系统编排+只 stub 外部边界 → 条件命中 → 两层落地 → RED→GREEN(禁 sleep, fake clock/手动触发定时任务/poll-retry 等最终态)→ 归档+拆栈+PR 人审。触发词:完整功能链路 / 端到端旅程 / 跨 feature 测试 / 通路挖掘 / path inventory / 关键旅程 / 安全网 / journey 测试 / full chain testing / e2e journey / 链路贯通测试。天然要最多代码才能跑、是最后才能执行的一格;代码未落地时只能"挖候选通路 + 写 RED E2E"不能跑。遵循 testing-system-blueprint 蓝本(风险分级 / 可追溯 / 发布门 / 三层节奏),受自愈护栏约束 (只写测试不改产品码、断言不可弱化、禁伪造修复、有界重试、产 PR 人审,发现真 bug 回交 superpowers TDD)。 被 test-routing-advisor 判定"完整功能链路"时调用,也可直接触发。兄弟:backend-testing(单后端)/ frontend-testing(单前端)/ fullstack-slice-testing(局部前后端)。
局部前后端接缝测试执行器(stack-agnostic / project-agnostic)。当一个 feature 的前后端两侧都收尾、 需要把"单前端阶段拿来 mock 的那份假设"与"单后端的真实行为"做一次对账时使用:在**单 feature 内**, 让消费者侧(前端/调用方)↔ 提供者侧(后端/被调方)的**单条切片**以真实形态对接、停止 mock,验证接缝。 它是 backend-testing / frontend-testing 的对账——单前端 mock 撒的谎(字段/类型/状态码/错误体/鉴权/时序) 在这里穿帮。**仅限单 feature 内单切片,不跨 feature**(跨多 feature 旅程属"完整功能链路"第四格)。覆盖四个 能力缺口——环境编排(让两侧+依赖以真实形态可复现一键起来)、契约真实性(消费者 mock↔提供者规格比对)、 接缝粘合(凭证透传/序列化往返/错误映射/头部跨域)、真实时序(条件命中:仅切片含流式/实时/异步才测)。 与前两格的根本区别——新难点是"起真栈(环境编排)"而非写断言:前两格能把另一侧 mock 掉,这格不能, 必须真把两侧拉活。先读两侧栈清单按栈实例化编排/契约工具,再 RED→GREEN 补接缝断言并固化为回归。 触发词:局部前后端测试 / 前后端接缝测试 / 切片对账 / 真前后端对接 / 起真栈集成 / 契约漂移验证 / 消费者契约对账 / fullstack slice testing / seam testing / contract drift / 前后端集成补测。 遵循 testing-system-blueprint 蓝本(风险分级 / 可追溯 / 发布门 / 三层节奏),受自愈护栏约束(只写测试不改 产品码、断言不可弱化、禁伪造修复、有界重试、产 PR 人审)。被 test-routing-advisor 判定"局部前后端"时调用, 也可直接触发。兄弟:backend-testing(单后端)/ frontend-testing(单前端)。
测试路由顾问:在某个 feature 的所有 task 完成(全绿)、进入收尾阶段时,先通篇扫描该 feature 的所有 task/文件,把它们归入一个「开放可增减」的场景类别集合(单后端 / 单前端 / 局部前后端 / 完整功能链路 / 可增类…),判定本 feature 整体属于哪一类,再把每个测试缺口 「路由到对应类别的执行器 skill」去闭环补测。它是 stack-agnostic 的检测器 / 路由器: 本 skill 只做「判类 + 标缺口 + 路由」,不写死任何单栈工具为答案——具体工具由被路由到的 类别 skill 按栈(读 package.json / pyproject / go.mod 等判栈后)实例化。当前路由去向: 单后端 → `backend-testing` skill;单前端 → `frontend-testing` skill;局部前后端 → `fullstack-slice-testing` skill;完整功能链路 → `full-chain-testing` skill(gstack `/qa` 折叠进它的 UI 可走段,非依赖)。判类、缺口标注、 三层节奏、可追溯、发布门等方法标准统一遵循 `testing-system-blueprint` skill。判类信号来自 任务范围标签、依赖图、跨模块契约声明、验收标准 AC,因此与具体项目无关。它的杀手锏:从依赖图 推导出「完成本 feature 后某条完整功能链路(A→B→C)首次贯通」并主动提示「这条链路现在可以 端到端测了」——这是人最容易忘的事。 当某个 feature 正在收尾、用户说出类似「这个 feature 该测什么 / 收尾测试 / 测试路由 / feature 完成后测什么 / 该用什么测试 / run test routing / what should I test now / which testing tool should I use / what tests does this feature need」时务必使用。 它只做建议与路由——绝不编写、运行或强制任何测试;测试是否真的写了、过了、断言有没有被弱化, 靠确定性的 CI 闸和护栏化自愈 agent 来保证。
测试体系蓝本(testing blueprint / test strategy)——一份 stack-agnostic、project-agnostic 的"测试作为体系"方法骨架。当需要确定测试策略、做风险分级(P0–P3)、建立需求↔测试可追溯、 规划三层测试节奏、设计闭环补测、定义发布 go/no-go 门(release gate)时遵循本蓝本。 触发词:测试体系蓝本、测试策略、测试策略蓝本、风险分级、可追溯、需求追溯、发布门、 闭环补测、testing blueprint、test strategy、test pyramid、release gate。 它被 test-routing-advisor(路由器)和各类别测试 skill(如 backend-testing)共同遵循。 本蓝本只给"方法与标准",不写死任何语言/框架/工具,不执行测试也不强制门禁—— 能力是通用原语,工具由调用方读项目栈后实例化;门禁的强制由 CI/hook/pre-commit 承担。
| name | add-atomic-chat-tool |
| description | Add Atomic Chat MCP server so the container agent can call local models served by the Atomic Chat desktop app via its OpenAI-compatible API. |
This skill adds a stdio-based MCP server that exposes models running in the local Atomic Chat desktop app as tools for the container agent. Claude remains the orchestrator but can offload work to local models served by Atomic Chat on http://127.0.0.1:1337/v1 (OpenAI-compatible).
Tools exposed:
atomic_chat_list_models — list models currently available in Atomic Chat (GET /v1/models)atomic_chat_generate — send a prompt to a specified model and return the response (POST /v1/chat/completions)Model management (download, delete) is done through the Atomic Chat desktop UI — the app is a fork of Jan and manages its own model library.
The skill ships the MCP server source in this folder and copies it into the agent-runner tree at install time, then wires it up with small edits to index.ts, providers/claude.ts, and container-runner.ts. No branch merge — all edits are additive and idempotent.
Check if container/agent-runner/src/atomic-chat-mcp-stdio.ts exists. If it does, skip to Phase 3 (Configure).
Verify Atomic Chat is installed and its local API server is running. On the host:
curl -s http://127.0.0.1:1337/v1/models | head
If the request fails:
atomic-chat.dmg).1337.cp .claude/skills/add-atomic-chat-tool/atomic-chat-mcp-stdio.ts container/agent-runner/src/atomic-chat-mcp-stdio.ts
Edit container/agent-runner/src/index.ts. Find the mcpServers object that currently looks like this:
const mcpServers: Record<string, { command: string; args: string[]; env: Record<string, string> }> = {
nanoclaw: {
command: 'bun',
args: ['run', mcpServerPath],
env: {},
},
};
Add an atomic_chat entry alongside nanoclaw:
const mcpServers: Record<string, { command: string; args: string[]; env: Record<string, string> }> = {
nanoclaw: {
command: 'bun',
args: ['run', mcpServerPath],
env: {},
},
atomic_chat: {
command: 'bun',
args: ['run', path.join(__dirname, 'atomic-chat-mcp-stdio.ts')],
env: {
...(process.env.ATOMIC_CHAT_HOST ? { ATOMIC_CHAT_HOST: process.env.ATOMIC_CHAT_HOST } : {}),
...(process.env.ATOMIC_CHAT_API_KEY ? { ATOMIC_CHAT_API_KEY: process.env.ATOMIC_CHAT_API_KEY } : {}),
},
},
};
Edit container/agent-runner/src/providers/claude.ts. Find 'mcp__nanoclaw__*', in the TOOL_ALLOWLIST array and add 'mcp__atomic_chat__*', on the following line:
'mcp__nanoclaw__*',
'mcp__atomic_chat__*',
];
Edit src/container-runner.ts in buildContainerArgs. Find the TZ env line:
args.push('-e', `TZ=${TIMEZONE}`);
Add ATOMIC_CHAT forwarding right after it:
args.push('-e', `TZ=${TIMEZONE}`);
// Atomic Chat MCP tool: forward host overrides if set (default is host.docker.internal:1337).
if (process.env.ATOMIC_CHAT_HOST) {
args.push('-e', `ATOMIC_CHAT_HOST=${process.env.ATOMIC_CHAT_HOST}`);
}
if (process.env.ATOMIC_CHAT_API_KEY) {
args.push('-e', `ATOMIC_CHAT_API_KEY=${process.env.ATOMIC_CHAT_API_KEY}`);
}
[ATOMIC] log lines at info levelIn the same file, find the stderr logger:
container.stderr?.on('data', (data) => {
for (const line of data.toString().trim().split('\n')) {
if (line) log.debug(line, { container: agentGroup.folder });
}
});
Replace it with:
container.stderr?.on('data', (data) => {
for (const line of data.toString().trim().split('\n')) {
if (!line) continue;
if (line.includes('[ATOMIC]')) {
log.info(line, { container: agentGroup.folder });
} else {
log.debug(line, { container: agentGroup.folder });
}
}
});
.env.exampleAppend to .env.example:
# Atomic Chat MCP tool (.claude/skills/add-atomic-chat-tool)
# Override the host where Atomic Chat exposes its OpenAI-compatible API.
# Default: http://host.docker.internal:1337 (with fallback to localhost)
# ATOMIC_CHAT_HOST=http://host.docker.internal:1337
# Optional API key. Leave unset for a local Atomic Chat install — it does not require auth.
# ATOMIC_CHAT_API_KEY=
pnpm run build
pnpm exec tsc -p container/agent-runner/tsconfig.json --noEmit
./container/build.sh
All three must be clean before proceeding.
By default, the MCP server connects to http://host.docker.internal:1337 (Docker Desktop) with a fallback to localhost. To use a custom host, add to .env:
ATOMIC_CHAT_HOST=http://your-atomic-chat-host:1337
Atomic Chat does not require authentication when running locally — leave this unset. Only set it if you've put Atomic Chat behind a reverse proxy that enforces auth:
ATOMIC_CHAT_API_KEY=sk-...
launchctl kickstart -k gui/$(id -u)/com.nanoclaw # macOS
# Linux: systemctl --user restart nanoclaw
Tell the user:
Send a message like: "use atomic chat to tell me the capital of France"
The agent should use
atomic_chat_list_modelsto find available models, thenatomic_chat_generateto get a response.
tail -f logs/nanoclaw.log | grep -i atomic
Look for:
[ATOMIC] Listing models... — list request started[ATOMIC] Found N models — models discovered[ATOMIC] >>> Generating with <model> — generation started[ATOMIC] <<< Done: <model> | Xs | N tokens | M chars — generation completedThe agent is looking for a CLI that doesn't exist instead of using the MCP tools. This means:
container/agent-runner/src/atomic-chat-mcp-stdio.ts existscontainer/agent-runner/src/index.ts has the atomic_chat entry in mcpServerscontainer/agent-runner/src/providers/claude.ts includes mcp__atomic_chat__* in TOOL_ALLOWLIST./container/build.shcurl http://127.0.0.1:1337/v1/modelsdocker run --rm curlimages/curl curl -s http://host.docker.internal:1337/v1/modelsATOMIC_CHAT_HOST in .envmodel not found / 404 on generateThe model ID passed to atomic_chat_generate must exactly match one of the IDs returned by atomic_chat_list_models. Ask the agent to list models first, then pick one from that list.
Atomic Chat lazy-loads models into memory on first use. The initial call may take longer while the model warms up. Subsequent calls against the same model are fast.
The agent may not know about the tools. Try being explicit: "use the atomic_chat_generate tool with llama3.2-3b-instruct to answer: ..."
Atomic Chat respects each model's native context length. If you hit limits, pass max_tokens explicitly when calling atomic_chat_generate, or switch to a model with a larger context window in the Atomic Chat UI.