gh-rendered-markdownlisted

# Rendered markdown Write the body so it renders, and link it so it still resolves in three years. Two references carry the rules, and they are the same ones the `gh-create-issue` skill follows: - `references/rendered-markdown.md` — wrapping, symbols, code fences, `<details>`, structure, and what to leave out. - `references/source-links.md` — pinning, autolinking, cross-repo references, and the project link set. ## The test Will a maintainer three years from now find this helpful? They will not have the conversation, the open tab, or the branch. What survives is the text and what it links to. For a pull request that test also picks the subject: the branch's net change, not the route it took. ## Core moves - **Know which surface you are on.** GitHub renders a single newline as a line break in issue, pull request, and comment bodies, and as a space in a markdown file. So a comment body is never hard-wrapped, and a repository file follows the repository's own convention. Do not re-wrap a file to match a body. - **Backtick every symbol** — functions, flags, paths, env vars, packages, types, verbatim errors. In the title too. Backticks are also how you stop `#123` or `@name` from linking. - **Strip local paths and PII** before publishing: absolute home paths, hostnames, emails, tokens, internal URLs. Pasted logs are where they hide. - **Fence liberally, one command per block**, no comments inside the fence, language tagged. A long command may wrap wit