forge-openclaw-plugin 0.3.14 → 0.3.16

package/skills/forge-openclaw/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: forge-openclaw-plugin
-description: use when the user wants to save, search, update, review, start, stop, reward, explain, compare, or run Forge records, or when the conversation is clearly about a Forge entity or domain surface such as a goal, project, strategy, task, habit, note, wiki_page, calendar_event, calendar_connection, work_block_template, task_timebox, task_run, work_adjustment, insight, preference item, preference context, preference catalog, preference judgment, preference signal, questionnaire instrument, questionnaire run, self observation, movement, life_force, workbench, psyche_value, behavior_pattern, behavior, belief_entry, mode_profile, mode_guide_session, flashcard, trigger_report, event_type, emotion_definition, sleep_session, workout_session, or training_load. identify the exact Forge object or specialized surface, keep the main conversation natural, guide psyche intake with active listening before storing it, and for psyche issues that need understanding first usually begin with one exploratory question before any formulation or save suggestion.
+description: use when the user wants to save, search, update, review, start, stop, reward, explain, compare, or run Forge records, or when the conversation is clearly about a Forge entity or domain surface such as a goal, project, strategy, task, habit, note, wiki_page, calendar_event, calendar_connection, work_block_template, task_timebox, task_run, work_adjustment, insight, preference item, preference context, preference catalog, preference judgment, preference signal, questionnaire instrument, questionnaire run, self observation, operator_overview, operator_context, calendar_overview, sleep_overview, sports_overview, training_load, weight_loss, movement, life_force, workbench, psyche_value, behavior_pattern, behavior, belief_entry, mode_profile, mode_guide_session, flashcard, trigger_report, event_type, emotion_definition, sleep_session, or workout_session. identify the exact Forge object or specialized surface, keep the main conversation natural, guide psyche intake with active listening before storing it, and for psyche issues that need understanding first usually begin with one exploratory question before any formulation or save suggestion.
 ---
 
 Forge is the user's structured system for planning work, doing work, reflecting on patterns, and keeping a truthful record of what is happening. Use it when the user is clearly working inside that system, or when they are describing something that naturally belongs there and would benefit from being stored, updated, reviewed, or acted on in Forge. Keep the conversation natural first. Do not turn every message into intake. When a real Forge entity is clearly present, name the exact entity type plainly, help with the substance of the conversation, and then offer Forge once, lightly, if storing it would genuinely help.
@@ -59,7 +59,7 @@ PM surface rule:
   human/bot ownership filters.
 - Guided modal flows handle create, edit, move, link, and closeout actions.
 
