Skills

What a skill is

A skill is a reusable description of how a piece of work gets done: the steps, when it is relevant, what context it needs, and what the result has to look like. FixControl ships a set of them and you can write your own.

A skill is a requirement, never a grant. It can say "this job needs the ability to open a browser", and an agent that does not hold that ability simply cannot run the skill — the skill cannot hand it out. What an agent is allowed to do stays with governance and policy; a skill only shapes how it does what it may already do.

Open it at Skills (/skills). Reading is open to everyone who can sign in — an operator watching a run has to be able to see which skills shaped it. Creating a skill, switching one on or off, importing and reviewing are admin-only. Editing a skill and assigning it to agents can be done by an admin or a manager.

You can ask for this instead of navigating to it. Ask Command Center "what can the agents do?" and it lists the skills, what each is for, which agents use it, and whether an agent it is assigned to can actually satisfy it. It can switch a skill on or off, give one to an agent or take it away, and simulate whether a skill would fire for a piece of work without running anything. Writing a new skill — its steps, its triggers, what it requires — stays here: a procedure is not a sentence.

Why you would use one

Three reasons, in the order they usually come up:

Make a recurring job consistent. The same kind of ticket should be handled the same way, whoever is on shift and whichever run picks it up.
Write down what your team knows. "Check the migration folder before touching the schema" is knowledge that otherwise lives in one engineer's head.
Ask for real verification. Two of the shipped skills do not just describe work — they open a real browser against the changed routes and against the previewed application, and produce a verification result.

The list

The Skills page is a registry of every skill your organisation has — the ones FixControl ships, the ones you wrote, and the ones you imported. Per skill it shows the name, its source, its trust level (Internal, Verified, Community, Quarantined), its review state (Pending review, Approved, Rejected, Needs re-review), its risk, which agents use it, and its status. Clicking a row opens the details beside the list; Open full page opens the skill's own page.

Quick filters: All, Installed, Active, Needs review and Attention, plus filters on source, trust, category, risk, the agent that uses it and the platform. Attention is the one worth watching: it collects skills whose assigned agent cannot actually run them (Assigned agent cannot run it — the skill is then inert rather than silently half-running), skills in quarantine, skills whose content no longer matches its checksum, and imported skills with an update available.

Add / Discover skill offers three ways in: Discover skills (a curated catalog), Import from a source, and Write a custom skill. Whatever the way in, a new skill never starts influencing runs the moment you save it: a custom skill lands as a draft waiting for review, an imported one lands disabled and waiting for review.

Importing a skill, review and trust

Besides writing your own, you can import a skill from outside: an entry from the discovery catalog, a skill in a GitHub or GitLab repository, a SKILL.md file, or pasted text. Importing and reviewing are admin-only. An imported skill always lands disabled and pending review.

Pinned, never floating. An import is fetched at an exact commit and stored as a snapshot with a checksum. The skill runs that stored version — never whatever the source says today. If the stored content ever stops matching its checksum, the skill is put in quarantine and nothing runs it.
Scanned, then reviewed by a person. Every imported version is scanned for things a skill should never ask for — overriding the system's instructions, leaking secrets, bypassing approvals, pushing to production, arbitrary shell commands, hidden characters and more. Before a skill can be approved, every high or critical finding has to be acknowledged one by one. A clean scan is one layer, not a verdict: the review is the decision.
Only approved and trusted skills are used. A skill is available to an agent only when its trust is Internal or Verified, its review is Approved, its content matches its checksum, and it fits the environment's platform and runtime. That is checked when you assign it, when you enable it, and again at every run.
Updates wait for review. Check for update fetches a newer version from the source; it waits for review next to the pinned one, with a diff, and the pinned version keeps running until you switch. Switching back to an older approved version is a rollback, and recorded as one.
Editing an approved custom skill — its instructions, procedure, capabilities, context, roles or output contract — sends it back to Needs re-review; until it is approved again, no agent uses it. Renaming it, or changing its description, cost or triggers, does not.
A custom or imported skill that requires no capability at all is refused: it would reach every agent.

Every step — import, review, approval, rejection, update, version switch, rollback, quarantine — is recorded in the skill's audit history.

FixControl engineering skills (opt-in)

FixControl ships a set of engineering skills — advisory guidance on how to understand code before changing it, debug, test, review and more. They are off for your organisation until you switch them on: the Skills page says how many are available and that they are switched off for this organisation, with the button Enable FixControl engineering skills ({count}). Switching them on is an admin decision and is recorded with the value before and after; Disable switches them off again.

