Skills

What a skill is

A skill is a documented procedure an agent loads when it becomes relevant — a Markdown file with YAML frontmatter, same shape as an agent. A skill has no model and no budget of its own: an agent calls activate_skill, and the skill’s instructions enter that agent’s context and run on its budget. The reason skills exist is context economy. A comprehensive scanner might know how to analyze twenty vulnerability classes, but loading all twenty procedures up front would crowd out the code it’s supposed to be reading. Instead it loads the SQL-injection procedure when it’s looking at a query, and the SSRF procedure when it’s looking at an outbound request.

Skill or agent?

Write a skill when	Write an agent when
You’re capturing how to do one thing well	You’re defining a job with its own output
An existing agent could follow your instructions	You need different tool permissions or a different model
The procedure is only relevant sometimes	The work deserves its own budget and can be delegated to
You want it available to many agents	You want to name it as a workflow step

When in doubt, start with a skill. It’s cheaper — nothing to budget, nothing to orchestrate — and you can promote it to an agent later if it grows its own output.

Frontmatter reference

Key	Required	Type	What it does
`name`	Yes	string	How the skill is activated and listed.
`description`	Yes	string, ≤500 chars	When to use this skill. Agents read it to decide whether to activate.
`allowed-tools`	No	string[]	Tools the procedure expects. See the tool reference.
`license`	No	string	Optional license string.
`compatibility`	No	object	`min-version` / `max-version` constraints.
`metadata`	No	object	Free-form key/value data.

---
name: ssrf-analysis
description: Confirms or rules out server-side request forgery where user input reaches an outbound HTTP call. Use when a request URL, host, or path is influenced by request data.
allowed-tools:
  - shell
  - code_lineage
  - ripgrep_search
---

# SSRF analysis

## Confirming

1. Identify the outbound call and the client library in use.
2. Trace the URL argument back to its source with `call_graph`.
3. Establish whether an attacker controls the scheme, host, or path — not merely the query string.
4. Check for an allow-list, a resolved-IP check, or a proxy that constrains the destination.

## Ruling out

Discard the candidate when the host is a compile-time constant, or when the only
attacker-controlled portion is a path segment appended to a fixed host with no
traversal possible.

Like an agent’s, the description is load-bearing: it’s what an agent reads when deciding whether this skill applies.

Built-in skills

Skill	What it does
`vulnerability-scan`	Uses natural-language policy descriptions to find vulnerabilities in application logic.
`opengrep-rule-creator`	Authors OpenGrep rules for detecting a vulnerability or code pattern.
`codeql-rule-creator`	Authors CodeQL queries for vulnerabilities, bug patterns, and code-quality issues.
`policy-detection-creator`	Turns a security requirement into a stored natural-language policy detection.
`skill-creator`	Turns a procedure — often a script you already have — into a skill and saves it to your organization. See organization skills.
`agent-creator`	Authors, edits, and deletes agent definitions through the agent tools.
`secrets-scan`	Finds leaked credentials in a repository with the `secrets_scan` tool and files one masked finding per secret. Works in chat against an attached workspace and as a workflow step.
`sca-scan`	Finds known-vulnerable dependencies in a repository’s lockfiles with the `sca_scan` tool and files one finding per vulnerable package, with the fixed version. Works in chat against an attached workspace and as a workflow step.

The scanner agents also draw on an internal library of class-specific analysis skills, which is what distinguishes the standard and comprehensive profiles from basic.

Where to author a skill

Skills are authored in the CLI — as files on disk, or saved to your organization by asking the CLI to create one. Unlike agents and detections, there is no skill editor in the web console today.

A skill lives in one of two places, and each is loaded by something different:

Local files on your machine are loaded by your own CLI sessions.
Organization skills are loaded by cloud runs — workflow steps, and agents that chat dispatches to run against a repository.

Local files

In the CLI, a skill is a file on disk:

~/.amplify/skills/<name>/SKILL.md    # available in every session
./skills/<name>/SKILL.md             # project-local

Override those locations with AMPLIFY_SKILLS_DIR. Skills load at startup, so restart the CLI after adding one. A skill directory can hold supporting files — reference documents, example rules, helper scripts — next to SKILL.md, and the instructions can point the agent at them. Local files never leave your machine: cloud runs don’t see them.

Organization skills

To make a skill available to cloud runs, save it to your organization from the CLI while signed in. The built-in skill-creator skill guides the flow — ask for it directly:

I have check.py. Write a skill so the agent can run it, and save it to the organization.

The agent reads the script, confirms the name is free with list_skills, drafts SKILL.md, bundles the script under scripts/, and calls create_skill. There is no local target for create_skill; local skills stay plain files, as above. Bundled files are read from your machine when the skill is created. The CLI refuses files that look like credentials or configuration — dot-files and dot-directories, keys, keychains, shell histories, system directories — and each file must be UTF-8 text of at most 1 MiB. Files inside your local skill directories (~/.amplify/skills, ./skills, or anything in AMPLIFY_SKILLS_DIR) are allowed, so a local skill can be saved to your organization as-is; a dot-file or key inside one of those directories is still refused. When a cloud run activates the skill, the runtime tells the agent the skill’s directory, so SKILL.md should refer to bundled files by a path relative to the skill root — python3 scripts/check.py — and invoke scripts through their interpreter rather than executing them directly. The skill’s name is its frontmatter name: kebab-case, 1–64 characters. It must not reuse the name of a skill Amplify already provides (the server refuses those) or of a skill your organization already has. Organization skills can’t be edited after creation today; list_skills from the CLI shows what’s saved. Your interactive CLI sessions don’t load organization skills, and neither does the chat agent you talk to directly or the sub-agents it spawns beside itself — only workflow steps, and agents that chat dispatches to run against a repository.

Using skills in the CLI

/skills lists the catalog: every skill this session can activate, built-in and local. Activation isn’t a command — the agent calls activate_skill itself when a skill’s description matches the task at hand. To test a skill you’re writing, edit the file, restart, and give the agent a task the description should trigger. If you want a specific procedure followed, ask for it by name. Once authenticated, the agent can also call list_skills to show your organization’s saved skills beside the session’s own.

Get Started

Agents & detections

Data & connections

Integrations

Working interactively

Workflows

What a skill is

Skill or agent?

Frontmatter reference

Built-in skills

Where to author a skill

Local files

Organization skills

Using skills in the CLI

Next steps

Detections

The CLI

​What a skill is

​Skill or agent?

​Frontmatter reference

​Built-in skills

​Where to author a skill

​Local files

​Organization skills

​Using skills in the CLI

​Next steps

Detections

The CLI

What a skill is

Skill or agent?

Frontmatter reference

Built-in skills

Where to author a skill

Local files

Organization skills

Using skills in the CLI

Next steps