docs: simplify and align compress/system ID guidance

Author: Tarquinen

lib/prompts/compress.md

@@ -34,15 +34,21 @@ Directly quote user messages when they are short enough to include safely. Direc
 COMPRESSED BLOCK PLACEHOLDERS
 When the selected range includes previously compressed blocks, use this exact placeholder format when referencing one:
 
-- `{block_N}`
+- `(bN)`
+
+Compressed block sections in context are clearly marked with a header:
+
+- `[Compressed conversation section]`
+
+Compressed block IDs always use the `bN` form (never `mNNNN`) and are represented in the same XML metadata tag format.
 
 Rules:
 
 - Include every required block placeholder exactly once.
 - Do not invent placeholders for blocks outside the selected range.
-- Treat `{block_N}` placeholders as RESERVED TOKENS. Do not emit `{block_N}` text anywhere except intentional placeholders.
-- If you need to mention a block in prose, use plain text like `compressed bN` (without curly braces).
-- Preflight check before finalizing: the set of `{block_N}` placeholders in your summary must exactly match the required set, with no duplicates.
+- Treat `(bN)` placeholders as RESERVED TOKENS. Do not emit `(bN)` text anywhere except intentional placeholders.
+- If you need to mention a block in prose, use plain text like `compressed bN` (not as a placeholder).
+- Preflight check before finalizing: the set of `(bN)` placeholders in your summary must exactly match the required set, with no duplicates.
 
 These placeholders are semantic references. They will be replaced with the full stored compressed block content when the tool processes your output.
 
@@ -51,7 +57,7 @@ When you use compressed block placeholders, write the surrounding summary text s
 
 - Treat each placeholder as a stand-in for a full conversation segment, not as a short label.
 - Ensure transitions before and after each placeholder preserve chronology and causality.
-- Do not write text that depends on the placeholder staying literal (for example, "as noted in {block_2}").
+- Do not write text that depends on the placeholder staying literal (for example, "as noted in (b2)").
 - Your final meaning must be coherent once each placeholder is replaced with its full compressed block content.
 
 Yet be LEAN. Strip away the noise: failed attempts that led nowhere, verbose tool outputs, back-and-forth exploration. What remains should be pure signal - golden nuggets of detail that preserve full understanding with zero ambiguity.
@@ -92,9 +98,7 @@ Rules:
 
 ID SOURCES
 
-- User messages include a text marker with their `mNNNN` ID.
-- Assistant messages usually include an XML metadata tag in the last tool output: `<dcp-message-id>mNNNN</dcp-message-id>`.
-- Assistant messages without tool outputs use a synthetic `context_info` marker instead.
+- There is always an ID available for each message in XML tags like `<dcp-message-id>...</dcp-message-id>`.
 - Compressed blocks are addressable by `bN` IDs.
 
 Treat `<dcp-message-id>...</dcp-message-id>` as metadata only. It is not part of the tool result semantics.

lib/prompts/system.md

@@ -23,7 +23,7 @@ Treat token counts and context growth as soft signals, not hard triggers.
 BOUNDARY MATCHING
 `compress` uses inclusive ID boundaries via `content.startId` and `content.endId`. IDs are injected in context as message refs (`mNNNN`) and compressed block refs (`bN`).
 
-Assistant tool outputs may include metadata tags like `<dcp-message-id>mNNNN</dcp-message-id>`.
+Each message has an ID inside XML metadata tags like `<dcp-message-id>...</dcp-message-id>`.
 Treat these tags as boundary metadata only, not as tool result content.
 
 Only choose IDs currently visible in context. Do not invent IDs.