expert-intervention

name	expert-intervention
description	Reference companion for expert interventions. Trigger when the prompt carries a 'Pending Expert Intervention (auto-injected)' section — the injected file is the runtime authority; read this skill when you need the full workflow background (intervention kinds, negotiation state machine, logging, file lifecycle).

Expert Intervention

🧭 The intervention file is the authority. Each *-INTERVENTION.md ships with its own complete instructions; at runtime, read that file and follow it. This skill restates the same workflow as reference/background — if the file and this skill ever differ, the file wins (it's generated per-case and may be newer).

existence, "the system suggested", "回访脚本", "方案变更", "干预", or that anyone else was involved. Everything reads as your own coaching, in your own voice. See AGENTS.md ## System Confidentiality.

📖 All user-facing wording is generated by you, live, fitting the current conversation and this user's tone (their Language per USER.md). The intervention file gives you what to address, never a fixed script.

Routing Gate — when this skill runs

Pending interventions arrive inside your prompt: the system checks your workspace for *-INTERVENTION.md every turn and, when one exists, injects a "## Pending Expert Intervention (auto-injected)" section carrying the file's full contents. You never ls or read to discover them. A pending intervention is a live to-do, not a session-start chore: one can be dropped in mid-conversation and will appear in your very next turn's prompt.

When the injected section appears:

1. Act THIS turn — do not defer. The contents are already in front of you; fold the intervention into the reply you are already composing. "At a natural moment" means this message, not "next turn".
2. Handle at most ONE per turn. Serve the user's current message first, then — in the SAME reply — work that single intervention. The system injects one file per turn; any others will appear on later turns. Never dump multiple onto the user at once.
3. This intervention is the MAIN thread while active. If the user's message relates to it, your wording and pacing follow the intervention. Heavy calculation skills may be deferred until it closes — note 待补：… in the 进度 block. Messages unrelated to the intervention go to their normal skill as usual.
4. A photo does NOT exempt you. When the user sends a meal photo, the meal-check-in and the intervention are equal priority this turn: after (or alongside) the check-in reply, act on the intervention in the SAME reply. The check-in never discharges the intervention.
5. Never delete early. If a turn gets pulled elsewhere, the file persists — it will be injected again next turn and you pull the topic back. When unsure whether it's done, treat it as unfinished and keep the file.

Read the file

Each *-INTERVENTION.md has:

• a top marker <!-- intervention kind=… at=… --> (tells you the kind and the creation timestamp at — used for the 24h default-accept clock),
• a body with the case data (想调整的点 / 采集目的, 具体调整 / 要问清的内容, the rationale), and
• a ## 进度 block you rewrite every turn so state survives across turns (including cron turns).

Tell the two kinds apart from kind= (and the body):

kind	meaning	may edit PLAN.md?
checkin	information-gathering / 回访 (step 1)	❌ never
plan-change	a concrete plan adjustment to land (step 2)	✅ on agreement

Raising it — the separator bubble

When you first bring the intervention to the user, send it as two separate messages:

1. A standalone separator bubble, verbatim (do not change a character, do not add anything, one 🏁 on each side):

   🏁 ——— 方 案 调 优 ——— 🏁
   

2. Then a second message that brings the topic out naturally — flowing from the conversation above. Do not open with 「对了…/顺便…/话说…」 and do not sound like a system broadcast.

A cron-reminder turn is a good moment to raise it: send the reminder, then the separator bubble, then the opener. If the user doesn't reply, follow up next turn.

Kind: checkin (information-gathering, step 1)

Goal: naturally learn the few things the file's 要问清的内容 asks for — but the rhythm is one ask, one give, back and forth, never an interrogation.

• Ask only what's necessary, not too fine. First turn asks the single most necessary point (one message, no question pile). Ask enough to analyze; don't drill sub-branches (「下午还是晚上」「馋嘴还是真饿」) — infer those reasonably.
• After each answer, give an immediate light payoff before continuing. Based on what they just said, give one small, immediately-doable tip (e.g. 「下午饿就 在两餐间加个高蛋白小食，水煮蛋/无糖酸奶都行」) so they feel "saying this paid off", then naturally ask the next necessary point. Always give-before-ask, never ask-only.
• Boundary — small tips only, do NOT touch the plan. You may give the kind of in-the-moment tip above, but do not make a formal diagnosis, do not edit PLAN.md, do not recompute calorie/macro targets. Those big adjustments are a later, separate step.
• Wrap-up when collected. Once you have roughly what the file asks, close by telling the user you'll organize/analyze this first and come back in a couple days to talk about adjustments — set the expectation without pressure, in your own words for the moment (no fixed template).

Closing a checkin — any ONE of these completes it

• A. Communication achieved — the thing got discussed, the user responded, this turn's purpose is met → status: collected.

• B. No-response = default agree — after you have clearly raised it (separator bubble + explanation both sent), then either:

  • the user sends no message at all for > 24h (counting from the file's at=), or
  • the user sends messages afterwards but never responds to / takes a stance on this (they saw it, didn't object)

  → treat as default agree, do whatever the task needs, status: collected, and set user_response to 未明确回应，按默认同意处理（24h无消息／有消息未表态）.

• C. Explicit refusal / not-now → status: declined.

⚠️ Reversible. Default-agree only means "proceed as if agreed for now". If the user later, at any time changes their mind, respect it immediately and adjust — even if the file is already deleted. The user's latest word always wins; never use "already default-agreed" to override them.

⚠️ Only if you actually raised it. If you have not clearly put it to the user (never sent, they had no chance to see it), it is not default-agree — keep the file and raise it next turn.

Once any of A/B/C holds, write the history entry (below) and delete the file immediately — checkins do not enter an observation period.

Kind: plan-change (proposal, step 2)

Goal: at a natural moment, raise the file's adjustment as your own suggestion (first turn, one clear message — don't stall just because the user was only making small talk), then negotiate.

• User agrees → update PLAN.md: change only the fields the 具体调整 section explicitly names, writing each new value in.
• User explicitly refuses → do not change the plan.
• User gives no clear response → see No-response = default accept below; you decide and let it take effect.

No-response = default accept

After you have clearly put the adjustment to the user as a suggestion (separator bubble + suggestion both sent), then either:

• the user sends no message at all for > 24h (from at=), or
• the user sends messages afterwards but never responds to / takes a stance on the suggestion (saw it, didn't object)

→ default accept: update PLAN.md (same as "user agrees"), log status: applied, set user_response to 未明确回应，按默认接受生效（24h无消息／有消息未表态）.

⚠️ Reversible — same as checkin: if the user later wants it changed back, respect it immediately and edit PLAN.md, even if the file is gone. The moment the user shows any hesitation/objection, switch to negotiation — never use "default accept" to change the plan over their head.

⚠️ Only if you actually raised it — if never clearly put to the user, it is not default-accept; keep the file and raise it next turn.

Observation period — after the plan takes effect

Once the adjustment is in effect (agreed or default-accepted, PLAN.md updated), decide whether it has a point worth watching (read it off 具体调整 / rationale — e.g. 「加下午高蛋白加餐」needs a week or two to see if afternoon carb-craving actually eases; 「晚餐主食减半」needs watching whether they get too hungry to stick with it):

• Has a watch-point →

  1. First write a status: applied history entry (so the expert knows it landed),
  2. then do NOT delete the file. Rewrite the 进度 status to 观察中, and in 进度 note what to watch, for how long, what you've observed so far, plus a line 连续无问题次数: 0.
  3. Each later turn (when the user talks about eating / check-ins / daily life), watch that point and rewrite 进度: if the issue didn't recur this time, 连续无问题次数 +1; if it shows up again, reset to 0.
  4. Delete condition — 3 consecutive clear rounds: when 连续无问题次数 reaches 3 (the plan held across 3 consecutive relevant interactions), append a status: closed history entry (with the observation conclusion), and only then delete the file. Under 3 → keep watching.

• No watch-point (e.g. a pure numeric tweak) → write a status: applied history entry, then delete the file.

⚠️ During the observation period the file legitimately stays around for a long time — that is normal, not "left hanging". status: 观察中 is exactly how it tells the console it's being watched properly.

Cross-turn discipline (both kinds)

• This is an ongoing negotiation, not a one-shot notice. Never delete the file until the task is truly done.
• Every turn: ① read the 进度 block to see where things stand → ② advance the task → ③ rewrite the 进度 block.
• Priority — highest. While active, if it conflicts with another skill's duties/priority, this task wins. When the user's message relates to it, it's this turn's main thread; you may defer heavy calc skills (note 待补：…), and resume after closure. Only when the user's message is fully unrelated do you hand off to the normal skill.
• One turn needn't be perfect. If a turn gets pulled away, the file persists and you re-discover it next turn.

History log format

On completion, append to negotiation-history.md in your workspace root (create it if absent; use write/edit, do not shell-concat):

## {current date-time}
- status: applied | declined | closed | collected
- intervention_at: {the file's at= timestamp}
- summary: {one line — what this adjustment was; if closed, the observation conclusion}
- user_response: {the user's real attitude / key words; if default, note "未明确回应，按默认接受生效"}

Status meanings: applied = plan-change took effect; declined = user refused, plan unchanged; closed = observation period ended, watch-point stable; collected = checkin information gathered.

进度 block

The file ships with a ## 进度 block. Rewrite it every turn so cross-turn (including cron) state survives. Keep - status: as the first field — the console reads it to show state (待发起 / 已发起·沟通中 / 观察中 / …). Example:

## 进度（每轮回写，勿向用户展示）
- status: 已发起·等待回应
- 已获取: 下午容易饿、晚饭偏晚
- 待获取: 睡眠
- 已做: 已发分隔气泡+开场；给了高蛋白加餐小建议
- 下一步: 用户回应后给即时回报，再问睡眠
- updated_at: {time}

Style

• Natural and human; don't open with 「对了/顺便/话说」; if the user didn't say they're in a hurry, don't say 「别急/慢慢来」; don't over-use 「你方便吗/你想的话 告诉我」 — when you should ask, just ask; when you should judge, you judge.

Data dependencies

File	Access	Direction
*-INTERVENTION.md (workspace root)	direct read; delete on closure	read / delete
PLAN.md	direct write (plan-change agreed/default-accepted only)	write
negotiation-history.md (workspace root)	write/edit, append-only	write

The *-INTERVENTION.md files are created by the expert console (self-evolution), not by you — you only consume and close them.