Przejdź do treści
Biblioteka skilli
Dokumenty i biuro · Pisanie

markdown

/markdown

Pisze i poprawia pliki Markdown w repozytorium dotfiles zgodnie z konfiguracją markdownlint i ustawieniami zawijania oxfmt, uruchamiając markdownlint-cli2 --fix oraz oxfmt.

Repozytorium
dotfiles ↗
Licencja
MIT
Ostatnia zmiana repozytorium
26.10.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
1
Adresy URL w SKILL.md
4
Przestarzałość

Brak sygnałów. Repozytorium zmienione 26.10.2026, bez odwołań do wycofanych modeli i API.

Licencja

MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.

Co sprawdzić przed instalacją
  • SKILL.md zawiera komentarze HTML (1). Nie widać ich w podglądzie Markdown, a model je czyta.

Co robi i kiedy

Pisze i poprawia pliki Markdown w repozytorium dotfiles zgodnie z konfiguracją markdownlint i ustawieniami zawijania oxfmt, uruchamiając markdownlint-cli2 --fix oraz oxfmt.

Oryginalny opis (EN)

WHAT: Author and edit markdown in this dotfiles repo so it conforms to the project markdownlint config and oxfmt prose-wrap settings, and runs through `markdownlint-cli2 --fix` and `oxfmt` cleanly. WHEN: User asks to write, edit, restructure, or fix lint on any `.md` / `.mdc` file. Defer to the more specific `commit-message`, `doc-sync`, or skill/plan/AGENTS authoring guides when those apply. DO-NOT: Run prettier instead of oxfmt, mass-rewrap mid-edit, or add a `README.md` inside a skill folder.

Jak działa

  1. When to use this skill
  2. Repo configuration at a glance
  3. Rules to satisfy
  4. Style conventions to layer on top of lint
  5. oxfmt and prose wrap
  6. Workflow
  7. Validation gates
  8. Common pitfalls
  9. Quick reference
  10. Related docs
Sekcje z nagłówków SKILL.md, w oryginale · 211 linii, 1 962 słów
Podgląd SKILL.md
---
name: markdown
description:
  'WHAT: Author and edit markdown in this dotfiles repo so it conforms to the project markdownlint config and oxfmt
  prose-wrap settings, and runs through `markdownlint-cli2 --fix` and `oxfmt` cleanly. WHEN: User asks to write, edit,
  restructure, or fix lint on any `.md` / `.mdc` file. Defer to the more specific `commit-message`, `doc-sync`, or
  skill/plan/AGENTS authoring guides when those apply. DO-NOT: Run prettier instead of oxfmt, mass-rewrap mid-edit, or
  add a `README.md` inside a skill folder.'
---

# Markdown authoring and linting

Single source of truth for "is this markdown going to land cleanly" in this repo. Wraps the project markdownlint rules,
the custom `authoring-guide` and `skill-authoring-guide` rules from `@public-projects/agents-tooling`, and oxfmt's
markdown prose-wrap behavior into one workflow.

The deep authoring conventions live in
[node_modules/@public-projects/agents-tooling/guides/skill-authoring-guide.md](../../../node_modules/@public-projects/agents-tooling/guides/skill-authoring-guide.md)
and
[node_modules/@public-projects/agents-tooling/guides/authoring-guide.md](../../../node_modules/@public-projects/agents-tooling/guides/authoring-guide.md);
read them before writing a new SKILL.md, AGENTS.md, reference doc, or plan. This skill covers the formatting and linting
surface only.

## When to use this skill

Apply whenever the user asks to:

- Add or edit any `.md` / `.mdc` file in this repo (root docs, `docs/**`, `plans/**`, `.agents/skills/**`,
  `config/**/skills/**`, package READMEs, etc.).
- Fix `markdownlint-cli2` or `oxfmt` failures on a markdown file.
- Restructure or rewrap an existing markdown file.
- Convert ad-hoc markdown into something safe to commit through `lint-staged`.

Stop and defer when the task is governed by a more specific skill:

- Commit messages and PR descriptions -- use `commit-message`.
- `REFERENCE.md` / `README.md` doc-sync after a shell-surface change -- use `doc-sync`.
- A new SKILL.md, AGENTS.md, or active plan -- still use this skill for formatting, but the structural rules live in the
  upstream authoring guides linked above.

## Repo configuration at a glance

Three config files drive the rules; do not duplicate or override them in prose, just satisfy them.

