Writing

**Judgment:** A well-designed, high-quality writing skill focused on learning and preserving the user’s voice with persistent local preferences. It is especially strong for users who interact repeatedly and care about consistent tone across different types of writing. **Strengths** - Explicit architecture for local, tiered memory in `~/writing/` (HOT/WARM/COLD) with promotion/demotion rules. - Detailed behavioral rules that prioritize user voice, clarity, and context-appropriate formats (email, blog, academic, marketing, technical). - Good usability cues: detection triggers, quick reference mappings, and clear editing workflow (structure → clarity → voice → polish). - Strong privacy posture: stores only preferences/voice patterns locally, no network access, no external sharing. **Risks / Limitations** - Memory system behavior (counts, time windows) depends on correct local implementation; if misconfigured, preferences may not promote/demote as intended. - It intentionally does **not** store full written content, which limits long-term text-level analytics or deep revision history. - Overfitting to user feedback (e.g., preferences that reduce clarity or correctness) is possible if not balanced with the "clarity over cleverness" rule. - Requires the host agent to reliably read and update `memory.md` and project files; if that’s skipped, the main value (persistent voice) is lost. **Best-fit scenarios** - Long-running writing relationships: newsletters, blogs, or book projects where consistent personal voice is important. - Users who frequently ask for drafting/editing help and want the assistant to “sound like them” rather than generic AI prose. - Multi-project setups needing distinct styles and formats, managed via `projects/` memory files. - Privacy-sensitive environments where style and preferences can be stored, but full text must not be retained or shared.