Skills System Tuning

How to use Canoma's built-in skills, create custom skills, and keep outputs consistent across teams.

Skills are reusable instruction packs that shape how Canoma responds to recurring security workflows. You can use built-in skills, clone and customize them, or create your own from scratch.

How Skills Work in Canoma

Activation Model

Skills can be enabled/disabled individually.
A master toggle controls whether any skills run.
Canoma injects only the skill registry first, then loads full skill files on demand.

Model Compatibility

Skills run only when the selected mode supports skills for the current task.
In Auto mode, Canoma manages this automatically.
If a workflow depends on skills, verify activation status in Settings before critical runs.

Built-In Skills You Already Have

Canoma currently ships with these system skills:

threat-analysis
indicator-extraction
report-generation
vulnerability-assessment

What to Do with Built-In Skills

Enable them directly if they match your workflow.
Use Examples tab to inspect behavior.
Clone a built-in skill when you need org-specific output format or constraints.

Custom Skills: Creation Paths

1) Create with Canoma

Use conversational skill generation in Settings.
Canoma drafts name, trigger description, and full instruction body.

2) Write Skill Instructions Manually

Use the editor for direct SKILL.md-style authoring.
Best for precise workflows and strict formatting requirements.

3) Upload a Skill File

Import .md/.txt files (with YAML frontmatter supported).
Useful when migrating playbooks from existing documentation.

4) Clone + Customize

Clone built-in examples, then edit triggers/workflow/output structure.
Fastest way to get high-quality starting points.

Skill Authoring Requirements

Required Sections

When to Use
When NOT to Use
Workflow
Output Format (or Output Structure)
Constraints

Naming and Triggering

Skill names should be kebab-case and concise.
Trigger descriptions should be "pushy": include synonyms, acronyms, and edge cases.
Add explicit "do not trigger" conditions to reduce false positives.

Quality and Governance

Validation Set

Keep a small prompt suite for each skill:

Typical workflow prompts
Ambiguous prompts (boundary tests)
Negative prompts (should not trigger)

Change Management

Track version and update reason.
Peer-review any workflow or constraint changes.
Re-test with the validation set before enabling broadly.

Practical Skill Template

bash

When to Use
When NOT to Use
Workflow
Output Format
Constraints
Escalation Rule

Common Mistakes

Mistake	Impact	Better approach
Vague trigger description	Skill fires inconsistently	Include explicit terms, synonyms, exclusions
Missing output format	Hard handoffs to SOC/VM/leadership	Enforce fixed section structure
No negative conditions	Over-triggering and noisy responses	Add clear "When NOT to Use" boundaries
Untested updates	Silent quality regressions	Re-run validation prompt set after each edit