> ## Documentation Index
> Fetch the complete documentation index at: https://qodex.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Skills
> Skills define how Qodex behaves in specific testing domains through drop-in markdown files.
# Skills
Skills tell Qodex how to behave in a specific testing domain.
A skill can specialize the agent for API testing, UI exploration, security checks, auth flows, reporting, or your own internal testing rules.
## What a skill is
A skill is a single `.skill.md` file. YAML frontmatter declares the skill's identity, the tools it can call, and a few behavioral settings. The markdown body is the instruction set the LLM sees when that skill is active.
Drop a `.skill.md` file in the project's skills directory. No TypeScript, no compilation, no restart. The skill loader picks it up on the next agent turn.
## File format
```markdown theme={null}
---
id: security
name: Security Testing
description: Automated security testing against OWASP Top 10 and OWASP API Top 10.
tools:
allow: [api_call, browser, memory, finding_report]
deny: []
---
# Security Testing
You are a security testing agent. Your job is to systematically test the
target application against OWASP Top 10 (2021) and OWASP API Security Top 10.
Pass means the app blocked the attack. Fail means the app is vulnerable.
```
## How Qodex uses a skill
The coordinator agent reads the user's brief and the available skills. It then calls one of two tools to engage a skill:
* `invoke_skill(skill_id, brief)` runs the named skill inline. The coordinator's prompt is replaced with the skill body for the duration of the call, then resumes.
* `spawn_subagent(skill_id, brief)` runs the named skill in an isolated sub-agent with its own context. The sub-agent returns a structured result; only the result flows back to the coordinator.
Both tools take a `skill_id` whose enum is generated from the on-disk skill files at startup. If you add a new skill file, it appears as a valid argument on the next process boot.
## Tool access per skill
Each skill declares which tools it can call. The registry filters the tool list to the skill's allow/deny set before the LLM ever sees a list, so the model cannot wander into out-of-scope territory. A skill scoped to functional testing never sees security probes; a skill scoped to security never sees performance tooling.
## Built-in skills
Twelve `.skill.md` files ship in the qodeclaw repo. The list as of June 2026:
| Skill | Purpose |
| ------------- | ------------------------------------------------------------------------------------------------------------- |
| `analyze` | Reads imported specs and collections, summarizes endpoints, identifies auth, recommends an authoring strategy |
| `api` | Functional API testing: scenario authoring, chained calls, assertions, run-and-triage |
| `api-author` | Specialist sub-agent for translating an English brief into a structured scenario JSON |
| `auth` | Login resolution and credential probing across HTTP and UI login flows |
| `explore` | Deterministic crawl of a web app to populate the Pages catalog and discover endpoints |
| `pentest` | Active penetration testing: attack vectors, exploitation chains, evidence capture |
| `performance` | Performance testing (load, latency, memory) |
| `report` | Final-pass summarization across a scan's outputs into a human-readable report |
| `security` | OWASP Top 10 + OWASP API Top 10 audits with inverted-semantics scenarios |
| `setup` | First-run setup actions during onboarding |
| `ui` | UI scenario authoring, intent-driven steps, UI run orchestration |
| `ui-author` | Specialist sub-agent for translating a UI brief into a structured scenario JSON |
The reference list with full descriptions lives at [Skills: built-in](/skills-built-in).
## Project skills override built-ins
A `.skill.md` file in your project's skills directory with the same `id` as a built-in replaces it. The built-in `security` skill is your baseline; your project's `security.skill.md` is the override. Useful for domain-specific testing: GraphQL, gRPC, compliance, internal protocols.
## When to use it
* Use a skill when the agent needs recurring domain-specific behavior, such as compliance checks, internal protocols, or a proprietary auth flow.
* Copy and edit a built-in when it is close but not exact.
* Use tool gating when a category should only have access to specific tools.
## When not to use it
* A one-off probe. Use chat directly; the coordinator picks the right built-in.
* Hardcoding business logic that belongs in [memory](/memory) instead. Skills are reasoning rules; memory is project facts.
## On the roadmap
Planned: a skill registry for npm-based or Git-based distribution so teams can share project skills without copy-paste. See [backlog.md](https://github.com/flinket/qodeclaw/blob/master/backlog.md).
Planned: skill routing telemetry. Track which skills the coordinator chose for which briefs, surface drift patterns, feed back into the skill descriptions used at routing time.
## Related
Write a project skill that overrides a built-in.
The shipped skill catalog with full descriptions.
The other half of agent context.
The coordinator + sub-agent execution model.