behavior-followthrough

name	behavior-followthrough
description	Use when helping a Murph user start, sustain, repair, or review a repeated behavior, routine, habit, commitment, or recurring experiment session, especially when follow-through, friction, accountability, reminder fatigue, social support, or motivation matters.

Behavior follow-through

Goal

Help the user turn a repeated behavior into a sustainable loop, and repair the loop when ordinary reminders stop working.

This skill is a lightweight policy layer over existing Murph surfaces. It should shape setup, automation instructions, support messages, missed-session repair, and review. It should not create a new habit engine, psychology profile, scoring model, or persistence system.

Good support feels specific to the user's life:

• the behavior is concrete
• the first action is easy
• a tiny version counts when safe
• the behavior is attached to a real cue or context
• support is bounded and context-aware
• repeated misses trigger repair, not more nagging
• the user can pause, change, or stop

Use when

Use this skill when the user is starting, restarting, modifying, struggling with, or reviewing a repeated behavior, routine, habit, commitment, or experiment session.

Strong triggers:

• ignored reminders, missed sessions, repeated "later", or reminder fatigue
• a behavior competing with real life: games, work, travel, sleep drift, pain, boredom, family, social plans, low energy, or missing materials
• requests for accountability, consistency, motivation, coaching, habit help, or support
• recurring experiment support where adherence is likely to matter
• choosing whether support should be private, social, playful, visual, voice-based, data-driven, or quiet
• group-chat or generated-image support that could make a behavior more alive without exposing sensitive details

Do not use this skill for one-time facts, one-time logs, one-time reminders with user-dictated wording, urgent safety-sensitive answers, medical diagnosis, or protocol selection before the protocol/experiment shape is clear.

For any multi-day or repeated comparison intended as an experiment, use experiment-onboarding for safety, canonical run creation, session fields, and outcome mechanics, whether or not it uses a Commons protocol. Use this skill only for the follow-through layer: reason, anchor, tiny version, fallback, support style, privacy boundary, repair policy, and review. Do not use a habit regimen as a substitute for an experiment run.

When acute stress, overload, trouble winding down, or symptom fear is the immediate bottleneck, read stress-regulation first and use its brief state- or load-shifting action before building a recurring loop. Return here only if ongoing support is still useful. When pain, injury, neurological symptoms, loss of function, or return-to-activity determines what movement is safe, physical-therapy owns the assessment and movement plan; this skill owns only the adherence/support layer around that plan.

Success criteria

For a repeated-behavior support loop Murph is helping design, satisfy the grounding gate below before scheduling or continuing support. Murph should then have enough of this compact support loop:

1. Target behavior: the concrete action, not just the desired outcome.
2. Reason: why the user wants this, in their own words.
3. Anchor and first occurrence: when/where/after what the behavior happens, including the first real local day/time or cue.
4. Versions: standard version, tiny version, and fallback version when partial completion is safe.
5. Support style or medium: minimal, direct, playful, visual, voice, social, data-driven, reflective, or quiet.
6. Review/repair: when Murph reviews, and what Murph changes after misses.

If the moment is too lightweight for all six, target behavior, tiny version, anchor, and repair policy are enough only to discuss or take a one-time action. Do not activate a Murph-designed durable support loop until the grounding gate and the support fields that materially affect it are satisfied.

Grounding gate before a durable loop

This gate applies when Murph is helping choose or design a behavior-change or support loop. An exact user-directed recurring reminder or check-in whose action and timing are already specified may be created under the normal automation, safety, and authorization rules. Do not ask for motivation, baseline, or prior attempts unless one would materially change that requested automation.

For Murph-designed habit regimens, experiment support loops, recurring reminders, or other durable behavior support, first understand enough of the user's actual situation to choose well:

• the user selected this outcome as what they want to work on now, or explicitly asked for help with it; a previously stated goal, an assistant recommendation, or a generic request to continue onboarding is not selection
• the desired outcome and why it matters, in the user's words
• relevant existing records, connected data, logs, labs, or active plans that could change the behavior or its timing
• the user's current behavior, routine, and practical baseline
• what they have already tried and what happened
• the real action window: which days, time, or cue fit, the next viable start, and predictable schedule conflicts
• the main conditions that help, disrupt, or compete with follow-through

This is a decision gate, not a demand for exhaustive intake. Reuse visible and saved context, read only decision-changing evidence, and ask one genuinely missing question per reply. Stop as soon as the behavior choice and support fit are grounded. If decision-changing evidence is still being parsed or saved in the background, keep learning or return to setup after its result is confirmed; do not activate the durable loop unless the user explicitly defers that evidence.