| File                           | What it sets                                                                                          |
| ------------------------------ | ----------------------------------------------------------------------------------------------------- |
| `.markdownlint.jsonc`          | `default: true` (all standard rules), MD013 line length 120 (code/tables exempt), MD024 siblings-only |
| `.markdownlint-cli2.jsonc`     | Loads custom `authoring-guide` + `skill-authoring-guide` rule packs, honors `.gitignore`              |
| `oxfmt.config.ts`              | `proseWrap: 'always'`, `printWidth: 120`, `singleQuote: true`, `trailingComma: 'all'`                 |
| `lint-staged.config.mjs`       | On commit: `markdownlint-cli2 --fix --no-globs` then `oxfmt` for `*.{md,mdc}`                         |
| `research/.markdownlint.jsonc` | Research subtree relaxes MD013 to 1200 and disables MD034 -- only applies under `research/`           |

`plans/**` is in the markdownlint `ignores` list, so plan files do not get linted on commit. Still wrap at 120 and use
the same conventions; the lint exemption is for in-flight drafting, not a license to ship malformed prose.

## Rules to satisfy

Standard markdownlint defaults all apply. The ones that bite most often in this repo:

- **MD003 / MD022 / MD023** -- ATX-style headings (`#`, not Setext underlines), surrounded by blank lines, no leading
  whitespace.
- **MD013 line length 120**, code blocks and tables exempt. Wrap prose at 120; do not split inside an inline code span
  if it would push the line under but break the span.
- **MD024 siblings_only** -- duplicate headings are fine across H2 sections, not within the same parent.
- **MD025** -- exactly one H1 per file. The H1 must come before the first H2.
- **MD031 / MD032** -- fenced code blocks and lists must be surrounded by blank lines.
- **MD034 no-bare-urls** -- wrap URLs in `<https://...>` or `[text](url)`. (Disabled under `research/` only.)
- **MD036** -- do not use bold/italic as a fake heading; use a real heading.
- **MD040** -- code fences need a language tag (`text` is fine for plain output, `bash` for shell, `sh` when the command
  is portable, `ts` for TypeScript, `jsonc` for commented JSON).
- **MD047** -- single trailing newline at end of file.
- **MD051** -- relative anchor links must point at real headings; rename safely.

Custom rules from `@public-projects/agents-tooling` (see
[skill-authoring-guide.md](../../../node_modules/@public-projects/agents-tooling/guides/skill-authoring-guide.md) for
the full surface):

- `skill-authoring-guide-frontmatter-required` / `frontmatter-shape` -- every `.agents/skills/*/SKILL.md` and
  `config/**/skills/*/SKILL.md` needs YAML frontmatter with `name` (kebab-case, matching the directory) and a
  `description` containing all three of `WHAT:`, `WHEN:`, `DO-NOT:` markers, under 1024 characters, no angle brackets.
- `skill-authoring-guide-folder-layout` -- skill subdirectories must be from the allowed set (`scripts`, `references`,
  `assets`, `evals`).
- `skill-authoring-guide-no-readme` -- never put a `README.md` inside a skill folder; use `SKILL.md`.
- `skill-authoring-guide-resource-mentions` -- if a skill has a non-empty `scripts/`, `references/`, or `assets/`
  directory, `SKILL.md` must mention it.
- `skill-authoring-guide-skill-required-sections` -- SKILL.md needs both a "when to use" section (e.g.
  `## When to use this skill`) and an action-oriented section (`## Steps`, `## Workflow`, `## Procedure`,
  `## Diagnostic flow`, etc.).
- `authoring-guide-doc-size-budget` -- soft caps: root AGENTS.md 120 lines, nested AGENTS.md 80, reference docs in
  `docs/` 300, active plans 400, skills 500. Trim or split when you exceed.
- `authoring-guide-non-empty-required-sections` -- AGENTS.md `Commands` / `Directory map` / `Key patterns` /
  `Boundaries` / `References` sections must have content; reference docs in `docs/**` must include `Related docs`.
- `authoring-guide-doc-opening-structure` -- docs start with an H1 and an early scope-statement paragraph.
- `authoring-guide-related-docs-last` / `-required` -- in reference docs, `## Related docs` is required and must be the
  final H2.
- `authoring-guide-no-bare-repo-paths` / `path-references` / `local-links` -- repo paths in prose must be markdown links
  or `path:` references, links must be relative, and `path:` references must point at real files.
- `authoring-guide-directory-map-table` / `-paths` -- AGENTS.md `## Directory map` is a `Path | Purpose` table whose
  paths resolve.
- `authoring-guide-boundaries-shape` -- AGENTS.md `## Boundaries` uses `Always`, `Ask first`, `Never` markers.
- `authoring-guide-commands-shape` -- AGENTS.md `## Commands` uses a bash fence or described command bullets.

## Style conventions to layer on top of lint

Lint passes are necessary but not sufficient. Match the existing tone:

- **Imperative, concrete, low-fluff prose.** No marketing voice, no rhetorical asides; see the `commit-message` skill
  for the rule set, applied here too.
