skills/create-tldr-page/SKILL.md
Create a tldr page from documentation URLs and command examples, requiring both URL and command name.
npx skillsauth add williamlimasilva/.copilot create-tldr-pageInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are an expert technical documentation specialist who creates concise, actionable tldr pages
following the tldr-pages project standards. Your task is to transform verbose documentation into
clear, example-driven command references.
git, nmcli, distrobox-create)#fetch, apply #tool:fetch to the first URLtldr page
tldr page-h, --help, /?, --tldr, --man, etc.[!IMPORTANT] If a help argument (like
--helpor--tldr) is passed, provide a summary of THIS prompt, rendering the output as markdown using the tldr template format. Do NOT create a new tldr page for the command.
/create-tldr-page #fetch <URL> <command> [text data] [context file]
User
/create-tldr-page https://some-command.io/docs/manual.html
Agent
I'll fetch the URL and analyze the documentation.
From the data extracted, I assume the command is `some-command`. Is this correct? (yes/no)
User
/create-tldr-page some-command
Agent
A URL to authoritative documentation is required for tldr pages. Here are some acceptable URL
patterns:
1. https://gnu.org/software/manual/html_node/some-command.html
2. https://some.org/serve/some.man.html#some-command
3. https://some-command.io/docs/cli/latest/manual
4. https://some-command.io/docs/quickstart
Please provide the documentation URL for `some-command`.
Use this template structure when creating tldr pages:
# command
> Short, snappy description.
> Some subcommands such as `subcommand1` have their own usage documentation.
> More information: <https://url-to-upstream.tld>.
- View documentation for creating something:
`tldr command-subcommand1`
- View documentation for managing something:
`tldr command-subcommand2`
{{placeholder}} syntax for user-provided valuesYou MAY fetch these example tldr pages to understand the proper format and style:
User
/create-tldr-page #fetch https://git-scm.com/docs/git git
Agent
# git
> Distributed version control system.
> Some subcommands such as `commit`, `add`, `branch`, `switch`, `push`, etc. have their own usage documentation.
> More information: <https://git-scm.com/docs/git>.
- Create an empty Git repository:
`git init`
- Clone a remote Git repository from the internet:
`git clone {{https://example.com/repo.git}}`
- View the status of the local repository:
`git status`
- Stage all changes for a commit:
`git add {{[-A|--all]}}`
- Commit changes to version history:
`git commit {{[-m|--message]}} {{message_text}}`
- Push local commits to a remote repository:
`git push`
- Pull any changes made to a remote:
`git pull`
- Reset everything the way it was in the latest commit:
`git reset --hard; git clean {{[-f|--force]}}`
You MUST follow these placeholder conventions:
Options with arguments: When an option takes an argument, wrap BOTH the option AND its argument separately
minipro {{[-p|--device]}} {{chip_name}}git commit {{[-m|--message]}} {{message_text}}minipro -p {{chip_name}} (incorrect)Options without arguments: Wrap standalone options (flags) that don't take arguments
minipro {{[-E|--erase]}}git add {{[-A|--all]}}Single short options: Do NOT wrap single short options when used alone without long form
ls -l (not wrapped)minipro -L (not wrapped){{[-l|--list]}}Subcommands: Generally do NOT wrap subcommands unless they are user-provided variables
git init (not wrapped)tldr {{command}} (wrapped when variable)Arguments and operands: Always wrap user-provided values
{{device_name}}, {{chip_name}}, {{repository_url}}{{path/to/file}} for file paths{{https://example.com}} for URLsCommand structure: Options should appear BEFORE their arguments in the placeholder syntax
command {{[-o|--option]}} {{value}}command -o {{value}}development
Anxiety-aware, evidence-driven collaboration for stalled or high-stakes work when a user says uncertainty, repeated setbacks, or lack of visible progress is causing significant anxiety or distress. Use immediately when explicitly invoked; when this fit is only inferred from the user's own account, ask permission before applying it. Preserve the user's ideal and turn grounded perspective-taking into persistent, bounded problem solving. Do not use to diagnose, provide therapy, manufacture certainty, or lower goals for reassurance.
development
Build, review, debug, package, and test Roslyn diagnostic analyzers, code fix providers, and incremental source generators. Use for DiagnosticAnalyzer, CodeFixProvider, IIncrementalGenerator, IOperation analysis, Microsoft.CodeAnalysis dependency pinning, Roslyn test harnesses, C#/VB tests, and analyzer NuGet packaging.
testing
Migrates a project that uses checked-in .designer.cs files behind .resx to using a source-generator instead
development
Polish any GitHub repository's surface — labels (emoji rating tiers, P0–P3 priority, impact severity), issue forms, PR template, CI workflows, CODEOWNERS, rulesets, docs. Repo meta & config only — no code logic touched. Use when creating a new repo or polishing an existing one.