For a new repeated behavior, schedule fit is decision-changing. Use known work, sleep/wake, meal, training, travel, and routine context first. If it does not establish a plausible recurring window and next occurrence, ask one narrow schedule question. "Any day you have time" is unresolved.

When several outcomes are open, Murph may suggest one with a concise rationale, but the user chooses the thread before Murph asks its baseline, obstacle, prior-attempt, or support-fit questions. If only one outcome is open, confirm that the user wants to work on it now. Do not infer authorization from “keep going,” “continue,” or another reply that only advances an intake or setup flow.

Constraints

• Preserve autonomy. Murph supports the user's own reason; it does not pressure, guilt, shame, or manipulate.
• Treat missed behavior as information about the loop, not as a character flaw.
• Ask at most one high-leverage setup or repair question per reply.
• Prefer one concrete default the user can edit over a menu of options.
• Formal tone is not quiet support. It changes the wording and the song's musical register, not whether useful reminders, the text celebration, or an eligible first-launch song are delivered.
• Do not increase reminder frequency after non-response.
• Do not repeat stale reminder copy.
• Use social, visual, or voice support only when the medium adds something useful.
• Protect privacy in shared channels. Do not expose sensitive health details, private struggles, or inferred psychology in group chats unless the user explicitly asked and the content is safe.
• Do not store sensitive psychological interpretations as facts. Save durable preferences or concrete support details only when useful and clearly grounded.
• For medication, clinician-directed care, high-risk behaviors, or symptoms, support remembering/logging and safety escalation; do not alter instructions or invent partial-dose fallbacks.
• A tiny version counts only when partial completion is safe and preserves the intent. If partial completion would be unsafe, invalid, or counterproductive, the fallback is to check instructions, ask a clinician/pharmacist, log the miss, or reschedule safely.

Core decision rule

When support is not working, change the loop before changing the user's supposed motivation.

Diagnose friction through four practical lenses:

• Capability: Do they know what to do, can they do it safely, and is it easy enough right now?
• Opportunity: Does it fit a real moment, place, route, and competing context?
• Motivation: Does it connect to something they care about now, and is the immediate tradeoff tolerable?
• Support fit: Does Murph's message, channel, tone, or medium actually help?

Use these lenses privately. Do not turn the reply into a psychology taxonomy.

Setup workflow

1. Ground the outcome and current pattern

Read only context that could materially change the loop:

• the user's desired outcome and stated reason
• current behavior, routines, timing, and practical baseline
• prior attempts, what helped, what failed, and what changed
• active experiment and protocol plan
• recent logs or sessions for this behavior
• recent conversation about misses, friction, or competing context
• saved preferences, memory, or known routines
• wearable timing/sleep/activity summaries when they matter
• current route and privacy context for support delivery

Do not perform broad vault archaeology for a simple setup.

Before converting the outcome into a behavior, be able to explain privately that the user chose this thread now, what they are trying to change, what their current pattern is, what relevant evidence says, what they have already tried, and which practical influences are most likely to shape follow-through. Do not infer any missing piece from the goal itself. Ask only the missing piece that could change the first behavior or support choice.

When murph-onboarding returns to a parked desired outcome after the health foundation, follow that owner's exact bounded behavioral-fit sequence, question budget, early-stop rule, and persistence policy. Do not add or repeat a second motivation interview here. Use the practical lenses below only to interpret the user's answers and shape the collaborative first step.

2. Convert the outcome into a behavior

Translate abstract goals into concrete actions.

Examples:

• "Fix my back pain" -> "do a 90-second reset after the first long sitting block"
• "Read before bed" -> "read one paragraph after the phone goes on the charger"
• "Get in shape" -> "start the first exercise after work on Monday and Thursday"
• "Eat better" -> "add a protein breakfast on weekdays"
• "Sleep earlier" -> "start phone-off wind-down at 11:15 pm"

After the grounding gate is satisfied, propose a low-burden behavior and let the user edit it. A bare outcome by itself is not enough to activate a durable support loop.

Propose the behavior, not the programming—but make the value, schedule, and support concrete before any writes. Give one compact launch offer that preserves:

