> ## Documentation Index > Fetch the complete documentation index at: https://docs.forge.ai/llms.txt > Use this file to discover all available pages before exploring further. # Skill Requests > Review, publish, distribute, and control reusable agent skills through the Forge Registry. The Skill Registry is the organization catalog for reusable agent skills. A skill is a reviewed instruction package that can teach an eligible agent or user how to perform a workflow, use approved tools, or follow an organization standard. Skills are content and workflow packages, not executable credentials. A skill can describe tool use and reference approved MCPs, but the agent still needs the corresponding identity, Registry access, policy decision, and runtime capability before an action can execute. ## What the Skill Registry provides Each published skill provides a durable record of: * Name, slug, description, owner, version, and publication state. * The reviewed `SKILL.md` content and package file manifest. * A content digest for identifying the exact approved package. * Audience rules for everyone, selected users, or selected directory groups. * Risk tier, threat-analysis findings, recommendations, and revision history. * Install and usage state for eligible users and supported agent clients. The Registry separates package publication from runtime authorization. A skill must be published for an audience before it can be installed, and its use can still be restricted by Skill Registry ACLs, organization policies, and the tools or MCP servers it references. ### Review risk information Skill analysis gives reviewers a customer-facing summary of the behavior and dependencies found in the submitted package. Depending on the available content, Forge can show: * An overall risk tier, summary, and recommended next steps. * Findings tied to the relevant instruction or package content. * MCP servers, tools, URLs, package names, and versions referenced by the skill. * Evidence explaining why the item matters and links to related Inventory or Investigation records. The analysis supports review; it does not replace reading the skill or checking the access granted to its audience. Missing URLs, packages, or tool references mean Forge did not observe them in the submitted evidence, not that the skill cannot reach external systems at runtime. ## Who can do what ### Console users Users with the required administration or Registry review access can: * Browse published skills and inspect their owner, version, digest, audience, and findings. * Submit a skill package for review or request a new revision. * Inspect the complete `SKILL.md`, package manifest, normalized content, and analysis results before publication. * Compare a replacement revision with the currently approved version. * Set or change the published audience to everyone, selected users, or selected directory groups. * Approve, reject, retry analysis, disable, or retire a published skill. * Configure Skill Registry ACLs and review usage and audit history. ### Self-serve users Eligible members can: * Browse skills published to their audience. * Read the approved instructions, version, owner, risk summary, and required capabilities before installation. * Install an approved skill in a supported client. * Submit a new skill or revision with a business use case and proposed audience, when self-service submissions are enabled for the organization. * Track analysis, review, approval, rejection, and publication status. Self-serve users cannot bypass publication, audience rules, ACLs, or policy controls by uploading a modified local copy. A local copy is outside the approved Registry supply chain and should be treated as an unapproved skill. ## Submit a skill A submission includes the package, business use case, and proposed audience. When self-service submissions are enabled, an eligible user can submit it from the Registry and track its analysis and review state. Console reviewers can submit on behalf of a team or use the same workflow for a controlled revision. ## Skill lifecycle ```text theme={"system"} Author or upload package ↓ Normalize and validate manifest ↓ Analyze content and package risk ↓ Review content, findings, and audience ↓ Publish an immutable approved revision ↓ Distribute to eligible users and clients ↓ Monitor use and retire or replace the revision ``` ### Package requirements A submission can be a Markdown file, ZIP archive, or `.skill` archive. A single Markdown file is treated as `SKILL.md`. An archive must contain exactly one `SKILL.md` at the archive root or inside one top-level folder. Forge rejects unsafe archive paths, unsupported active binaries, duplicate paths, missing manifests, and packages over its upload or analysis limits. The skill name is derived from YAML frontmatter, then the first H1 heading, then the uploaded filename. Keep skill packages focused and reviewable. A good skill should identify its purpose, expected inputs, safe operating boundaries, required tools, failure handling, and when to ask the user for confirmation. Do not place API keys, tokens, private customer data, or hidden executable payloads in a skill. ### Analysis and review Forge normalizes the package, stores a content digest and file manifest, and runs threat analysis. The request moves through: | Status | Meaning | | ---------------- | ---------------------------------------------------------- | | Pending analysis | Package normalization or automated analysis is running. | | Ready for review | Analysis completed and an authorized reviewer can decide. | | Analysis failed | Analysis did not complete and can be retried. | | Approved | The reviewed revision was published to the Skill Registry. | | Rejected | A reviewer rejected publication. | Analysis can produce a risk tier, findings, summary, and recommendations. A reviewer should compare the requested audience with the package's actual behavior and referenced tools, not approve based only on the skill description. ### Publish and revise Approval publishes the reviewed content as a Registry revision with its digest and audience. Revisions are reviewed independently. For a replacement, inspect the diff from the approved version and confirm that changes to instructions, tool references, data handling, or audience are intentional. To retire a skill, disable or remove its published access and revoke the audience as appropriate. Existing client installations should be checked for cached content and active workflows during retirement. ## Distribution and runtime behavior The Registry makes a skill discoverable only when its publication state, audience, and ACLs allow the current user to see it. Installation does not grant access to referenced MCP tools. At runtime, Forge evaluates the skill access decision and then separately evaluates each tool or content action. For a skill that references an MCP server, verify all of the following: 1. The skill revision is published and available to the user. 2. The referenced MCP server and tools are approved for the same audience. 3. The user's client has the required installation and connection state. 4. Credential and upstream scopes cover the requested operation. 5. Skill Registry ACLs, MCP ACLs, and organization policies allow execution. This separation lets an organization publish a general workflow while limiting the sensitive tools it can actually invoke. ## Review checklist Before publishing a skill: * Identify the author, owner, intended audience, and business outcome. * Read the complete `SKILL.md`, including examples and fallback behavior. * Confirm that instructions do not request secrets or bypass controls. * Enumerate every MCP server, tool, URL, file path, and external destination it references. * Verify that requested tools are approved independently and have least privilege. * Review threat-analysis findings, package digest, and revision diff. * Pilot with a small group and monitor sessions, tool calls, and policy results. * Define how to revoke, replace, and communicate a compromised revision. See [Registry ACLs](/developer/registry-acls) for Terraform-managed skill access and [Policies](/secure/overview) for organization-wide content controls.