How do I install the Rtfm skill?

Run npx skillmds@latest add kevin-liu-01/rtfm in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Rtfm?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

kevin-liu-01 (@kevin-liu-01) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Rtfm by kevin-liu-01 — Agent Skill

Name: Rtfm
Author: kevin-liu-01

File contents

RTFM

When you think you know how an API, tool, or system works, you are wrong until you have verified it against the source. This skill exists because workarounds for nonexistent limitations are worse than the problems they claim to solve.

When to use

Every time you:

claim a library, API, or tool lacks a feature
claim something "can't be done" or "isn't supported"
write a workaround, shim, or fallback
choose one approach over another based on a tool's capabilities
dismiss an option without trying it

Procedure

1. Read the primary source

The actual code, API docs, or type signature. Not a summary. Not a blog post. Not your memory.

Claim type	Where to look
"crate X doesn't support Y"	`docs.rs/X`, GitHub source, `Cargo.toml` features
"API doesn't accept parameter Z"	OpenAPI spec, SDK type definition, `--help`
"kernel doesn't support mode M"	`kernel.org/doc/html/`, `Documentation/` tree
"service doesn't offer feature F"	official product docs, changelog, pricing page
"protocol doesn't allow operation O"	RFC, spec PDF, reference implementation

2. Read the secondary source

Official examples, changelogs, migration guides.

README examples in the upstream repo
CHANGELOG entries for the version you are using
Official SDK example repos
Release notes and migration guides

3. Read the tertiary source

Community evidence that people are doing the thing you think is impossible.

GitHub issues and PRs mentioning the feature
Stack Overflow answers with working code
Reddit or HN threads with first-hand experience
Conference talks or blog posts from maintainers

4. Run it

If the claim is about runtime behavior, write a minimal test. Five lines. Compile it. Run it. See what happens. Do not theorize about what the compiler, runtime, or service will do. Ask it.

5. Only then decide

After steps 1-4, you may say "X doesn't support Y." Not before.

If you skipped any step, go back. The five minutes you spend reading docs saves the five hours you spend building and debugging a workaround for a limitation that does not exist.

The rule

If you have not read the docs, you have not earned the right to say it cannot be done. Read first. Decide second. Code third.

---name: rtfmdescription: Verify claims against primary sources before writing code or docs. Read the actual API, run the actual command, check the actual docs. Do not guess. Do not assume. Do not ship until verified.---# RTFMWhen you think you know how an API, tool, or system works, you arewrong until you have verified it against the source. This skill existsbecause workarounds for nonexistent limitations are worse than theproblems they claim to solve.## When to useEvery time you:- claim a library, API, or tool lacks a feature- claim something "can't be done" or "isn't supported"- write a workaround, shim, or fallback- choose one approach over another based on a tool's capabilities- dismiss an option without trying it## Procedure### 1. Read the primary sourceThe actual code, API docs, or type signature. Not a summary. Not ablog post. Not your memory.| Claim type | Where to look ||---|---|| "crate X doesn't support Y" | `docs.rs/X`, GitHub source, `Cargo.toml` features || "API doesn't accept parameter Z" | OpenAPI spec, SDK type definition, `--help` || "kernel doesn't support mode M" | `kernel.org/doc/html/`, `Documentation/` tree || "service doesn't offer feature F" | official product docs, changelog, pricing page || "protocol doesn't allow operation O" | RFC, spec PDF, reference implementation |### 2. Read the secondary sourceOfficial examples, changelogs, migration guides.- README examples in the upstream repo- CHANGELOG entries for the version you are using- Official SDK example repos- Release notes and migration guides### 3. Read the tertiary sourceCommunity evidence that people are doing the thing you think isimpossible.- GitHub issues and PRs mentioning the feature- Stack Overflow answers with working code- Reddit or HN threads with first-hand experience- Conference talks or blog posts from maintainers### 4. Run itIf the claim is about runtime behavior, write a minimal test. Fivelines. Compile it. Run it. See what happens. Do not theorize aboutwhat the compiler, runtime, or service will do. Ask it.### 5. Only then decideAfter steps 1-4, you may say "X doesn't support Y." Not before.If you skipped any step, go back. The five minutes you spend readingdocs saves the five hours you spend building and debugging aworkaround for a limitation that does not exist.## The ruleIf you have not read the docs, you have not earned the right to sayit cannot be done. Read first. Decide second. Code third.

Frequently asked questions

Rtfm