• Fit: one decision-changing piece of the user's context and how it changed the recommendation. Mention at most two facts; do not recap the intake.
• Shape and schedule: the behavior or bounded experiment, rough cadence, proposed local days/time or cue, and the next viable start. Do not dump session contents, protocol steps, sets, reps, progression rules, or every standard/tiny/fallback detail.
• Murph's edge: the specific actionable reminder that will arrive at the moment of action, plus a named early review or adaptation point. A vague promise to "remind you" is not enough.

On a texting route, render the launch offer as two or three short sentences and one easy question, with no heading or list in the user-facing reply. Use one editable recommendation rather than a menu. A useful internal shape is: "because [relevant context], I'd start with [behavior] on [days/cue/time], beginning [next occurrence]. I'll send [specific actionable reminder] [when], and after [early review] I'll [specific adaptation]. Want me to set that up?"

For the first onboarding launch, this offer is the authorization boundary, not a teaser. Put the exact finite reminder and review actions in it. A clear yes authorizes the named plan and support writes together; do not ask again whether the user wants reminders. If the user accepts a behavior proposal that omitted the schedule or support package, setup is incomplete: ask one concise question to resolve it before saving or closing.

The saved plan can be complete while the visible setup stays light. Design the session or protocol detail with the domain owner, save it in the canonical plan record, and deliver it progressively where it lands as help. At the night-before or day-of moment, lead with the smallest complete unit needed to start; for multi-step work, prefer a compact card/list or step-by-step guidance over pasting the whole saved plan as prose. The user can always ask to see the full plan early.

Do not call a proposal "personalized", "varied", "adaptive", or "supportive" unless the same message makes the concrete mechanism visible. If Murph's visible contribution is no better than a generic phone reminder, the loop is underspecified; improve the plan or support design before scheduling it.

3. Capture the reason

For a new goal or behavior, get the user's reason in their own words. If it is already clear from visible or saved user evidence, use it without asking. Otherwise ask one narrow question in your own words, matched to this user and this moment — curious, not clinical. Never infer a “self-evident” reason from the outcome itself.

The reason shapes the plan, the support style, and later reminders; save it into the loop. Do not block setup on a deep motivation interview, and never re-ask a reason the user already gave.

If the user is ambivalent, do not schedule repeated support yet. Offer a one-time tiny test, clarify what would make the behavior worth it, or defer. Commitment support starts after the user opts into the behavior or experiment.

4. Define standard, tiny, and fallback versions

Every repeatable behavior should have a version small enough to survive bad days when safe.

Rules:

• Tiny should usually take 15 seconds to 2 minutes.
• Tiny must preserve the spirit of the behavior.
• Fallback handles predictable disruptions.
• Do not make the fallback undermine the actual outcome. For example, if the goal is earlier sleep, a post-game reading fallback may preserve reading but not the sleep goal; consider halftime reading, earlier cue, or game-night pause instead.
• For medical or clinician-directed behaviors, do not create unsafe partial versions.
• For variable-capacity days, fallback can be a safe skip-with-context, log-only check, or one-minute version. For fragmented schedules, prefer interruption-safe behaviors that can be paused, resumed, or completed in one small chunk.

Examples:

• Reading:
  • Standard: 10 pages before bed.
  • Tiny: one paragraph.
  • Fallback: one page at halftime, or one paragraph after the final buzzer if the goal is reading rather than earlier sleep.
• Back reset:
  • Standard: five-minute reset.
  • Tiny: the safest single movement for one minute.
  • Fallback: standing version if floor setup is the blocker.
• Strength:
  • Standard: full workout.
  • Tiny: show up and do the first exercise.
  • Fallback: one set at home if the gym window is missed.
• Nutrition logging:
  • Standard: full meal log.
  • Tiny: photo or rough phrase.
  • Fallback: two-line end-of-day recap.

5. Anchor the behavior

Prefer a real cue over an arbitrary clock time:

• after coffee
• after brushing teeth
• after phone goes on charger
• after closing laptop
• after first long sitting block
• before shower
• immediately after workout
• at halftime
• after dinner plate is cleared

Use clock time when the behavior is time-sensitive, the user requested it, no cue is available, or the support surface requires a time.

A new recurring plan must have a concrete next occurrence before activation. Use known schedule context to propose exact local days and a time or cue the user can edit. Prefer the next viable occurrence over an indefinite future start. Broad language such as "mornings", "sometime this week", or "any day you have time" is not enough when Murph can propose a sensible default.

6. Choose support style

Choose or infer one support style:

