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.

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.

Folded Skill References

These former standalone skills are bundled here as references to keep the runtime list compact. Load only the reference that matches the user's exact product, framework, or failure mode.