markdown-no-artificial-line-wraps

$npx mdskill add prisma/prisma-next/markdown-no-artificial-line-wraps

Writes clean Markdown without artificial line breaks

  • Prevents noisy diffs from fixed-column hard wraps in prose.
  • Depends on GitHub rendering and standard Markdown parsers.
  • Analyzes text structure to avoid breaking links mid-paragraph.
  • Outputs single-line paragraphs for optimal viewer soft-wrapping.

SKILL.md

.github/skills/markdown-no-artificial-line-wrapsView on GitHub ↗
---
name: markdown-no-artificial-line-wraps
description: >-
  Writes and edits Markdown without inserting manual hard line breaks at a fixed column
  (e.g. 72 or 80). GitHub, docs sites, and editors soft-wrap prose; artificial breaks make
  diffs noisy and reflow awkward. Use when creating or editing .md files, PR bodies, ADRs,
  READMEs, rulecards, or any Markdown where the user cares about readable source and clean
  diffs — or when the user asks to avoid "hard wrapping" or "80-column" line breaks in prose.
---

# Markdown: no artificial line wraps

## Instructions

1. **Prose paragraphs** — Keep each paragraph as **one line** (or join wrapped lines into one) so the renderer can wrap in the viewer. Do not break lines mid-sentence to stay under ~80 characters.

2. **When hard newlines are correct**
   - **Lists**: one line per list item is fine; keep item text on one line unless the item is genuinely multiple paragraphs.
   - **Headings**: single line.
   - **Fenced code blocks**: preserve author intent; do not reflow code to 80 cols.
   - **Tables, block quotes, HTML**: follow normal Markdown rules; table rows may be long.
   - **Poetry / intentional line breaks**: keep explicit breaks where semantics require them.

3. **Links and emphasis** — Prefer not splitting a paragraph so that a `[text](url)` link is alone on a continuation line in a way that obscures reading; the whole paragraph can be one line.

4. **Rationale** — GitHub and most Markdown renderers wrap to the viewport. Fixed-width breaks in source only help in raw terminals; they harm `git diff` and merge conflict resolution.

## Don’t

- Reformat existing Markdown by hard-wrapping every paragraph to 80 columns unless the user explicitly asks for that style in that file.
- Apply this rule to non-Markdown formats (e.g. `.ts` comment blocks) unless the user asks for Markdown-style prose there.

More from prisma/prisma-next

SkillDescription
adr-review>-
ast-visitor-pattern>-
bumping-biomeBumps `biome` package versions (e.g. `@biomejs/biome`) using `pnpm`, aligns `biome.jsonc` files with the new version/s across the repository and runs biome-related checks. Use when required to update `biome` to a newer version - explicitly or implicitly (e.g. after running `pnpm up`, `pnpm update`, `pnpm upgrade` without specific package names).
contrib-prOpen a high-quality external contributor PR against prisma-next. Use when the user is an outside contributor (not a Prisma maintainer) and wants to submit a change as a pull request from a fork. Encodes the contribution flow from CONTRIBUTING.md so the resulting PR passes review on the first round.
drive-agent-personasLibrary of agent personas — named bias-frames that other skills load to shift execution-time defaults. Skills name a persona by ID (e.g. "Adopt the architect persona"), and this skill resolves that ID to the persona doc that frames the executor for the rest of the task. Use when authoring a new skill that needs a particular reviewer/implementer/orchestrator stance, or when an existing skill instructs you to adopt a named persona.
drive-create-plan>
drive-create-project>
drive-create-spec>
drive-discussionDrops the agent into a structured Q&A mode that iterates with the user toward a complete understanding of a topic, then documents the outcome (project spec, plan, decision record, or whatever shape fits). The agent adopts one or more personas from the `drive-agent-personas` library — named explicitly by the user, or inferred from conversation context and announced. Typical use is design work at the start of a task, or mid-implementation when a load-bearing assumption has been falsified. Use ONLY when the user explicitly invokes this skill (e.g. "discussion mode", "pressure-test this", "let's design this", "design mode", "tech design mode", "product mode", "pm mode", "challenge my idea"). Never auto-invoke.
drive-orchestrate-plan>