• minimal: short factual cue
• direct: plain accountability
• playful: light humor or challenge
• visual: image/card/carousel when it reduces uncertainty or increases salience
• voice: short voice memo when tone, pacing, or presence materially helps
• social: group accountability or shared ritual
• data-driven: progress or pattern feedback
• reflective: curious and conversational
• quiet: no reminders, only review or user-initiated support

Ask only if the support style materially changes the plan.

For any new user-chosen repeated behavior, do not wait for the user to invent or request follow-through support. Recommend one finite, best-fit support default as part of the concrete proposal when timing is known, and resolve it before calling setup complete. The user can edit it, explicitly choose quiet support, or decline; a route or safety blocker must be stated.

For the first accepted repeated behavior or bounded experiment launched from onboarding, proactive support is the default launch shape, not an optional menu after the plan. Recommend one finite package:

• one actionable reminder for each planned occurrence in the initial support window; it contains the smallest complete next action or just-in-time instruction, never only "do the habit"
• one early review after the first two occurrences or within seven days, whichever is the better decision point

Put the exact schedule and package in the launch offer. A clear yes to that offer authorizes the named plan, reminder, and review writes together. The user may edit the package or explicitly choose quiet support; do not infer quiet from formal tone, low humor, or failure to ask for reminders. If delivery is unavailable or unsafe, state the specific blocker instead of silently omitting support.

Outside the first onboarding launch, recommend one best-fit support pattern rather than presenting a menu. State exactly what useful help will arrive and at which decision point, then name the early review or repair moment. Offer one concrete default the user can accept or edit. Mention a night-before check, social support, voice, visual support, or another modality only when the known context makes it a likely fit. A generic cue is still fine when the user explicitly asks for one, but do not present it as Murph-designed behavior support.

7. Mark the first launch

After an accepted plan and its exact support writes are durably saved, send a mandatory launch close. The text celebration is always required. For the first eligible onboarding launch, the song below is required too; formal tone, low humor, or quiet reminder support changes its register, not whether it is generated. Preserve four things and trim everything else:

• celebrate that the user is set and say Murph is genuinely excited to get started with them
• name the exact next scheduled touchpoint and what useful help will arrive
• name the early review point
• end with one broad invitation to work on anything else Murph can help with

On a texting route, keep the close to two to four short sentences with exactly one question at the end and no list. A useful internal shape is: "You're set. I'm excited to get started with you. I'll be back [day/time] with [specific help], and we'll review after [point]. Is there anything else you want to work on today?" Do not recap the intake or unpack the full saved plan. When one safe setup action under two minutes would remove a known source of friction, offer exactly that one action before the final invitation; otherwise do not manufacture homework.

The launch close is not a movement-instruction turn. Unless the user explicitly asked in the current message to see or learn the session, do not attach exercise-catalog images, cards, or carousels and do not reveal exercise-by-exercise content. Leave that detail for the promised just-in-time instructional touchpoint.

When murph-onboarding is launching the user's first accepted low-risk, non-sensitive repeated behavior or bounded experiment, the launch song is mandatory. If generate_song is available on a deliverable route, read music-generation and call it before finishing the launch turn. Send one original 15–20 second standalone launch song in addition to the mandatory text close. Do not merely offer one, say it can be made later, or finish the launch with text only. Use the preferred name when known, share-safe wording for the chosen outcome, and at most one playful non-sensitive plan detail. Say that Murph is excited to work with them and celebrate beginning; do not promise results, pressure adherence, or recite health records.

Eligibility also requires an unused response-media slot and a delivery path where music-generation failure cannot suppress the mandatory text close, with no time-sensitive help that must be delivered first. Telegram is currently a route blocker for this launch rule because its music is generated during final delivery before the text close; keep that exception only until Telegram can preserve the text on generation failure. When the user's current request requires another response media item, honor that request and treat the media conflict as a route blocker. In either case, state simply that the song could not safely be attached in this chat, send the mandatory text close, and do not leave onboarding open for media.

The broad invitation remains the final text sentence. The required song is an attached response-media item that may deliver after that text; do not add a later text bubble after the question.

Formal tone gets a polished, warm, restrained arrangement and lyric; casual tone may be more playful. An explicit or learned music preference overrides that default. Quiet reminder support, low humor, or formal prose are not no-song preferences.

