format-github-post

Formats GitHub PR descriptions, comments, and review replies using tables, Mermaid, alerts, and details blocks.

Updated Dec 25, 2021
One-click install
npx skills add https://github.com/kotahashihama/dotfiles --skill format-github-post-kotahashihama
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: format-github-post
Source: https://github.com/kotahashihama/dotfiles/tree/main/home/.claude/skills/format-github-post
Command: npx skills add https://github.com/kotahashihama/dotfiles --skill format-github-post-kotahashihama

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Long prose in GitHub PR descriptions, follow-up comments, and review replies buries the information reviewers actually need. This Skill provides decision rules for folding verbose prose into the right structural format so readers can find conclusions, warnings, and evidence quickly. ## Core Features & Use Cases - Format Selection Guide: Decision tables for choosing between tables, Mermaid diagrams, Alerts, <details> blocks, footnotes, and permalinks based on content type and posting destination (PR body, comment, review reply). - Alert Discipline: Restricts usage to NOTE, IMPORTANT, and WARNING with a 1-2 per body limit, plus rules for what to do when a third candidate appears. - Collapsing Rules: Clear criteria for what goes inside <details> versus what stays visible, and when a separate comment is the better container. - Use Case: When writing a PR description that includes a long test-output log and three caveats, this Skill tells you to keep the conclusion visible, fold the log into a named <details> block, and use at most two Alerts. ## Quick Start Ask the assistant to write or rewrite a GitHub PR description or review reply using the format-github-post skill to structure it with the right formatting elements.

Frequently Asked Questions about format-github-post

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I format a GitHub PR description with collapsible sections?

Use a <details> block with a descriptive <summary> name placed directly under the section that needs it. Keep the conclusion visible outside the block and fold only supporting evidence like logs, SQL, or full enumerations inside.

Which GitHub alert types should I use in pull requests?

Use only NOTE, IMPORTANT, and WARNING. NOTE is reserved for generator attribution, IMPORTANT for ordering or setup requirements, and WARNING for behavior that could break. Limit the PR body to one or two alerts total.

When should I use a table versus a Mermaid diagram on GitHub?

Use a table when three or more items share the same comparison criteria. Use Mermaid when the content expresses structure, relationships, or flow that a list cannot convey, such as dependencies or state transitions.

Why should I avoid Closes or Fixes keywords in PR descriptions?

Closes, Fixes, and Resolves automatically close the linked issue the moment the PR merges. If closing timing depends on releases or other PRs, reference the issue with just #123, which links without closing.

How do I reference specific code lines in GitHub comments?

Use a permalink containing the commit hash instead of path:line notation, since diffs shift during review and line numbers drift. Press y on a file view in GitHub to get the commit-pinned URL, which renders as an embedded code snippet.

When should I use a separate comment instead of a details block?

Use a separate comment for self-contained information referenced independently of the body, such as API contracts or investigation logs. Use a details block when the reader needs the content inline while reading a specific section.