forge-openclaw-plugin 0.2.67 → 0.2.69

package/skills/forge-openclaw/SKILL.md

@@ -111,6 +111,10 @@ Concrete route-key examples for internal use:
   `{"routeKey":"selection","query":{"from":"2026-05-01T00:00:00.000Z","to":"2026-05-14T23:59:59.999Z","placeIds":["place_home"],"userIds":["user_operator"]}}`
 - Movement trip detail:
   `{"routeKey":"tripDetail","pathParams":{"id":"trip_123"}}`
+- Movement settings read:
+  `{"routeKey":"settings","query":{"userIds":["user_operator"]}}`
+- Movement settings update:
+  `{"routeKey":"settingsUpdate","body":{"trackingEnabled":true,"publishMode":"draft_review","retentionMode":"aggregates_only"}}`
 - Movement missing-stay correction:
   first `{"routeKey":"userBoxPreflight","body":{"kind":"stay","startedAt":"2026-05-06T13:00:00.000Z","endedAt":"2026-05-06T15:00:00.000Z","placeLabel":"Home","userId":"user_operator"}}`,
   then `{"routeKey":"userBoxCreate","body":{"kind":"stay","startedAt":"2026-05-06T13:00:00.000Z","endedAt":"2026-05-06T15:00:00.000Z","placeLabel":"Home","userId":"user_operator","note":"Manual correction after reviewing the timeline."}}`
@@ -126,6 +130,12 @@ Concrete route-key examples for internal use:
   `{"routeKey":"listFlows","query":{"includeArchived":false}}`
 - Workbench box catalog:
   `{"routeKey":"boxCatalog"}`
+- Workbench flow creation:
+  `{"routeKey":"createFlow","body":{"title":"Research digest","slug":"research-digest","description":"Turn a topic into a cited digest with a stable published summary.","nodes":[],"edges":[]}}`
+- Workbench flow edit:
+  `{"routeKey":"updateFlow","pathParams":{"id":"flow_research_digest"},"body":{"description":"Keep the same input contract but add a stronger evidence-check node."}}`
+- Workbench flow deletion:
+  `{"routeKey":"deleteFlow","pathParams":{"id":"flow_research_digest"}}`
 - Workbench run detail:
   `{"routeKey":"runDetail","pathParams":{"id":"flow_research_digest","runId":"run_123"}}`
 - Workbench published output:
@@ -134,6 +144,8 @@ Concrete route-key examples for internal use:
   `{"routeKey":"latestNodeOutput","pathParams":{"id":"flow_research_digest","nodeId":"node_summary"}}`
 - Workbench run execution:
   `{"routeKey":"runFlow","pathParams":{"id":"flow_research_digest"},"body":{"input":{"topic":"question flow quality"}}}`
+- Workbench flow chat follow-up:
+  `{"routeKey":"chatFlow","pathParams":{"id":"flow_research_digest"},"body":{"message":"Refine the summary around API route risks and keep the published output stable."}}`
 
 Preferences rule:
 
@@ -486,6 +498,10 @@ through `forge_create_entities` or `forge_update_entities`.
   `/api/v1/movement/day`, `/api/v1/movement/month`, `/api/v1/movement/all-time`,
   `/api/v1/movement/timeline`, `/api/v1/movement/places`,
   `/api/v1/movement/selection`, and `/api/v1/movement/trips/:id`.
+- Use `GET /api/v1/movement/settings` and `PATCH /api/v1/movement/settings` when
+  the user wants to inspect or change passive capture, publish mode, retention mode,
+  or companion readiness. Do not treat movement settings as a place, stay, trip, or
+  batch entity write.
 - When the user is filling a missing-data gap, the default write path is a user-defined overlay box, not a raw stay or trip patch. Use `POST /api/v1/movement/user-boxes/preflight` if you need to confirm overlap or snap to the nearest missing interval, then `POST /api/v1/movement/user-boxes` with `kind: "stay"` or `kind: "trip"`.
 - When the user is repairing already-saved movement data, use the repair routes that match the saved object:
   `PATCH /api/v1/movement/user-boxes/:id`,
@@ -496,7 +512,7 @@ through `forge_create_entities` or `forge_update_entities`.
 - Use `PATCH /api/v1/movement/stays/:id` or `PATCH /api/v1/movement/trips/:id` only when the user is editing an existing recorded stay or recorded trip. Do not use those routes to fill a missing span.
 - If the user says something as explicit as "that missing block was me staying home", do not reopen broad intake. Confirm the interval or place only if it is still ambiguous, then create the overlay and read the timeline back.
 - Life Force lives under `/api/v1/life-force*`. Use `GET /api/v1/life-force` for the current energy overview, `PATCH /api/v1/life-force/profile` for durable profile changes, `PUT /api/v1/life-force/templates/:weekday` for weekday curve edits, and `POST /api/v1/life-force/fatigue-signals` for real-time tired or recovered signals.
