Draft a skill from your sessions
Draft a new skill or improve an existing one from your team's Claude Code sessions. Slancha shows scan findings and usage counts; it does not grade skill quality. Drafts require human approval before publication.
Before you start
- Premium access enabled for the workspace by Slancha.
- Sessions flowing in. A draft needs at least four recorded sessions to read. See Sessions and Install the CLI.
- The workspace's own key for its model provider. See Jobs and keys.
- The admin role. Only an admin can start a draft, because it sends session excerpts to a model provider. An admin can also let agent tokens start drafts, in Workspace settings.
Write a new skill
On Skills, choose New skill from traces. Give it:
- a name, which must not already be in the library;
- one line saying what it is for;
- the project it is written from. The picker lists the projects Claude Code worked in over the last 30 days, with a session count for each. A project is the directory Claude Code was running in.
Read the notice, tick the box that says you understand which traces are sent and to whom, and choose Write the skill. If no sessions were seen in the last 30 days there is nothing to pick, and the dialog says so.
Improve a skill you serve
Open the skill's page and choose Improve from traces. The job reads the sessions in which that skill was used, from the last 30 days. A draft improves the body of SKILL.md. It leaves the frontmatter alone. It may also add or replace files under references/ and examples/. It does not touch scripts/ or anything else.
The button is off, with the reason beside it, when:
- you are not an admin;
- a change to that skill already waits for review;
- another job for the skill is running;
- the served version has not cleared its security scan. A model reads a version only after its scan clears.
How each session is labeled
Before any model reads a session, Slancha labels it from the trace alone. No model decides the label.
| Label (as the console shows it) | Meaning |
|---|---|
errored (errored) | A turn in the session was recorded as an error. |
user followed up (followed_up) | The user said something after the agent's answer. |
no follow-up (no_follow_up) | The session ended on the agent's first answer. |
Sessions with errors or follow-ups are read first. A follow-up may be a correction, thanks or another request; it does not establish failure.
What leaves Slancha
The job sends scrubbed excerpts of your workspace's sessions to the workspace's model provider on the workspace's own key. The admin acknowledges this each time, and the acknowledgement is recorded in the audit trail. The job reads sessions from your tracing project; see Security for every flow.
What the job writes
The job reads the sessions, updates the skill's wiki, and proposes a version. Before anything is stored:
- A check looks for opaque identifiers the draft would add, such as UUIDs and long hex strings.
- The same credential check an upload gets runs on everything the draft wrote. A hit proposes nothing. The job names the file, the line and the kind of secret, never the value.
- The scan described in Skills and review runs on the result, with no model.
A passing draft waits in Review, proposed by the job rather than a person. Its card marks it as unmeasured and shows up to 12 shortened source sessions: the label, first request, follow-up and ending. Review that evidence before approving.
If no proposal is created, the job page gives the reason: no change, blocked scan, failed static checks, duplicate content or invalid candidate.
The wiki
Open Wiki for model-written observations about a drafted skill and a record of each draft's outcome.
What it costs
The model provider bills calls to your own key under the pricing for the models and service tier used. The job page estimates costs from list prices; it is not a bill.
Each run has a server-configured cost cap that cannot currently be changed in the console or hosted API. Runs stop after exceeding it; the cap is not a guaranteed spending limit.
What is not measured
Slancha shows scan findings and usage counts; it does not grade skill quality. It does not compare a draft with the previous version. The skill page shows plugin-reported use and tool invocation successes and failures by version, not measured task quality. Review later sessions to assess whether the change helped; those observations do not prove the change caused an improvement.