Skills and review

Every skill change needs a clean security scan and an approver's decision before publication.

What a skill is

A skill contains a root SKILL.md and any supporting text files. SKILL.md names the skill, explains when to use it and gives its instructions.

The name must match the upload name: up to 64 characters using lowercase letters, digits and single hyphens.

Upload

Open Skills > Upload a skill. Proposers, approvers and admins can upload a zipped folder or SKILL.md with its files. Uploads wait in Review; they are not published.

Upload limits:

Only text files are accepted. A file that holds what looks like a credential is refused, and the message names the file, the line and the kind of secret, never the secret. A package that fails Slancha's admission checks is refused too. Warnings from those checks travel with the change and show on the review card.

Each skill can have one pending change. Approve or reject it before uploading another. Uploads identical to the published version are rejected as duplicates. Other uploads propose a new skill or an update.

The security scan

Uploads are scanned automatically with a skill scanner. Model-assisted analysis is off; no model call or key is needed.

A version is cleared only if all of this holds:

• the scan ran to the end;
• the scanner's recommendation is SAFE;
• the scan reports no problems;
• no finding has HIGH or CRITICAL severity.

Anything else counts as not cleared, including a scan that failed or was cancelled. The review card lists each finding as a rule id, a severity and a file and line, never the scanned text. Approve stays disabled until the scan clears, and the API refuses the approval too. Nobody can override a blocked scan from the console. A proposer or above can scan again from the review card or the skill's page. If the scan could not start, the upload stands and the card offers to scan again.

A clean scan permits approval; it does not establish quality or safety.

Review

Open Review to inspect pending changes. Each card shows:

• who made the change and when, and whether it was uploaded or written from sessions;
• the security scan, and any reason to hesitate (a blocked scan, a failed acceptance criterion, a stale base, a warning);
• for an update, the size of the change: lines added and removed, and how much of the body changed. A large rewrite is flagged;
• the files in the package, changed files first;
• the diff between what is served and what is proposed, and a side-by-side view;
• for a draft, the sessions it was written from, each with its label (see Sessions). For an upload the card says so: uploaded by a person, not measured.

Slancha shows scan findings and usage counts; it does not grade skill quality. Review the evidence before approving.

Acceptance criteria

An admin can set acceptance criteria on a skill's page: exact rules each new version must meet. A rule is one of:

Matching is exact and case-sensitive. A skill takes up to 50 rules, and a rule's text is 1 to 500 characters.

Everyone can read the rules on the skill's page, with whether the served version and the version waiting for review pass each one, and why not. Only an admin changes them.

A change that fails a rule cannot be approved. The review card lists each failure, Approve stays disabled, and the API refuses the approval too. The rules are checked again when someone approves, so a rule added during a review still counts. Upload a version that passes, or ask an admin to change the rule. A rollback is not checked; its result says when the version it restores fails a rule. To check a skill before you upload it, run slancha criteria <skill> --check <folder or zip>; see Install the CLI.

Approve, reject, roll back

Approvers and admins can:

• Approve serves the version. The approval names the exact change you reviewed, so if someone replaced the pending version while you read, the approval is refused and you review again. It is also refused if the served version changed since the proposal was made, or if the version fails the skill's acceptance criteria.
• Reject drops the pending version. An optional reason, up to 500 characters, goes into the audit trail.
• Roll back serves a version this skill served before, or stops serving a skill that began as a new one (the button says Unpublish). A rollback is recorded in history and can itself be undone. It serves bytes that were already approved. It does not scan them again.

History

History lists publications newest first, with the action, versions, person and time. Download any published version as a zip.

The audit trail shows the latest 100 approvals, rejections, rollbacks and downloads, with the person responsible.

Use

The skill list shows how often each skill was used in the last seven days. A skill's page breaks the last 30 days down by version: invoked, reference reads, succeeded and failed. The Slancha plugin reports this; see Install the CLI.

These are Skill tool invocation counts: success comes from the hook event and tool response, not a judgment of the finished task. Slash-command invocations can have no success value. These counts do not establish task completion or that a skill improved the result.