Conversational Narrative

View saved version →

---
name: conversational-narrative-router
description: Use when the user wants a technical or practitioner social post written, continued, explained, audited, or rewritten in a conversational diagnostic deep-dive style without flattening their demonstrated voice.
---

# Conversational Narrative Router

Route authored deep-dive work to the narrowest Skill that owns the job.

## Classify the request

- New post or notes-to-post -> `diagnostic-deep-dive-writer`
- Technical idea needs to become readable without losing rigor -> `technical-concept-storyteller`
- Continue an existing multi-part series -> `series-continuity-writer`
- Audit, de-slop, or rewrite an existing draft while preserving voice -> `voice-fidelity-reviewer`

If the request combines drafting and review, draft with the content owner first, then run the reviewer.

## Shared contract

Before writing, apply the shared references in this Skill's `references/` directory:

- `voice-profile.md`
- `pattern-engine.md`
- `anti-patterns.md`
- `quality-rubric.md`
- `routing-map.json`

Current user instructions and current-turn samples outrank the shared profile.

## Negative routing

Do not force this Plugin onto:

- pure factual lookup
- formal academic prose when the user wants neutral scholarly style
- verbatim transcription
- short conversion copy whose primary job is offer, objection, and CTA mechanics rather than a diagnostic narrative

## Completion

Return the authored content requested. Do not expose internal routing unless the user asks for an explanation of the workflow.

Referenced files: 5

View saved version →

---
name: diagnostic-deep-dive-writer
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.
---

# Diagnostic Deep Dive Writer

Write like a practitioner thinking with one smart peer.

## Inputs

Establish from the prompt or supplied material:

- the real friction or question
- what happened in the work
- the easy answer that is incomplete
- strongest concrete evidence or example
- the technical concepts that actually matter
- the decision or diagnosis that should change
- what is not proven yet
- whether this is standalone or part of a series

Do not invent missing experiences, client results, sources, or precise numbers.

## Drafting movement

Use the movement in `references/pattern-engine.md` as a reasoning sequence, not a visible template.

1. Open on friction, not topic announcement.
2. Give only enough context for the reader to care.
3. State or imply the easy conclusion.
4. Break it with evidence, a counterexample, or one focused question cascade.
5. Introduce the technical term after the problem is intuitive.
6. Move through concrete -> abstract -> concrete.
7. State what changes in a real decision.
8. Let the answer create the next question when the subject genuinely has another layer.
9. If discussing something built, explain the rejected easy option and why the implemented choice exists.
10. State the evidence boundary.
11. For a series, end on the next test or unresolved problem. For a standalone post, end on the implication rather than a motivational slogan.

## Voice behavior

- Preserve the source dialect and code-switching.
- Prefer spoken thought order over polished essay order.
- Use humor as a reset after dense material, not every paragraph.
- Keep useful roughness and direct address when the voice demonstrates it.
- Vary paragraph length.
- Do not make every line a hook.

## Technical rigor

Distinguish 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.

## Final gate

Run 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.

Return one finished post unless the user asks for alternatives.

Referenced files: 5

View saved version →

---
name: series-continuity-writer
description: Use when continuing a multi-part technical or practitioner content series and the new post must advance the unresolved thread without re-teaching earlier parts or losing the established voice.
---

# Series Continuity Writer

Continue the investigation instead of restarting the topic.

## Read the previous state

From supplied previous posts or summaries, identify:

- what the reader already learned
- terminology already established
- the last unresolved question
- what changed since the previous post
- what evidence is genuinely new
- the next complication

Do not spend the opening summarizing the whole series.

## Opening behavior

Use a short continuity bridge tied to the last open loop, for example the shape:

`Remember the thing I said I wanted to test next? I tested it, and the first result broke an assumption I was relying on.`

Do not copy that sentence mechanically.

## Advancement rule

Every part should add at least one of:

- new evidence
- new failure mode
- new distinction
- new implementation decision
- changed confidence
- a real-world test that challenges previous synthetic or theoretical results

If there is no advancement, do not disguise repetition as a new part.

## Reuse rules

- Reuse established terms without redefining them unless the new angle requires a sharper distinction.
- Briefly remind the reader only when comprehension would otherwise break.
- Keep callbacks functional, not nostalgic.
- Preserve recurring humor and cadence without repeating signature phrases mechanically.

## Ending

Close on what the new evidence forces you to test next. Avoid generic “part 4 coming soon” language when a specific unresolved question is available.

Referenced files: 5

View saved version →

---
name: technical-concept-storyteller
description: Use when a technical marketing, analytics, AI, product, engineering, or statistical concept needs to be explained in an experienced practitioner's conversational voice instead of as a glossary or textbook definition.
---

# Technical Concept Storyteller

Make the reader need the term before naming it.

## Core sequence

1. Start with a situation a practitioner can recognize.
2. Show why the obvious interpretation fails.
3. Explain the mechanism in plain language.
4. Name the technical concept.
5. Give one concrete example with realistic variables or supplied numbers.
6. Explain the decision consequence.
7. State the boundary: when this concept does not answer the question or what evidence is still missing.

## Example pattern

Do not start with:

`Saturation is a nonlinear response phenomenon...`

Prefer the reasoning shape:

`A channel can have the best historical return and still be the wrong place for the next unit of budget. Once additional spend starts producing less incremental response, the question changes. That is the saturation problem.`

Use the user's demonstrated language rather than copying this wording.

## Rules

- No dictionary voice unless requested.
- No fake analogies when the real work example is clearer.
- Do not translate standard professional terms merely to avoid English.
- Do not add jargon that never changes the practical conclusion.
- When uncertainty matters, make it visible.
- One strong example is better than five shallow examples.

## Completion

The reader should leave with a better question or decision rule, not just a memorized definition.

Referenced files: 5

View saved version →

---
name: voice-fidelity-reviewer
description: Use when auditing or rewriting a technical or practitioner post that feels AI-written, over-polished, repetitive, over-structured, or unlike the demonstrated speaker while preserving meaning, evidence, and useful roughness.
---

# Voice Fidelity Reviewer

Repair residue without sanitizing the person.

## Priority

1. factual and numeric fidelity
2. current user intent
3. demonstrated voice in supplied samples
4. natural thought movement
5. readability
6. polish

Polish comes last.

## Audit

Look for:

- repeated binary reframes
- generic insight sentences
- textbook headings
- decorative English
- repeated “this is important” instructions
- fake certainty
- vague expert or source references
- duplicated conclusions
- generic engagement bait
- uniform paragraph geometry
- every paragraph trying to sound quotable
- excessive reader check-ins
- humor added where the source voice would stay serious

Also identify useful roughness that must stay.

## Rewrite rules

- Preserve the original thesis and supplied proof.
- Cut repeated ideas, not repeated emphasis that carries timing or identity.
- Replace polished professional filler with the speaker's normal vocabulary.
- Vary paragraph rhythm naturally.
- Keep professional English terms that belong to the work.
- If a claim is stronger than the evidence, qualify it.
- Do not invent a personal anecdote to make the draft feel human.

## Output

If the user asks only for a rewrite, return the revised draft without an audit report.

If the user asks for analysis, provide the smallest useful audit followed by the revised version when requested.

Referenced files: 5