-- Workbench lives under `/api/v1/workbench/*`. Use those dedicated routes for flow catalog reads, flow CRUD, runs, published outputs, node results, and latest-node-output reads instead of trying to force Workbench through the batch entity routes.
+- Workbench lives under `/api/v1/workbench/*`. Use those dedicated routes for flow catalog reads, flow CRUD, runs, saved-flow chat follow-ups, published outputs, node results, and latest-node-output reads instead of trying to force Workbench through the batch entity routes.
 - If you need the OpenClaw HTTP mirror instead of the raw Forge runtime path, the
   same specialized families are exposed under `/forge/v1/movement/*`,
   `/forge/v1/life-force/*`, and `/forge/v1/workbench/*`.
@@ -505,8 +521,16 @@ through `forge_create_entities` or `forge_update_entities`.
   `POST /api/v1/workbench/flows` for flow creation,
   `PATCH /api/v1/workbench/flows/:id` and `DELETE /api/v1/workbench/flows/:id` for saved-flow edits or deletion,
   `/api/v1/workbench/flows/:id/run` or `/api/v1/workbench/run` for execution,
+  `POST /api/v1/workbench/flows/:id/chat` for saved-flow chat follow-ups,
   `/api/v1/workbench/flows/:id/output` for published outputs, and the run/node routes
   under `/api/v1/workbench/flows/:id` for run history and node-level inspection.
+- For Workbench flow creation or edits, clarify the stable input contract, intended
+  published output, and smallest structural change before asking for raw JSON or node
+  payloads. For deletion, confirm the saved flow and whether published outputs or run
+  history need preservation elsewhere before using the delete route.
+- For Workbench flow chat follow-ups, use `POST /api/v1/workbench/flows/:id/chat`
+  only when the user wants flow-specific conversation. Do not turn that follow-up
+  into a new run, note, or generic entity update unless the user asks for that.
 - If you are unsure which specialized route family applies, check `forge_get_agent_onboarding` and use its `entityRouteModel.specializedDomainSurfaces` section before guessing.
 - If the truth of the current Movement, Life Force, or Workbench state is still unclear, prefer the dedicated read before the mutation so the correction stays truthful.
 - After a concrete Movement, Life Force, or Workbench correction, read the relevant specialized view back when the user is trying to understand the result rather than only store it.

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -1370,8 +1370,9 @@ Preferred opening question:
 ## Movement
 
 Aim: clarify whether the user wants to understand time in place, review travel
-behavior, add or update a stay or trip, inspect one place, or link movement context to
-another Forge record before choosing the dedicated route family.
+behavior, add or update a stay or trip, inspect one place, change movement operating
+settings, or link movement context to another Forge record before choosing the
+dedicated route family.
 
 Arc:
 
@@ -1382,14 +1383,16 @@ Arc:
 3. Ask whether the focus is a stay, a trip, a place, a timeline window, or a selected span.
 4. Ask for the time window, place, or movement item that makes the question concrete.
 5. Ask what they are trying to notice, preserve, or answer through that movement context.
-6. Choose the dedicated day, month, all-time, timeline, places, trip-detail, or
-   selection route once the question shape is clear.
-7. If the truth of one uncertain span is still unclear, read the timeline or saved-box
+6. If the user is changing movement operating behavior, ask whether the change is
+   about passive tracking, publish mode, retention, or companion readiness.
+7. Choose the dedicated day, month, all-time, timeline, places, trip-detail,
+   selection, or settings route once the question shape is clear.
+8. If the truth of one uncertain span is still unclear, read the timeline or saved-box
    detail before you mutate it.
-8. Skip the meta lane question when the user already named the exact correction or
+9. Skip the meta lane question when the user already named the exact correction or
    review target and only one ambiguity remains.
-9. Use the dedicated movement route once you know whether the user needs timeline
-   review, overlay, place or trip detail, selection summary, or repair.
+10. Use the dedicated movement route once you know whether the user needs timeline
+   review, overlay, place or trip detail, selection summary, settings, or repair.
 
 Direct action rules:
 
@@ -1398,6 +1401,11 @@ Direct action rules:
 - Treat day, month, all-time, timeline, trip detail, and selection as internal read
   lanes. With the user, ask for the useful time window, place, selected span, stay, or
   trip instead of listing route choices.
+- Treat settings as a separate movement lane for passive capture, publish mode, and
+  retention behavior. Ask what operating behavior should change instead of routing it
+  through a place, stay, or trip edit.
+- Use settings reads before settings writes when the current capture or publish state
+  is uncertain.
 - Preflight with `/api/v1/movement/user-boxes/preflight` when overlap or exact timing
   is unclear, then create the overlay with `/api/v1/movement/user-boxes`.
 - Use `kind: "stay"` when the user stayed in one place and `kind: "trip"` when they