What they do once on: they add a delimited block of advisory guidance to the task of the Developer, QA and Support agents they are assigned to — never to the system instructions, and never with any permission. The guidance says itself that it is subordinate to every system rule, scope, approval policy and execution constraint. A guidance text is handed over whole or not at all (at most 4,000 characters per skill), and the text of a shipped guidance skill cannot be edited. A skill you switched on or off one by one keeps its own status when you use the organisation-wide switch.

Statuses

Status	Means
Active	Eligible for selection. This is the only status a run ever picks.
Draft	Being written. Never selected.
Disabled	Switched off, kept. Never selected.
Archived	Retired, kept for history. Never selected.

What is inside a skill

The detail page has ten tabs: Overview, Provenance, Review, Instructions, Triggers, Context, Capabilities, Agents, Verification and Versions.

Provenance — where the skill came from: shipped by FixControl, written by your organization, or imported, with the source and the exact pinned version — plus the platforms and runtimes it fits.
Review — the review state, the security scan findings and the review decision.
Instructions — the procedure in plain language, and the result expected from it.
Triggers — when the skill is relevant. A trigger matches on the agent's role, the kind of issue, a flag on the issue, a changed-file pattern, a UI/UX mission, a failing test, an explicit request, or always. Patterns are literal text or a bounded wildcard — never a regular expression, so a trigger cannot be written that takes a long time to evaluate.
Context — which sources the skill needs the agent to have read.
Capabilities — what the skill requires (and optionally prefers). This is the list that decides whether an assigned agent can run it at all.
Agents — who it is assigned to. Assigning an agent that lacks a required capability is allowed and flagged, not silently dropped.
Verification — whether the skill produces a verification result, and how strict it is.
Versions — see Every change is a version.

What a custom skill may never require

Some capabilities are not shapeable by a skill, because a skill is not the place where authority is decided: delegating orchestration, the technical gate, the security gate, the deployment gate, escalating a workflow, applying a patch, releasing to production, unattended deployment, and carrying a CI/CD verdict. Requiring one of those is refused when you save, with the capability named.

How a skill is chosen for a run

Order matters, and it is not the order you might expect:

The orchestrator picks the agent for the piece of work. A skill never selects an agent and never routes work — see Orchestration & context.
Only then are that agent's active, assigned, triggered skills collected.
They are ordered by the priority of the trigger that matched, highest first, and at most five are carried into the run. What was cut is recorded, so a run can tell you that a sixth skill matched and did not make the cut.

Every selection is recorded per run with one of four outcomes: selected, executed, refused or failed. A refusal names its reason — most often a capability the agent does not hold.

Changing a FixControl skill

You can adapt a shipped skill to your organisation without forking it. Editable: the name, description, instructions, triggers, context requirements, verification policy, cost policy and status.

Locked for the life of the skill: its required and optional capabilities, its procedure, its output contract, and which agent roles may hold it. Those four are what makes a shipped skill the thing it claims to be — an organisation that could rewrite them could turn "verify in a real browser" into something that verifies nothing while still reporting a verification.

An edited FixControl skill is labelled edited in the list, and Restore puts the shipped version back.

Un-assigning a shipped default is an explicit act and is stored as one, so an upgrade never quietly re-attaches a skill you deliberately removed.

Every change is a version

A skill version is identified by its content, not by an edit counter: the governing fields are hashed, and the hash is the version. Two consequences that matter in practice:

A run can always name exactly the version it ran under — including the untouched default, because that is a version too.
Editing a skill back to what it said before produces the same version it had before, and the timeline still shows both edits.

Versions are append-only: a new version is added, never written over an old one.

Cost

Each skill carries a cost class — Low, Medium or High — so a skill that opens a browser is visibly not the same weight as one that adds a paragraph of instructions. The class is informational: it does not override the model-cost ceilings on the agent itself, which are described in Orchestration & context.

Try it before you rely on it

Each skill has a read-only simulation: it answers "given this kind of work, would this skill be selected, and what would it be allowed to do?" Nothing runs, no work is created, no agent is dispatched. It uses the same resolver the real run uses, so the answer cannot drift from the real behaviour.

FAQ

Can a skill give an agent a new ability? No. It can only require one the agent already has. This is the single rule that keeps skills safe to delegate to an admin.

Can I make a skill run for every issue? Yes — the always trigger. Remember the cap of five skills per run: an always-on skill competes with the ones that matched something specific.

What happens to a skill whose agent was paused? Nothing runs it. Pausing an agent removes its tasks from the plan; the skill stays assigned and becomes active again when the agent does.

Are skills per project? No. A skill belongs to your whole organization. Scope work to a project with projects and triggers, not with a second copy of the skill.