-Forge has four major stored-entity surfaces and three specialized domain surfaces. The planning side covers goals, projects, strategies, tasks, habits, notes, calendar events, recurring work blocks, task timeboxes, live work sessions, and agent-authored insights. The Health side covers sleep sessions, sports and workout sessions, the read-only training-load surface for cardiovascular load and HR zone review, companion pairing, and habit-generated workout records that should still stay linked to the broader Forge graph. The Preferences side covers contextual taste modeling, pairwise comparisons, direct signals, editable concept libraries, and preference items that can come from Forge entities or seeded concept domains such as food, activities, places, countries, fashion, people, media, and tools. The Psyche side covers values, patterns, behaviors, beliefs, modes, guided mode sessions, flashcards, trigger reports, event types, and reusable emotion definitions. The specialized domain surfaces are Movement, Life Force, and Workbench; agents must use their dedicated route families instead of forcing them through batch CRUD. Forge also has a SQLite-backed Wiki memory layer with explicit spaces, Markdown content in database rows, backlinks, optional embeddings, and structured links back to Forge entities. Forge is also multi-user: every entity can belong to a typed `human` or `bot` user through `userId`, and read routes can scope to one or many users with `userId` or repeated `userIds`. The current access posture is configurable through a directional user graph, but the live default is still permissive: Forge can list users directly, every relationship edge starts open, and a user can read or affect another user's linked records when the route explicitly asks for them. Use `forge_get_user_directory` when owner identity or cross-user access matters. Strategies can also be locked into a contract with `isLocked`; once locked, do not mutate the graph or target structure unless the user explicitly wants the strategy unlocked first. The model should use the real entity names, not vague substitutes. Say `project`, not “initiative”. Say `behavior_pattern`, not “theme”. Say `trigger_report`, not “incident note”.
+Forge has four major stored-entity surfaces, read-model surfaces, and three specialized domain surfaces. The planning side covers goals, projects, strategies, tasks, habits, notes, calendar events, recurring work blocks, task timeboxes, live work sessions, and agent-authored insights. The Health side covers sleep sessions, sports and workout sessions, the read-only training-load surface for cardiovascular load and HR zone review, the weight-loss and nutrition workflow, companion pairing, and habit-generated workout records that should still stay linked to the broader Forge graph. The Preferences side covers contextual taste modeling, pairwise comparisons, direct signals, editable concept libraries, and preference items that can come from Forge entities or seeded concept domains such as food, activities, places, countries, fashion, people, media, and tools. The Psyche side covers values, patterns, behaviors, beliefs, modes, guided mode sessions, flashcards, trigger reports, event types, reusable emotion definitions, questionnaire instruments, questionnaire runs, and the note-backed self-observation calendar. Read-model surfaces include `operator_overview`, `operator_context`, `calendar_overview`, `sleep_overview`, `sports_overview`, `training_load`, `weight_loss`, and the self-observation calendar; ask what practical decision the read should support before adding write-shaped questions. The specialized domain surfaces are Movement, Life Force, and Workbench; agents must use their dedicated route families instead of forcing them through batch CRUD. Forge also has a SQLite-backed Wiki memory layer with explicit spaces, Markdown content in database rows, backlinks, optional embeddings, and structured links back to Forge entities. Forge is also multi-user: every entity can belong to a typed `human` or `bot` user through `userId`, and read routes can scope to one or many users with `userId` or repeated `userIds`. The current access posture is configurable through a directional user graph, but the live default is still permissive: Forge can list users directly, every relationship edge starts open, and a user can read or affect another user's linked records when the route explicitly asks for them. Use `forge_get_user_directory` when owner identity or cross-user access matters. Strategies can also be locked into a contract with `isLocked`; once locked, do not mutate the graph or target structure unless the user explicitly wants the strategy unlocked first. The model should use the real entity names, not vague substitutes. Say `project`, not “initiative”. Say `behavior_pattern`, not “theme”. Say `trigger_report`, not “incident note”.
 Habits are a first-class recurring entity in the planning side.
 NEGATIVE HABIT CHECK-IN RULE: for a `negative` habit, the correct aligned/resisted outcome is `missed`. `missed` means the bad habit was resisted, the user stayed aligned, and the habit should award its XP bonus.
 
@@ -103,12 +103,25 @@ any route-key or endpoint detail.
   route-key-to-`METHOD /api/v1/...` source of truth when checking specialized
   methods, especially POST aggregate reads such as Movement `selection` and DELETE
   repair paths. When a route key's exact path contains placeholders such as `:id`,
-  `:weekday`, `:runId`, or `:nodeId`, pass those values in `pathParams` using the
-  placeholder names exactly. Do not place IDs inside `routeKey`, invent a raw route
-  string, or ask the user to choose an endpoint when the lane already selects one. If
-  that schema and live onboarding disagree, trust the live onboarding for the current
-  call and treat the disagreement as a Forge contract bug to fix, not as a reason to
-  guess a nearby route.
+  `:weekday`, `:slug`, `:runId`, `:nodeId`, or `:pointId`, pass those values in
+  `pathParams` using the placeholder names exactly. Do not place IDs inside
+  `routeKey`, `query`, or `body`, invent a raw route string, or ask the user to
+  choose an endpoint when the lane already selects one. If that schema and live
+  onboarding disagree, trust the live onboarding for the current call and treat the
+  disagreement as a Forge contract bug to fix, not as a reason to guess a nearby
+  route.
+- If a specialized route-key tool is unavailable, stale, or missing the needed route
+  key, do not fall back to generic batch CRUD and do not invent a nearby raw path. Read
+  live onboarding, use the exact `methodRoutes` entry for the selected Movement, Life
+  Force, or Workbench lane, and cross-check OpenAPI only to confirm the same method
+  and path.
+- Before every Movement, Life Force, or Workbench call, run a route-contract
+  handshake internally: select the product lane in plain language, verify the matching
+  `routeKey` against live onboarding `routeKeys` and `methodRoutes`, fill any
+  placeholders through `pathParams`, and ask the user only for the missing product
+  noun that fills the placeholder. If the contract is missing a lane the product
+  clearly supports, report a contract bug instead of silently using generic batch
+  CRUD or a nearby route.
 
 Concrete route-key examples for internal use:
 
