standing orders vs lobster workflows

[solar creek]

Is there an easy way to convert a standing order to lobster workflow

[marsh spoke]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[celest plinth]

Short answer: there isn't a one-click converter right now.

Standing orders and Lobster solve different layers:

• Standing order = durable authority/policy: what the agent is allowed to own, when it should escalate, what it must never do.
• Lobster workflow = deterministic execution: concrete steps, JSON pipes, approvals, resumable state.

The practical conversion path is manual but pretty mechanical:

1. Keep the standing order in AGENTS.md or a referenced standing-orders file.
2. Pull out the repeatable execution steps into a .lobster workflow.
3. Put risky side effects behind Lobster approval steps.
4. Trigger it with cron using a prompt like “run the inbox-triage Lobster workflow per standing orders.”

So a standing order like “own daily inbox triage” becomes:

• standing order: scope, escalation, approval policy
• cron: when to run

[celest plinth]

• Lobster: exact commands/tools to list, categorize, preview, approve, apply

Docs:
https://docs.openclaw.ai/automation/standing-orders
https://docs.openclaw.ai/tools/lobster
https://docs.openclaw.ai/automation/cron-jobs

If you paste the standing order, I can help sketch what the matching .lobster shape should look like.

[solar creek]

I'm thiking of converting because sometimes it does quite carry out every step in the standing order

[celest plinth]

Yep, that’s exactly the case where Lobster is a better fit.

Standing orders are instructions, so the agent can still skip or compress steps if it thinks it has enough context. Lobster turns the repeatable part into an actual execution contract: step A runs, then step B receives A’s output, then step C runs only if the approval/check passes.

I’d split it like this:

• Keep the standing order for policy: authority, boundaries, escalation, “what not to do”
• Move the “must always happen” checklist into Lobster steps
• Add verification steps after important actions, not just at the end
• Make the cron/trigger say: “run this Lobster workflow per standing orders”

A good pattern is:

name: daily-triage
steps:

[celest plinth]

  - id: collect
    command: your-tool collect --json
  - id: classify
    command: your-tool classify --json
    stdin: $collect.stdout
  - id: verify
    command: your-tool verify --json
    stdin: $classify.stdout
  - id: preview
    command: your-tool preview
    stdin: $verify.stdout
    approval: required
  - id: apply
    command: your-tool apply
    stdin: $verify.stdout

[celest plinth]

    condition: $preview.approved

The key is to make each step produce/check structured output, so the agent isn’t “remembering” the workflow from prose. It’s executing a pipeline. Docs are here: https://docs.openclaw.ai/tools/lobster

[solar creek]

It;s actually a program, you can find it here, perhaps it is too long? https://cl1p.net/4569

[celest plinth]

I looked at it. It’s not just “too long”; it’s doing three jobs at once, and that makes step skipping more likely.

The main issues I’d fix:

• It repeats the output format twice. That gives the agent two chances to drift or partially satisfy one copy.
• There are lots of negative rules (“do not…”) mixed into execution steps. Useful as policy, but noisy for a runbook.
• Some caps are hard to reconcile: total whole run max 9 lookups, Firecrawl max 6 total, max 2 per holding, high-conviction max 2, FX max 1. If you have several holdings, the workflow can hit caps before it has enough data.
• “Scan the S&P 500” conflicts with “do not run broad market/S&P 500 queries” unless you already have a candidate list or a deterministic screener source.
• Delivery is hard-coded to Telegram media. That’s fine if this only runs from Telegram, but it should be explicit that Discord/web/etc. are unsupported for this program.
• The high-conviction pick still needs judgment. Lobster can enforce steps, but the candidate selection probably needs either a fixed candidate source or a small LLM/json step.

I’d split it into:

1. Standing order: authority, forbidden actions, source policy, financial-advice disclaimer, escalation rules.
2. Lobster workflow: load portfolio -> for each ticker fetch compact quote -> generate chart -> verify chart sent -> build report -> validate required labels.
3. Report template: one canonical template only, kept short.
4. Candidate policy: either “evaluate these 5 candidates from a file” or “use this one screener endpoint,” not open-ended S&P scanning.

[celest plinth]

So yes, this is a strong candidate for Lobster. The deterministic part is the per-ticker loop + caps + chart delivery + final format gate. Keep only the interpretation/summary as the flexible AI part.

I’d also reduce the standing order to maybe 25-40 lines and move most of the checklist into the workflow file. That will probably improve reliability even before you fully convert it.

[solar creek]

Where does it repeat the output format?

[celest plinth]

Two places:

1. Under “### Final Format Gate” you define the required sections/labels:

• holding sections
• Previous close -> Close
• 5% target
• Chart
• Average down?
• Return to original value
• My take
• Risk Alerts
• Bottom Line
• High Conviction Pick
• Firecrawl / Proxy Usage

2. Then under “### Output Format” you give the full report template.

[celest plinth]

But later, after “### Formatting Rules” and “### Delivery / Retry Rules”, there’s another “### Output Format” block that repeats the same “Start the entire response with…” template and the Firecrawl / Proxy Usage format.

So the exact full template appears twice. The “Final Format Gate” is fine as a validation checklist, but I’d keep only one full Output Format block and make the gate say “verify against the Output Format below/above.”

[solar creek]

So which one should I remove

[celest plinth]

Remove the second “### Output Format” block near the bottom, after “### Delivery / Retry Rules”.

Keep the earlier full “### Output Format” block, because it sits closer to the Execution Steps and Final Format Gate, so the program reads in a cleaner order:

1. rules/policy
2. data + chart rules
3. execution steps
4. calculation rules
5. output format
6. formatting/delivery retry rules

I’d leave “### Final Format Gate” in place, but shorten it slightly so it validates the one surviving template instead of restating too much. Something like:

“Before sending, verify the report matches the Output Format exactly, including one section per holding and these required labels: Previous close -> Close, 5% target, Chart, Average down?, Return to original value, My take, Risk Alerts, Bottom Line, High Conviction Pick, Firecrawl / Proxy Usage.”

That keeps the checklist without maintaining two templates.