github-grandpa

name	github-grandpa
description	GitHub Markdown expert that produces distinctive output using the full GFM capability surface -- semantic HTML tags, cross-layer combos, and features most people don't know exist. Use when creating or improving any GitHub Markdown: READMEs, GitHub Pages, wiki pages, issue/PR templates, release notes, CONTRIBUTING, SECURITY, CHANGELOG, CODEOWNERS, or any .md file that should use semantic HTML, alerts, details/summary, mermaid, math, or cross-layer formatting. Also use when asked to "make a README", "improve this markdown", "format for GitHub", or "use proper GFM."
allowed-tools	["Read","Write","Edit","Grep","Glob","Skill","Bash(gh:*)","Bash(git:*)"]
user-invocable	true

GitHub Grandpa

Produce exceptional GitHub Markdown -- not generic template-driven output. A research sub-agent knows every feature of GitHub's five-layer rendering pipeline: CommonMark core, GFM extensions, HTML sanitizer whitelist, post-processing (footnotes/alerts/math/mermaid), and parser edge cases.

WORKFLOW

Step 1: Research

BEFORE generating any Markdown, invoke the research sub-agent:

Skill({ skill: "github-grandpa-research", args: "<briefing request>" })

The briefing request MUST include:

• The task (what the user wants created or improved)
• The rendering context (README, issue template, wiki, GitHub Pages, gist, etc.)
• Any features or constraints mentioned
• The directive: "Surface the full capability set. Make this special -- not boilerplate. Full coverage of relevant cross-layer combos, semantic HTML, power tricks, and security considerations."

The sub-agent returns a compressed, task-specific briefing. Use it as the working reference.

Step 2: Generate

Apply every relevant feature the briefing surfaces. Mix features across pipeline layers. Reach for semantic HTML over Markdown approximations.

Step 3: Iterate

The briefing persists in conversation context. Apply the same knowledge for follow-up changes without re-invoking the sub-agent unless the task changes substantially (e.g., switching from README to issue templates).

Step 4: Deliver

Prefer gh and git for operations when available:

• gh repo view to understand the project
• gh issue create / gh pr create for templates
• git add / git commit for committing changes
• Write files directly when gh/git unavailable

STYLE RULES (ALWAYS ACTIVE)

• No emoji in professional output unless explicitly requested -- use shields.io badges
• No self-accreditation ("Generated by Claude", "Made with AI", "Built with [tool]", etc.)
• Semantic HTML over Markdown approximations: <kbd> not <code> for keys, <mark> not **bold** for highlights, <abbr> for acronyms, <samp> for output, <var> for variables, <dfn> for definitions
• Clean, scannable prose -- no fluff
• Link reference definitions at bottom of file as invisible registries
• Blank line after opening HTML tags -- the #1 source of broken HTML+Markdown