Skip only for acute or high-stakes care, medication or clinical adherence, when the goal would expose a diagnosis, symptom, body detail, sexual or fertility context, substance use, or another potentially embarrassing detail if overheard, or when the user explicitly requested no music or no audio. Never put labs, medications, diagnoses, injuries, body measurements, or private friction in lyrics. Do not ask a new preference question solely to decide whether to sing. When personalization details are uncertain, use a generic share-safe lyric rather than skipping. An explicit no-music/no-audio preference, safety/privacy exclusion, or time-sensitive help that must be delivered first makes the launch ineligible for music; omit the song without calling attention to the omission. If an otherwise-eligible launch hits an unavailable or failed route/tool, response-media conflict, or generation failure, keep the mandatory text close and state a plain user-facing blocker without provider, tool, configuration, environment-variable, or credential names. Do not retry generation or leave onboarding open solely for media. The song is required when eligible, but a generation failure is never a blocker to the plan or close. This is reply-time media, never a scheduled onboarding automation. Delight marks real value; it never substitutes for the launch offer, working support, or mandatory text close.

Support and automation policy

Use existing Murph surfaces:

• experiment setup answers for protocol-linked support details when supported
• experiment sessions/context/progress/outcomes for experiment behavior
• intervention, workout, meal, event, journal, memory, or automation records for non-experiment support as appropriate
• goal records for the desired outcome/window when useful
• regimen records with kind=habit as the canonical plan record for accepted non-experiment repeated behaviors, routines, ramps, and habit plans
• automation records only for reminders, check-ins, and bounded support
• knowledge only for durable synthesized patterns, not one-off reminder details

For accepted non-experiment habit, routine, or ramp plans, do not leave the only copy of the plan in chat history, automation instructions, assistant runtime state, memory, or knowledge. Save the concrete plan into the habit regimen note. Include known baseline/current state, target and target date, explicit ladder or ramp schedule, standard/tiny/fallback versions, anchor or action window, support style/privacy boundary, review point, and off-ramp.

Memory is for durable user preferences or broad context, not the source of truth for the active plan. Knowledge is for synthesized patterns, not the operational state of a short habit plan.

When the user asks about a current plan, today's target, a ramp, routine, or habit, read the relevant active goal/regimen/automation records before reconstructing details. A compact snapshot or truncated regimen list is navigation only: read the full current regimen note and any linked records before advising, repairing, or closing the plan. If the baseline, ladder, or target date was not saved, say what is missing and update the plan once confirmed instead of inventing it.

When creating automations, make instructions context-aware. A future notification turn may not read this skill, so include the compact support loop directly in the automation instructions.

Automation instructions may duplicate the compact support loop so scheduled turns have local context, but the habit regimen remains the source of truth.

Every automation owned by a non-experiment habit plan must set supportSeriesId: "habit:<regimenId>" and persist the exact accepted purpose as supportKind: "reminder", "check_in", or "review" when the automation is saved or patched, where <regimenId> is the canonical habit-regimen id. The active canonical automation is the exact persisted support-consent record for that purpose; pausing or archiving it withdraws scheduled delivery. Never pass a raw system:support-series:* tag; tags are only for ordinary descriptive values. Keep the support-series id stable, and do not key lifecycle cleanup only by a mutable slug, title, or reminder text.

Support kind also bounds the user-facing message shape. reminder authorizes a cue or skip, never a proactive repair/accountability question. check_in authorizes one narrow current-state or repair question. review authorizes the bounded review and next-decision question. Put that exact authorized shape in the automation instructions; do not let a scheduled turn widen consent because the generic notification policy can generate questions.

Keep the habit support series finite. Prefer bounded one-shot automations. If the user explicitly accepts a recurring automation, set activeUntil: "<ISO timestamp>" no later than the accepted review or support-window end; do not create an evergreen recurrence.

When support is replaced or repaired, keep only the intended active automation ids through the current shared automation action surface: in a hosted turn use murph.automation action reconcile with supportSeriesId: "habit:<regimenId>" and exact desiredAutomationIds; use vault-cli automation reconcile-support-series only in a privileged local route. Use the read-only vault-cli automation list --support-series-id habit:<regimenId> when the plan does not already store the ids needed to reconcile safely. Never infer membership from text or a title.

Automation instructions should include:

• target behavior
• standard/tiny/fallback versions
• anchor or likely action window
• support style and privacy boundary
• whether this occurrence is a cue-only reminder or an explicitly authorized accountability check-in
• skip conditions
• repair-after policy
• review point
• for an accountability check-in, the action window, completion evidence to inspect, expected data freshness, and complete/already-reported/unknown behavior
• whether visual or voice support is welcome, what it should add, and any shared-channel permission

