Deep dives, series chapters, and project files now share one update stream. Sync batches appear as compact project-file snapshots, so the page keeps its reading rhythm.
A complete walkthrough of triggering multiple Sub-agents via a single prompt to form an automated serial pipeline for parallel multi-task development
From architecture to command-line practice — a comprehensive breakdown of how OpenClaw, Claude Code, and Lark Bot work together
AGENTS.md is the top-level routing rule; Skills are domain execution modules — one handles path-selection, the other handles path-execution
Research on OpenClaw's native Lark integration — a complete migration path from Webhook Bridge to WebSocket long-connection, with full configuration steps
No content yet
The question sounds like a documentation placement issue: should a complex default workflow live in AGENTS.md, or should it become a dedicated skill?
In practice, it is a question about system boundaries.
A default workflow belongs in AGENTS.md because it is routing logic. It decides how the agent should classify a request, which knowledge source to read first, when to ask a question, and when to execute.
A skill is different. A skill is an execution module for a specific domain once the task has already been routed.
In other words:
AGENTS.md decides which path to take.The default workflow runs before any skill is selected.
If the rule says "first decide whether a skill applies," putting that rule inside a skill creates a loop: the agent would need to invoke a skill before it knows whether to invoke a skill.
That is the wrong layer.
The default workflow should sit above all skills because it governs intake, routing, escalation, and execution discipline across every task type.
AGENTS.md is useful for rules that apply broadly:
Those rules are not tied to one domain. They shape the agent's behavior before the domain is known.
Skills are best used for specialized workflows:
Each skill should assume the task has already been classified. Then it can provide detailed steps, scripts, templates, and checks for that domain.
A healthy agent system keeps the layers separate:
AGENTS.md.AGENTS.md files.This separation keeps the agent predictable. It also makes skills easier to reuse because they do not need to carry global operating rules.
If a rule answers "how should the agent decide what to do next?", put it in AGENTS.md.
If a rule answers "how should the agent complete this specific class of task?", put it in a skill.
Core stack: Cursor | Git Worktree | Opus 4.6 & Codex-5.3
Core goal: Use a single prompt to trigger multiple sub-agents into an automated serial workflow, enabling parallel development across multiple tasks.
Current proposal: openspec/changes/redesign-skill-card-vertical
0 TASK 0: Proposal review
openspec-review-specs skill.1 TASK 1: Architect review
neversight-skills_feed-system-architect skill.2 TASK 2: Implementation
/opsx/apply directly to turn the refined proposal into code.3 TASK 3: Code review
git commit to save the initial implementation.4 SubAgent 4: Auto-refinement
5 SubAgent 5: Archiving
/opsx/archive to archive the proposal status.git commit to close the loop for this feature.The current pipeline is highly automated, but the total runtime is still a bit long.
This guide explains how OpenClaw, Claude Code, and a Lark bot can work together as one operating loop.
The goal is not to make one tool do everything. The goal is to let each tool handle the layer it is good at.
| Component | Role | Core capability |
|---|---|---|
| Claude Code | Local coding agent | Reads and edits code, runs shell commands, uses Git, and handles engineering tasks |
| OpenClaw | Local AI gateway and channel hub | Connects Telegram, Lark, Discord, and other channels; dispatches models and tools |
| Lark bot | Collaboration interface | Sends and receives team messages, docs, and operational updates |
The practical workflow is:
The important point is that Claude Code remains local and capable, while OpenClaw handles channel access and routing.
To bind the current chat to Claude Code:
/acp spawn claude --bind hereThis creates a Claude ACP session in the current chat. Messages sent after that can be forwarded directly to Claude Code, and Claude works in the configured local workspace.
For larger tasks, use a persistent thread:
/acp spawn claude --mode persistent --thread autoThis keeps intermediate progress, results, and follow-up context in a dedicated topic instead of polluting the main chat.
For short tasks:
/acp spawn claude --mode oneshotThis is useful for one-off work such as reviewing a pull request, generating a short report, or checking a repository state.
| Command | Purpose |
|---|---|
/acp status |
Check the current ACP binding |
/acp cancel |
Cancel the running task |
/acp close |
Close the session and unbind |
/acp doctor |
Check ACP health |
Claude Code does not directly need to own Lark tools. A clean split is:
This avoids mixing channel permissions into the coding agent.
/acp spawn claude --bind hereWrite a daily engineering update:
- Done: fixed the login bug
- In progress: refactoring the order module
- Blocked: waiting for designOpenClaw uses the configured bot identity to send the message.
Using a bot identity is operationally stable:
Use Claude Code as the local engineering worker.
Use OpenClaw as the gateway and dispatcher.
Use Lark as the collaboration surface.
That split keeps the system composable without forcing one agent to own every integration.
Research date: 2026-03-13
Goal: Run OpenClaw with both Telegram and Lark so the same gateway can receive messages, dispatch agents, and send operational updates across channels.
The current OpenClaw environment already has Telegram running normally. Lark is connected through a webhook bridge rather than the native OpenClaw integration.
| Channel | Status | Notes |
|---|---|---|
| Telegram | Running | Multiple bots are configured, with direct-message and group policies |
| Lark | Webhook bridge | Events are relayed through a local bridge service |
The current path is:
Lark -> Cloudflare Tunnel -> bridge.py -> OpenClaw GatewayThe bridge receives Lark events, forwards them to OpenClaw, handles group reply rules, and performs message deduplication.
This works, but it has costs:
OpenClaw can integrate with Lark directly through a long-lived WebSocket connection. That removes the public webhook endpoint and reduces the deployment surface.
Native integration can support:
Create a Lark enterprise app, enable bot capability, and get the App ID and App Secret.
The app should include permissions for receiving and sending IM messages, reading message resources, and accessing files if the workflow needs media handling.
Example permission areas:
im:message
im:message:send_as_bot
im:message:readonly
im:chat.members:bot_access
im:resourceUse Lark's long-connection event subscription and add the message receive event.
Use the OpenClaw channel setup flow:
openclaw channels addSelect Lark or Feishu, then enter the app credentials.
Restart the gateway, send a direct message and a group mention, then confirm that OpenClaw receives and responds through the native channel.
Telegram is already the more mature channel in this setup. The main follow-up is policy tuning:
The target architecture is:
Telegram -> OpenClaw Gateway
Lark -> OpenClaw Gateway
Other IM -> OpenClaw GatewayOpenClaw becomes the single channel hub. Claude Code or other local agents can then be launched behind it through ACP.
Move Lark from webhook bridge mode to native integration.
The migration reduces maintenance cost, avoids public tunnel dependency, and makes the Lark channel match the Telegram channel more closely in operational behavior.
Suggested priority: