Claude Code Skills

Claude Code Skills

jamf-cli ships a Claude Code skills plugin for administering Jamf environments through natural language. You describe what you want and the agent makes the CLI calls: looking up IDs, fetching API specs, constructing request bodies and chaining operations.

Requirements

• Claude Code CLI installed and signed in
• jamf-cli installed and at least one profile configured (see Setup Guide)

Installing the Skills Plugin

The plugin is published as a Claude Code marketplace plugin. Add the marketplace and install the plugin from within Claude Code:

/plugin marketplace add Jamf-Concepts/jamf-cli
/plugin install jamf-cli-skills@jamf-cli

That installs these skills:

Skill	Invoke with	Purpose
jamf-cli	/jamf-cli	Session setup: verifies install, loads the CLI reference, and selects a profile. Run this first.
jamf-audit	/jamf-audit	Runs a Jamf Pro instance health audit, prioritises findings, and offers remediation
jamf-backup	/jamf-backup	Guides a config backup, compares with previous backups, and can initialise git tracking
jamf-bulk	/jamf-bulk	Safe batch operations: previews every batch before executing, requires explicit confirmation
jamf-investigate	/jamf-investigate	Answers natural language questions about a Jamf Pro instance
jamf-migrate	/jamf-migrate	Guided migration workflows between Jamf Pro instances
jamf-report	/jamf-report	Generates ad-hoc reports from Jamf Pro data, and shareable HTML fleet reports (see Fleet Dashboard). In Claude Desktop, where there is no Bash tool, it drives the MCP Server tools instead

Starting a Session

Run /jamf-cli at the start of a session, before any other skill. It:

1. Verifies jamf-cli is installed (offers a Homebrew install if it is missing)
2. Fetches the full CLI command reference into context
3. Prompts you to select an existing profile or create a new one

Once the skill completes, describe tasks in plain English:

"List all computers that haven't checked in for 30 days"

"Create a test device group, scope the macOS Hardening blueprint to it, and deploy"

"Back up all scripts and config profiles to a local directory"

Agent Rules

The agent works through jamf-cli and calls no Jamf API itself.

Before any create, update, apply, or patch operation, the agent:

1. Fetches the OpenAPI spec for the resource from the repository, for the authoritative request body schema
2. Runs --scaffold for the exact JSON template from the installed binary
3. Constructs the body from those two sources, never from memory

A PreToolUse hook fires as the agent is about to run a mutating command, reminding it to complete these steps.

--scaffold is the source that cannot go stale: the binary you are about to run renders it from the spec it was built from. Step 1 depends on a repository layout, and v1.29.0 moved it: the Jamf Pro API is one normalised document, specs/JamfProAPI.yaml, in place of 165 per-resource specs/<ResourceName>.yaml files. A plugin copy installed before then asks for a path that no longer exists, so re-run /plugin install jamf-cli-skills@jamf-cli and read a 404 on a spec fetch as a stale plugin.

The layout is unchanged in v1.30.0, and specs/ still holds exactly two Jamf Pro documents. The second one is the trap: App Installers is described by specs/AppInstallers.yaml and is absent from JamfProAPI.yaml, so an agent fetching the normalised document for pro app-installers* gets a 200 and no schema, which is harder to notice than a 404. Fall back to --scaffold and create --help there.

On Classic and Platform resources, create --help carries what a scaffold cannot: the required-field list, the optional sections, and Allowed values: for every enum-constrained field. Those two need no spec fetch. The modern Pro generator renders none of that, which is where step 1 earns its keep.

Agentic Usage Tips

Be specific about the resource and operation

Good prompts name the resource and the operation:

"Create a static Platform device group called 'Test - Staging' and scope the Jamf Security Cloud blueprint to it"

A vague prompt such as "set up a test group" leaves the agent guessing between a Classic smart group, a Classic static group, and a Platform device group. Those three have incompatible APIs.

Retired spellings an agent reaches for from memory

An agent composing commands from memory reaches for the pre-v1.29.0 spellings. 103 pro resource names were retired; 100 of them still work and print a warning on stderr naming the replacement, so the command succeeds and the agent may miss the line. The rest fail at a non-zero exit with the replacement named in the message, in one of three shapes: a withdrawn endpoint, an operation whose name moved along with its resource, or a former leaf that is a command group now.

Have the agent read the catalog:

jamf-cli commands -o json    # every shipped command, its aliases, flags and API

/jamf-cli loads that at session start. Full tables: Pro Command Renames.

v1.30.0 adds a second such hazard. The Classic scope subcommands took a bare name positional through v1.29.0 and now take [<id>] with --name as the alternative, so an agent writing pro classic-policies scope get "Deploy Chrome" from memory gets exit 2. The refusal names --name, and the fix is scope get --name "Deploy Chrome" or scope get 1. It applies to get, add and remove on all nine scopeable Classic resources.

Platform resources require Platform device groups

Blueprints, compliance benchmarks, and DDM reports scope to Platform device groups (pro platform-device-groups), which use UUID identifiers. The Platform API rejects Classic computer groups, which carry integer IDs.

Asking the agent to create a test group for Platform workflows, be explicit:

"Create a Platform device group called 'Test - Blueprints'" ✅

"Create a computer group called 'Test - Blueprints'" ← agent may use Classic API ⚠️

Object IDs are positional

The CLI takes an object ID as a positional argument, and a name lookup as a flag:

jamf-cli pro scripts get 42                # correct: the ID is positional
jamf-cli pro scripts get --name "Example"  # correct: name lookup is a flag
jamf-cli pro scripts get --id 42           # wrong: unknown flag: --id (exit 2)

Ask for a resource by name and the agent either passes --name, where the resource supports it, or lists the collection first to resolve the ID.

Two --name answers to recognise when a result looks like a typo:

• A name matching more than one object is an error. Matches accumulate across every page before the decision, so two objects sharing a name on opposite sides of a 100-item page boundary come back as ambiguous.
• A name matching an object the collection returns no ID for says so, in wording distinct from "not found", which keeps apply from reading it as absence and creating a duplicate.

Prefer apply over create/update

apply is an idempotent name-based upsert: it creates or replaces, which makes it the right default for most configuration tasks. create fails when the resource exists; update requires a known ID and an existing resource. The agent prefers apply unless you ask for a different operation.

Confirming destructive operations

The agent asks for confirmation before:

• delete operations
• apply that would replace an existing resource
• Any bulk operation affecting multiple objects

To skip confirmations (in an automated context, say), pass --yes in your prompt:

"Delete all scripts in the 'Legacy' category, yes to all"

Checking available commands

To find out what the agent can do for a resource, ask:

"List the operations available for compliance benchmarks"

The agent consults the CLI reference loaded during session setup and lists the subcommands.

Troubleshooting

"jamf-cli is not installed". Run /jamf-cli and select the Homebrew install option, or follow the Setup Guide#Installation.

"No profiles found". Run jamf-cli pro setup or jamf-cli platform setup in your terminal, then re-run /jamf-cli to pick the new profile. See Setup Guide for full setup instructions.

Agent uses the wrong API for groups. Say "Platform device group" in your prompt when working with blueprints or compliance benchmarks.

Agent constructed an incorrect request body. The agent fetches the spec before constructing a body; where it skipped that, ask it to run jamf-cli pro <resource> create --scaffold and retry from that template.