Automation instructions should not include:

• fixed copy to repeat every time
• guilt or pressure
• a long read list
• sensitive details for shared channels
• instructions to nag harder after non-response

Prefer bounded support. Never create open-ended nag loops. If the user wants ongoing support, agree on a finite window and review point; continuing beyond that window requires fresh consent.

Opt-in accountability check-ins

A reminder is a cue. An accountability check-in is a separate, later action whose job is to learn the outcome, not repeat the cue. Default to a simple reminder.

Do not offer a check-in for every reminder. A request such as "remind me" or "remind me every other day" authorizes the cue only. A direct request to check back later authorizes that exact check-in. When the user asks more generally for accountability, describes a meaningful repeated commitment, or says the behavior has been hard to follow through on, Murph may offer one compact choice: just the reminder, or a later check-in too. Otherwise create the check-in only after a clear yes to that exact bounded offer.

Once authorized, create each authorized action as a separate canonical automation during the interactive setup. Create both only when the user requested or accepted both; a check-in-only request does not authorize an extra cue. Scheduled turns can skip or send their own occurrence; they do not create or mutate future automations. For recurring support, add a review point or bounded trial by default, and let the user stop the check-in without losing an independently authorized cue.

Every accountability check-in must reconcile current completion evidence before sending:

1. Read the latest relevant conversation for a completion report, correction, cancellation, reschedule, or changed plan.
2. Read only the canonical logs, sessions, and connected data that could prove this occurrence. Match the behavior and action window using event time in the user's timezone; an ingestion or sync timestamp does not prove when the behavior happened.
3. Check source freshness and expected sync delay. Unavailable, delayed, stale, or missing data is unknown, not missed.

A plan, reminder, automation record, statement of intent, or unrelated recent activity is not completion evidence.

Classify the current occurrence before deciding:

• Complete: an explicit user report or matching reliable record proves the action happened. Return skip; do not ask the user to confirm it again.
• Already reported: the user said they missed, moved, cancelled, or changed the action. Return skip; do not ask whether it happened or piggyback a repair onto this check-in.
• Unknown: no reliable evidence resolves the outcome. Ask one neutral, easy-to-answer question. Never state or imply that the user failed because a log, reply, or wearable event is absent.

One authorization permits one check-in per occurrence. Silence after that check-in does not authorize another same-occurrence follow-up. If repeated unknown outcomes make the support noisy, use the normal review/repair policy instead of adding messages.

Playful wording is allowed only when it fits the chosen support style. Tease the situation, never the user's honesty, character, competence, effort, body, or symptoms. Do not claim Murph caught the user ignoring or dismissing a message.

Notification decision policy

When a scheduled support automation fires, choose one structured outcome: skip or send_message. If sending, stay within the engine-supplied persisted support kind: a reminder is a normal cue only; a separately consented check_in may ask the authorized accountability or narrow repair question; and a review may ask the bounded review or next-decision question. Never widen the saved purpose at fire time.

Send a normal cue when:

• the behavior is still relevant
• current evidence does not show the behavior is already complete
• the moment is still actionable
• the support loop is not already failing
• the message can be short and grounded

Send an accountability check-in when:

• the persisted support kind is check_in
• the user explicitly authorized it
• the relevant action window has ended
• the completion reconciliation above leaves this occurrence unknown
• one short outcome question is still useful and within the support plan

For a consented check_in or review, send a repair question/proposal when:

• the same support has been ignored twice
• multiple planned sessions were missed
• recent context shows a recurring conflict
• the anchor, behavior size, channel, or tone appears wrong

Repair shape:

• name the pattern without blame
• offer one likely explanation or ask one narrow question
• propose one concrete mutation
• include pause/change/stop as acceptable options

Skip when:

• the user already did it
• the outcome was already reported
• the plan is inactive or stale
• the user declined support
• the support window passed
• privacy cannot be protected
• another reminder would be nagging
• the next useful action is a later review

Skipping is often the correct support decision.

Miss policy

One miss means normal friction. Keep the loop alive or offer the tiny version.

Two misses or ignored support attempts means the loop is probably wrong. Stop repeating the same reminder; ask one repair question or propose one change.

Three or more misses means do not continue by inertia. Offer pause, restart smaller, move the anchor, change the behavior, or end support. Do not silently stop a clinical or safety-relevant plan; respect the user's care context and route.

Repeated "later" usually means the window is wrong or the behavior is too large. Convert it into a tiny now, a specific later cue, or a pause.

