Agent kit for working on canonical/chisel-releases. Cross-agent skills + scripts for authoring and reviewing chisel slice definition files.
81
85%
Does it follow best practices?
Impact
75%
Average score across 5 eval scenarios
Low
Low-risk findings worth noting
The knowledge in these reference files is derived from three upstream projects. When in doubt, always defer to these sources over anything written here.
canonical/chisel (tool behaviour)The Go source code defines what chisel actually does: how it parses SDFs, resolves dependencies, extracts files, runs mutate scripts, handles wildcards, and validates fields. The tool's behaviour is the ultimate arbiter of what is valid.
internal/setup/ (SDF parsing), internal/slicer/ (slice cutting logic)canonical/chisel-docs (official documentation)The documentation source renders to https://documentation.ubuntu.com/chisel/en/latest/. It is the authoritative reference for SDF format, CLI usage, and slicing workflows.
https://raw.githubusercontent.com/canonical/chisel-docs/main/docs/<path>.md; rendered at https://documentation.ubuntu.com/chisel/latest/<path>/how-to/slice-a-package.md -- canonical slicing workflowreference/chisel-releases/slice-definitions.md -- SDF format specificationreference/chisel-releases/chisel.yaml.md -- release config schema (format versions, archives, maintenance)explanation/slice-design-approaches.md -- grouping-by-content vs grouping-by-functionexplanation/slices.md -- conceptual overview of slicesreference/cmd/cut.md -- chisel cut CLI referencereference/manifest.md -- manifest formathow-to/install-pro-package-slices.md -- pro slicescanonical/chisel-releases (existing slices & conventions)The collection of published SDFs is the ground truth for conventions, naming patterns, and reviewer expectations. Studying real SDFs is more reliable than any written convention doc.
chisel.yaml, slices/bash.yaml, slices/base-files.yamlmain carries what the release branches do not: CONTRIBUTING.md, README.md with the live release-branch list, .github/yamllint.yaml, and the reusable CI workflows plus the scripts they drive (.github/scripts/validate-hints/, install-slices/, removed-slices/, pkg-deps/). A release branch's own .github/workflows/ci.yaml only calls into them, so read the definitions on mainAlso: chisel-releases navigator https://canonical.github.io/chisel-releases-navigator/; Ubuntu release schedule https://wiki.ubuntu.com/Releases.
When sources conflict: tool behaviour > chisel-docs > chisel-releases conventions > these reference files.
When a reference file disagrees with the repo, trust the repo. When in doubt, read slices/bash.yaml or slices/base-files.yaml on the target release branch.