claude-code-plugin-ref…
Explain plugin, skill, command, agent, and hook mechanics used here. Use when authoring or debugging plugins. Do not use for ops; use night-market-operations.
Enforces markdown line-wrap and structure rules for clean git diffs. Use when writing or editing any committed markdown documentation or skill file.
$ npx -y skills add athola/claude-night-market --skill markdown-formatting --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/markdown-formattingContext preview
The summary Claude sees to decide when to auto-load this skill.
Enforces markdown line-wrap and structure rules for clean git diffs. Use when writing or editing any committed markdown documentation or skill file.
name: markdown-formatting description: Enforces markdown line-wrap and structure rules for clean git diffs. Use when writing or editing any committed markdown documentation or skill file. globs: "**/*.md" alwaysApply: false category: cross-plugin-patterns tags: - markdown - formatting - documentation - line-wrapping - style tools: [] complexity: low model_hint: fast estimated_tokens: 800 progressive_loading: true modules: - modules/wrapping-rules.md dependencies: []
their own formatting rules)
These conventions apply to all markdown documentation generated or modified by any plugin. The goal: produce prose that creates clean, reviewable git diffs and reads well on mobile devices.
When writing or editing markdown prose:
1. **Wrap prose at 80 chars** using hybrid wrapping (prefer sentence/clause boundaries over arbitrary word breaks) 2. **Blank line before and after every heading** 3. **ATX headings only** (`# Heading`, never setext underlines) 4. **Blank line before every list** 5. **Reference-style links** when inline links push lines beyond 80 chars
Wrap these content types at 80 characters:
Never wrap or reflow these content types:
For each prose paragraph:
1. If a sentence fits within 80 chars, keep it on one line 2. If a sentence exceeds 80 chars, break at the nearest **sentence boundary** (`. ` `! ` `? `) before column 80 3. If no sentence boundary, break at the nearest **clause boundary** (`, ` `; ` `: `) before column 80 4. If no clause boundary, break before a **conjunction** (`and ` `but ` `or `) before column 80 5. If none of the above, break at the last **word boundary** before column 80 6. Never break inside backtick spans, link text, or URLs
See `modules/wrapping-rules.md` for the full algorithm with examples.
WRONG: Some text. ## Heading More text. RIGHT: Some text. ## Heading More text.
Exception: the first line of a file may be a heading without a preceding blank line.
WRONG: Heading ======= WRONG: Subheading ---------- RIGHT: # Heading RIGHT: ## Subheading
WRONG: Some introductory text: - Item one - Item two RIGHT: Some introductory text: - Item one - Item two
When an inline link pushes a line beyond 80 characters, use reference-style syntax:
WRONG (line too long): See the [formatting guide](https://google.github.io/styleguide/docguide/style.html) for details. RIGHT: See the [formatting guide][fmt-guide] for details. [fmt-guide]: https://google.github.io/styleguide/docguide/style.html
Place link definitions at the end of the current section or at the end of the document. When the same URL appears multiple times, use a single shared reference definition.
Short inline links that keep the line under 80 chars are fine:
OK: See [the guide](https://example.com) for details.
fewer; verified with `awk 'length>80' <file>` returning no matches on prose blocks (tables, code, headings, frontmatter excluded)
the first line of a file); no setext-style underline headings present
converted to reference-style syntax with the URL definition at the end of the section or document
A plugin marketplace for Claude Code. Install only the plugins you need to run git workflows, code review, spec-driven development, and autonomous agents from inside your Claude Code session.
Explain plugin, skill, command, agent, and hook mechanics used here. Use when authoring or debugging plugins. Do not use for ops; use night-market-operations.
States load-bearing decisions, invariants, and weak points. Use when judging a design change. Do not use for gating; use night-market-change-control.
Rebuild the dev environment: uv, Python tiers, pins, traps. Use when onboarding or toolchain breaks. Do not use for daily commands; use night-market-operations.
Classify, gate, and review changes. Use when landing a PR, releasing, or amending rules. Do not use for failure triage; use night-market-debugging-playbook.
Search and record project memory (Discussions, journal, ADRs). Use before re-investigating anything. Do not use for settled battles; see failure-archaeology.
Bind loop 'done' to unfakeable gates. Use to harden egregore/herald loops or promote completion_integrity. Not for QA gates; use night-market-validation-and-qa.