@@ -239,12 +252,12 @@ Health rule:
   `forge_parse_food_log_with_chatgpt` must use Forge's configured `openai-codex`
   ChatGPT subscription connection, not a metered OpenAI Platform API path.
 - In `forge_get_agent_onboarding.entityRouteModel.readModelOnlySurfaces`, operator,
-  calendar, self-observation, sleep, sports, and training-load read models are published with
+  calendar, self-observation, sleep, sports, training-load, and weight-loss read models are published with
   both camelCase names and entity-style aliases where useful, including
   `operatorOverview`, `operatorContext`, `calendarOverview`, `sleepOverview`,
-  `sportsOverview`, `trainingLoad`, `operator_overview`, `operator_context`,
+  `sportsOverview`, `trainingLoad`, `weightLoss`, `operator_overview`, `operator_context`,
   `calendar_overview`, `self_observation`, `sleep_overview`,
-  `sports_overview`, and `training_load`. Treat those as read-only surfaces,
+  `sports_overview`, `training_load`, and `weight_loss`. Treat those as read-only surfaces,
   not batch CRUD entities.
 - Use `forge_get_operator_overview` for a broad Forge status read, `forge_get_operator_context`
   for current work and risk, and `forge_get_calendar_overview` before calendar-aware
@@ -258,12 +271,24 @@ Write to Forge only with clear user consent. If the user is just thinking aloud,
 Entity conversation rule:
 
 - For all entity creation or update flows, first use [`entity_conversation_playbooks.md`](./entity_conversation_playbooks.md) to decide the next best question.
+- Calibrate depth before deepening: choose quick capture, guided formulation,
+  review-first, or action-first. For quick capture, use the user's supplied wording,
+  ask only the one structural, accuracy, or consent detail that changes the write, and
+  do not force full exploration. For guided formulation, use active listening and
+  Psyche hypotheses when the user is trying to understand or name charged material.
+  For review-first, read before write-shaped questions. For action-first, act or ask
+  only for the missing target, span, weekday, flow, run, node, correction, or consent.
 - Ask only for what is missing or unclear. Do not walk through every schema field.
 - Before asking another question, run the playbook's minimum save-readiness
   checkpoint: if accepted wording, meaningful body, route lane, target object or
   time scope, and any ownership/placement that changes later use are already clear,
   summarize once and write, read, run, or update instead of collecting optional
   fields.
+- Run the no-question gate before every follow-up: ask only if the answer can change
+  record type, accepted wording, hierarchy placement, owner/accountability, timing,
+  route lane, target object, correction, link, verification read, run/publish/preserve
+  action, or consent. If the question would only add warmth, completeness, optional
+  metadata, or form polish, skip it, summarize what is clear, and act or close.
 - Treat partial answers as progress. Before another follow-up, identify what is
   already usable: operation, entity or surface, target record or time span, working
   wording, owner or placement, route lane, and consent. Ask only for the first missing
@@ -276,8 +301,14 @@ Entity conversation rule:
   most directly supported by what was learned and ask only for the missing detail
   that would permit that action. Do not hand the user a broad menu after the read has
   already narrowed the work.
+- Make the read's decision value explicit before any follow-up: what the read rules
+  in, what it rules out, and what one uncertainty remains. If no answer-changing
+  uncertainty remains, close cleanly instead of asking another question.
 - Let each question have one job. Know what you are trying to clarify before you ask it.
-- Before you ask, decide the exact missing thing you need and how that answer will help you name, place, or save the record.
+- Before you ask, decide the exact missing thing you need and how that answer will
+  help you save, update, review, link, schedule, correct, run, publish, preserve,
+  enrich, open the UI, or stop. If you cannot name what the user's answer would
+  change, summarize and act instead of asking.
 - Prefer a progression of:
   concrete example or intent -> working name -> purpose or meaning -> placement in Forge -> operational details -> linked context.
 - Use those same playbooks for action-heavy non-Psyche flows such as `work_adjustment`, `preference_judgment`, `preference_signal`, and specialized `movement`, `life_force`, or `workbench` requests so the conversation starts from what the user is trying to understand, change, add, update, link, or run before you choose the route.
@@ -292,6 +323,14 @@ Entity conversation rule:
 - When the operation is not already explicit, identify the job first:
   add, update, review, compare, navigate, link, or run. Skip that meta question
   when the action is already obvious from the user's wording.
