rule-creation Skill
Description
Auto-triggers Context Engineering compliance and Lobster enforcement evaluation when proposing, creating, or formalizing new rules, policies, processes, workflows, or behavioral constraints.
Context Engineering is the practice of wiring rules into your AI's context so they're reliably followed — not just hoped for via prompting. Credit: Muratcan Koylan (@koylanai)
Use this skill any time you are:
- - Declaring a new rule (e.g. "From now on, always X")
- Formalizing a policy (e.g. "The policy for Y is Z")
- Creating a behavioral constraint (e.g. "Never do X without doing Y first")
- Proposing a process or workflow
- Updating governance documents (TOOLS.md, CRITICAL-RULES.md, CONSTITUTION.md, etc.)
When This Skill Matches
Trigger phrases:
- - "Add this rule…"
- "Create a policy…"
- "From now on…"
- "The rule is…"
- "New constraint…"
- "Formalize that…"
- "Wire this rule…"
- "Make it a HARD rule…"
- Any governance/policy update request
Mandatory Workflow
When this skill triggers, always execute the following steps in order. Do NOT ask permission — CE-PROCESS compliance means wire first, report after.
Step 1: Identify the Rule
Extract:
- - Rule name — short slug (e.g.
no-bare-spawns, external-message-gate) - Rule description — plain language statement of what the rule requires
- Rule type —
HARD (non-negotiable, always enforced) or soft (guideline, use judgment)
Step 2: Evaluate Enforcement Need (CR-012 Criteria)
Run scripts/evaluate-enforcement-need.js or apply manually:
A rule needs Lobster enforcement if ANY of the following are true:
| Criterion | Examples |
|---|
| High-stakes | Sends external messages, spends money, deletes data, publishes public content, deploys to production |
| Pattern of violations |
A similar rule was already stated but broken or ignored |
|
Multi-step sequence | Requires multiple ordered steps (do A, then B, then C) |
|
External / public action | Affects things outside the user's local files |
Scoring:
- - 0 criteria matched →
needsEnforcement: false (wire to TOOLS.md only) - 1+ criteria matched →
needsEnforcement: true (create Lobster workflow + wire)
Step 3: Lobster Availability Preflight
Before creating any workflow, verify Lobster is actually enabled:
Run scripts/check-lobster-available.js or check manually:
openclaw plugins list | grep -i lobster
| Output | Meaning | Action |
|---|
| INLINECODE8 | ✅ Available | Proceed to Step 3a |
| INLINECODE9 |
❌ Unavailable | Use fallback (below) |
| No lobster row | ❌ Not installed | Use fallback (below) |
Fallback when Lobster is unavailable:
- - Skip workflow creation entirely
- Proceed directly to Step 4 (wire to docs) — no Lobster reference in the entry
- Report: INLINECODE10
- Include hint:
Run: openclaw plugins enable lobster to activate
Never claim enforcement is wired when Lobster is disabled.
Step 3a: Create Lobster Workflow (enforcement needed AND Lobster available)
If needsEnforcement: true and Lobster preflight passed:
- 1. Copy INLINECODE13
- Fill in:
name, description, steps specific to rule enforcement - Save to INLINECODE16
- Note the workflow path for wiring
Step 4: Wire to Docs
Run scripts/wire-rule-to-docs.js or manually append to the appropriate file:
Routing:
- - Operational rules → INLINECODE18
- Identity/persona constraints →
SOUL.md or INLINECODE20 - Hard system rules →
CRITICAL-RULES.md (if exists) or INLINECODE22 - Project-specific rules → relevant project board or INLINECODE23
Entry format (from templates/tools-md-entry.template.md):
CODEBLOCK1
Step 5: Report What Was Done
Your response must include:
CODEBLOCK2
Never say:
- - ❌ "Want me to add this to TOOLS.md?"
- ❌ "Should I wire this through CE?"
- ❌ "Is this CE compliant?"
Always say:
- - ✅ "Added
<rule> to <file>. Enforcement: <status>."
Script Reference
| Script | Purpose |
|---|
| INLINECODE28 | Preflight: verify Lobster plugin is enabled in this OpenClaw instance |
| INLINECODE29 |
Evaluate CR-012 criteria against rule description |
|
scripts/wire-rule-to-docs.js | Append rule entry to TOOLS.md or specified target file |
|
scripts/report-rule-creation.js | Generate user-facing summary of what was created |
Workflow Reference
| Workflow | Purpose |
|---|
| INLINECODE32 | Full end-to-end rule creation pipeline |
Context Engineering Auto-Trigger (HARD)
This skill embodies the Context Engineering Auto-Trigger principle:
"When proposing any new rule, behavioral constraint, or policy change: Wire it first. Add the rule to the appropriate file BEFORE responding. Never ask permission to formalize a rule."
The act of recognizing a rule IS the trigger. Wire immediately. Report after.
rule-creation 技能
描述
在提议、创建或正式制定新规则、政策、流程、工作流或行为约束时,自动触发上下文工程合规性与Lobster执行评估。
上下文工程是将规则嵌入AI上下文的实践,以确保规则被可靠遵循——而非仅通过提示期望其生效。致谢:Muratcan Koylan (@koylanai)
在以下任何情况下使用此技能:
- - 声明新规则(例如:从现在起,始终执行X)
- 正式制定政策(例如:Y的政策是Z)
- 创建行为约束(例如:未经Y不得执行X)
- 提议流程或工作流
- 更新治理文档(TOOLS.md、CRITICAL-RULES.md、CONSTITUTION.md等)
此技能匹配时
触发短语:
- - 添加此规则……
- 创建政策……
- 从现在起……
- 规则是……
- 新约束……
- 正式制定……
- 嵌入此规则……
- 设为硬性规则……
- 任何治理/政策更新请求
强制工作流
当此技能触发时,始终按顺序执行以下步骤。无需请求许可——CE-PROCESS合规意味着先嵌入,后报告。
步骤1:识别规则
提取:
- - 规则名称——简短标识(例如:no-bare-spawns、external-message-gate)
- 规则描述——用通俗语言说明规则要求
- 规则类型——HARD(不可协商,始终强制执行)或soft(指导原则,酌情使用)
步骤2:评估执行需求(CR-012标准)
运行scripts/evaluate-enforcement-need.js或手动应用:
如果满足任意以下条件,规则需要Lobster执行:
| 标准 | 示例 |
|---|
| 高风险 | 发送外部消息、花费资金、删除数据、发布公开内容、部署至生产环境 |
| 违规模式 |
类似规则已被声明但被违反或忽略 |
|
多步骤序列 | 需要多个有序步骤(先做A,再做B,最后做C) |
|
外部/公开操作 | 影响用户本地文件之外的内容 |
评分:
- - 0个标准匹配 → needsEnforcement: false(仅嵌入至TOOLS.md)
- 1个及以上标准匹配 → needsEnforcement: true(创建Lobster工作流并嵌入)
步骤3:Lobster可用性预检
在创建任何工作流之前,验证Lobster是否已启用:
运行scripts/check-lobster-available.js或手动检查:
bash
openclaw plugins list | grep -i lobster
| 输出 | 含义 | 操作 |
|---|
| lobster … loaded | ✅ 可用 | 继续步骤3a |
| lobster … disabled |
❌ 不可用 | 使用备用方案(如下) |
| 无lobster行 | ❌ 未安装 | 使用备用方案(如下) |
Lobster不可用时的备用方案:
- - 完全跳过工作流创建
- 直接进入步骤4(嵌入文档)——条目中不包含Lobster引用
- 报告:⚠️ 执行:不可用(Lobster未启用)
- 包含提示:运行:openclaw plugins enable lobster以激活
切勿在Lobster禁用时声称已嵌入执行机制。
步骤3a:创建Lobster工作流(需要执行且Lobster可用)
如果needsEnforcement: true且Lobster预检通过:
- 1. 复制templates/lobster-workflow.template.lobster
- 填写:name、description、特定于规则执行的步骤
- 保存至workflows/.lobster
- 记录工作流路径以供嵌入
步骤4:嵌入文档
运行scripts/wire-rule-to-docs.js或手动追加至相应文件:
路由:
- - 操作规则 → TOOLS.md
- 身份/角色约束 → SOUL.md或agents/identity.md
- 硬性系统规则 → CRITICAL-RULES.md(若存在)或AGENTS.md
- 项目特定规则 → 相关项目面板或agents/projects.md
条目格式(来自templates/tools-md-entry.template.md):
<规则名称>()
<规则描述>
[若启用Lobster执行]:由以下执行: workflows/.lobster
步骤5:报告已完成操作
你的响应必须包含:
✅ 规则已嵌入:<规则名称>
📄 位置:<添加至的文件>
🔒 执行:
📋 类型:
切勿说:
- - ❌ 要我将其添加至TOOLS.md吗?
- ❌ 我是否应通过CE嵌入此规则?
- ❌ 这符合CE要求吗?
始终说:
- - ✅ 已将<规则>添加至<文件>。执行状态:<状态>。
脚本参考
| 脚本 | 用途 |
|---|
| scripts/check-lobster-available.js | 预检:验证此OpenClaw实例中Lobster插件已启用 |
| scripts/evaluate-enforcement-need.js |
根据规则描述评估CR-012标准 |
| scripts/wire-rule-to-docs.js | 将规则条目追加至TOOLS.md或指定目标文件 |
| scripts/report-rule-creation.js | 生成面向用户的创建内容摘要 |
工作流参考
| 工作流 | 用途 |
|---|
| workflows/create-rule.lobster | 完整的端到端规则创建流程 |
上下文工程自动触发(HARD)
此技能体现了上下文工程自动触发原则:
在提议任何新规则、行为约束或政策变更时:先嵌入。在回复之前将规则添加至相应文件。切勿请求许可来正式制定规则。
识别规则的行为本身就是触发器。立即嵌入。事后报告。