prose-craft
Use when writing fiction, editing fiction prose, reviewing chapters, or drafting scenes. Covers prose craft, dialogue mechanics, scene structure, and common failure modes in AI-assisted fiction. Trigger phrases: "write fiction", "edit chapter", "prose review", "scene draft", "dialogue check", "fiction craft", "edit this scene", "review my prose".
What this skill does
# Fiction Prose Craft Practical guardrails for writing fiction. Each rule is a thing that goes wrong in drafts — especially AI-assisted drafts — and how to fix it. ## Prose Craft **Show, don't name the sensation.** "Her hands were shaking" not "she felt afraid." The reader should infer the emotion from the physical detail. When you name the emotion directly, you shortcut the reader's experience of it. The physical detail makes them feel it; the label just tells them about it. > Before: She felt a surge of grief. > After: She opened the cabinet and his coffee mug was still there, handle turned out the way he always left it. **Concrete and sensory.** Name the object, the sound, the texture. "The fluorescent light buzzed" not "the room felt sterile." Abstraction is the default mode of lazy prose. Every time you reach for an adjective like "eerie" or "beautiful," ask what specific sensory detail would make the reader reach that conclusion on their own. **Vary sentence rhythm.** Short sentences for impact, longer for texture. Three short sentences in a row creates urgency. A long sentence after them releases it. Read the paragraph aloud — if it drones, the rhythm is flat. This isn't a rule about sentence length. It's a rule about pacing. > The door opened. He stepped in. The room was empty. She'd taken everything — > the books, the lamp, the framed photograph from their trip to the coast that > he'd always assumed meant as much to her as it did to him. **No purple prose, no cliches.** "Her eyes were pools of liquid sapphire" is not prose, it's decoration. Precision matters as much here as in technical writing — it's just applied to different material. If a phrase sounds like you've read it a hundred times before, you have, and so has the reader. **Cut adverbs that duplicate the verb.** "She whispered quietly" — the verb already did that work. "He sprinted quickly" — what else would sprinting be? Adverbs earn their place only when they contradict or modify: "she whispered fiercely" does real work because it creates tension between the quietness of whispering and the intensity of the delivery. ## Dialogue Craft **Distinct character voices.** Characters have different vocabularies, sentence lengths, and ways of noticing the world. A physicist and a nurse describe the same car accident differently — one talks about vectors and impact force, the other about the angle of the victim's arm and whether the breathing was shallow. If you can swap dialogue lines between characters and nobody notices, the voices aren't distinct enough. **Subtext over statement.** Characters rarely say exactly what they mean. The gap between what's said and what's meant is where tension lives. "I'm fine" from a character who clearly is not fine does more narrative work than a paragraph of internal monologue explaining their emotional state. > Before: "I'm really angry that you didn't tell me about the diagnosis," she said. > After: "So when were you going to mention it?" She lined up the salt and pepper shakers until they were exactly parallel. "Or was that on someone else's list?" **No "As You Know, Bob" exposition.** If a character explains something, they need a reason to explain it, and the other character needs a reason to listen. Two scientists don't explain basic physics to each other. A parent doesn't narrate their child's life history to them at dinner. If you need the reader to know something, find a context where the explanation is natural — a newcomer, a misunderstanding, a teaching moment. **Dialogue tags: "said" is invisible.** "Exclaimed," "opined," "mused," "interjected" — these draw attention to the author, not the character. The reader's eye skips over "said" and stays in the scene. Use fancy tags only when they genuinely add information that context doesn't already provide, which is almost never. **Physical beats over attribution.** A physical action between dialogue lines grounds the scene in space and does double duty. "She set down the coffee cup" tells you where they are and gives the conversation a physical rhythm. It does more work than "she said angrily" because it shows the anger (or the composure, or the distraction) instead of naming it. > "I don't think this is going to work." He turned the pen over in his fingers, clicked it twice. "Not the way you want it to." ## Scene Structure **Enter late, leave early.** Start the scene as close to the conflict as possible. Don't show characters arriving, sitting down, ordering coffee, exchanging pleasantries before the conversation that matters. The reader doesn't need the establishing shot — they'll orient themselves. Same at the end: once the scene's turn has happened, get out. The lingering goodbye is almost always fat to trim. **Every scene needs tension.** Even quiet scenes. Tension doesn't require shouting or explosions. It can be internal — a character deciding whether to open an envelope. Interpersonal — two people who disagree about something small that represents something large. Situational — a ticking clock, a narrowing set of options. If a scene has no tension at all, it's not a scene, it's a transition, and transitions should be one sentence, not three pages. **End on a turn.** Something has changed by the end of the scene. A new piece of information arrived. A decision was made. A relationship shifted, even slightly. If nothing changed, the scene may not need to exist. The turn doesn't have to be dramatic — "she realized she'd been wrong" is a turn. "They kept talking about the same thing and neither changed their mind" is not. ## AI-Fiction Failure Modes These are the patterns that show up reliably when AI writes or co-writes fiction. Knowing them makes them easier to catch and fix. **Don't resolve ambiguity too early.** If a question is meant to haunt the reader, let it haunt. AI tends to tie up loose ends because it pattern-matches toward resolution — toward the most probable next token, which is often the tidy answer. Good fiction tolerates discomfort. Not every question needs an answer in the chapter it's raised. **Don't flatten characters into one voice.** Different people process the same event differently. A pragmatist and a philosopher watching the same sunset have different interiorities — one thinks about when to leave, the other about the nature of color perception. If all your characters narrate in the same register, they're not characters, they're the model's default voice wearing different name tags. **Don't explain science at the reader.** Dramatize it through character action and consequence. If a character understands Kolmogorov complexity, they act on that understanding — they make a decision, they notice a pattern, they build something. They don't stop the plot to deliver a lecture. The reader learns what the concept means by watching it matter to someone. > Before: "Kolmogorov complexity," Dr. Chen explained, "is the length of the shortest computer program that produces a given output. It tells us about the fundamental compressibility of information." > After: Chen stared at the sequence. Too short. No structure she could see, no repeating motif — but the file was four kilobytes, not four hundred. Something was compressing it, and she didn't know what. **Don't write emotional stage directions.** "She felt a wave of sadness wash over her" is the fiction equivalent of a screenwriter's parenthetical. Instead, show what sadness looks like from inside: what the character notices (the crack in the ceiling she's never seen before), what they fail to notice (that someone asked them a question), how their body behaves (she realized she'd been holding the phone for ten minutes without dialing). **Don't open with a setting camera pan.** "The laboratory was a cavernous space filled with humming equipment and the faint smell of ozone" — this is a movie establishing shot, not prose. Start with a person doing something. Let the setting emerge from what the characte
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.