Menu
Standardised tox/make/just command names for charm projects — format, lint, unit, integration, docs
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Known-good Juju bundle shapes (COS Lite, 12-Factor + COS, Identity Platform, Charmed Kubeflow) — canonical app lists and relation edges
Implementing Juju actions for operational tasks in charms. WHEN: add Juju actions to a charm, implement backup / rotate-credentials / restore actions, declare actions in charmcraft.yaml, write action handlers, test actions with Scenario, run actions with juju run.
Adding and validating charm configuration options. WHEN: add charm configuration options, declare config in charmcraft.yaml, validate config values in config-changed, apply config to a Pebble layer, apply config to a machine charm, write Scenario tests for config.
End-to-end workflow for building ops-framework charms for custom applications (K8s and machine). WHEN: build a custom Juju charm, write src/charm.py with Pebble, write a machine charm with systemd, decide K8s vs machine substrate, scaffold a non-paas-charm with charmcraft init, customise the ops framework charm lifecycle.
Workflow for charming infrastructure software (databases, caches, message brokers, proxies, monitoring). WHEN: charm infrastructure software, charm a database / cache / message broker / proxy / monitoring system, implement peer relations, leader election, primary/replica failover, backup and restore actions, clustering.
Expert guidance for developing, building, testing, and publishing Juju charms using charmcraft. WHEN: edit charmcraft.yaml, run charmcraft pack, run charmcraft init, manage charm libraries, publish a charm to Charmhub, set up multi-base builds, configure relations / config options, set up storage or containers.
| name | charm-development-commands |
| description | Standardised tox/make/just command names for charm projects — format, lint, unit, integration, docs |
| globs | ["tox.ini","Makefile","justfile","pyproject.toml","CONTRIBUTING.md","HACKING.md"] |
Charms must provide a consistent, minimal set of named commands for formatting, linting, type checking, and testing. This makes it easier to work across charming teams and enables ecosystem-wide compatibility testing. Based on Canonical spec OP061.
Adapted from the
charm-development-commandsskill intonyandrewmeyer/charming-with-claude, CC BY 4.0 (Tony Meyer, 2025). Reformatted for cantrip's bundled-skill frontmatter; content otherwise unchanged. See Provenance at the foot of this skill for the source link.
| Command | Definition |
|---|---|
| (no args) | Running the tool with no arguments must execute the lint and unit commands |
format | Automatically format code (including tests) according to project style |
lint | Report linting errors (ruff, pylint, flake8, isort, pydocstyle, bandit, etc.) and static type checking issues (pyright, ty, mypy). Must include Charmhub hosted charm libraries that this charm provides, if any; should include test code |
unit | Run unit tests for the charm and its libs. Includes both deprecated Harness and state-transition (Scenario) framework tests |
integration | Run integration tests against a real Juju controller. Includes pytest-operator, python-libjuju, and Jubilant tests |
docs | Build documentation (if docs are in the repository). Should run make run in the docs directory |
Note: use format (not the Go-style fmt) — this has been the
charmcraft profile standard and aligns with other full-word commands.
Charms may include additional commands as needed:
static-lib).static = static-charm + static-lib).fmt as alias for format).functional tests — validate workload interactions without Juju (especially for machine charms).Commands must be run with one of these tools:
| Tool | Examples |
|---|---|
| tox | tox, tox -e lint, tox -e unit -- -k test_foo |
| make | make, make lint, make unit ARGS='-k test_foo' |
| just | just, just lint, just unit |
The most highly recommended runner is the one used in charmcraft
profiles — tox at present. Commands must work without
additional arguments.
For repositories containing more than one charm:
format, lint, unit, integration must be available in each charm folder.format should be available at the top level, formatting all charms.lint is ideally at the top level (may need to run per-charm for conflicting dependencies).unit and integration are ideally at the top level, running all tests.docs: at the top level if one set of docs; in each charm folder if separate docs.Requirements for running commands (e.g. installing uv or tox)
must be clearly documented in a CONTRIBUTING or HACKING file
at the top level of the repository.
Adapted from the charm-development-commands skill
in tonyandrewmeyer/charming-with-claude,
CC BY 4.0 (Tony Meyer, 2025). Content reformatted for cantrip's
bundled-skill frontmatter; otherwise unchanged.