> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/build-and-improve/intelligence/skills.md). # Skills Create and maintain reusable Agent capabilities that encode how a recurring operational task should be done. A Skill is a reusable operating method for the Agent. Most Skill building happens **from the Agent itself**: give it representative work, examples, rules and corrections, and let the Agent write or update the Skill for review. Use **Intelligence → Skills** as the canonical inventory, version-history and direct-edit surface. ![The current Skills inventory in Intelligence.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FOG2pKRAQD03aex3aaa7e%2Fskills-current.png?alt=media) ## One object, two doors The Agent is where Skills are usually built and corrected. Intelligence is where the resulting Project Skills are listed, inspected, versioned and edited directly. A Skill published from the Agent is not a separate kind of Skill; it is the same maintained Project capability shown here. ![The Agent proposing a reusable Skill after a user asks to make the method available to the rest of the team.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FbbbfFesFekOwBpYCSPGc%2Fskill-proposal.png?alt=media) For the complete builder method, including common Skill patterns and design guidance, see Skills and operating methods. ## Common shapes you will see Typical Skill shapes include: * document generation from maintained templates and structured data; * recurring data checks and exception lists; * staged work with human checkpoints; * connectors that wrap a system into reusable named operations; * file intake and structured extraction; * form/questionnaire completion from maintained facts; * tender or bid responses; * constraint-checked option generation; * supporting report rendering and durable correction/rules loops. These are reusable work shapes, not product templates a builder can currently select from a blueprint catalogue. ## What a Skill contains A useful Skill can define the intended outcome, rules and checks, authorised system actions, reference material, Project files, Tables, Workflows and the points where the Agent should bring a person into the work. That can include Agent-native tools such as **Ask user** for structured input or **Propose a call** to offer the user a live **Call with Agent** from the web Agent. The user starts the live call by pressing **Call**. It can also specify the presentation surface: an in-stream HTML widget for a compact interactive result, or an HTML artefact for richer standalone output. The Connection remains separate: the Skill can use an authorised Connection, but the Skill does not own or grant that credential. ## Skill detail, components and approval The current Skill detail surface uses a two-pane layout: editable Skill fields on the left and **Preview**, **Tests** and **Versions** on the right. Skills can attach components such as Workflows, files, credentials, Tables and Knowledge. Where the component can perform an action, the Skill surface can expose an **Ask for approval** control. The Agent can also propose files and existing Project data as part of a Skill build. Review the proposed components as part of the draft gate; accepting the Skill means accepting the maintained capability it contains. ![A current Skill detail view with Components and approval controls alongside Preview, Tests and Versions.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2F1NF7FQiLe2eOHIoYoFbq%2Fskill-components-current.png?alt=media) This Skill-level approval is separate from connection-level action policy and from explicit Workflow `Request Decision` or `Request Input` nodes. ## Tests and evaluations Eligible Project builders can open **Tests** from Skill detail and Skill proposal views to exercise representative cases during the build/review loop. The surface follows the normal Project and acting-user permission boundary. Use tests to reduce uncertainty about known cases, then make an explicit review/publish decision. Test evidence does not silently publish or rewrite the live Skill, and operator feedback remains evidence to inspect rather than an automatic instruction change. ![The current Tests surface on a Skill, showing representative cases and their pass or fail results before review and publishing.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FIfdkm5dN7WAIvxhHSTgI%2Fskill-tests-surface-current-prod.png?alt=media) ## Invocation, versions and publishing When **Allow the agent to invoke this skill automatically** is enabled, the Skill is available for automatic use. When it is off, the Skill is hidden from the Agent's automatic Skill list and is invoked explicitly with `/skill-name`. Skills also expose an enabled state, version information and a **Publish** action. Agent-authored updates are reviewed as proposed changes before they replace the live version; version history provides the maintained record of those published changes. Treat these as capability lifecycle controls. An edited draft is not equivalent to a silently self-modifying production Skill. ## Practical lifecycle **representative task → expected outcome → Agent writes or updates Skill → review → run representative cases → correct → review diff → rerun previously-good cases → publish → improve from evidence** Corrections are evidence for a reviewed improvement, not permission for the production Skill to rewrite itself silently. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.lleverage.ai/build-and-improve/intelligence/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 `automate deployments from our CI pipeline` 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.