+- Keep the operation lane explicit across every entity family. Normal stored entities
+  can be added, updated, reviewed/navigated, linked, or placed; action workflows use
+  verbs such as start, continue, complete, adjust, judge, signal, publish, sync, or
+  observe; specialized CRUD uses lifecycle verbs; read models need a practical read
+  question and scope; Movement, Life Force, and Workbench use review, correct,
+  repair, run, inspect, publish, or preserve lanes through their dedicated route keys;
+  and Psyche entities need formulation before storage when the user wants
+  understanding rather than direct save.
 - For emotionally meaningful non-Psyche records such as goals, habits, and notes, reflect the meaning before you ask for structure.
 - When the user is vague, ask for one small concrete example, stake, or desired outcome before you ask them to name the record.
 - When the user is clear, say what the record seems to be becoming and ask only for the last missing detail.
@@ -347,6 +386,10 @@ Psyche interview rule:
 - Do not minimize functional analysis, trigger chains, behavior patterns, modes, beliefs, or schema themes. Once at least one concrete example is clear, offer one careful interpretive hypothesis when it would help the user understand the function, protection, cost, belief, mode, or schema theme.
 - Phrase interpretive hypotheses as collaborative and testable, not as verdicts. A good hypothesis says what the reaction may be protecting, predicting, relieving, or costing, then asks whether that lands or needs correction.
 - For Psyche hypotheses, reduce the formulation burden. After one concrete example, offer one tentative function, danger, protection, payoff, or cost hypothesis and ask one fit-or-correction question. Do not make the user prove the experience, list evidence, or design repair before the wording feels held.
+- Use the Psyche hypothesis examples when one concrete episode, belief sentence,
+  behavior, or mode voice is visible and another broad question would make the user do
+  all the interpretation alone. Offer one testable formulation, ask one correction
+  question, and then bridge to the saveable record if it lands.
 - Do not keep asking broad exploratory Psyche questions after the cue, meaning, protection, payoff, or cost is already visible. For `behavior_pattern`, `belief_entry`, `mode_profile`, `mode_guide_session`, and `trigger_report`, the next helpful move is usually one active formulation plus one correction question, not another passive reflection.
 - Do not leave the user with interpretation alone. Once the hypothesis lands or is
   corrected, name the primary Forge record it becomes and ask one accuracy or consent
@@ -374,6 +417,9 @@ Psyche interview rule:
   trigger episode, value phrase, event kind, emotion signature, or flashcard message,
   treat it as real data and ask one accuracy or consent question instead of reopening
   origin, evidence, or repair.
+- For direct Psyche saves, do not reopen origin, evidence, or repair when the user
+  already supplied usable wording and asked to save it. Reflect the wording, ask one
+  accuracy or consent question, and save when accepted.
 - When the conversation reveals an adjacent entity such as a linked belief, mode, value, pattern, or note, name that gently and ask whether the user wants to map it too.
 - If nuance matters, preserve it in a linked Markdown `note` instead of forcing every detail into normalized fields.
 - If the user shows imminent risk of self-harm, suicide, violence, inability to stay safe, or severe disorientation, stop normal intake and prioritize urgent human support or emergency help instead.
@@ -438,7 +484,7 @@ Use these exact entity meanings when deciding what the user is describing.
 
 `flashcard` is a small therapeutic reminder card. Use it when the user wants a sentence or short message that can be shown back during an urge, trigger, mode activation, belief activation, or values-based pivot. The message is the main content; title is optional and compact. Tags, trigger sentence, trigger situation, and Psyche links matter most for retrieval. Styling fields such as colors, typography, layout, visual tone, and image make the card easier to recognize but should come after the therapeutic sentence is clear.
 
-When a user says something like "I feel the urge to drink" or "help me not do this", search existing `flashcard` records first with `forge_search_entities` using `entityTypes: ["flashcard"]` and the user's urge, trigger words, tags, and situation language. If a matching card exists, show the flashcard message first, then add brief psychotherapy-informed support around it: grounding, urge surfing, cognitive defusion, schema/mode-aware reflection, or a values pivot. Do not create a new card until you have checked whether an existing one already fits.
+When a user says something like "I feel the urge to drink" or "help me not do this", search existing `flashcard` records first with `forge_search_entities` using `entityTypes: ["flashcard"]` and the user's urge, trigger words, tags, and situation language. If a matching card exists, show the flashcard message first, then add brief psychotherapy-informed support around it: grounding, urge surfing, cognitive defusion, schema/mode-aware reflection, or a values pivot. If no card fits and the user wants one, create only after the cue or urge sentence and the short message are clear; postpone visual style, colors, tags, and optional links until the intervention sentence works.
 
 `trigger_report` is one specific emotionally meaningful episode described as what happened, what was felt, what was thought, what was done, what happened next, and what would help next time.
 

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -110,6 +110,29 @@ Forge correctly, and gather only the structure that still matters.
 - When the record is already clear enough to save, save it instead of performing a
   ceremonial extra question.
 
