podman-desktop-kit
CLAUDE.md0 starsChanged 14 days agoApache-2.0View on GitHub
A Claude Code plugin (pd) for working upstream issues in podman-desktop. Zero-dependency ESM on Node >= 22, no build: lib/ is what runs. The plugin works on somebody else's repository, and most rules below follow from that. Read before changing anything: CONTRIBUTING.md (where code goes, how to add a command, check, state, skill or agent) and section 2.2 of the specification (the invariants a change must not break). This file does not repeat them; it lists what has gone wrong…
In this repository24 other files it gives its agents.
The file
We split this CLAUDE.md into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 7
Read before changing anything: CONTRIBUTING.md (where code goes, how to add a command, check, state, skill or agent) and section 2.2 of the …
- Very specific: line 22
Never run a test without --import ./test/helpers/isolate-home.js: without it a run writes into the live $PDKIT_HOME journal.
- Distinctive: line 72
Do not reopen a split the round-2 review rejected without new facts.
- Distinctive: line 84
Comments say why, and must stay true: When code moves, update or remove comments that name the old place.
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
podman-desktop-kit
A Claude Code plugin (pd) for working upstream issues in podman-desktop.
Zero-dependency ESM on Node >= 22, no build: lib/ is what runs. The plugin
works on somebody else's repository, and most rules below follow from that.
Read before changing anything: CONTRIBUTING.md (where code
goes, how to add a command, check, state, skill or agent) and
section 2.2 of the specification
(the invariants a change must not break). This file does not repeat them; it
lists what has gone wrong more than once.
Commands
npm test # whole suite
node --import ./test/helpers/isolate-home.js --test test/<module>.test.js # one file
claude plugin validate . --strict # manifest
pdkit doctor --gate-selftest --repo <podman-desktop fork> # after lib/hooks/, hooks/hooks.json, bin/pdkitNever run a test without --import ./test/helpers/isolate-home.js: without it a
run writes into the live $PDKIT_HOME journal.
Anonymity in everything that ships
Skills, agents, knowledge/, templates/, docs/, the root *.md files and
test fixtures are published to everyone who installs the plugin. None of them
may carry:
- real GitHub logins or names — use
maintainer1,reviewer2,contributor3…, the same placeholder for the same person across a file (bot and service accounts may stay where a test is about them); - real branch names, worktree names or paths, local absolute paths
(
/Users/...), or anything else copied from one machine or one session; - in prompts and knowledge: issue or PR numbers, and the incident behind a rule.
Rephrase, don't redact: state the situation and the rule it led to, so the lesson stays and the reference goes. "A reviewer asked for X on a PR touching Y" — not who, not which PR. This applies to text drawn from a live run, an issue or a review thread as much as to text you write.
SOLID: the structure is deliberate
0.11.4 and 0.11.5 were spent bringing lib/ to SOLID. Keep it there; do not
reintroduce what was removed.
- One responsibility per module, stated in its header comment. A new concern is a new module with a single owner, not a branch in an existing one.
- Extend by adding a row, not editing a chain: a command is a file in
lib/commands/plus aREGISTRYrow; an action is a function plus anACTIONSrow plus aUSAGEline; a state entry rule is an element ofENTRY_RULESinlib/state/entry.js; a preflight check is a file plus aCHECK_IDSentry; a template is a file plus aTEMPLATESrow. No newif (action === ...)chains. - One way in to each external thing: git only through
lib/git.js, gh only throughlib/gh.js, each with anoptions.execseam for tests.state.jsonis written only bylib/state.js,slices.jsononly bylib/slice.js. - Facades are the API: outside its package, nothing imports
lib/slice/*,lib/validation/*orlib/state/*; a submodule never imports its facade; preflight checks never importlib/preflight/index.js. A facade'sdepsholds only access to the file it owns, never a pure function. - Modules return data; only
lib/cli.jsandlib/commands/*write to stdout or stderr.lib/commands/support.jsholds what two commands share and no domain logic. - No new import cycles. The three runtime
await import()cycles inlib/state.jsare documented and the only ones allowed.
test/invariants.test.js enforces most of this; a failure there is the design
talking, not a test to adjust. SOLID is not a license to split: size alone is
not a finding, and a long function that is one ordered scenario stays whole.
Do not reopen a split the round-2 review rejected without new facts.
Other recurring mistakes
- Collect facts, reach no verdict. What must be true goes in
lib/with a test; what needs judgement goes inskills/oragents/. Noscoreorrecommendationfields inlib/. - Plugin files from prompts go through
${CLAUDE_PLUGIN_ROOT}/. Skills and subagents run in the podman-desktop checkout, so a bareknowledge/x.mdresolves against the wrong repository. - A skip is never a pass, and a message is never wider than what was measured.
- Comments say why, and must stay true. When code moves, update or remove comments that name the old place.
docs/is one file per section, with stable numbers; a new section is a new numbered file linked from itsREADME.mdand its neighbours' footers.- American spelling everywhere — prose, comments, identifiers, test
names:
license,behavior,color,initialize,judgment. Three exceptions are data, not prose, and stay as they are: the'cancelled'CI verdict (and GitHub's ownCANCELLED), thenormalisedkey in the cost report and its snapshots, andartefact, which awaits a rename of its own. - Every
.jsand YAML file carries the full Apache header with SPDX inside it (after the shebang inbin/pdkit).
Commits and releases
- Conventional commits,
type(scope): subject; the body says why. - User-visible change →
CHANGELOG.mdunder## [Unreleased]. - Squash with
git reset --soft <base> && git commit, nevergit rebase -i. - Release only per
RELEASING.md: push the release commit, wait for CI to be green on every OS, only then tag and publish.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

