The fifth time I watched a .deb package build clean, pass lintian, and then crash on install because the symlink in debian/myapp.links pointed at /usr/lib/myapp/bin/myapp while debian/rules installed the venv to /opt/venvs/myapp, I stopped blaming myself and started blaming the process.
Debian packaging has great tooling. debhelper handles most of the ceremony. lintian catches most of the policy violations. But neither one checks whether the six files in your debian/ directory actually agree with each other. That's on you. And if you're packaging Python projects with dh-virtualenv, the surface area for cross-file mismatches is large enough to guarantee you'll hit one.
debian/rules says --use-system-packages. debian/control doesn't list the python3-* packages in Depends. The venv inherits system numpy at build time, but the built package doesn't declare the dependency, so it works on the build machine and breaks everywhere else.
debian/myapp.prerm calls systemctl stop myapp before #DEBHELPER#. Debhelper also stops the service. Now you have a race condition in your package removal script, which is exactly where you want nondeterministic behavior.
debian/myapp.postinst writes a default config to /etc/myapp/config.yaml without checking if it already exists. That file isn't a conffile because postinst created it, not the package manager. dpkg doesn't track it. Every upgrade silently overwrites whatever the operator changed.
And when you're packaging your twelfth project, you will forget at least one.
So Claude and I built a skill that doesn't forget.
super-cow-powers is a Claude Code skill for Debian packaging. When you ask it to create or audit a debian/ directory, it enforces six gated checklists. Required files. Daemon-specific files. CLI-specific files (and explicitly, no daemon files for CLI tools). Maintainer script safety. And the one that matters most: cross-file consistency.
This is the #1 source of packaging bugs that survive lintian. The skill cross-references install root against .links paths, ReadWritePaths= in the service file against directories in .dirs, ExecStart= against symlink targets, EnvironmentFile= against the .default file, and --use-system-packages in rules against python3-* in Depends.
The kind of checks that are tedious for a human but trivial for a model with instructions.
The checklists are gates, not suggestions. Each one ends with consequence language: "Can't check all boxes? The service will either fail to start, fail to stop cleanly, or leave orphaned users on purge." The model doesn't get to skip items to be polite.
We ran the eval suite after installing it. The test case was a CLI tool called datamunch. The skill produced the right files (control, rules, changelog, copyright, source/format, lintian-overrides, links), correctly omitted daemon files (no service, no postinst, no dirs), and passed all 17 applicable checklist items with zero failures.
The cross-file consistency checks are currently enforced by instructions to the model, not by a script. That's the honest limitation. It works because the checklists are specific and the consequence language discourages skipping, but there's no mechanical verification yet. A validate-debian.sh and a set of Claude Code hooks that run it on every write to debian/ are on the roadmap.
The skill includes 15 ready-to-use templates with __PKG__ placeholders, three reference documents covering dh-virtualenv patterns, systemd integration, and a combined Debian policy + FHS 3.0 summary. The reference docs were cross-checked against the official Debian New Maintainers' Guide and the FHS 3.0 spec before release.
GPL v3. AI-generated PRs welcome, with rules: disclose the tooling, don't hallucinate policy citations, verify templates actually build.