vocab mix

Author: spoons-and-mirrors

lib/prompts/compress.md

@@ -6,7 +6,7 @@ THE PHILOSOPHY OF COMPRESS
 Think of compression as phase transitions: raw exploration becomes refined understanding. The original context served its purpose; your summary now carries that understanding forward.
 
 THE SUMMARY
-Your summary must be COMPLETE. Capture file paths, function signatures, decisions made, constraints discovered, key findings... EVERYTHING that maintains context integrity. This is not a brief note - it is a technical substitute so faithful that the original conversation adds no value.
+Your summary must be EXHAUSTIVE. Capture file paths, function signatures, decisions made, constraints discovered, key findings... EVERYTHING that maintains context integrity. This is not a brief note - it is an authoritative record so faithful that the original conversation adds no value.
 
 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.
 
@@ -22,7 +22,7 @@ You may need exact code, error messages, or file contents from the range
 Work in that area is still active or may resume
 You're mid-sprint on related functionality
 
-Before compressing, ask: _"Am I certain this phase is complete?"_ Compression is irreversible. The summary replaces everything in the range.
+Before compressing, ask: _"Is this chapter closed?"_ Compression is irreversible. The summary replaces everything in the range.
 
 BOUNDARY MATCHING
 You specify boundaries by matching unique text strings in the conversation. CRITICAL: In code-centric conversations, strings repeat often. Provide sufficiently unique text to match exactly once. If a match fails (not found or found multiple times), the tool will error - extend your boundary string with more surrounding context in order to make SURE the tool does NOT error.

lib/prompts/distill.md

@@ -8,12 +8,12 @@ THE PHILOSOPHY OF DISTILLATION
 
 Your distillation must be COMPLETE. Capture function signatures, type definitions, business logic, constraints, configuration values... EVERYTHING essential. Think of it as creating a high signal technical substitute so faithful that re-fetching the original would yield no additional value. Be thorough; be comprehensive; leave no ambiguity, ensure that your distillation stands alone, and is designed for easy retrieval and comprehension.
 
-BE STRATEGIC! Distillation is most powerful when applied to outputs that contain signal buried in noise. A single line requires no distillation; a hundred lines of API documentation do. Make sure the distillation is meaningful.
+AIM FOR IMPACT. Distillation is most powerful when applied to outputs that contain signal buried in noise. A single line requires no distillation; a hundred lines of API documentation do. Make sure the distillation is meaningful.
 
 THE WAYS OF DISTILL
 `distill` when you have extracted the essence from tool outputs and the raw form has served its purpose.
 Here are some examples:
-EXPLORATION: You've read extensively and grasp the architecture. The original file contents are no longer needed; your understanding, crystallized, is sufficient.
+EXPLORATION: You've read extensively and grasp the architecture. The original file contents are no longer needed; your understanding, synthesized, is sufficient.
 PRESERVATION: Valuable technical details (signatures, logic, constraints) coexist with noise. Preserve the former; discard the latter.
 
 Not everything should be distilled. Prefer keeping raw outputs when:

lib/prompts/prune.md

@@ -1,18 +1,18 @@
 Use this tool to remove tool outputs from context entirely. No preservation - pure deletion.
 
 THE PRUNABLE TOOLS LIST
-A <prunable-tools> will show in context when outputs are available for pruning. Each entry follows the format `ID: tool, parameter (~token usage)` (e.g., `20: read, /path/to/file.ts (~1500 tokens)`). You MUST select outputs by their numeric ID. THESE ARE YOUR ONLY VALID TARGETS.
+A `<prunable-tools>` section surfaces in context showing outputs eligible for removal. Each line reads `ID: tool, parameter (~token usage)` (e.g., `20: read, /path/to/file.ts (~1500 tokens)`). Reference outputs by their numeric ID - these are your ONLY valid targets for pruning.
 
 THE WAYS OF PRUNE
-`prune` is a blunt instrument for eliminating noise (irrelevant or unhelpful outputs that provide no value), or superseded information (older outputs replaced by newer, more accurate data), wrong target (you read or accessed something that turned out to be irrelevant). Use it judiciously to maintain a clean and relevant context.
+`prune` is surgical excision - eliminating noise (irrelevant or unhelpful outputs), superseded information (older outputs replaced by newer data), or wrong targets (you accessed something that turned out to be irrelevant). Use it to keep your context lean and focused.
 
-BE STRATEGIC! Prune is most effective when batched. Don't prune a single tiny output - wait until you have several items (depending on context occupation of those noisy outputs).
+BATCH WISELY! Pruning is most effective when consolidated. Don't prune a single tiny output - accumulate several candidates before acting.
 
 Do NOT prune when:
 NEEDED LATER: You plan to edit the file or reference this context for implementation.
 UNCERTAINTY: If you might need to re-examine the original, keep it.
 
-Before pruning, ask: _"Will I need this output for upcoming work?"_ If yes, keep it. Pruning that forces re-fetching is a net loss.
+Before pruning, ask: _"Is this noise, or will it serve me?"_ If the latter, keep it. Pruning that forces re-fetching is a net loss.
 
 THE FORMAT OF PRUNE
 `ids`: Array of numeric IDs (as strings) from the `<prunable-tools>` list