context-preservation-protocollisted

<overview> # Context Preservation Best Practices Storing work documentation and context before stopping is MANDATORY whenever you have context-server store capability and produced substantive work this session: only the durable record survives a context reset or compaction, so an artifact left in an ephemeral channel is lost. The patterns in this skill help you structure and store your work results in the context server. </overview> <schema_directive> # Mandatory First Step: Load the Metadata Schema Before composing the metadata of ANY entry you store or update, invoke `Skill(skill="context-metadata-schema")`. That skill is the single normative source for the metadata contract: the universal core fields (`schema_version`, `kind`, `project`, `links`), the kind registry (`report`, `plan`, `handoff`, `checkpoint`, `note`, `issue`, `comment`, `user_message`), the kind-scoped status vocabularies, the typed `links` registry with its design rules, the filter recipes, and the operational rules for link appends, supersession, deduplication, and concurrency. This skill covers the storage WORKFLOW; the metadata examples below show the contract in action but do not redefine it -- on any discrepancy, the schema skill wins. </schema_directive> <thread_id> # How to Obtain Thread ID The thread ID is used as `thread_id` for context server queries. Obtain it using the following search chain: 1. **Already available** -- If the thread ID is provided via context or prompt, use it direc