Coding Lead
This is a coding execution skill for any agent that owns implementation work.
It defines how coding work runs, not who should own the task.
In multi-agent teams, routing may be handled elsewhere; in single-agent use, this skill still works directly.
Route by complexity. Current production path is claude-only. Do not depend on ACP session persistence in IM threads; use direct execution, direct acpx, and existing implementation session continuity instead.
Task Classification
| Level | Criteria | Action |
|---|
| Simple | Single file, <60 lines, clear local scope | Direct: read/write/edit/exec |
| Medium |
2-5 files, clear scope, likely follow-up questions | Prefer Claude ACP
mode:"run" or direct acpx → fallback direct |
|
Complex | Multi-module, architecture, needs continuity | Use existing implementation session continuity + context files + direct acpx/direct execution |
When in doubt, go one level up.
Practical default rule
- - Simple: stay in the current session; do not open ACP unless clearly beneficial
- Medium: prefer Claude ACP one-shot (
run) when available; otherwise direct acpx - Complex: preserve continuity through the existing implementation session, on-disk context files, and serial follow-ups; do not make IM-bound ACP
session the default path - ACP unavailable: medium/complex fall back to direct acpx or direct execution; simple tasks were already direct by default
- Never block on ACP availability: ACP is an accelerator, not a hard dependency
Multi-agent dispatch rule (when dispatching to other agents)
- - Dispatch to ACP-configured agents (agents with
runtime.type: "acp" in openclaw.json): use sessions_spawn(runtime="acp"), may include INLINECODE5 - Dispatch to standard agents (all others): use
sessions_spawn(runtime="subagent"), never include streamTo - Results from subagent spawns arrive via auto-announce, not polling
- How to tell which is which: check the target agent's config in openclaw.json — if it has
runtime.type: "acp", use ACP; otherwise use subagent
Tech Stack (New Projects)
| Layer | Preferred | Fallback |
|---|
| Backend | PHP (Laravel/ThinkPHP) | Python |
| Frontend |
Vue.js | React |
| Mobile | Flutter | UniApp-X |
| CSS | Tailwind | - |
| DB | MySQL | PostgreSQL |
Existing projects: follow current stack. New: propose first, wait for confirmation.
Tool Detection & Fallback
All tools are optional. Detect once per session:
| Tool | Check | Fallback |
|---|
| smart-agent-memory | INLINECODE9 ok? | INLINECODE10 + manual .md writes |
| qmd |
qmd --version ok? |
grep (Linux/macOS) /
Select-String (Windows) /
find |
|
ACP | See ACP detection below | Direct read/write/edit/exec |
Notation: [memory] [qmd] [acp] = use if available, fallback if not.
ACP Detection & Routing
Run once per session, stop at first success:
Step 1: Try sessions_spawn (timeout: 30s)
sessions_spawn(runtime: "acp", agentId: "claude", task: "say hello", mode: "run", runTimeoutSeconds: 30)
Preferred in OpenClaw because it cleanly supports both:
- -
mode: "run" for one-shot coding tasks - INLINECODE21 for persistent long-context coding threads
- Got a reply →
ACP_MODE = "spawn". Done. - Error or no reply within 30s → kill session, go to Step 2.
Step 2: Try acpx CLI (timeout: 30s)
# Detect acpx path (OS-dependent)
# Windows: %APPDATA%\npm\node_modules\openclaw\extensions\acpx\node_modules\.bin\acpx.cmd
# macOS/Linux: $(npm root -g)/openclaw/extensions/acpx/node_modules/.bin/acpx
# Use exec with timeout
acpx claude exec "say hello" # timeout 30s
- - Got a reply →
ACP_MODE = "acpx". Done. - Error, empty output, or stuck beyond 30s → kill process, go to Step 3.
Step 3: No ACP available
ACP_MODE = "direct". Agent executes all coding tasks directly with read/write/edit/exec. Load team standards (see Coding Standards below).
Cache the result
Set a session variable (mental note):
ACP_MODE = "spawn" | "acpx" | "direct"
- - Cache lifetime = current session. Each new session re-detects once. Keep the detection note minimal and refresh it whenever the underlying mode stops working.
- If a cached mode fails mid-session (e.g. acpx suddenly errors), re-run detection from Step 1.
ACP Agent Policy
Current supported ACP coding agent: claude only.
- - Do not route coding work to codex or other future agents in the production path yet.
- If a request merely mentions ACP or coding-agent execution without naming a different approved agent, default detection and execution guidance to Claude.
- If documentation mentions other coding agents, treat them as future possibilities only, not current operating policy.
- Code review can still be done by the coordinating OpenClaw agent, but ACP execution guidance in this skill is claude-only.
Rule Priority
Apply rules in this order:
- 1. Matched skill instructions (this skill wins for coding execution when loaded)
- Agent role fallback only when the coding skill is not loaded or does not cover the case
- Team templates / README / generated docs provide boundaries and ownership, not competing execution logic
If the same topic appears in multiple places, follow the highest-priority source above and simplify the lower-priority wording instead of combining conflicting chains.
Context File Lifecycle
Context files exist to preserve continuity across the current code chain, but they must stay tidy.
- - Store active context files under INLINECODE26
- Use a stable name per task chain: INLINECODE27
- Reuse the same file for the same chain; do not create a new file every turn
- Active context file cap per project: 60
- Context-file lifecycle window per project: 100 total files (active + archive). When approaching the limit, prune stale archived files first, then merge or remove low-value active chains only if truly superseded.
- When a task is completed, either delete the temporary context file or move it under
.openclaw/archive/ if it has durable follow-up value - If a file is stale, ownerless, or superseded by a newer chain, treat it as cleanup/archive candidate
- Before creating a new active context file, check whether an existing file for that chain can be reused
Context Naming
Recommended pattern:
- - INLINECODE29
- task slug should be short, stable, and human-readable
- avoid timestamp-only names for active files unless the task truly has no durable identifier
Coding Standards — Two Layers, No Overlap
Layer 1: Project-level (Claude Code owns)
Projects may have their own
CLAUDE.md,
.cursorrules,
docs/ — these are
Claude Code's responsibility. It reads them automatically.
Do NOT paste project-level rules into ACP prompts.
Layer 2: Team-level (OpenClaw owns)
shared/knowledge/tech-standards.md — cross-project standards (security, change control, tech stack preferences). Only relevant for
direct execution (simple tasks without ACP).
When spawning ACP
- - Don't embed coding standards in the prompt — Claude Code has its own CLAUDE.md
- Do include: task description, acceptance criteria, relevant context (file paths, decisions)
- Do include task-specific constraints if any (e.g., "don't change the API contract")
When executing directly (no ACP)
Load standards once per session, first match wins:
- 1.
shared/knowledge/tech-standards.md (team-level, if exists) - Built-in defaults (below, if nothing exists)
Built-in Defaults (fallback for direct execution)
- - KISS + SOLID + DRY, research before modifying
- Methods <200 lines, follow existing architecture
- No hardcoded secrets, minimal change scope, clear commits
- DB changes via SQL scripts, new tech requires confirmation
Simple Tasks
- 1. Read target file(s) (standards already loaded per above)
- [memory] Recall related decisions
- Execute with read/write/edit/exec
- [memory] Record what changed and why
Medium/Complex Tasks
Step 1: Build Context File
Write to <project>/.openclaw/context-<task-id>.md (ACP reads from disk, not from prompt):
CODEBLOCK2
Minimal context file structure:
CODEBLOCK3
Full template with examples → see references/prompt-templates.md
Step 2: Lean Prompt
Use the smallest prompt that still preserves correctness. Start with the task and acceptance criteria. Add only the minimum extra header needed for the run to be unambiguous.
CODEBLOCK4
Step 3: Spawn (use detected ACP_MODE)
CODEBLOCK5
run vs sustained execution
- - run: one-shot, bounded Claude ACP coding task
- sustained execution: for repeated follow-up on the same code chain, keep working in the existing implementation conversation/session and persist context on disk; do not rely on IM-bound ACP thread/session support
- direct fallback: when ACP is unavailable or unstable, execute directly with read/write/edit/exec instead of stalling
Step 4: Fallback Detection
| Condition | Action |
|---|
| Spawn failed / timeout | → Direct execution |
| Empty output / no file changes |
→ Direct execution |
| Partial completion | → Agent fixes remaining |
Fallback: [memory] log failure → agent executes directly → report to user.
Never silently fail. Always complete or report why not.
Step 5: Verify & Record
- 1. Check acceptance criteria + run tests
- Verify the final result against the task, acceptance criteria, and any explicit no-go constraints before declaring done
- [memory] Record: what changed, decisions, lessons; only promote durable facts to long-term memory
- Clean up context file
Complex Tasks
Read references/complex-tasks.md only for Complex-level tasks — roles, QA isolation, parallel strategies, RESEARCH→PLAN→EXECUTE→REVIEW flow.
Context Reuse (Token Savings)
- - Context file on disk instead of prompt embedding → major token savings per spawn
- Simple tasks stay direct: don't pay ACP/session overhead for tiny edits
- Medium tasks use
run: cheaper than opening a persistent session - Complex tasks use sustained session continuity: preserve continuity through the existing implementation session plus context files
- Serial follow-ups: continue in the same implementation conversation and refresh the on-disk context file as the task evolves
- [qmd]: precision search → only relevant snippets in context file
- No standards in ACP prompts: Claude Code reads its own CLAUDE.md/.cursorrules — don't duplicate
- ACP prompt stays lean: task + acceptance criteria + context file path. No generic rules
- Direct execution: load team standards once per session, not per task
Memory Integration
[memory] Before: recall related work + lessons for context file.
[memory] After: record what changed, decisions made, lessons learned.
Cross-session: agent remembers across sessions; Claude Code doesn't. This is the core advantage.
Parallel Execution Boundaries
Parallelism is allowed in the current production path, but only with explicit boundaries.
- - Hard cap: 5 concurrent work units total
- Active context files per project must stay <= 60
- Total context files per project should stay <= 100 across active + archive
- Define boundaries first: by project, by module, by task stage, or by owner
- Never let two work units modify the same code chain, same file cluster, or same acceptance scope
- Parallel work must have a merge owner and an acceptance owner before execution starts
- If boundaries are fuzzy, collapse back to sequential execution
Recommended shape:
- - 1 coordinating implementation session
- up to 4 additional bounded work units (Claude ACP
run, direct acpx, or direct execution)
Good parallel cases:
- - independent products
- different modules with separate files and acceptance criteria
- one bounded Claude ACP
run while direct tasks proceed elsewhere
Bad parallel cases:
- - same bug chain
- same module with shared intermediate state
- duplicate research on the same problem
- implementation and delivery work both editing the same area
See references/prompt-templates.md for multi-project examples.
Smart Retry (max 3)
- 1. Analyze failure → 2. Adjust prompt → 3. Retry improved → 4. Max 3 then fallback/report.
Each retry must be meaningfully different.
Progress Updates
Start → 1 short message. Error → immediate report. Completion → summary. Fallback → explain.
Safety
- - Never spawn in ~/.openclaw/ — coding agents may damage config
- Always inspect and confirm the intended working directory before spawning or writing; then set
cwd explicitly to the project directory - Review before commit — especially complex tasks
- Kill runaway sessions — timeout or nonsensical output
See Also
编码主导
这是一个适用于任何负责实现工作的智能体的编码执行技能。
它定义了编码工作的运行方式,而非谁应负责该任务。
在多智能体团队中,路由可能由其他模块处理;在单智能体使用场景中,此技能仍可直接生效。
按复杂度路由。当前生产路径仅限Claude。不要在IM线程中依赖ACP会话持久性;应使用直接执行、直接acpx以及现有的实现会话连续性。
任务分类
| 级别 | 标准 | 操作 |
|---|
| 简单 | 单个文件,<60行,明确的局部范围 | 直接:读/写/编辑/执行 |
| 中等 |
2-5个文件,范围明确,可能有后续问题 | 优先使用Claude ACP mode:run 或直接acpx → 回退至直接执行 |
|
复杂 | 多模块、架构问题、需要连续性 | 使用现有实现会话连续性 + 上下文文件 + 直接acpx/直接执行 |
如有疑问,提升一个级别。
实用默认规则
- - 简单:留在当前会话;除非明显有益,否则不打开ACP
- 中等:优先使用Claude ACP一次性执行(run)(可用时);否则直接acpx
- 复杂:通过现有实现会话、磁盘上下文文件和串行后续操作保持连续性;不要将IM绑定的ACP session设为默认路径
- ACP不可用:中等/复杂任务回退至直接acpx或直接执行;简单任务默认已为直接执行
- 切勿因ACP可用性而阻塞:ACP是加速器,而非硬性依赖
多智能体调度规则(当调度至其他智能体时)
- - 调度至配置了ACP的智能体(在openclaw.json中具有runtime.type: acp的智能体):使用sessionsspawn(runtime=acp),可包含streamTo=parent
- 调度至标准智能体(所有其他智能体):使用sessionsspawn(runtime=subagent),切勿包含streamTo
- 子智能体生成的结果通过自动通知到达,而非轮询
- 如何区分:检查目标智能体在openclaw.json中的配置——如果具有runtime.type: acp,则使用ACP;否则使用子智能体
技术栈(新项目)
| 层级 | 首选 | 备选 |
|---|
| 后端 | PHP(Laravel/ThinkPHP) | Python |
| 前端 |
Vue.js | React |
| 移动端 | Flutter | UniApp-X |
| CSS | Tailwind | - |
| 数据库 | MySQL | PostgreSQL |
现有项目:遵循当前技术栈。新项目:先提出方案,等待确认。
工具检测与回退
所有工具均为可选。每个会话检测一次:
| 工具 | 检测方式 | 回退方案 |
|---|
| smart-agent-memory | node ~/.openclaw/skills/smart-agent-memory/scripts/memory-cli.js stats 是否正常? | memory_search + 手动.md写入 |
| qmd |
qmd --version 是否正常? | grep(Linux/macOS)/ Select-String(Windows)/ find |
|
ACP | 参见下方ACP检测 | 直接读/写/编辑/执行 |
标记:[memory] [qmd] [acp] = 可用则使用,不可用则回退。
ACP检测与路由
每个会话运行一次,在首次成功时停止:
步骤1:尝试 sessions_spawn(超时:30秒)
sessions_spawn(runtime: acp, agentId: claude, task: say hello, mode: run, runTimeoutSeconds: 30)
在OpenClaw中首选,因为它干净地支持:
- - mode: run 用于一次性编码任务
- mode: session 用于持久的长上下文编码线程
- 收到回复 → ACP_MODE = spawn。完成。
- 错误或30秒内无回复 → 终止会话,进入步骤2。
步骤2:尝试 acpx CLI(超时:30秒)
bash
检测acpx路径(依赖操作系统)
Windows:%APPDATA%\npm\nodemodules\openclaw\extensions\acpx\nodemodules\.bin\acpx.cmd
macOS/Linux:$(npm root -g)/openclaw/extensions/acpx/node_modules/.bin/acpx
使用带超时的exec
acpx claude exec say hello # 超时30秒
- - 收到回复 → ACP_MODE = acpx。完成。
- 错误、空输出或超过30秒卡住 → 终止进程,进入步骤3。
步骤3:无ACP可用
ACP_MODE = direct。智能体直接使用读/写/编辑/执行处理所有编码任务。加载团队标准(参见下方编码标准)。
缓存结果
设置会话变量(心理记录):ACP_MODE = spawn | acpx | direct
- - 缓存生命周期 = 当前会话。每个新会话重新检测一次。保持检测记录简洁,并在底层模式失效时刷新。
- 如果缓存的模式在会话中失败(例如acpx突然报错),从步骤1重新运行检测。
ACP智能体策略
当前支持的ACP编码智能体:仅限claude。
- - 不要在生产路径中将编码工作路由至codex或其他未来智能体。
- 如果请求仅提及ACP或编码智能体执行而未指定其他已批准的智能体,默认检测和执行指导指向Claude。
- 如果文档提及了其他编码智能体,仅将其视为未来可能性,而非当前操作策略。
- 代码审查仍可由协调的OpenClaw智能体执行,但此技能中的ACP执行指导为仅限claude。
规则优先级
按此顺序应用规则:
- 1. 匹配的技能指令(加载时,此技能在编码执行方面优先)
- 智能体角色回退(仅当编码技能未加载或未覆盖该情况时)
- 团队模板/README/生成的文档提供边界和所有权,而非竞争的执行逻辑
如果同一主题出现在多个位置,遵循上述最高优先级的来源,并简化较低优先级的措辞,而非合并冲突的链条。
上下文文件生命周期
上下文文件的存在是为了在当前代码链中保持连续性,但它们必须保持整洁。
- - 将活动上下文文件存储在 <项目>/.openclaw/ 下
- 每个任务链使用稳定的名称:context-<任务标识>.md
- 同一链重用同一文件;不要每次轮次都创建新文件
- 每个项目的活动上下文文件上限:60
- 每个项目的上下文文件生命周期窗口:总计100个文件(活动+归档)。接近限制时,首先清理过时的归档文件,然后仅合并或移除真正被取代的低价值活动链。
- 任务完成时,删除临时上下文文件,或如果具有持久的后续价值,则移至 .openclaw/archive/ 下
- 如果文件过时、无归属或被更新的链取代,将其视为清理/归档候选
- 在创建新的活动上下文文件前,检查该链的现有文件是否可重用
上下文命名
推荐模式:
- - <项目>/.openclaw/context-<任务标识>.md
- 任务标识应简短、稳定且人类可读
- 除非任务确实没有持久的标识符,否则避免为活动文件使用仅时间戳的名称
编码标准 — 两层,无重叠
第1层:项目级(Claude Code负责)
项目可能有自己的 CLAUDE.md、.cursorrules、docs/ — 这些是
Claude Code的责任。它会自动读取它们。
不要将项目级规则粘贴到ACP提示中。
第2层:团队级(OpenClaw负责)
shared/knowledge/tech-standards.md — 跨项目标准(安全、变更控制、技术栈偏好)。仅与
直接执行相关(无ACP的简单任务)。
生成ACP时
- - 不要在提示中嵌入编码标准 — Claude Code有自己的CLAUDE.md
- 要包含:任务描述、验收标准、相关上下文(文件路径、决策)
- 要包含任务特定的约束(如有)(例如不要更改API契约)
直接执行时(无ACP)
每个会话加载一次标准,首次匹配优先:
- 1. shared/knowledge/tech-standards.md(团队级,如果存在)
- 内置默认值(如下,如果不存在)
内置默认值(直接执行的回退)
- - KISS + SOLID + DRY,修改前先研究
-