Skill
verification-before-co…
Before telling the user a coding task is done, actually verify it — build, run the relevant tests/linter, and confirm the change does what was asked with no…
@duckbugioView SkillAutomation
Skill
/library-docs-lookup
When writing code against an external library, framework, SDK, or API, look up its CURRENT documentation with the context7 MCP tools instead of relying on memory. Use whenever you import/call a third-party package or hit an unfamiliar or fast-moving API.
Install
$ npx -y skills add duckbugio/flock --skill library-docs-lookup --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/library-docs-lookup
Context preview
The summary Claude sees to decide when to auto-load this skill.
When writing code against an external library, framework, SDK, or API, look up its CURRENT documentation with the context7 MCP tools instead of relying on memory. Use whenever you import/call a third-party package or hit an unfamiliar or fast-moving API.
SKILL.md
library-docs-lookup.SKILL.mdname: library-docs-lookup
description: When writing code against an external library, framework, SDK, or API, look up its CURRENT documentation with the context7 MCP tools instead of relying on memory. Use whenever you import/call a third-party package or hit an unfamiliar or fast-moving API.
Look up real library docs (don't guess the API)
Training data goes stale: library APIs, method signatures, config keys, and best practices change between versions. Guessing them is a top source of subtly-wrong code. When you touch an external library/framework/SDK/API, get the CURRENT docs.
How
The `context7` MCP server is available. Use its tools:
1. **`resolve-library-id`** — resolve the library name (e.g. "tauri", "centrifuge-go", "react-query") to its context7 id. 2. **`get-library-docs`** — fetch the up-to-date docs for that id, scoped to the topic/symbol you need (the specific hook, method, or config option).
Pull the version the project actually depends on — check `go.mod` / `package.json` / `Cargo.toml` / `requirements.txt` — not "latest", when they differ.
When to use it
- Calling a method/option you're not 100% sure exists in the version in use.
- Wiring up a new dependency, an SDK client, or a framework feature.
- An unfamiliar or fast-moving library (cloud SDKs, web frameworks, build tools).
- A compile/runtime error that looks like an API mismatch.
When NOT to bother
- The standard library or a tiny, stable utility you know cold.
- Pure project-internal code — read the repo, not external docs.
Prefer one focused docs lookup over a wrong guess you then have to debug.
Read more
name: library-docs-lookup description: When writing code against an external library, framework, SDK, or API, look up its CURRENT documentation with the context7 MCP tools instead of relying on memory. Use whenever you import/call a third-party package or hit an unfamiliar or fast-moving API.
Look up real library docs (don't guess the API)
Training data goes stale: library APIs, method signatures, config keys, and best practices change between versions. Guessing them is a top source of subtly-wrong code. When you touch an external library/framework/SDK/API, get the CURRENT docs.
How
The `context7` MCP server is available. Use its tools:
1. **`resolve-library-id`** — resolve the library name (e.g. "tauri", "centrifuge-go", "react-query") to its context7 id. 2. **`get-library-docs`** — fetch the up-to-date docs for that id, scoped to the topic/symbol you need (the specific hook, method, or config option).
Pull the version the project actually depends on — check `go.mod` / `package.json` / `Cargo.toml` / `requirements.txt` — not "latest", when they differ.
When to use it
- Calling a method/option you're not 100% sure exists in the version in use.
- Wiring up a new dependency, an SDK client, or a framework feature.
- An unfamiliar or fast-moving library (cloud SDKs, web frameworks, build tools).
- A compile/runtime error that looks like an API mismatch.
When NOT to bother
- The standard library or a tiny, stable utility you know cold.
- Pure project-internal code — read the repo, not external docs.
Prefer one focused docs lookup over a wrong guess you then have to debug.
Ships withflock
Run a Claude Code AI dev team on your server and drive it from chat. Describe a feature in Telegram, VK or LO; the team plans it, builds it on a branch, tests it, reviews it, and opens a PR — each chat in its own isolated workspace.
Get the whole plugin
Other skills on flock.
@duckbugioView Skill