+## Depth calibration
+
+Use this before choosing how much to ask. The goal is to match the user's actual job,
+not to make every entity feel equally deep.
+
+- Quick capture: the user already gave usable wording and says "save this", "remember
+  this", "log this", or otherwise makes storage the job. Reflect the working shape
+  once, ask only the one structural, accuracy, or consent detail that changes the
+  write, and do not force a full exploration.
+- Guided formulation: the user wants to understand, name, map, decide, or work
+  through unclear or charged material. Use active listening, one lane at a time, and
+  Psyche hypotheses when appropriate before saving.
+- Review-first: the user wants to inspect, compare, navigate, or understand something
+  already in Forge. Read the relevant stored entity, overview, or specialized surface
+  before asking write-shaped questions.
+- Action-first: the target task run, work adjustment, preference judgment or signal,
+  questionnaire run, Movement correction, Life Force signal/template, or Workbench
+  run/output is already clear. Act, or ask only for the missing target, span, weekday,
+  flow, run, node, correction, or consent.
+- Do not downgrade psychologically meaningful material into quick capture when the
+  user is asking to understand it. Do not expand a simple storage request into therapy
+  or project planning when a concise save is enough.
+
 ## Plain-language rule
 
 Keep API and architecture nouns inside your own reasoning. Do not ask the user about
@@ -160,6 +183,50 @@ choice is an internal classification step, not a user-facing menu.
 - Once the lane is selected, use the exact route key internally and do not invent a
   friendlier path.
 
+## Dedicated surface route fallback
+
+Use this when the adapter tool surface is missing, stale, or narrower than live Forge
+onboarding.
+
+- First prefer the route-key tools when they exist:
+  `forge_call_movement_route`, `forge_call_life_force_route`, or
+  `forge_call_workbench_route`.
+- If a route-key tool is unavailable, stale, or lacks the needed route key, read live
+  onboarding and use the exact `methodRoutes` entry for the selected lane. Cross-check
+  OpenAPI only to confirm the same method and path.
+- Do not fall back to generic batch CRUD for Movement, Life Force, or Workbench just
+  because a route-key tool is missing. They remain specialized domain surfaces.
+- Do not invent a nearby raw path, put IDs into the route key, or ask the user to pick
+  an endpoint. Ask only for the missing product identifier or span that fills the
+  published path.
+- Before calling a specialized route, check the selected `methodRoutes` entry for
+  placeholders such as `:id`, `:weekday`, `:slug`, `:runId`, `:nodeId`, or
+  `:pointId`. Every placeholder must be filled through `pathParams` with the same
+  name before the call; never hide one inside `query`, `body`, or `routeKey`.
+- If a required placeholder is missing, ask for the product noun that fills it: the
+  saved place, movement box, trip, weekday, flow, slug, run, node, or trip point.
+- If tool schema, live onboarding, and OpenAPI disagree, trust live onboarding for the
+  immediate call when it names the exact route, then treat the disagreement as a Forge
+  contract bug to fix.
+
+## Specialized route-contract handshake
+
+Use this before every Movement, Life Force, or Workbench call so the route path is
+truthful without turning the user's turn into implementation talk.
+
+- Select the product lane first in plain language: movement span or repair, energy
+  assumption or signal, saved flow/run/node/output, or published artifact.
+- Then verify the matching `routeKey` against live onboarding `routeKeys` and
+  `methodRoutes`. The route key and method/path must come from that contract, not from
+  memory or a guessed URL.
+- If `methodRoutes` contains placeholders, fill every placeholder through
+  `pathParams` with the exact placeholder name before the call. Ask the user only for
+  the missing product noun that fills the placeholder.
+- Cross-check OpenAPI when you are debugging or when a route-key tool looks stale; do
+  not make the user choose between endpoint names.
+- If the contract is missing a lane the product clearly supports, stop and report a
+  contract bug instead of silently using generic batch CRUD or a nearby route.
+
 ## Dedicated surface verification loop
 
 Use this after a Movement, Life Force, or Workbench mutation or result-producing run.
