> For the complete documentation index, see [llms.txt](https://docs.stepsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stepsecurity.io/github/agent-skills.md). # Agent Skills The **Agent Skills** page provides an inventory of AI agent skills committed to the repositories in your GitHub organization. It shows the skills detected in supported agent skill folders, which repository each one lives in, which AI agent loads it, how it is managed, and whether it contains executable content. To open it, select **Agent Skills** in the **GitHub** section of the left navigation. {% hint style="info" %} This page covers skills committed to your GitHub repositories. For skills installed on developer machines, see [Agent Skills](/developer-machines/ide-and-ai-agents/agent-skills.md) in Dev Machine Guard. {% endhint %} Agent skills are reusable capability folders, each containing a `SKILL.md` file plus optional supporting files, that AI coding agents such as Claude Code, Cursor, and Windsurf load to perform specialized tasks. A skill committed to a repository is available to every developer and every agent session that works in that repository. Because skills can ship scripts, register hooks, and embed shell commands, a skill merged into a repository becomes part of your software supply chain.
The page header shows the total number of skills and the number of repositories they were found in. {% hint style="info" %} Agent Skills is available for organizations on GitHub.com. GitHub Enterprise Server is not supported. {% endhint %} ### How Skills Are Detected StepSecurity scans each repository in your organization once a day and records the skills committed to its default branch. Skills that exist only on other branches do not appear until they are merged into the default branch. Archived repositories are not scanned. Repositories are scanned for the same agent skill folders that Dev Machine Guard detects on developer machines, such as `.agents/skills`, `.claude/skills`, `.cursor/skills`, and `.windsurf/skills`. For the full list of supported AI coding agents, see [Agent Skills](/developer-machines/ide-and-ai-agents/agent-skills.md) in Dev Machine Guard. ### Filtering and Search Two rows of filter chips scope the list. Each chip shows the number of matching skills. * **Source**: * `All skills`: all skills detected in supported locations in the organization's repositories * `skills.sh managed`: skills installed and version-managed by the skills.sh CLI (command-line interface) * `Committed in repo`: standalone skill folders committed directly to the repository and not managed by any CLI * **Agent**: a chip per AI agent detected in your repositories (for example, `Claude Code`, `Cursor`, or `Windsurf`), plus `Shared` for skills stored in the shared `.agents/skills` directory Below the chips, you can: * Search skills by name or repository * Narrow the table to one repository with the **Select repository** dropdown * Narrow the table by executable content with the **Any flags** dropdown: `Has code`, `Has hooks`, or `Shell execution` ### Skill Table Each row is one skill folder in one repository. A skill that is present in several agent directories of the same repository appears once per directory. The skill table shows the following columns: * **Skill**: the skill name and description from `SKILL.md`, followed by the path of the skill folder in the repository (for example, `.claude/skills/linked-script`). The following badges can appear next to the skill: * `invalid yaml`: the frontmatter of the skill's `SKILL.md` could not be parsed * `symlink`: the skill folder in this location is a symbolic link * **Repository**: the repository the skill is committed to * **Agent**: the agents that load the skill, with the skill's folder name beneath. StepSecurity determines the agent from the **agent folder**, the convention directory the skill is committed to. Examples include: | Agent folder | Agent | | ------------------ | ------------- | | `.agents/skills` | `Shared` | | `.claude/skills` | `Claude Code` | | `.cursor/skills` | `Cursor` | | `.windsurf/skills` | `Windsurf` | Other agent folders supported by Dev Machine Guard, such as `.github/skills`, are also detected. In a monorepo, the Agent column also shows the **project path**: the package the agent folder sits under. A skill nested in a package applies only when an agent is working in that package. * **Source**: how the skill is managed. * `skills.sh managed`: installed and version-tracked by the skills.sh CLI, with an upstream source such as a GitHub repository or a site that publishes skills at the standard `/.well-known/skills/` path. The column shows the upstream source (for example, `github`) and the upstream ref the skill was installed from (for example, `skills.sh ยท v1.4.2`). * `Local`: no managed source was identified for the skill. A `Local` skill may have been written in the repository, or copied or downloaded into it by hand. * **Flags**: executable content detected in the skill. A dash means no flags were detected. * `code`: the skill folder ships executable script files, in addition to `SKILL.md` * `hooks`: the skill declares a hooks block that runs automatically on the skill's lifecycle events * `shell`: the `SKILL.md` body injects shell commands. In Claude Code, for example, these run when the skill loads, subject to Claude Code's permissions and settings * **Files**: the number of files in the skill folder, including `SKILL.md`, counted from the repository's file listing. A skill is meant to be a `SKILL.md` plus whatever it bundles, so a high count means the folder holds more than instructions. The number of **scripts** appears beneath: files with an executable source extension, such as `.sh`, `.py`, `.js`, or `.ts`. Scripts are the files the `code` flag reports, and they are what an agent can run. {% hint style="info" %} Skills with flags deserve closer review, and a pull request that adds or changes a flagged skill deserves the same scrutiny as a change to a CI/CD (continuous integration and continuous delivery) workflow. In Claude Code, for example, inline shell commands can run when the skill loads, bundled scripts run when the agent invokes them, and hooks run on the skill's lifecycle events, subject to Claude Code's permissions and settings. Other agents handle skills differently. Whatever runs, runs with the privileges of the developer or automation running the agent. {% endhint %} ### Skill Details Select a skill in the table to open its details panel. The panel header shows the skill name, its source (for example, `skills.sh managed`), and the full path to its `SKILL.md`, prefixed with the repository name.
At the top of the panel, **Files** and **Scripts** show the number of files in the skill folder and how many of them are scripts. **Skill Information** includes: * **Description**: the description from `SKILL.md` * **Repository**: the repository the skill is committed to, linked to GitHub * **Agent**: the agent that loads the skill * **Path**: the path to `SKILL.md` within the repository, with a copy button * **Agent folder**: the skill folder, linked to its location in the repository * **Flags**: the `code`, `hooks`, and `shell` flags detected for the skill * **Version** and **License**: the version and license recorded for the skill * **Branch**: the branch the skill was read from (the repository's default branch) * **Last scanned**: when StepSecurity last scanned the skill **Declared behavior** shows the permissions and invocation settings that the skill's `SKILL.md` frontmatter declares. The descriptions below follow Claude Code's behavior for each field: * **Allowed tools** (`allowed-tools`): tools the agent can use without asking for permission during the turn that invokes the skill, such as `Read`, `Write`, or `Bash` * **Invocation**: who can start the skill and how it runs * `no model invocation` (`disable-model-invocation: true`): the agent can't start the skill on its own; a user has to invoke it * `not user invocable` (`user-invocable: false`): only the agent can start the skill; it is hidden from the `/` menu * `context fork` (`context: fork`): the skill runs in a separate subagent context * **Model override** (`model`): the model the agent switches to when the skill is invoked {% hint style="warning" %} Review **Allowed tools** for skills committed to a repository. In Claude Code, a skill's `allowed-tools` grant applies even when the repository's workspace has not been trusted, so a committed skill can give itself broad tool access, such as `Bash`, without a permission prompt. See [Pre-approve tools for a skill](https://code.claude.com/docs/en/skills#pre-approve-tools-for-a-skill) in the Claude Code documentation. {% endhint %} For skills.sh managed skills, **Provenance** shows where the skill came from: * **Managed by**: the tool that installed the skill (the skills.sh CLI), with a link to it * **Source**: the upstream source type (for example, `github`), linked to the upstream source * **Ref**: the upstream ref the skill was installed from (for example, `v1.4.2`) * **Upstream path**: the skill's folder within the upstream source * **Upstream folder hash**: the hash recorded for the upstream skill folder, with a copy button * **Lock file**: the skills.sh lock file that records the installation (`skills-lock.json`), linked to the repository --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stepsecurity.io/github/agent-skills.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.