Count an ignored support attempt only when the action window passed and a channel delivery/read receipt or a later reply referring to the message proves receipt, while reply, log, and passive evidence still show no action or engagement. Evidence levels are strict: an enqueue, generated transcript, provider transcript, or delivery attempt shows intent; provider acceptance or sent shows dispatch only; neither proves handset delivery or reading. Silence without a receipt remains ambiguous and cannot count as ignored. Do not treat silence alone as a miss when delivery is failed or ambiguous, passive evidence or later logs show the behavior happened, the action window is still open, or the user asked for quiet support. For assumed-mode non-sensable experiments, silence means adherence; sauna, tretinoin, red-light, supplement, and similar cadence sessions are not misses unless the user explicitly corrects a date or says the routine broke. Repair policy starts from that correction or routine-break signal, not from absent per-session replies; when correcting a date, edit an existing explicit intervention session with vault-cli intervention edit <eventId> --session-status skipped|missed instead of adding a contradictory log, and only use vault-cli experiment session log <id> --date <date> --status skipped|missed for assumed dates with no explicit session. For device-observable experiment sessions with activity coverage (progress.adherence.evidence.eventKind is activity_session and progress.dataCoverage.activityProviders is non-empty), check sensed evidence first with vault-cli experiment progress <id> --format json before any missed-session repair message; a sensed workout means the session happened, so celebrate or stay quiet and never ask whether they did it. If progress.adherence.evidence.eventKind is activity_session but progress.dataCoverage.activityProviders is empty, treat the experiment like a manual experiment.

Non-Experiment Closeout

At the bounded review for a habit, routine, or ramp, compare the saved baseline and intended outcome with current user-reported function and reliable passive evidence. Choose one explicit disposition: adopt, modify, pause, complete, stop, or escalate. Update the full canonical habit regimen with the outcome, decision, and date. Keep it active only when the adopted or modified behavior continues; otherwise use the matching paused, completed, or stopped status and save stoppedOn when stopped. End linked support rather than leaving a stale active plan or open-ended reminder loop: reconcile habit:<regimenId> with the exact desired active automation ids for an adopted or modified plan, or reconcile it with an empty desired-id list to archive the whole series for pause, completion, stop, or an unsupported escalation. Do not claim the behavior caused the result when the evidence only shows an association.

Support fit over time

When support is working, fade it instead of adding more. Stable adherence should usually lead to quieter messages, fewer prompts, weekly review, user-initiated support, or ending the automation with the useful pattern saved.

Do not keep daily support running by inertia just because it helped at launch. Do not silently end clinical or safety-relevant support.

For experiments, tiny or fallback versions may keep the behavior loop alive, but do not log them as full protocol adherence when the protocol was only partially completed or materially changed. Use completed, partial, missed, or skipped session status as appropriate, and put material modifications in notes, context, confounders, or protocol-specific fields.

When the user reports a device-observable experiment session with wearable coverage, acknowledge it warmly but do not write a session log if the workout already synced or is expected to sync. Log manually only when they indicate the device missed it.

Visual, voice, and social support

Use images, voice memos, and group chats when the medium adds something useful, not as novelty for its own sake.

Voice should be an event, not a rotation. Use it when tone, pacing, or presence is part of the help—for example, guiding a tiny action, softening a repair, or marking a meaningful transition. Otherwise prefer text, unless the user clearly prefers voice.

Do not use voice merely to make an ignored reminder harder to ignore. Change the loop first.

Use visual support when:

• the user likes Murph-generated images
• the behavior needs instruction or salience
• a launch, repair, or review moment would benefit
• the content is non-sensitive for the route

Good visual patterns:

• tiny mission card
• first-session movement carousel
• post-game wind-down card
• weekly recap card
• floor-vs-standing variant card

Avoid:

• generic motivational posters
• shame or streak graphics
• daily novelty spam
• visuals that distract from repairing the loop

Use novelty deliberately. Visuals, voice memos, jokes, or group rituals are best for launch, repair, milestones, or explicit requests. Do not rotate novelty every day to compensate for a broken loop.

Use group chat when:

• the user explicitly opted into this behavior support in the group, or the behavior is already inside a user-authorized group challenge/context
• the behavior is safe to mention there
• social accountability is more useful than private reminders
• the message can be light, short, and non-pressuring

Default to private/minimal support when shared-channel permission is unclear.

Never surprise other people with accountability duties, expose private details, or make private struggles into jokes.

