원클릭으로
markdown-conventions
Conventions for writing or editing markdown. Use whenever you are writing or editing a .md or .markdown file.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Conventions for writing or editing markdown. Use whenever you are writing or editing a .md or .markdown file.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
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.
SOC 직업 분류 기준
| 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