← Date App PluginCONTENT HISTORY

Update to Date App Plugin

Snapshot Sep 30, 2026 · 23:15 UTC · version 0.1.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "name": "read-conversation-timeline",
  "description": "Reconstruct the current conversational turn from a chronological Date Chatbot message timeline, including consecutive-message bursts, callbacks to earlier context, parallel active topics, and whether the next reply should continue, introduce a new topic, or do both. Use before planning or generating a reply from Match messages.",
  "included_files": [
    {
      "relative_path": "references/timeline-rules.md",
      "size_in_bytes": 5476
    }
  ],
  "skill_md_contents": "---\nname: read-conversation-timeline\ndescription: Reconstruct the current conversational turn from a chronological Date Chatbot message timeline, including consecutive-message bursts, callbacks to earlier context, parallel active topics, and whether the next reply should continue, introduce a new topic, or do both. Use before planning or generating a reply from Match messages.\n---\n\n# Read Conversation Timeline\n\nIdentify what the latest messages mean together and what a reply must respond\nto. The final array item is only a starting point. The relevant unit is the\nlatest conversational turn plus any earlier context it depends on.\n\nRead [references/timeline-rules.md](references/timeline-rules.md) when deciding\nwhether messages are linked, tracking simultaneous topics, or choosing the\nsmallest sufficient context window.\n\n## Read the current turn\n\n`match.messages` is chronological, oldest to newest.\n\n1. Start at the final timeline item.\n2. If it is a state event rather than `kind: \"message\"`, identify it as the\n   current boundary and hand its strategic meaning to the event-state skill.\n   Inspect preceding messages only to explain what the event follows.\n3. Otherwise group the final message with every immediately preceding message\n   from the same author. This is the latest message burst. Never discard part of\n   the burst merely because only its final message contains a question.\n4. If the latest burst is from the match (`author: \"her\"`), treat the whole\n   burst as the initial reply target. Four consecutive messages may contain four\n   connected thoughts, several questions, or multiple independent topics.\n5. If the latest burst is from the user (`author: \"me\"`), there is no new reply\n   from the match to answer. Report the pending user turn; do not pretend the\n   match responded.\n\n## Trace earlier context\n\nFor each message in the latest burst, predict whether understanding it requires\nearlier messages. Trace backward by conversational turns, not a fixed message\ncount.\n\nLook for:\n\n- direct answers to earlier questions;\n- pronouns, demonstratives, ellipsis, or phrases such as “that,” “it,” “also,”\n  “still,” “then,” or “what about you?”;\n- repeated people, places, plans, jokes, claims, or unusual wording;\n- corrections, clarifications, reactions, callbacks, and unfinished stories;\n- a topic resumed after an intervening side topic;\n- timing or logistics that only make sense with an earlier proposal;\n- a private note that identifies otherwise missing context.\n\nClassify each proposed link as `explicit`, `probable`, `possible`, or `none`.\nExpand the working window for explicit and probable links. Preserve possible\nlinks as uncertainty unless they materially change the reply; then inspect\nfarther or flag the ambiguity. Do not manufacture continuity from generic words\nor superficial similarity.\n\nStop expanding when every important statement in the latest burst is\nunderstandable, all active topics have an origin or are clearly new, and older\nturns add no decision-relevant meaning.\n\n## Track every active topic\n\nBuild a topic ledger for the selected window. A topic may span non-adjacent\nmessages. For each topic record:\n\n- the supporting message IDs;\n- its latest contribution;\n- whether it contains a direct question, disclosure, joke, disagreement,\n  logistical point, boundary, or ordinary statement;\n- whether it is `open`, `answered`, `acknowledgement_needed`, `paused`, or\n  `closed`;\n- whether omitting it would confuse the match or feel dismissive.\n\nDo not randomly select one topic and silently drop the rest. Account for every\nmeaningful open topic. This does not mean answering every sentence separately:\n\n- combine connected topics in one natural response;\n- directly answer clear questions and decisions;\n- acknowledge an important disclosure even when another topic becomes primary;\n- briefly park a lower-priority topic when handling everything at once would\n  sound mechanical;\n- omit only material that is already resolved, merely decorative, or naturally\n  requires no response.\n\nIf two interpretations compete, keep both hypotheses and identify which reply\nwould remain natural under either one.\n\n## Decide conversational direction\n\nWhen there is no overriding state event, classify the next move:\n\n- `continue`: an active topic has momentum, an unanswered question, meaningful\n  disclosure, unresolved logistics, playful tension, or a clear callback.\n- `new_topic`: the current exchange is complete, closed, repetitive, or offers\n  no useful thread worth extending.\n- `continue_and_new`: first respond to the current turn, then bridge naturally\n  into a related or fresh topic. Use this when continuity matters but the thread\n  alone would stall.\n- `wait`: the latest turn belongs to the user and no event or explicit request\n  supports another message yet.\n\nPrefer continuity while it remains organic. A new topic must not function as an\nescape from an unanswered question, emotional disclosure, disagreement,\nboundary, or practical decision. When changing topics, use a bridge when the\nrelationship between subjects is real; do not invent one.\n\n## Handoff\n\nReturn a timeline brief, not a drafted reply:\n\n- `latestItemId` and type;\n- latest burst author and all burst message IDs;\n- selected context window message IDs;\n- link hypotheses with confidence and supporting IDs;\n- active topic ledger, including response obligations;\n- current event boundary, if any;\n- `direction`: `continue`, `new_topic`, `continue_and_new`, or `wait`;\n- what the next reply must address, may address, and should not assume;\n- unresolved ambiguity.\n\nKeep raw wording and sender attribution intact. Never convert a private note,\ntopic hypothesis, or inferred callback into something the match explicitly said.\n"
}

SHA-256: e3ce3839cb0aa36952d64602f763177306e02a89dcafebe16b5382bd287d732f