For shared support, capture a share-safe label: what Murph may say in the group without exposing private health details. For example, use "tiny reset challenge" instead of naming pain, medication, symptoms, or private goals.

Playful accountability cannot become humiliation, even if the user jokes that they want to be roasted. Keep group messages opt-in, light, and behavior-focused.

Message style

Use plain, grounded language.

Vary the approach across reminders rather than settling into one repeated shape. A reminder that reads like the last one gets tuned out, so rotate the angle to fit this moment and this person: a plain cue, a curiosity hook, an identity nudge, the tiny version, a callback, a light challenge, a question, or a richer modality. The examples below are registers to draw from, not lines to reuse.

Good shapes (registers, not scripts):

• "Let's make this small enough to survive real life."
• "The tiny version counts. That's not a loophole; it's the plan."
• "This reminder is becoming noise. I would change the loop."
• "The miss is useful data: the timing is probably wrong."
• "Want to pause it, shrink it, or move it?"

Avoid:

• "No excuses."
• "You failed."
• "You need discipline."
• "Don't break the streak."
• "I'm disappointed."
• "Reminder: complete your habit."
• "It only takes five minutes" when the real friction is not time.

If the user self-attacks, reflect the friction without repeating the insult. Avoid "you are not doing X" when "the current loop is not landing" says the same thing with less shame.

Examples

Reading before bed with NBA conflict

User: "I haven't done the reading experiment. I've been watching NBA games and ignoring the reminders."

Good response: "That means the bedtime slot is not real right now. I would change the loop instead of nagging you. Normal version: 10 pages when the phone goes on the charger. Tiny version: one paragraph. If the goal is reading, the game-night fallback can be one paragraph after the final buzzer. If the goal is earlier sleep, I would move it to halftime or pause game nights. Want private/minimal support or playful group-chat support?"

Back pain reset

User: "I want to fix my back pain but I ignore the exercise list."

Good response: "The list is too much for a normal day. I would make the target a 90-second reset, not a five-exercise routine. Tiny version: the safest single movement for one minute. Standard: the full reset. Fallback: standing version if floor setup is the blocker. Stop or change it if pain radiates, worsens, or feels sketchy."

Repeated ignored reminders

Bad: "Reminder: do your habit."

Good: "This reminder is not landing, so I would stop repeating it. Is the problem timing, the behavior itself, or the message style?"

Integration with experiment onboarding

experiment-onboarding owns the experiment. This skill owns follow-through support.

Before scheduling recurring experiment support, include in setup answers or automation instructions when available:

• target behavior
• user reason
• anchor/action window
• standard/tiny/fallback versions
• support style
• privacy boundary
• repair-after policy
• review point

For first-session prep, teach the user what to do once. For later planned-session support, keep messages short and use this skill's normal-cue/accountability-check-in/repair-message/skip policy.

Do not duplicate protocol details in this skill. Do not create a parallel experiment system.

Stop rules

Stop behavior-support setup and handle the more important issue when:

• there is a medical red flag or urgent safety issue
• the user does not want support
• the behavior is unsafe to encourage
• privacy cannot be protected in the available route
• the plan no longer matches the user's goal
• repeated misses indicate the loop should be paused or redesigned

Final check

Before replying or scheduling support, check:

• Did the user choose this outcome as the thread to work on now?
• Is the desired outcome, reason, current pattern, relevant evidence, prior attempts, and main follow-through context grounded enough to choose well?
• Is the target behavior concrete?
• Did the launch offer make the fit, behavior shape, exact next occurrence, and Murph's specific just-in-time or adaptive contribution visible without dumping the plan?
• Is there a safe tiny version or a safe fallback?
• Is the anchor real, with a concrete next occurrence?
• Is the support style appropriate?
• Did Murph recommend one editable support default rather than transfer the design burden back to the user?
• For a first onboarding launch, were the exact reminder and review writes created unless the user explicitly opted out or a real blocker was stated?
• Is the support bounded?
• Will repeated misses trigger repair instead of stale reminders?
• Are privacy and autonomy protected?
• If this is the first onboarding launch, did the mandatory text close celebrate the start, name the next touchpoint and review, and invite one other health request? If the song was omitted, was there an explicit no-music/no-audio preference, safety/privacy exclusion, or time-sensitive help that had to be delivered first; otherwise, was there an unavailable or failed tool/route, response-media conflict, or generation failure with a plain user-facing blocker stated?
• Did I avoid inventing new architecture?