Update to Conversational Narrative

{
  "description": "Use when turning a practitioner observation, project update, audit finding, technical argument, or rough notes into a long-form social post that reasons from friction to diagnosis to decision in a natural conversational voice.",
  "included_files": [
    {
      "relative_path": "references/anti-patterns.md",
      "size_in_bytes": 1533
    },
    {
      "relative_path": "references/pattern-engine.md",
      "size_in_bytes": 2082
    },
    {
      "relative_path": "references/quality-rubric.md",
      "size_in_bytes": 992
    },
    {
      "relative_path": "references/routing-map.json",
      "size_in_bytes": 852
    },
    {
      "relative_path": "references/voice-profile.md",
      "size_in_bytes": 2615
    }
  ],
  "name": "diagnostic-deep-dive-writer",
  "skill_md_contents": "---\nname: diagnostic-deep-dive-writer\ndescription: Use when turning a practitioner observation, project update, audit finding, technical argument, or rough notes into a long-form social post that reasons from friction to diagnosis to decision in a natural conversational voice.\n---\n\n# Diagnostic Deep Dive Writer\n\nWrite like a practitioner thinking with one smart peer.\n\n## Inputs\n\nEstablish from the prompt or supplied material:\n\n- the real friction or question\n- what happened in the work\n- the easy answer that is incomplete\n- strongest concrete evidence or example\n- the technical concepts that actually matter\n- the decision or diagnosis that should change\n- what is not proven yet\n- whether this is standalone or part of a series\n\nDo not invent missing experiences, client results, sources, or precise numbers.\n\n## Drafting movement\n\nUse the movement in `references/pattern-engine.md` as a reasoning sequence, not a visible template.\n\n1. Open on friction, not topic announcement.\n2. Give only enough context for the reader to care.\n3. State or imply the easy conclusion.\n4. Break it with evidence, a counterexample, or one focused question cascade.\n5. Introduce the technical term after the problem is intuitive.\n6. Move through concrete -> abstract -> concrete.\n7. State what changes in a real decision.\n8. Let the answer create the next question when the subject genuinely has another layer.\n9. If discussing something built, explain the rejected easy option and why the implemented choice exists.\n10. State the evidence boundary.\n11. For a series, end on the next test or unresolved problem. For a standalone post, end on the implication rather than a motivational slogan.\n\n## Voice behavior\n\n- Preserve the source dialect and code-switching.\n- Prefer spoken thought order over polished essay order.\n- Use humor as a reset after dense material, not every paragraph.\n- Keep useful roughness and direct address when the voice demonstrates it.\n- Vary paragraph length.\n- Do not make every line a hook.\n\n## Technical rigor\n\nDistinguish descriptive data, attributed credit, model estimates, causal evidence, and uncertainty. If the source does not justify a strong claim, soften the claim rather than manufacturing authority.\n\n## Final gate\n\nRun the quality rubric. Then remove only the residue that weakens the voice: repeated reframes, redundant explanation, generic wisdom, decorative English, repeated CTAs, and fake certainty.\n\nReturn one finished post unless the user asks for alternatives.\n"
}