@@ -226,6 +293,9 @@ worked.
   answers the user's practical question and ask only for the missing detail that would
   permit that action. Do not hand the user a broad menu after you just learned enough
   to narrow the next move.
+- Make the read's decision value explicit before any follow-up: what the read rules
+  in, what it rules out, and what one uncertainty remains. If there is no
+  answer-changing uncertainty, do not ask another question.
 - For Movement, Life Force, Workbench, calendar, health, and operator overviews,
   keep the follow-up anchored to the read result: the span that is missing, the
   weekday curve that needs correction, the failed run or node, the overloaded day, or
@@ -483,6 +553,33 @@ Use this before you choose an API path or ask for more structure.
 - For Movement, Life Force, and Workbench, use the lane
   to choose the dedicated route family before you ask for lower-level details.
 
+## Operation coverage checkpoint
+
+Use this as a live handling and simulation check so every entity family is exercised
+as real work, not only as a create form.
+
+- Normal stored entities need four possible lanes in the agent's head: add a new
+  record, update an existing record, review or navigate existing records, and link or
+  place the record in Forge. Ask the lane only when the user's verb does not already
+  choose it.
+- Action workflows need action verbs instead of CRUD verbs: start, continue, complete,
+  adjust, judge, signal, publish, sync, or observe. Once the action verb is clear,
+  ask only for the missing target, answer, comparison, minutes, or consent.
+- Specialized CRUD surfaces need lifecycle verbs: create, read, update, sync,
+  reconnect, delete, or browse. For wiki pages, ask about the durable page or evidence
+  source; for calendar connections, ask about the provider workflow and lifecycle
+  action.
+- Read-model surfaces need a practical read question plus scope. Do not ask
+  write-shaped questions until the read creates a concrete follow-up.
+- Movement, Life Force, and Workbench need their dedicated operation lanes: review,
+  correct, repair, run, inspect, publish, or preserve. After the lane is clear, use
+  the exact dedicated route key internally and ask only for the span, place, weekday,
+  flow, run, node, output, correction, or preservation choice that is still missing.
+- Psyche entities need a formulation lane before the storage lane when the user wants
+  understanding. Direct saves can move to one accuracy or consent question; guided
+  formulation should stay with one lived example, one hypothesis when useful, and one
+  corrected saveable shape.
+
 ## Route posture checkpoint
 
 Use this quick split before the conversation gets too detailed.
@@ -666,9 +763,12 @@ of those things, stop asking, summarize the working record, and act with consent
 
 Do not drift into vague reflection or internal route language. Replace "that sounds
 important" with the specific stake you heard, and replace API words such as surface,
-CRUD, payload, mutation path, or endpoint with product nouns the user recognizes:
-belief, pattern, note, wiki page, timeline, overlay, weekday template, flow, run,
-node result, or published output.
+CRUD, payload, mutation path, route key, batch route, or endpoint with product nouns
+the user recognizes: belief, pattern, note, wiki page, timeline, overlay, missing
+stay, weekday template, flow, run, node result, or published output. If you cannot
+name the product noun yet, ask one grounding question about the real span, place,
+weekday, flow, run, node, belief sentence, parent record, or save confirmation
+instead of adding reflective filler.
 
 ## Steering moves
 
@@ -754,8 +854,10 @@ Use this quick internal check before every follow-up question.
    operational detail?
 3. Does it affect the API posture: batch CRUD, specialized CRUD, action workflow, or
    specialized domain route?
-4. What is the smallest question that would answer that unknown?
-5. If the user already gave enough to act, stop asking and move to a short summary or
+4. What concrete action would a possible answer enable: save, update, review, link,
+   schedule, correct, run, publish, preserve, or stop?
+5. What is the smallest question that would answer that unknown?
+6. If the user already gave enough to act, stop asking and move to a short summary or
    the write.
 
 Useful calibration heuristics:
@@ -772,6 +874,38 @@ Useful calibration heuristics:
   skip it.
 - If the next question would not change the API path, write shape, wording, timing, or
   useful links, skip it.
