Skills

Purpose

Skills are reusable instructions that describe how to perform a type of work. They can guide agents on method, context, criteria, and expected behavior. Allye's library shows only resources authorized for the user and current context.

Prerequisites

• Be authenticated and have an active team.
• Have skill view permission to browse the library.
• Have create permission in the skills module to create, import, or fork a skill.
• To edit, delete, activate, or export a skill, have the corresponding capability.

Key concepts

Scope and ownership

The current library works with three internal scopes:

• Personal: belongs to one person and is appropriate for individual preferences and methods.
• Team: belongs to a team and guides shared work.
• Organization: belongs to the organization and defines broad practices.

Ownership and scope determine who can view, edit, activate, delete, or fork a skill. A skill appearing in search does not imply that the person has the right to change it.

Category and origin

Skills can be classified as Frontend, Backend, Mobile, Fullstack, DevOps, Infrastructure, Architecture, Code Review, Testing, Security, Documentation, Performance, or Other. The origin can be manual, a local file, or GitHub, among other registered origins.

Lifecycle and review

The observed lifecycle is draft, in_review, approved, or rejected. The main library presents the approved and current version when it is authorized. History records revisions, origin, version, digest, and, when applicable, the reason for rejection.

A rejected revision can be reopened as a new draft for correction.

Find a skill

1. Open Skills.
2. Search by name or content.
3. Filter by scope, category, owner, lifecycle, or runtime when those filters are available.
4. Sort by recency or name.
5. Choose grid, table, grouped, or ecosystem view to change how results are read.
6. Open a skill to review its description, content, compatibility, origin, and lifecycle.

The list is paginated. Use Load More when more results are available; the ecosystem view may load additional pages automatically.

Create a personal skill

1. Select New Skill.
2. Enter a name and description.
3. Keep the Personal scope, which is the scope allowed for creation in the current flow.
4. Choose a category.
5. Write Markdown instructions, including the objective, context, steps, and limits.
6. Select Create Skill.
7. Review the draft and, when the review flow is available for your role, submit it for evaluation.

A skill should be actionable. Prefer verifiable instructions, the necessary file names or product concepts, and clear criteria for stopping and asking for clarification.

Recommended structure

# Skill name

## When to use
## Required context
## Procedure
1. ...
2. ...

## Constraints
## Expected result

Import skills

Local file

1. Select Import.
2. Choose one or more compatible files.
3. Review the detected name, description, category, and content.
4. Confirm the Personal scope.
5. Import the items and open them to validate the result.

GitHub

1. Select GitHub.
2. Enter the requested repository or source.
3. Choose the branch and listed files.
4. Confirm the import into the Personal scope.
5. Review the origin, path, branch, and commit shown in the detail view.

Importing is different from approving: imported content still has to follow the workspace lifecycle and authorization rules.

Edit, activate, export, and fork

• Edit: change the name, description, content, or category when your capability allows it.
• Activate/deactivate: use the activation control to prevent a skill from being used without deleting it.
• Export: download the Markdown content when you have export permission.
• Fork: create a copy in an authorized scope, preserving the relationship to the origin when the product records it.
• Reopen review: for a rejected revision, use the reopen action to generate a new draft.

Before editing a team or organization skill, check its owner and purpose. A broad change can alter the behavior of several agents.

For agents

Agents should consume a skill as operational guidance, not as unquestionable authority:

1. Resolve the skill by the name or slug available in the workspace.
2. Confirm its scope, owner, lifecycle, and whether the revision is current and approved.
3. Read the full content before starting the procedure.
4. Combine the skill with the current request, permissions, and active team.
5. If an old skill conflicts with the current workspace state, stop and ask for confirmation or record the decision in Memories.
6. Do not treat a draft or rejected skill as an approved default.
7. When suggesting a new skill, include usage context, constraints, and success criteria.

Personal skills are appropriate for agent or user preferences. Rules that must apply to the entire team should be proposed in the Team scope and reviewed before adoption.

Current states and limitations

Current state: the application provides an authorized library, filters, pagination, multiple views, creation, editing, deletion, file import, GitHub import, fork, Markdown export, lifecycle, and revision history.

• The main library filters resources to show skills visible to the owner, team, or organization authorized in the current context, including approved and current skills.
• In the current flow, creation, import, and fork are restricted to the Personal scope in the interface.
• Marketplace appears in legacy types and services, but it is not the primary writing flow for the current library; do not treat it as a creation destination.
• The application shows history and allows rejected revisions to be reopened, but the complete submission and administrative review experience depends on the role and is not uniform across screens.
• A skill can have valid content and still not be current or approved. Check its lifecycle and revision before recommending its use.
• If no skills appear, review scope, filters, active team, and authorization before concluding that the library is empty.

Next steps

• Record the decisions and reasoning behind a skill in Memories.
• Put navigable explanations in Documentation.
• Use Access and teams to understand owners, groups, and capabilities.
• Create a small personal skill before proposing a team or organization rule.