share-pretty-gist

Share text, code, reports, or other content externally via a beautifully rendered GitHub Gist. ALWAYS use this skill whenever creating a gist — whether the user says "create a gist", "make a gist", "share as a gist", "share this", "share this code", or any variation involving the word "gist". This is the default way to create gists. Also use proactively when sharing content and a gist would be the best format.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "share-pretty-gist" with this command: npx skills add linuz90/gists.sh/linuz90-gists-sh-share-pretty-gist

Share Pretty Gist

Package and share content as a beautifully rendered GitHub Gist on gists.sh.

When to Use

Use this skill when the user wants to share content with others, not just store it. Triggers include:

  • "Share this as a gist"
  • "Make a shareable link for this code/report/doc"
  • "Package this for someone to read"
  • "Send this to [person] as a gist"
  • Any request to create a gist where the emphasis is on presentation and readability

This is different from plain gist creation (storage) because it focuses on structuring the content so it renders beautifully on gists.sh.

Workflow

Step 1: Prepare the content

Infer from context what the user wants to share. Use good judgment on structure:

  • Code: Use the correct filename with proper extension (e.g. server.ts, config.yml, query.sql) so Shiki highlights it correctly. Add a brief comment header if context would help the reader.
  • Report/doc: Use a .md file. Structure with clear headings, bullet points, and GFM alerts where appropriate.
  • Tutorial/guide: Use a .md file. Use numbered steps, language-tagged code blocks, and > [!TIP] / > [!NOTE] alerts for callouts.
  • Quick share (snippet, error log, config): Use the most fitting extension. Keep it minimal.

For multi-file gists, put the most important file first (it displays by default as the first tab on gists.sh).

If it's obvious from the context that there's some specific text or markdown content to share, put it in the gist with no changed or only minor formatting ones as needed.

NEVER put meta-commentary in the gist content, like "This is what {user name} asked me to share...".

Step 2: Create the gist

gh gist create <files> -d "Clear description of what this contains"

The -d description becomes the title on gists.sh, so make it descriptive and useful.

If gh is not available or authenticated, guide the user through the installation and setup.

Step 3: Warm the cache

After creating the gist, fetch the gists.sh page once to warm up the cache, so it loads instantly for the reader:

curl -s https://gists.sh/{user}/{id} > /dev/null

Step 4: Present the URL

Show gists.sh as the primary shareable link:

-> https://gists.sh/{user}/{id}

(original on GitHub: https://gist.github.com/{user}/{id})

Rules

  • ALWAYS create SECRET gists. Even when asked to "share with someone" or "share externally", the gist must be secret. Only use --public if the user EXPLICITLY asks for a public gist.
  • Always include -d with a clear, concise, but descriptive title. This is the first thing readers see on gists.sh.
  • Use correct filenames with proper extensions (e.g. server.ts, config.yml, Dockerfile) so syntax highlighting works correctly.
  • Use natural, descriptive filenames. Never prefix filenames with redundant words like "gist-" or "shared-" (e.g. use README.md not gist-readme.md, use setup-guide.md not gist-setup-guide.md).
  • Always warm the cache after creating or updating a gist.
  • Try to avoid using em dashes in any content, unless they're already in the original content to share.
  • No meta-commentary ("The user asked me to...", "Here is a summary of..."). Get straight to the content.
  • Write for the reader, not the creator. The person opening the link should understand the content without needing the original conversation context.

gists.sh Rendering Tips

  • Try to use language tags on all code blocks (```typescript, ```yaml, etc.) for proper syntax highlighting.
  • GFM alerts also can be used because they render nicely: > [!NOTE], > [!TIP], > [!IMPORTANT], > [!WARNING], > [!CAUTION].
  • Avoid raw HTML unless strictly necessary. Stick to standard GitHub Flavored Markdown.
  • Multi-file gists render as tabs on gists.sh. The first file is shown by default.
  • Tables, task lists, and other GFM features all work.
  • YAML front matter in markdown files renders as a structured table above the content.
  • Structured data files get interactive viewers: JSON/GeoJSON (collapsible tree), YAML (tree), CSV/TSV (sortable table), ICS/iCal (calendar cards). Use proper file extensions so the viewer activates.
  • Link to a specific file in a multi-file gist with ?file={filename}.

Updating Existing Gists

When updating a gist that was previously shared:

  1. Edit the gist with gh gist edit {id}
  2. POST to the refresh endpoint to bust stale cache. There is a 1-minute cooldown between purge requests:
    curl -s -X POST https://gists.sh/{user}/{id}/refresh
    
  3. Warm the cache with the updated content:
    curl -s https://gists.sh/{user}/{id} > /dev/null
    

Display Parameters

Only suggest these when the user explicitly requests a specific display style. Default URLs with no params are preferred.

  • ?theme=dark / ?theme=light -- force dark or light mode
  • ?noheader -- hide title, tabs, and copy buttons
  • ?nofooter -- hide author info and footer
  • ?mono -- monospace font for all text
  • ?file={filename} -- show a specific file from multi-file gists

Parameters are composable: gists.sh/{user}/{id}?theme=dark&noheader&nofooter

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

Agent Dev Workflow

Orchestrate coding agents (Claude Code, Codex, etc.) to implement coding tasks through a structured workflow. Use when the user gives a coding requirement, f...

Registry SourceRecently Updated
Coding

Tesla Commander

Command and monitor Tesla vehicles via the Fleet API. Check status, control climate/charging/locks, track location, and analyze trip history. Use when you ne...

Registry SourceRecently Updated
Coding

Skill Creator (Opencode)

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize a...

Registry SourceRecently Updated
Coding

Documentation Writer

Write clear, comprehensive documentation. Covers README files, API docs, user guides, and code comments. Create documentation that users actually read and un...

Registry SourceRecently Updated