Format Markdown File Code Block

Purpose

Make technical Markdown notes easier to scan by formatting command-like content consistently:

• •Multi-line command sequences -> fenced bash code blocks
• •Single command lines -> inline code

Scope

Use this skill when editing .md notes that contain shell/CLI commands mixed with prose.

Formatting Rules

1. •Preserve existing non-shell fenced blocks

• •Do not alter fences such as mermaid, json, yaml, python, typescript, etc.

1. •Rebuild shell-like formatting safely

• •If needed, remove and rebuild only removable shell/text fences (bash, sh, shell, zsh, fish, text, or empty language) to get consistent output.

1. •Multi-line sequences -> fenced block

• •Group contiguous command/continuation lines into:

<command lines>

1. •Single command lines -> inline code

• •Convert a single standalone command-like line to:

command ...

1. •Never format inside fenced blocks

• •Skip all transformations while inside any existing fenced block.

Command Detection Heuristics

Treat a line as command-like when it matches one or more:

• •Starts with known CLI verbs (git, ssh, curl, docker, kubectl, python, npm, yarn, pnpm, brew, systemctl, etc.)
• •Starts with prompt form ($ ...)
• •Looks like env assignment (KEY=value)
• •Looks like shell function/brace snippets (name() {, {, })
• •Uses shell operators (|, &&, ||, >, <, ;) or explicit continuation (\\)

Heading Handling

Some notes store commands as headings (for example ### curl ... or ### -H ...).

• •If a heading body is clearly command-like, demote it to a normal command line before block formatting.
• •Keep true semantic headings unchanged.

Continuation Handling

While inside a command sequence, include continuation lines such as:

• •option lines (--foo, -H ..., including escaped variants like \-H ...)
• •assignment lines
• •lines ending with \\
• •connector/operator lines

Safety Guardrails

• •Do not wrap prose paragraphs as code.
• •Do not destroy Markdown links or note structure.
• •Keep edits deterministic and minimal.
• •Prefer one pass that is idempotent (running again should produce no further changes).

Verification Checklist

After formatting:

• •Non-shell fences (e.g., mermaid) still exist and are unchanged.
• •Multi-line commands are fenced.
• •Single command lines are inline-coded.
• •No command lines were formatted inside existing code fences.
• •Spot-check beginning, middle, and end of each modified file.

Output Policy

• •Keep original command text unchanged unless required to avoid formatting breakage.
• •Use bash language tag for inserted fenced shell blocks.