package-map
Skill0 starsChanged 11 days agoApache-2.0View on GitHub
Explains which podman-desktop package owns a piece of functionality and which layer is responsible. Use when asked where something lives, which package to change, or what a layer is for.
In this repository24 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
Not just the package — the layer, and what the layer implies:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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
Two sources, and they answer different halves of the question.
pdkit packages --of packages/main/src/plugin/exec.ts # which package owns a path
pdkit packages # every package, by layerThe generated map ($PDKIT_HOME/package-map.json, built by pdkit init from
pnpm-workspace.yaml) knows what exists. ${CLAUDE_PLUGIN_ROOT}/knowledge/package-map.md holds what
a generator cannot know: intent, boundaries, and why the layer order is what it
is. Answer from the first, explain from the second.
What a complete answer contains
Not just the package — the layer, and what the layer implies:
extension-api → main → preload → renderer + ui → extensions/* → tests → website/docsThat order does two jobs at once. It is merge order, because upper layers depend on lower ones. And it is reviewer selection: the people who review a public API change are not the people who review a UI change, so a change spanning both waits for both. That is why layers decide slicing, and why "which layer" is usually the more useful half of the answer.
The boundary that catches people
Utilities get duplicated between packages/main and packages/renderer. Before
concluding that a helper needs writing, look in both — reviewers do, and they
push back on it.
The other one: packages/extension-api is a public contract. A type that looks
like an internal utility can be declared there too, which makes changing it a
compatibility question rather than a refactor. preflight greps for exactly
this; do not rely on the file's location to tell you.
When the map cannot answer
- No map —
pdkit inithas not run in this repository. - Layer
other—packages/api,packages/webview-apiandstorybookmatch no rule inslicing.layer_order. Say so rather than guessing a layer: merge order for those three is genuinely undecided, and saying so is the answer. - The path is not in any package — say that too. Repository-root files
(
.github/, config, scripts) belong to no layer and are reviewed by whoever owns the area they configure.
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.