[DOCS] Skills page: add a third-party community skill install example

Documentation Type

Missing documentation (feature not documented)

Documentation Location

<https://code.claude.com/docs/en/skills>

Section/Topic

Skills page — third-party / community skill install example

What's Wrong or Missing?

The Skills page explains the format and the personal vs. project vs. plugin scopes well, but it doesn't show what installing and running a third-party community skill actually looks like end-to-end. A user who hears "someone published a skill I want to try" today has to assemble the workflow from multiple pages.

A short worked example would also be a natural place to land two pieces of guidance that matter for any skill that ships its own scripts:

1. Declaring required env vars / bins in SKILL.md so users know what to set up before launching.
2. Permissions guidance for overlapping built-in tools, so a skill that brings its own network reach doesn't quietly compete with built-ins like WebSearch / WebFetch in a project that already uses them.

A concrete community example already exists today: iflow-search — Agent-Skills-format, one SKILL.md plus three small bash scripts (web_search.sh, image_search.sh, web_fetch.sh). Its SKILL.md declares:

• env: IFLOW_API_KEY
• bins: bash, curl

iFlow's own skill page (<https://platform.iflow.cn/docs/skill>) lists Claude Code as one of its supported targets, so it's a public, low-risk reference example — not an endorsement request.

Suggested Improvement

A short addition to the Skills page (or a sibling page linked from it) covering:

1. Where Claude Code looks for personal vs. project skills, and the on-disk layout it expects under .claude/skills/<name>/.
2. A worked install of one real community skill into the personal scope (copy the skill folder in, restart Claude Code, confirm it loads).
3. Required env-var setup, performed in the shell before launching Claude Code — env-only, never as a CLI flag, never committed:

~~~bash
echo 'export IFLOW_API_KEY="YOUR_IFLOW_API_KEY"' >> ~/.zshrc
source ~/.zshrc

use the equivalent rc file if you use bash or another shell

~~~

YOUR_IFLOW_API_KEY is a placeholder; real keys come from <https://platform.iflow.cn/profile?tab=apiKey>.

1. How to verify the skill is discoverable (whatever the equivalent of a "list installed skills" surface is).

Trust / security note worth surfacing

For any third-party skill that brings its own network reach, the docs could note in the same place:

• The skill's SKILL.md should declare what it touches via allowed-tools and via the env / bins it requires.
• Permissions guidance for overlapping built-in tools — when a skill ships scripts that duplicate functionality already covered by built-ins (e.g. a skill's own search/fetch scripts vs. WebSearch / WebFetch), the docs could point users to the project-level permissions surface so they can scope which path actually runs. I'm not sure whether this is documented today; if it isn't, it would pair naturally with a third-party install example.

This isn't unique to iflow-search — it applies to any skill that shells out to the network.

Scope guardrails

• Framing should be "community / third-party skill example," not an official endorsement.
• This is strictly about user-installable Agent Skills — not provider/model integrations.
• No real API key in this issue; any doc copy should use the YOUR_IFLOW_API_KEY placeholder only.
• Not requesting a PR invite — flagging the gap and offering an example that already exists, in case the team finds it useful. Happy to share verification artifacts (sample SKILL.md frontmatter, install transcript) in-thread.

Impact

Low - Minor confusion or inconvenience

Additional Context

• Skill source: <https://github.com/iflow-ai/iflow-skills/tree/main/skills/iflow-search>
• iFlow skill docs (lists supported targets): <https://platform.iflow.cn/docs/skill>
• iFlow platform docs: <https://platform.iflow.cn/docs/>