- **No em-dashes (`—`) anywhere.** Use a regular hyphen with spaces around it (`-`) or restructure the sentence.
  Existing skills are written this way; oxfmt does not auto-convert.
- **Tables for tabular data, lists for steps, fenced code for commands.** Do not encode steps as a numbered table; do
  not encode a table as a bulleted list.
- **Single quotes in YAML frontmatter** when the description contains colons (which it always does, due to `WHAT:` /
  `WHEN:` / `DO-NOT:`). Escape inner single quotes by doubling them (`it''s`). Existing skills use this; do not switch
  to double quotes mid-file.
- **Relative links** to real files (`../../../node_modules/.../guide.md`, `../bats-test-conventions/SKILL.md`). No
  absolute paths, no bare URLs to repo files.
- **Code fence languages**: `bash` for shell snippets the user runs, `sh` only when truly POSIX, `text` for opaque
  output, `ts` / `tsx` / `jsonc` / `yaml` / `toml` as appropriate. Never leave a fence untagged.
- **One blank line between block elements.** Two blanks is not "more readable", it is a lint failure waiting to happen.

## oxfmt and prose wrap

`oxfmt` runs after `markdownlint-cli2 --fix` on commit, so it reflows prose last:

- `proseWrap: 'always'` rewraps each paragraph to fit `printWidth: 120`. Do not hand-wrap to a narrower width to "look
  nicer"; oxfmt will undo it and the diff churns.
- Lists, fenced code, and tables are not reflowed. Keep table rows as one logical line.
- Hard line breaks (two trailing spaces or `\`) are preserved; use them only when meaningful.
- Inline HTML, comments (`<!-- -->`), and link reference definitions are left alone.

If oxfmt reflows your wrapping on the first run after editing, that is expected; let it win and move on.

## Workflow

1. **Read before writing.** For an edit, `read` the file (and any neighbors) so you match local voice and section
   structure. For a new SKILL.md / AGENTS.md / plan / docs reference, read the relevant authoring guide in
   `node_modules/@public-projects/agents-tooling/guides/` first.
2. **Pick the right home.** SKILL.md goes in `.agents/skills/<kebab-name>/`; pi/agent skills go in
   `config/agents/skills/<kebab-name>/` or `config/pi/skills/<kebab-name>/`. Reference docs go in `docs/`. Active
   execution plans go in `plans/`. Domain READMEs sit at the directory root they index.
3. **Draft to the rules.** Write with the lint rules in mind: ATX headings, blank lines around blocks, fence languages,
   relative links, no bare URLs, no em-dashes, 120-column prose.
4. **Lint with autofix.** Run `npm run markdownlint -- <files>` (or `npx markdownlint-cli2 --fix '<glob>'`) on the
   touched files first; full-suite `npm run markdownlint` before claiming done if the change spans many files.
5. **Format.** Run `npx oxfmt <files>` (or `npm run format -- <files>`) to apply prose-wrap. Re-read the diff; if oxfmt
   rewrapped a paragraph, accept its choice rather than fighting it.
6. **Re-lint.** Run `npm run markdownlint:check -- <files>` (or `npx markdownlint-cli2 '<glob>'` without `--fix`) to
   confirm no remaining findings. The `:check` script omits `--fix` so it surfaces anything the autofix could not
   resolve.
7. **Verify links and paths.** For any `path:` reference, link to a docs file, or directory-map entry, run a quick `ls`
   / `read` to confirm the target exists. The `path-references`, `directory-map-paths`, and `local-links` rules will
   fail otherwise.
8. **Stage and commit.** `lint-staged` re-runs both tools on commit; if either fails, fix and re-stage rather than
   bypassing with `--no-verify`.

## Validation gates

Before claiming the markdown change is done, all of these must pass:

- `npx markdownlint-cli2 '<changed-files-glob>'` exits 0 (no `--fix`, so it reflects what the autofix could not
  resolve).
- `npx oxfmt --check <files>` exits 0.
- For SKILL.md: directory name matches frontmatter `name`, frontmatter contains `WHAT:` / `WHEN:` / `DO-NOT:`, and the
  body has at least one `## When to use this skill` and one action-oriented section (`## Workflow`, `## Steps`,
  `## Procedure`, `## Diagnostic flow`).
- For AGENTS.md: line count under the budget (root 120, nested 80), and the required sections are non-empty.
- For reference docs in `docs/**`: ends with `## Related docs` containing real links.

Quote the relevant pass output in the reply, per `lint-and-test-gate`.

## Common pitfalls

- **Bypassing oxfmt** by hand-wrapping at 80 or 100 characters. The reflow runs on commit; the diff fights you next
  edit. Wrap at 120.