@@ -1427,6 +1435,8 @@ Helpful follow-up lanes:
 - whether the edit is a missing-gap overlay versus a true recorded stay/trip patch
 - whether the user is trying to repair one recorded movement item versus fill a
   missing span
+- whether they are changing passive capture, publish mode, retention, or companion
+  readiness rather than movement history
 
 Lane-to-route map:
 
@@ -1436,6 +1446,8 @@ Lane-to-route map:
   `/api/v1/movement/all-time`, `/api/v1/movement/places`, or `/api/v1/movement/selection`
 - inspect the full life timeline:
   `/api/v1/movement/timeline`
+- inspect or change passive capture and publishing settings:
+  `GET /api/v1/movement/settings` or `PATCH /api/v1/movement/settings`
 - create or revise one saved place:
   `/api/v1/movement/places` or `/api/v1/movement/places/:id`
 - inspect one trip:
@@ -1461,6 +1473,7 @@ Ready to act when:
 - the time range, place, stay, trip, or selection is clear enough
 - the user goal is clear enough to tell review, overlay, and repair apart
 - the user goal is clear enough to choose the route
+- for settings changes, the intended tracking, publish, or retention behavior is clear
 
 Preferred opening question:
 
@@ -1550,18 +1563,25 @@ Arc:
 
 1. Ask what they are trying to learn, repair, publish, or run through Workbench
    before you narrow to flow discovery, editing, execution, or results.
-2. Ask whether the job is flow discovery, one flow edit, execution, run history, published output, node-level inspection, or latest-node-output lookup.
+2. Ask whether the job is flow discovery, one flow edit, execution, run history, published output, node-level inspection, latest-node-output lookup, or a follow-up message in a saved flow chat.
 3. Ask which flow, slug, run, or node the request is about.
 4. Ask whether they need the stable flow contract, one run result, one published
    output, one node result, or the latest node output.
-5. If the user already named the flow and action clearly, skip the meta lane
+5. If the user is creating or editing a flow, clarify the flow's job, stable inputs,
+   expected public output, and the smallest structural change before asking for node
+   details.
+6. If the user wants to delete or archive a flow, ask which saved flow is affected
+   and what future run, published output, or public contract should no longer exist.
+7. If the user wants to continue a saved flow chat, ask which flow should receive the
+   follow-up and what the message should accomplish.
+8. If the user already named the flow and action clearly, skip the meta lane
    question and ask only for the missing run, node, or output scope.
-6. If the user wants a stable public input contract or published output, prefer those
+9. If the user wants a stable public input contract or published output, prefer those
    dedicated reads instead of detouring through run history first.
-7. If the user is debugging one failed run, ask whether the useful artifact is the run
+10. If the user is debugging one failed run, ask whether the useful artifact is the run
    summary, one node result, the latest node output, or the published output before
    you start asking for edits.
-8. Route to the dedicated workbench route family once the execution lane is clear.
+11. Route to the dedicated workbench route family once the execution lane is clear.
 
 Helpful follow-up lanes:
 
@@ -1582,7 +1602,7 @@ Lane-to-route map:
 - run from a payload-first contract:
   `/api/v1/workbench/run`
 - send one follow-up message into a saved flow chat:
-  `/api/v1/workbench/flows/:id/chat`
+  `POST /api/v1/workbench/flows/:id/chat`
 - inspect published output or run history:
   `/api/v1/workbench/flows/:id/output` or `/api/v1/workbench/flows/:id/runs`
 - inspect one run or node result:
@@ -1617,12 +1637,24 @@ Direct action rules:
   unless they explicitly want historical debugging.
 - If the user wants to understand what inputs a flow can accept before editing or
   running it, read the box catalog or flow detail before asking for a payload.
+- For new flows, ask what the flow should reliably produce, what input contract it
+  should accept, and what first node or box should anchor it. Do not start by asking
+  for raw JSON.
+- For flow edits, ask what behavior should change and how the public contract stays
+  stable, unless the user explicitly wants to change the contract.
+- For flow deletion, confirm the saved flow and whether published outputs or run
+  history still need to be preserved elsewhere before calling delete.
+- For flow chat follow-ups, use the saved flow chat route only when the user wants to
+  continue a flow-specific conversation. Do not turn a chat follow-up into a new flow
+  run, note, or generic entity update unless that is what the user asks for.
 
 Ready to act when:
 
 - the workbench lane is clear
 - the flow, run, or node is clear enough
 - the requested read or mutation is clear enough to choose the route
+- for flow CRUD, the intended stable input, output, or lifecycle effect is clear
+- for flow chat, the saved flow and follow-up message aim are clear
 
 Preferred opening question: