Menú
Conventions for writing or editing markdown. Use whenever you are writing or editing a .md or .markdown file.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Port recent general tech-writing changes from the work skill (orm-claude-tech-writing) into this repo's copy of the tech-writing skill. Use when the user asks to sync, fold in, or apply recent tech-writing changes from work, update the tech-writing skill from the work one, or catch this repo's skill up to the work one.
Create git commits following the workflow and message conventions. Use whenever the user asks to commit, make a commit, save changes, or any variation of committing work. Always use this skill instead of the default commit behavior.
Guidance for writing technical prose for an engineering audience — PR descriptions, commit message bodies, design docs and RFCs, technical explanations, multi-sentence code comments, incident write-ups, and any explanation of how a system behaves. Use this skill whenever you draft or revise writing whose reader is another engineer, even if the user only says "write up X", "explain this", "draft a PR description", or "write a comment block". Also use it when asked to re-explain or clarify a confusing technical explanation — including phrasings like "I don't understand what this means", "explain this more clearly", "rewrite this so it makes sense", "explain it to me like a robot", "pretend you're a robot and explain again", or "robotify that". These robot-voice and re-explain requests should trigger the skill even when you're restating something you said earlier in the same conversation. This skill governs full-prose writing: for code comments and commit messages it applies to the prose body — a multi-sentence
Add a temporary, self-deleting mise task to root mise.toml that runs a one-time action on the *other* machine after it next pulls, then prints a reminder to delete the task. Use when a change on this machine leaves the other machine needing a one-off action that `mise run sync` / manage-symlinks won't do on its own — e.g. pruning a stale symlink left by a rename, or migrating a config file in place. The action runs once and then the task is deleted, so it's not for durable machine setup. For syncing an app install, use add-install-task instead.
Turn on (or adjust) spoken progress narration via the macOS `say` command, so the user can follow your work by ear while away from the keyboard. The user invokes this with `/say [level]` — they pass a level word as the argument (off, quiet, default, verbose) or nothing for the default level. Narration is off unless invoked. This is user-invoked only; do not trigger it on your own.
Conventions for git commands other than commit. Use whenever you are about to push, amend, or rebase. For commits, use the `commit` skill.
| name | markdown-conventions |
| description | Conventions for writing or editing markdown. Use whenever you are writing or editing a .md or .markdown file. |
Rules for writing and editing markdown in any repo.
Always include a blank line before a list (ordered or unordered). Some renderers won't recognize the list otherwise.
In markdown prose, don't put two ~ characters on the same line. Some
renderers I use pair them into strikethrough. A single ~ (e.g. ~100ms) is
fine; two on one line (e.g. "takes ~100ms and ~3 retries") is not. Rewrite one
or both as "about" or "roughly". Tildes inside backtick code spans are fine.
If an insertion or deletion shifts numbers in a numbered list, do not fix it with sequential Edit calls — that's slow and easy to get wrong. Pick one:
sed to renumber in one shot.When asked to wrap a markdown file, use:
prettier --prose-wrap always --print-width 80 --write <file.md> 2>&1