- **Setext-underline H1/H2** (`====` / `----` under a heading). MD003 wants ATX (`#` / `##`).
- **Code fences without a language tag.** MD040 fails. Use `text` if nothing else fits.
- **Bare URLs** like `https://example.com` in prose. Use `<https://example.com>` or `[anchor](https://example.com)`.
- **Bare repo paths in prose** like `dotenv/bin/git-sync`. Wrap them in a markdown link to the file or use
  `path: dotenv/bin/git-sync`. Code spans (`` `dotenv/bin/git-sync` ``) are also accepted by `no-bare-repo-paths` for
  reference; check the rule output if unsure.
- **Em-dashes in prose, especially around the `WHAT/WHEN/DO-NOT` markers.** The existing skills standardize on hyphens
  with spaces.
- **README.md inside a skill folder.** `skill-authoring-guide-no-readme` blocks it. Put installation notes in a
  repo-level README.
- **New skill subdirectories** beyond `scripts/` / `references/` / `assets/` / `evals/`. The folder-layout rule rejects
  anything else.
- **Frontmatter description missing one of the three markers** (`WHAT:`, `WHEN:`, `DO-NOT:`). All three are required;
  the rule is checked verbatim, so do not paraphrase the markers.
- **Frontmatter `name` not matching the directory name.** Both must be kebab-case and identical.
- **Adding `## Related docs` to a SKILL.md just because reference docs need one.** It is required only in `docs/**.md`,
  not in skills.
- **Editing `REFERENCE.md` / README.md without running the `doc-sync` workflow** -- markdown lint will pass, but the doc
  surface will be inconsistent.
- **Letting lint-staged silently fix a file you did not re-read.** Always re-read after `--fix` so you understand the
  diff that landed.

## Quick reference

| Need                           | Command                                       |
| ------------------------------ | --------------------------------------------- |
| Lint everything (with autofix) | `npm run markdownlint`                        |
| Lint everything (check only)   | `npm run markdownlint:check`                  |
| Lint a single file (autofix)   | `npx markdownlint-cli2 --fix path/to/file.md` |
| Format prose (oxfmt)           | `npm run format -- path/to/file.md`           |
| Check format only              | `npm run format:check -- path/to/file.md`     |
| Confirm a path link resolves   | `ls path/to/target` or `read` it              |

## Related docs

- [Skill authoring guide](../../../node_modules/@public-projects/agents-tooling/guides/skill-authoring-guide.md) -
  Source of truth for SKILL.md frontmatter, layout, and validation rules.
- [Documentation authoring guide](../../../node_modules/@public-projects/agents-tooling/guides/authoring-guide.md) -
  AGENTS.md, reference doc, and plan structure rules enforced by the custom markdownlint pack.
- [commit-message skill](../commit-message/SKILL.md) - Subject + body rules that also apply to markdown prose voice.
- [doc-sync skill](../doc-sync/SKILL.md) - Pair this skill with `doc-sync` whenever a code change touches the public
  shell surface.
- [lint-and-test-gate skill](../lint-and-test-gate/SKILL.md) - Repo-wide rule: quote the pass output before claiming
  done.

Wersje

RepozytoriumWynikLicencja
Ta strona · weikinhuang/dotfiles100MIT
DaveSkender/Stock.Indicators100Apache-2.0
ryanmat/adw100Apache-2.0
clawic/skills90MIT
pingqLIN/skill-086MIT

Migawka bazy z 13.11.2026 · wersja paczki c7ce5207f50f (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100markdown-authoring
    Pisze dokumentację Markdown o deterministycznej strukturze, zgodną z lintem i zintegrowaną z CI: pliki README, strony dokumentacji, naprawa błędów markdownlint, reguły stylu i kontrole w pre-commit i potokach.
  • 100migrate-oxfmt
    Prowadzi migrację formatera projektu z Prettier lub Biome na Oxfmt.
  • 100migrate-oxfmt
    Prowadzi migrację formatera w projekcie JavaScript lub TypeScript z Prettier lub Biome na Oxfmt.
  • 100markdown-validation
    Sprawdza składnię, formatowanie i linki w plikach Markdown przez markdownlint-cli2 i markdown-link-check przy commitowaniu dokumentacji oraz w pull requestach.
  • 100markdown-lint
    Konfiguruje markdownlint-cli2 z hookami pre-commit, naprawia hurtowo błędy takie jak MD013, MD040 i MD060 oraz usuwa linie poziome, zachowując frontmatter YAML w monorepo.
  • 100format-cc
    Formatuje pliki Claude Code przy pomocy markdownlint, prettier i shellcheck: automatycznie poprawia Markdown, JSON i YAML oraz analizuje jakość skryptów powłoki.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.