Practice Log: Multi-Agent Serial Pipeline with Cursor + Git Worktree
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
Automated Serial Workflow (Agent Pipeline)
- Note: Do not use a SubAgent for any step that does not explicitly ask for one.
0 TASK 0: Proposal review
- Model: Gemini-3.1-pro
- Task: Use the
openspec-review-specs skill.
- Focus: Review proposal completeness, key data flows, and property/interface alignment.
1 TASK 1: Architect review
- Model: Opus 4.6
- Task: Review and improve the proposal from an architect’s perspective. Use the
neversight-skills_feed-system-architect skill.
- Focus: Examine the system design, look for reuse opportunities, and make sure the solution is robust.
2 TASK 2: Implementation
- Model: Opus 4.6
- Task: Run
/opsx/apply directly to turn the refined proposal into code.
3 TASK 3: Code review
- Model: Codex-5.3 (model switch)
- Task:
- Run
git commit to save the initial implementation.
- Review the current commit strictly against the proposal.
- This phase is read-only: do not modify code, so the review remains objective.
4 SubAgent 4: Auto-refinement
- Model: Opus 4.6 (switch back)
- Task: Ingest the review report from Agent 3, then update and fix the implementation based on the feedback.
5 SubAgent 5: Archiving
- Model: Opus 4.6
- Task:
- Run
/opsx/archive to archive the proposal status.
- Run the final
git commit to close the loop for this feature.
Bottleneck Review and Optimization
The current pipeline is highly automated, but the total runtime is still a bit long.
- Optimization idea: The current sub-agent responsibilities are too fine-grained. A next step is to reduce granularity by merging highly cohesive tasks, such as combining architect review and implementation into one larger agent step, or combining auto-refinement and archiving. This reduces communication overhead from model switching and context passing, which should improve total execution speed.
Why Default Workflows Belong in AGENTS.md, Not in a Skill
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.
The short answer
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.- A skill explains how to walk a specific path.
Why this cannot live inside one skill
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 as the routing layer
AGENTS.md is useful for rules that apply broadly:
- how to inspect the repo before editing
- how to choose between implementation, review, and research
- when to ask a clarifying question
- how to handle multi-step work
- how to respect local project constraints
- how to coordinate with specialized skills
Those rules are not tied to one domain. They shape the agent’s behavior before the domain is known.
Skills as execution modules
Skills are best used for specialized workflows:
- reviewing a draft article
- generating a logo asset matrix
- building a spreadsheet
- drawing a technical architecture diagram
- installing or publishing a skill
Each skill should assume the task has already been classified. Then it can provide detailed steps, scripts, templates, and checks for that domain.
The useful split
A healthy agent system keeps the layers separate:
- Global behavior and routing live in
AGENTS.md.
- Domain-specific procedures live in skills.
- Project-specific facts live in docs, decisions, learn notes, and local
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.
Practical rule
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.
OpenClaw + Telegram + Lark Integration Research Report
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.
Current setup
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 |
Current Lark architecture
The current path is:
Lark -> Cloudflare Tunnel -> bridge.py -> OpenClaw Gateway
The bridge receives Lark events, forwards them to OpenClaw, handles group reply rules, and performs message deduplication.
This works, but it has costs:
- extra service to maintain
- Cloudflare Tunnel requirement
- more moving parts during outages
- limited access to native OpenClaw Lark features
Native Lark integration
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:
- direct messages
- group messages with bot mentions
- interactive card messages
- bot message sending
- media file handling
Migration plan
Step 1: Create or update the Lark app
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:resource
Step 3: Enable event subscription
Use Lark’s long-connection event subscription and add the message receive event.
Use the OpenClaw channel setup flow:
openclaw channels add
Select Lark or Feishu, then enter the app credentials.
Step 5: Restart and verify
Restart the gateway, send a direct message and a group mention, then confirm that OpenClaw receives and responds through the native channel.
Telegram considerations
Telegram is already the more mature channel in this setup. The main follow-up is policy tuning:
- whether direct messages should be open or paired
- whether groups should be allowlisted
- whether streaming should be partial or full
- whether proxy settings are still required
Recommended target architecture
The target architecture is:
Telegram -> OpenClaw Gateway
Lark -> OpenClaw Gateway
Other IM -> OpenClaw Gateway
OpenClaw becomes the single channel hub. Claude Code or other local agents can then be launched behind it through ACP.
Recommendation
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:
- Switch Lark to native integration.
- Re-check Telegram DM and group policies.
- Add advanced Lark capabilities such as file upload and user identification only after the basic channel is stable.
Complete Guide: OpenClaw with Claude Code and Lark Bot
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.
Roles
| 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 |
Collaboration mode
The practical workflow is:
- Send an instruction from Telegram or Lark.
- OpenClaw receives the message.
- OpenClaw can spawn Claude Code as a local subprocess through ACP.
- Claude Code performs the engineering task on the machine.
- OpenClaw sends the result back to the chat.
The important point is that Claude Code remains local and capable, while OpenClaw handles channel access and routing.
Binding a chat to Claude Code
To bind the current chat to Claude Code:
/acp spawn claude --bind here
This 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.
Persistent threads
For larger tasks, use a persistent thread:
/acp spawn claude --mode persistent --thread auto
This keeps intermediate progress, results, and follow-up context in a dedicated topic instead of polluting the main chat.
One-shot execution
For short tasks:
/acp spawn claude --mode oneshot
This is useful for one-off work such as reviewing a pull request, generating a short report, or checking a repository state.
Common ACP commands
| 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 |
Using Claude with Lark operations
Claude Code does not directly need to own Lark tools. A clean split is:
- OpenClaw handles Lark messages, documents, and bot identity.
- Claude Code handles coding, debugging, and local file work.
- OpenClaw takes Claude’s output and sends it into Lark.
This avoids mixing channel permissions into the coding agent.
Example: engineering daily report
- Bind Claude in Telegram:
/acp spawn claude --bind here
- Ask Claude to draft the report:
Write a daily engineering update:
- Done: fixed the login bug
- In progress: refactoring the order module
- Blocked: waiting for design
- Ask OpenClaw to send the result to the target Lark group.
OpenClaw uses the configured bot identity to send the message.
Bot identity
Using a bot identity is operationally stable:
- no personal login session expiration
- predictable permission scope
- suitable for scheduled or background workflows
- easier to audit than user-level automation
Recommended mental model
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.