+- If you cannot say what the user's answer would change, do not ask the question.
+  Summarize what is already clear, take the read/write/run action, or close cleanly.
+- For review-first work, the follow-up must point to one action enabled by the read:
+  no change, save, update, correct, link, schedule, run, publish, preserve, enrich, or
+  open the UI. Do not ask a generic "what do you want to do with this?" after the read
+  already narrowed the practical next move.
+- For Movement, Life Force, and Workbench, the same rule applies through the product
+  object: missing span, place boundary, weekday curve, profile assumption, flow, run,
+  node, output, or preservation choice.
+
+## No-question gate
+
+Use this before every follow-up, especially after partial answers, reads, writes,
+repairs, and Psyche-adjacent material. A polished extra question is still a bad
+question when it cannot change the next action.
+
+- Ask only if the answer can change one of these: record type, accepted wording,
+  hierarchy placement, owner/accountability, timing, route lane, target object,
+  correction, link, verification read, run/publish/preserve action, or consent.
+- Do not ask for optional tags, colors, priority, assignees, dates, aliases, visual
+  style, or related links when the user already gave enough to save, read, run,
+  correct, or close.
+- If the next question would only make the conversation feel warmer, more complete, or
+  more like a form, skip it. Summarize what is clear and act, or close cleanly.
+- For review-first work, answer the practical question first. Ask another question
+  only when the read exposes an answer-changing uncertainty or a concrete action the
+  user has not yet authorized.
+- For specialized domains, do not ask a reflective "why" after the route lane and
+  target are already known; ask only for the span, place, weekday, flow, run, node,
+  output, correction, or preservation choice that permits the action.
+- For Psyche-adjacent work, do not keep exploring once the user has accepted a
+  formulation. Ask one accuracy or consent question, then save or stop.
 
 ## Abstract And Reusable Record Moves
 
@@ -2009,6 +2143,10 @@ 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.
+- For route keys with placeholders, identify the product object before calling:
+  `boxDetail`, `tripDetail`, `placeUpdate`, `userBoxUpdate`, `userBoxDelete`,
+  `automaticBoxInvalidate`, `stayUpdate`, `stayDelete`, `tripUpdate`, `tripDelete`,
+  `tripPointUpdate`, and `tripPointDelete` all need exact saved IDs in `pathParams`.
 - 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.
@@ -2157,6 +2295,8 @@ Direct action rules:
   `GET /api/v1/life-force`. Do not invent `/api/v1/life-force/overview`.
 - If the user is describing a durable baseline such as work capacity, recovery style,
   or action-point assumptions, patch the profile instead of logging a fatigue signal.
+- For the weekday-template route, fill `pathParams.weekday` from the real weekday name
+  or number before sending the update; do not bury the weekday only in the body.
 - If the user is describing a repeatable weekday rhythm, update that weekday template
   instead of treating it as a one-off right-now feeling.
 - If the user is describing how one weekday should usually feel, update that weekday
@@ -2261,6 +2401,11 @@ Direct action rules:
 
 - If the user needs the stable public contract of a flow, prefer the flow detail or
   published-output routes before a run-history read.
+- For Workbench route keys with placeholders, identify the saved flow, slug, run, and
+  node explicitly before calling. `flowDetail`, `flowById`, `flowBySlug`,
+  `publishedOutput`, `runHistory`, `runs`, `runDetail`, `runNodes`, `nodeResult`,
+  `latestNodeOutput`, `updateFlow`, `deleteFlow`, `runFlow`, and `chatFlow` all
+  depend on exact `pathParams`.
 - Treat saved-flow catalog, box catalog, run history, run detail, node result, latest
   node output, and published output as internal read lanes. With the user, ask whether
   they need the saved flow, its input contract, one run, one node, or the public

package/skills/forge-openclaw/psyche_entity_playbooks.md

@@ -83,6 +83,29 @@ Forge without turning the conversation into a worksheet.
 - Do not reopen the full origin story when the update is really about one changed
   meaning, one newly visible protection, or one new sentence the user can already say.
 
