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

---
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.

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 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.

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

Authoring your own skills

Write a project skill that overrides a built-in.

Built-in skills

The shipped skill catalog with full descriptions.

Memory

The other half of agent context.

How Qodex works

The coordinator + sub-agent execution model.