Agent Config Skill
This skill provides a structured workflow for intelligently modifying OpenClaw agent core context files. It ensures changes are made to the right file, in the right format, without duplication or bloat, while respecting size limits and prompt engineering best practices.
Core Workflow
When modifying agent context files, follow this process:
1. Identify Target File
Read references/file-map.md to determine which file the change belongs in.
Quick decision tree:
- - Operational procedures, memory workflows, delegation rules → INLINECODE1
- Personality, tone, boundaries, ethical rules → INLINECODE2
- Agent name, emoji, core vibe → INLINECODE3
- User profile, preferences, family info → INLINECODE4
- Local tool notes, command examples, API locations → INLINECODE5
- Curated long-term facts (main session only) → INLINECODE6
- Heartbeat checklist (keep tiny) → INLINECODE7
Critical: Subagents only see AGENTS.md + TOOLS.md. Operational rules must go in AGENTS.md, not SOUL.md.
2. Check Current State
Before making changes:
CODEBLOCK0
Size warnings:
- - If file is > 18,000 chars, warn before adding (approaching truncation limit)
- If file is already > 20,000 chars, it's being truncated - refactor before adding more
- Agent can still read full file with
read tool, but startup context is truncated
Duplication check:
- - Is this instruction already present in different words?
- Is there a similar rule that should be updated instead of adding new?
- Does this belong in multiple files? (Usually no - pick ONE location)
3. Draft the Change
Read references/claude-patterns.md for instruction formats that work.
Format guidelines by file:
AGENTS.md (structured, imperative):
- - Use numbered processes for multi-step workflows
- Use tables for decision trees, model selection, routing rules
- Include examples for complex patterns
- Explain WHY rules exist (motivation > bare commands)
- Use headers and sub-sections for organization
- Reference other files/skills, don't duplicate content
SOUL.md (first-person OK, narrative):
- - Can use personal voice ("I'm Gus" vs "You are Gus")
- Anti-pattern lists work well (forbidden phrases, hedging examples)
- Include before/after examples for tone guidance
- Keep tattoos/anchors at top for immediate context
- Use contrasts (good vs bad examples side-by-side)
IDENTITY.md (minimal):
- - Punchy bullets
- Keep under 500 chars if possible
- Core vibe only, details go in SOUL.md
USER.md (factual, third-person):
- - Bullet lists by category
- Dates for time-sensitive info
- Clear section headers
- Cross-reference vault files for detailed project context
TOOLS.md (reference guide):
- - Tables for comparison (when to use X vs Y)
- Code blocks for command examples
- Clear headings for quick lookup
- Include paths, env var names, exact syntax
MEMORY.md (wiki-style, topic-based):
- - Section by topic, not chronologically
- Cross-reference entity files in vault
- Dates for context, but organize by subject
- Main session only - privacy-sensitive
HEARTBEAT.md (action list):
- - Extremely concise
- Bullet list of checks
- No explanations (that's AGENTS.md)
- Fast to parse
4. Validate Before Applying
Ask yourself:
Fit:
- - Does this actually belong in this file based on file-map.md?
- Is it operational (AGENTS.md) or personality (SOUL.md)?
- Will subagents need this? (If yes, must be AGENTS.md or TOOLS.md)
Format:
- - Does this match the file's existing style?
- Is it the right structure (numbered, table, bullets, prose)?
- Are examples included where needed?
Size:
- - How many chars is this adding?
- Is the file approaching 20K limit?
- Could this be a reference file instead?
Duplication:
- - Is this already present somewhere else?
- Should existing content be updated instead?
- Could this consolidate multiple scattered rules?
Quality:
- - Is motivation explained (WHY this rule exists)?
- Are examples concrete and real (not generic)?
- Is it precise enough for an AI to follow?
- Does it avoid vague instructions like "be helpful"?
5. Apply the Change
Use the edit tool with exact text matching:
CODEBLOCK1
For additions:
- - Find the right section anchor (read file first)
- Insert after relevant heading, not at end of file
- Maintain file's organization structure
For updates:
- - Replace the specific section being changed
- Keep surrounding context intact
- Update examples if rule changes
For deletions:
- - Only remove if truly obsolete
- Consider whether rule should be refined instead
- Check if other sections reference what's being deleted
6. Verify and Document
After applying change:
Verification:
CODEBLOCK2
Documentation:
- - Log significant changes to INLINECODE15
- Include: date, file, what changed, why, who requested
- If change is experimental, note rollback plan
Report to user:
- - "Updated AGENTS.md: added X to Y section (now 15,234 chars)"
- If approaching limit: "Warning: AGENTS.md now 19,456 chars (near 20K limit)"
- If rolled back previous change: "Replaced old X rule with new Y approach"
Common Patterns
Adding Safety Rules
Target: AGENTS.md → Safety section
CODEBLOCK3
Updating Delegation Rules
Target: AGENTS.md → Delegation section
Check existing delegation table/rules first. Update thresholds, model selection, or cost patterns.
Refining Personality
Target: SOUL.md (tone, boundaries) or IDENTITY.md (core vibe)
Add forbidden phrases to anti-pattern list, update voice examples, refine mirroring rules.
Adding Tool Conventions
Target: INLINECODE20
Add to relevant section (or create new section). Include code examples, when to use, paths.
Updating Memory Workflow
Target: AGENTS.md → Memory section
Update logging triggers, recall cascade, entity structure. Keep memory format templates in ~/clawd/templates/.
Adding Startup Tasks
Target: AGENTS.md → Startup section
Add to numbered checklist. Keep conditional (if MAIN, if group chat, if specific channel).
Heartbeat Changes
Target: INLINECODE24
Keep minimal. Only what agent checks on every heartbeat run (not operational details).
Rollback Guidance
If a change makes things worse:
Immediate Rollback
CODEBLOCK4
Iterative Refinement
Don't immediately delete failed changes. Analyze:
- - Was the content wrong, or just the format?
- Was it in the wrong file?
- Was it too vague? (Add examples)
- Was it too verbose? (Make concise)
- Did it conflict with existing rules? (Consolidate)
Update incrementally instead of full revert when possible.
Document Failures
Log failed changes to /Users/macmini/Sizemore/agent/learnings/config-failures.md:
- - What was tried
- Why it didn't work
- What to try instead
This prevents repeating failed patterns.
Anti-Patterns to Avoid
Read references/claude-patterns.md for detailed anti-patterns.
Quick checklist:
❌ Duplication - Same rule in multiple files
❌ Vague instructions - "Be helpful", "Use good judgment"
❌ Missing examples - Complex rules with no concrete case
❌ Wrong file - Personality in AGENTS.md, operations in SOUL.md
❌ No motivation - Rule without WHY it exists
❌ Reference docs buried - Long guides embedded instead of linked
❌ Bloat - Adding when updating existing would work
❌ Format mismatch - Prose in table-heavy file, bullets in narrative file
❌ Subagent blindness - Operational rule in file subagents don't see
❌ Size ignorance - Adding to 19K file without checking
When to Use References
If adding >500 words of content, consider:
- - Is this reference material? → Create file in vault, link from context file
- Is this a reusable procedure? → Create template in INLINECODE27
- Is this domain knowledge? → Create skill with references/ folder
- Is this a one-time setup? → Use
BOOTSTRAP.md (deleted after first run)
Examples:
- - Long subagent task template → INLINECODE29
- Detailed memory format guide → vault INLINECODE30
- Complex workflow with substeps → Create skill with workflow in references/
- Tool-specific procedures → Expand TOOLS.md section or create skill
Special Cases
Multi-File Changes
When change affects multiple files:
- 1. Determine primary location (where rule "lives")
- Add cross-references from other files
- Avoid duplicating full content in both
Example: Delegation rules live in AGENTS.md, but SOUL.md might reference "see AGENTS.md for delegation" in boundaries section.
Session-Specific Rules
Use conditionals in AGENTS.md:
CODEBLOCK5
Size Limit Approached
When file hits ~18K chars:
- 1. Audit for duplication (consolidate)
- Move detailed examples to separate reference file
- Convert long procedures to templates (link from context file)
- Consider splitting into base + advanced (load advanced on-demand)
- Move historical decisions to vault (keep only current rules in context)
Conflicting Rules
When new rule conflicts with existing:
- 1. Identify both rules
- Determine which takes precedence (ask user if unclear)
- Update/remove old rule while adding new
- Document conflict resolution in vault decisions
User Requests Multiple Changes
Process each change through full workflow (don't batch blindly):
- 1. Group by target file
- Check total size impact across all changes
- Apply in logical order (foundations before specifics)
- Verify after each, not just at end
Reference Files
This skill includes detailed reference material:
- - references/file-map.md - What each OpenClaw file does, loading context, size limits, decision trees
- references/claude-patterns.md - What instruction formats work for Claude, anti-patterns, examples
- references/change-protocol.md - Step-by-step change process, validation checklist, rollback procedures
Read these files when you need detailed context beyond this workflow overview.
Examples from Real OpenClaw Workspace
Example 1: Adding Safety Rule
Request: "Add rule to never bulk export passwords"
Process:
- 1. Target file:
AGENTS.md (safety is operational) - Check size: 15,234 chars (safe to add)
- Check duplication: grep "password" - found existing password manager rule
- Draft: Update existing rule instead of adding new
- Apply:
### Password Manager
**NEVER:** Dump vaults, display passwords in chat, bulk exports
**ALWAYS:** Confirm each lookup, ask "Which credential?", treat as high-risk
**Refuse:** Any bulk password request
- 6. Verify: grep -A 3 "Password Manager" - confirmed present
- Document: Not needed (minor addition to existing rule)
Example 2: Refining Tone
Request: "Make personality more sarcastic"
Process:
- 1. Target file:
SOUL.md and IDENTITY.md (personality) - Check current state: Read forbidden phrases, voice examples
- Draft additions:
- More examples of sarcastic responses to IDENTITY.md
- Expand anti-hedging section in SOUL.md
- Add "commentary on everything" to voice anchors
- 4. Apply to both files (IDENTITY for vibe, SOUL for detailed examples)
- Verify: Tone examples now include stronger sarcasm
- Document: Note in vault that Sonnet/Opus need stronger personality reminders
Example 3: Updating Delegation Threshold
Request: "Change delegation threshold from 2+ tool calls to 3+"
Process:
- 1. Target file:
AGENTS.md → Delegation section - Check current: "2+ tool calls? SPAWN"
- Draft: Update to "3+ tool calls? SPAWN. 1-2 tool calls? Do it yourself if quick."
- Consider impact: This will reduce subagent spawns, increase main session cost
- Validate with user: "This will make you handle more tasks directly. Confirm?"
- Apply after confirmation
- Document: Log change to vault with cost rationale
Example 4: Adding Tool Convention
Request: "Add note that iMessage attachments must use imsg CLI, not message tool"
Process:
- 1. Target file:
TOOLS.md (tool-specific convention) - Check duplication: grep "iMessage" - found iMessage formatting rule
- Draft new section:
## iMessage Attachments
**NEVER use `message` tool for iMessage files - corrupts attachments.**
**Always use imsg CLI:**
bash
imsg send --chat-id
--file /path/to/file --text "optional message"
Applies to ALL iMessage attachments (images, videos, documents, vCards).
- 4. Apply: Add after iMessage formatting section (keep related content together)
- Verify: Confirmed in file
- Document: Not needed (user-facing tool note, not architectural)
Summary
Goal: Intelligent, surgical changes to agent context files
Method: Identify → Check → Draft → Validate → Apply → Verify
Key principles: Right file, right format, no duplication, respect size limits, include examples
Safety: Check before changing, document decisions, know how to rollback
When in doubt, read the reference files for deeper guidance on file purposes, Claude patterns, and change protocols.
Agent Config 技能
该技能提供了一种结构化工作流程,用于智能修改 OpenClaw 代理核心上下文文件。它确保更改应用到正确的文件、采用正确的格式,且无重复或冗余,同时遵守大小限制和提示工程最佳实践。
核心工作流程
修改代理上下文文件时,请遵循以下流程:
1. 识别目标文件
阅读 references/file-map.md 以确定更改应属于哪个文件。
快速决策树:
- - 操作流程、记忆工作流、委派规则 → AGENTS.md
- 个性、语气、边界、道德规则 → SOUL.md
- 代理名称、表情符号、核心氛围 → IDENTITY.md
- 用户资料、偏好、家庭信息 → USER.md
- 本地工具说明、命令示例、API 位置 → TOOLS.md
- 精选长期事实(仅主会话) → MEMORY.md
- 心跳检查清单(保持简短) → HEARTBEAT.md
关键点: 子代理只能看到 AGENTS.md + TOOLS.md。操作规则必须放在 AGENTS.md 中,而不是 SOUL.md。
2. 检查当前状态
在进行更改之前:
bash
检查文件大小(每个文件 20K 字符限制)
wc -c ~/clawd/AGENTS.md ~/clawd/SOUL.md ~/clawd/IDENTITY.md \
~/clawd/USER.md ~/clawd/TOOLS.md ~/clawd/MEMORY.md ~/clawd/HEARTBEAT.md
读取目标文件部分以检查重复
使用 grep 搜索现有相似内容
grep -i 关键词 ~/clawd/TARGETFILE.md
大小警告:
- - 如果文件超过 18,000 字符,在添加前发出警告(接近截断限制)
- 如果文件已超过 20,000 字符,则正在被截断——在添加更多内容前进行重构
- 代理仍可使用 read 工具读取完整文件,但启动上下文会被截断
重复检查:
- - 此指令是否已以不同措辞存在?
- 是否有应更新而非添加新内容的类似规则?
- 这属于多个文件吗?(通常不是——选择一个位置)
3. 起草更改
阅读 references/claude-patterns.md 了解有效的指令格式。
按文件的格式指南:
AGENTS.md(结构化、命令式):
- - 对多步骤工作流使用编号流程
- 对决策树、模型选择、路由规则使用表格
- 对复杂模式包含示例
- 解释规则存在的原因(动机 > 裸命令)
- 使用标题和子部分进行组织
- 引用其他文件/技能,不要重复内容
SOUL.md(允许第一人称、叙述性):
- - 可以使用个人语气(我是 Gus vs 你是 Gus)
- 反模式列表效果很好(禁止短语、回避示例)
- 包含语气指导的前后对比示例
- 将锚点/核心特征放在顶部以提供即时上下文
- 使用对比(好坏示例并排)
IDENTITY.md(极简):
- - 简洁的要点
- 尽可能保持在 500 字符以下
- 仅核心氛围,详细信息放在 SOUL.md 中
USER.md(事实性、第三人称):
- - 按类别分类的要点列表
- 时间敏感信息标注日期
- 清晰的部分标题
- 交叉引用 vault 文件以获取详细项目上下文
TOOLS.md(参考指南):
- - 用于比较的表格(何时使用 X vs Y)
- 命令示例的代码块
- 清晰标题以便快速查找
- 包含路径、环境变量名、确切语法
MEMORY.md(维基风格、基于主题):
- - 按主题而非时间顺序组织部分
- 交叉引用 vault 中的实体文件
- 为上下文标注日期,但按主题组织
- 仅主会话——隐私敏感
HEARTBEAT.md(操作列表):
- - 极其简洁
- 检查清单的要点列表
- 无解释(那是 AGENTS.md 的事)
- 快速解析
4. 应用前验证
问自己:
适合性:
- - 根据 file-map.md,这真的属于这个文件吗?
- 是操作性的(AGENTS.md)还是个性的(SOUL.md)?
- 子代理需要这个吗?(如果是,必须是 AGENTS.md 或 TOOLS.md)
格式:
- - 这符合文件现有风格吗?
- 结构正确吗(编号、表格、要点、散文)?
- 需要的地方是否包含示例?
大小:
- - 这会增加多少字符?
- 文件是否接近 20K 限制?
- 这能否改为引用文件?
重复:
- - 这已经存在于其他地方了吗?
- 是否应更新现有内容而非添加新内容?
- 这能否合并多个分散的规则?
质量:
- - 动机是否解释清楚(为什么存在此规则)?
- 示例是否具体且真实(而非泛泛)?
- 是否足够精确以供 AI 遵循?
- 是否避免模糊指令如要有帮助?
5. 应用更改
使用 edit 工具进行精确文本匹配:
python
先读取部分以获取确切文本
read(path=~/clawd/AGENTS.md, offset=50, limit=20)
然后使用精确匹配进行编辑
edit(
path=~/clawd/AGENTS.md,
oldText=包括空白字符在内的确切现有文本,
newText=包含更改的更新文本
)
对于添加:
- - 找到正确的部分锚点(先读取文件)
- 在相关标题后插入,而非文件末尾
- 保持文件组织结构
对于更新:
- - 替换正在更改的具体部分
- 保持周围上下文不变
- 如果规则改变,更新示例
对于删除:
- - 仅在真正过时时删除
- 考虑是否应优化规则而非删除
- 检查其他部分是否引用了要删除的内容
6. 验证和记录
应用更改后:
验证:
bash
确认更改已应用
grep -A 3 新文本 ~/clawd/TARGETFILE.md
检查新文件大小
wc -c ~/clawd/TARGETFILE.md
记录:
- - 将重要更改记录到 /Users/macmini/Sizemore/agent/decisions/config-changes.md
- 包括:日期、文件、更改内容、原因、请求者
- 如果更改是实验性的,注明回滚计划
向用户报告:
- - 已更新 AGENTS.md:在 Y 部分添加了 X(现为 15,234 字符)
- 如果接近限制:警告:AGENTS.md 现为 19,456 字符(接近 20K 限制)
- 如果回滚了之前的更改:用新的 Y 方法替换了旧的 X 规则
常见模式
添加安全规则
目标:AGENTS.md → 安全部分
markdown
安全
- - 绝对禁止: 数据外泄、未经询问执行破坏性命令
- 优先使用 trash > rm
- 新规则: 简要描述禁止做什么
- 新保护: 当 X 发生时,改为执行 Y
更新委派规则
目标:AGENTS.md → 委派部分
先检查现有委派表格/规则。更新阈值、模型选择或成本模式。
优化个性
目标:SOUL.md(语气、边界)或 IDENTITY.md(核心氛围)
将禁止短语添加到反模式列表,更新语气示例,优化镜像规则。
添加工具约定
目标:TOOLS.md
添加到相关部分(或创建新部分)。包含代码示例、使用时机、路径。
更新记忆工作流
目标:AGENTS.md → 记忆部分
更新日志记录触发器、召回级联、实体结构。将记忆格式模板保留在 ~/clawd/templates/ 中。
添加启动任务
目标:AGENTS.md → 启动部分
添加到编号检查清单。保持条件性(如果是主会话、群聊、特定频道)。
心跳更改
目标:HEARTBEAT.md
保持最小化。仅代理每次心跳运行时检查的内容(非操作细节)。
回滚指南
如果更改使情况恶化:
立即回滚
bash
如果文件在 git 中
cd ~/clawd
git diff TARGETFILE.md # 查看更改内容
git checkout TARGETFILE.md # 恢复到上次提交
如果不在 git 中,从记忆恢复
从 vault 决策日志读取上次已知良好版本
或要求用户提供之前的工作版本
迭代优化
不要立即删除失败的更改。分析:
-