+## Psyche depth calibration
+
+Use depth calibration without minimizing the material.
+
+- Direct save: if the user offers a belief sentence, functional loop, part voice,
+  trigger episode, value phrase, event kind, emotion signature, or flashcard message
+  and asks to save or remember it, treat that as real data. Reflect the formulation,
+  ask one accuracy or consent question, then save through shared batch CRUD when the
+  wording is accepted.
+- Guided formulation: if the user is trying to understand the pattern, mode, belief,
+  schema theme, trigger chain, or emotional meaning, stay with the experience. Ask one
+  concrete question at a time, then offer a testable hypothesis once one example is
+  visible.
+- Review-first: if the user asks whether an existing Psyche record still fits, read
+  the record first and ask about the smallest part that feels newly wrong or newly
+  visible.
+- Support action: if a Psyche formulation already landed and the user asks for a
+  flashcard, task, habit, note, or link, derive it from the accepted wording instead
+  of reopening the origin story.
+- Do not use quick capture to minimize functional analysis, triggers, behavior
+  patterns, modes, beliefs, or schemas. Do not turn a simple accepted save into a
+  therapy session when the user is asking for storage.
+
 ## First reflection menu
 
 Use one brief reflection that matches the center of the moment before you deepen.
@@ -256,6 +279,38 @@ example makes the hypothesis plausible, then let the user correct the danger,
 protection, payoff, cost, or wording. If the correction is usable, revise once and move
 toward the record shape instead of asking for another broad story.
 
+## Psyche hypothesis examples
+
+These are examples of active formulation, not scripts to recite. Use them when a
+concrete example is visible and another broad question would make the user do all the
+interpretive work alone.
+
+- `behavior_pattern`: "When the feedback arrives, your body seems to read exposure
+  before you can evaluate the actual content. One hypothesis is that the over-editing
+  protects you from the feared cost of being seen as unserious, while also keeping the
+  work from reaching people. Does that fit, or is the protection somewhere else?"
+- `belief_entry`: "The sentence seems less like 'I need to improve this' and more
+  like 'If this is seen, they will discover I am not legitimate.' Is that the belief,
+  or is there a sharper wording?"
+- `mode_profile`: "This part sounds like it takes control by tightening standards so
+  no one else gets a chance to judge first. Is its job mainly protection from shame,
+  or from losing control?"
+- `mode_guide_session`: "Right now the active part seems to be trying to stop
+  exposure immediately, not solve the whole project. Does it want you to hide, fix,
+  attack, freeze, or ask for help?"
+- `trigger_report`: "The meeting itself may be the trigger, but the charged moment
+  seems to be when silence started meaning danger. Is that the sequence to preserve,
+  or did the reaction begin earlier?"
+- `event_type`: "This sounds like a recurring 'feedback becomes danger' moment rather
+  than a generic meeting event. Would future reports recognize that category?"
+- `emotion_definition`: "This dread seems to include a body brake, a prediction of
+  exposure, and an urge to disappear. Is that what distinguishes it from ordinary
+  anxiety?"
+
+After using an example-shaped hypothesis, ask exactly one correction question. If the
+user accepts or corrects it, bridge to the saveable record instead of asking for a new
+origin story.
+
 ## Hypothesis Without Cross-Examination
 
 A hypothesis is meant to reduce the user's burden of formulation, not make them prove
@@ -301,6 +356,25 @@ of leaving it as warm reflective prose.
   corrected, name the primary Forge record it becomes and ask one accuracy or consent
   question that moves toward that save.
 
+## Flashcard support sequence
+
+Use this when the user reports an urge, trigger, belief activation, mode activation,
+or asks for a card they can use in the hard moment.
+
+- Search existing `flashcard` records first using the user's exact urge sentence,
+  trigger situation, tags, and nearby Psyche wording.
+- If a matching card exists, show the card's message first before adding your own
+  support. The card is the intervention; the therapist-like wrapper should be brief.
+- If no card fits and the user wants one, formulate the cue or urge sentence and the
+  smallest usable message before asking about visual style, colors, tags, or optional
+  links.
+- When creating a new card from a belief, mode, trigger report, value, behavior, or
+  behavior pattern, preserve the accepted primary formulation first, then derive the
+  card from it. Do not turn card creation into a second broad Psyche interview.
+- Ready-to-save minimum: cue or urge sentence, one message the user can recognize
+  while activated, and at least one retrieval cue such as a tag, trigger situation, or
+  linked Psyche record.
+
 ## Psyche progressive disclosure
 
 Use this when the user has already supplied meaningful Psyche material. The next move
@@ -1096,6 +1170,9 @@ Arc:
    the message and retrieval cues are clear.
 6. If the user is in an urge right now, search existing flashcards first, show the
    matching message first, then support it with brief psychotherapy-informed guidance.
+7. If no matching card exists, create only after the cue or urge sentence and the
+   short message are clear; postpone visual styling until the intervention wording
+   works.
 
 Helpful follow-up lanes: