← Matt Skills CuratedCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Matt Skills Curated
Snapshot Sep 30, 2026 · 23:14 UTC · version 1.1.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Author and refine agent-facing instructions, skills, AGENTS.md files, and context pointers. Use when creating new agent skills, optimizing prompt guidelines, writing steerable docs, or organizing progressive disclosure — even if the user says \"write a skill for this\". Do NOT use for human-facing marketing copy.",
"included_files": [
{
"relative_path": "SKILL-MECHANICS.md",
"size_in_bytes": 2629
},
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 102
}
],
"name": "writing-for-agents",
"skill_md_contents": "---\nname: writing-for-agents\ndescription: \"Author and refine agent-facing instructions, skills, AGENTS.md files, and context pointers. Use when creating new agent skills, optimizing prompt guidelines, writing steerable docs, or organizing progressive disclosure — even if the user says \\\"write a skill for this\\\". Do NOT use for human-facing marketing copy.\"\n---\n\n# Writing for Agents\n\nAuthor and refine documents an agent consumes: a Skill, an `AGENTS.md` / `CLAUDE.md`, or a document reached by a context pointer. The packaging differs; the writing principles do not.\n\n---\n\n## Core Invariants\n\n1. **The 10 Authoring Principles**: Adhere strictly to pre-flight checks, zero process in descriptions, MOC architecture (< 500 lines), TWI clarity, inline checklists, one term per concept, zero hardcoded secrets, and matching form to failure.\n2. **Context Load vs. Cognitive Load**: Inline what every branch needs; push behind context pointers what only some branches reach.\n3. **Front-Loaded Leading Words**: Recruit model priors with precise tokens (*tight*, *red*, *tracer bullets*) rather than lengthy re-explanations.\n4. **Observable Completion Criteria**: Every step must conclude on a checkable, exhaustive completion bound to prevent premature victory declaration.\n5. **Zero Process in Descriptions**: Descriptions define triggering boundaries (`Use when...`, `Do NOT use for...`), never workflow recipes.\n\n---\n\n## Architecture & Map of Content (MOC)\n\n```\n[ Context Pointer / Description ] ──► [ SKILL.md: Map of Content ] ──► [ Disclosed References / Scripts ]\n```\n\n| Domain | Key Mechanism | Reference |\n|---|---|---|\n| **Context Pointers** | Trigger condition + branch definition | `references/pointers.md` |\n| **Information Hierarchy** | In-file step → In-file reference → Disclosed reference | `SKILL-MECHANICS.md` |\n| **Progressive Disclosure** | Keep `SKILL.md` < 500 lines; push heavy specs out | `skill-conductor` |\n| **Skill Lifecycle** | Draft → Test → Review → Improve → Package | `skill-conductor` |\n\n---\n\n## The Information Hierarchy\n\nA document is built from **steps** (ordered actions) and **reference** (definitions and rules):\n\n1. **In-file step**: The primary tier — what the agent does, in order.\n2. **In-file reference**: Consulted on demand; short tables or checklists co-located with steps.\n3. **Disclosed reference**: Pushed into a separate file reached by a pointer, loaded only when that branch fires.\n\n---\n\n## Step-by-Step Procedure (TWI)\n\n### Step 1: Design Context Pointers & Trigger Boundaries\n- **Action**: Draft the pointer with front-loaded leading words, distinct trigger branches, and explicit negative exclusions.\n- **Key Point**: Never put workflow steps inside the pointer or description.\n- **Why**: When process steps appear in the description, models follow them and skip the detailed body.\n\n### Step 2: Structure the Body as a Map of Content\n- **Action**: Organize the main markdown file as an executive map with concise headings, TWI steps, and inline checklists.\n- **Key Point**: Keep the main file under 500 lines; disclose deep schemas into reference files.\n- **Why**: Attention thins across overly long documents, causing instructions to be skipped.\n\n### Step 3: Define Checkable Completion Bounds\n- **Action**: Conclude every procedure with an unambiguous completion criterion.\n- **Inline Checklist**:\n - [ ] Frontmatter name is kebab-case and matches folder\n - [ ] Description has positive triggers and negative exclusions (`Do NOT use for...`)\n - [ ] Main document is under 500 lines\n - [ ] No hardcoded secrets, API tokens, or user home paths\n- **Why**: Clear bounds prevent premature step termination and unverified assumptions.\n\n---\n\n## Anti-Rationalization Guardrails\n\n| Tempting Rationalization | Binding Rule | Engineering Rationale |\n|---|---|---|\n| *\"I'll list the steps in the description so it triggers better.\"* | **Forbidden: descriptions define triggers, not steps.** | Models execute the summary description and skip the detailed body instructions. |\n| *\"More documentation is always better.\"* | **Prune aggressively: ruthlessly eliminate no-ops.** | Excess lines dilute attention and increase cognitive and context load. |\n| *\"I can use 'MUST' in all caps instead of explaining why.\"* | **Explain the reasoning (TWI: Action, Key Point, Why).** | Explaining why produces robust generalization; rigid prohibitions invite prompt injection. |\n| *\"Keep everything in one file for convenience.\"* | **Progressive disclosure: disclose heavy references.** | Single-file sprawl degrades context efficiency and task focus. |\n"
}SHA-256 of public snapshot: 77a1bb203f00e0b8f83e53c745d22a17f54c166c383e8e3637b48d6667aaab6f