> ## Documentation Index > Fetch the complete documentation index at: https://docs.getpioneer.dev/llms.txt > Use this file to discover all available pages before exploring further. # Skills Overview > Use skills to extend Pioneer with reusable instructions, tools, and workflows. Skills give Pioneer reusable behavior. Without a skill, you repeat instructions in prompts about repository layout, report format, checks, safe commands, and expected output. A skill packages those instructions so you can install, review, enable, disable, and reuse them. A skill can be a small writing guide or a package with dependency checks and dynamic tools. In either case, it becomes part of the gateway's working environment. Pioneer skills are compatible with the [Agent Skills specification](https://agentskills.io/specification). In practice, that means a skill follows the open Agent Skills format built around a `SKILL.md` file plus optional scripts, references, assets, and supporting resources. ## When skills help Use a skill when the same behavior should show up again and again. Teams use skills for repository conventions and support workflows. Researchers can use them for literature notes, companies for internal API helpers, and individuals for a preferred document format. If the instruction is one-off, put it in the thread. If it should become part of how Pioneer works in a workspace, make it a skill. ## Where skills live Skills are installed for the current workspace on a gateway. That means your work workspace can have approved work skills, your personal workspace can have personal skills, and your sandbox workspace can be where you test new or untrusted packages. Use a separate gateway when the skill should run on a different machine or security boundary. ## Enabled and implicit skills Installed skills can be enabled or disabled. A disabled skill stays installed on the gateway, but agents should not use it. Enabled skills can be **implicit** or **not implicit**. An implicit skill is available automatically when Pioneer decides it is relevant. A not implicit skill is available only when you explicitly ask for it, either by selecting it in the composer or by naming it in your prompt. Newly installed skills start not implicit by default. Use implicit mode only for trusted, general-purpose behavior that should naturally apply in many threads. Use not implicit mode for specialized, risky, noisy, or rarely needed skills. ## Selecting skills in a thread In the desktop composer, use the add button and choose **Add skills** to attach one or more skills to the next turn. Selected skills appear as attachment chips above the input, not as inline text inside the message. After you send the turn, the same chips appear on the user message in the timeline. A selected skill is sent to the gateway as a turn capability. Pioneer resolves it as an explicit composer capability for that turn, applies normal policy and validation, and reports diagnostics if the skill is missing, disabled, blocked, or unavailable. Composer-selected skills do not paste the full `SKILL.md` body into the prompt. The prompt gets a compact skill entry with the exact `read_skill` slug and description; the full instructions remain available through `read_skill`. Pioneer can also expose selected system skills, such as Browser, through the same composer and capability flow. When a supported CLI runtime can consume them, system skills can be exported for that runtime as well. Availability still depends on the gateway, provider/runtime capabilities, current policy, and the selected turn. ## Skill packs A skill pack is a folder containing several related skills. Install the folder once, then inspect or select the individual skills inside it when a turn needs only part of the pack. Packs are useful for a team workflow that has separate research, implementation, and review capabilities but shares one release and installation boundary. Pioneer keeps the identity of each retained skill stable when a pack is renamed, moved between sources, or updated. Existing policies, workspace bindings, and history follow that identity instead of turning the update into a set of unrelated new skills. Pack install, update, and removal are handled as one operation, so a failed change does not leave a half-updated pack. ## Using skills safely Installing a skill should not be treated like pasting a harmless prompt. Skills can include dynamic tools, dependency expectations, and workflow instructions that affect what agents do. Skill tools run through the gateway and follow the turn permission mode plus sandbox/resource policy. Test unfamiliar skills in **Supervised** mode first, and use a separate gateway when the skill should not share the same host environment. Before trusting a skill, look at what it adds, what commands or services it expects, and whether it asks for broad file or network access. Then try it with a low-risk prompt before using it on important work. ## Typical flow Install the skill, review validation results, fix missing dependencies, confirm that it is enabled in the current workspace, and try it in a thread from the composer. Keep it explicit-only until you know it behaves well. Make it implicit only when it is trusted and broadly useful. Build a skill package with a SKILL.md contract. Add a skill package and read validation results. Enable, disable, update, or remove installed skills. Decide what is safe to trust on a gateway. ## Further reading * [Skills Architecture](/architecture/skills) explains parsing, validation, dependency checks, policy, and dynamic tools. * [Permission System](/architecture/permissions) explains how turn permission modes and sandbox/resource policy apply to dynamic skill tools. * [Tools Architecture](/architecture/tools) explains why skill-provided tools need trust and policy. * [Agent Loop](/architecture/agent-loop) explains where selected skills enter a turn.