메뉴
Standardised tox/make/just command names for charm projects — format, lint, unit, integration, docs
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.