plugins/dev-tools/skills-pi/looking-up-docs/SKILL.md
Compatibility router for library documentation lookup. Use when user says "look up docs", "how to use", "API for", "syntax for", "examples of", "show me the docs", or needs API references, code examples, or framework-specific documentation. Routes to the context7-cli workflow.
npx skillsauth add alexei-led/claude-code-config looking-up-docsInstall 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.
This skill preserves the old looking-up-docs trigger while routing the actual
workflow to context7-cli. Do not maintain a second competing docs lookup flow
here.
Use the context7-cli workflow for narrow docs lookup. SHOW the exact ctx7
commands you ran in the response — claiming "I used Context7" without
emitting a command does not satisfy this skill.
Identify the library and version from project files (package.json,
go.mod, pyproject.toml, lockfiles). State the version or say it is
unknown.
Unless the user already supplied /org/project or /org/project/version,
resolve a library ID by running and showing:
ctx7 library <name> "<specific query>"
Query docs with a real topic by running and showing:
ctx7 docs /org/project "<specific query>"
Ground syntax and examples in returned docs.
If ctx7 is missing on PATH, fall back to npx (or bunx) for both
library and docs invocations and say a fallback was used:
npx ctx7@latest library <name> "<specific query>"
npx ctx7@latest docs /org/project "<specific query>"
# or, if you use Bun:
bunx ctx7@latest library <name> "<specific query>"
bunx ctx7@latest docs /org/project "<specific query>"
Use web tools such as web_search or web_answer only when Context7 has
no useful match, and say a fallback was used.
Use this skill for:
Do not use this skill as the primary workflow for:
Route those to researching-web; use docs lookup later for exact syntax in the
chosen library.
ctx7 library more than 3 times for one question.ctx7 docs more than 3 times for one question.ctx7 docs --json when structured output helps.When answering a docs lookup, report:
If the user asks to describe the workflow, describe these steps instead of answering from memory.
tools
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, TypeScript, Go, web code, or infrastructure operations.
tools
Use when planning, executing, checkpointing, finishing, or inspecting lightweight spec-driven work. Runs one task at a time using `.spec/` markdown files and the bundled `specctl` helper. NOT for broad product discovery beyond a short requirement interview.
testing
Author, inspect, troubleshoot, and review infrastructure across IaC, Kubernetes, cloud resources, containers, CI/CD, and Linux hosts. Use when changing Terraform/OpenTofu, Kubernetes, Helm, Kustomize, Dockerfiles, GitHub Actions, AWS, GCP, Cloud Run, BigQuery, IAM, logs, instances, or service health. NOT for deploy/apply/rollback workflows (see deploying-infra). NOT for shell scripts or generic command pipelines (see writing-shell).
development
Configure safe git workflow hygiene: pre-commit/pre-push hooks, Gitleaks secret scanning, .gitignore rules, local git config, and guardrails. Use when setting up git hooks, gitleaks/git leaks, staged pre-commit checks, pre-push validation, core.hooksPath, .gitignore, or git config best practices. NOT for creating commits (use committing-code), cleaning branches/worktrees (use cleanup-git), or creating worktrees (use using-git-worktrees).