Four skills cite knowledge/testing-layers.md, a file that lives in domains/testing/knowledge/. Domain knowledge/ is copied per domain, so a skill only ever receives its own domain's knowledge. These citations cannot resolve for any consumer, on any operator.
The skills install fine and the reference dangles — nothing errors, the agent simply cannot open what the body points at.
Affected
| Citing file |
Domain |
Ships when |
domains/coding/skills/coding-guidelines/repos/metamask-mobile.md (3 sites) |
coding |
--repo metamask-mobile |
domains/pr-workflow/skills/pr-guidelines/repos/metamask-mobile.md |
pr-workflow |
--repo metamask-mobile |
domains/pr-workflow/skills/pr-readiness-check/repos/metamask-mobile.md |
pr-workflow |
--repo metamask-mobile |
domains/perps/skills/perps-review-pr/skill.md |
perps |
always |
Five of the six sites are in repos/metamask-mobile.md overlays, which is plausibly why this went unnoticed — it only manifests on Mobile installs.
The underlying question
Cross-domain knowledge isn't a supported concept today. testing-layers.md is genuinely useful to skills outside testing — the citations are reasonable, the delivery mechanism just doesn't exist. Options, roughly in increasing order of cost:
- Rewrite the citations to name-only — "see the
testing-layers knowledge file" — so they stop promising a resolvable path. Cheapest, no installer change, but the agent still has no copy to read unless the testing domain was also installed.
- Duplicate the file into each citing domain's
knowledge/. Resolves everywhere, at the cost of four copies drifting apart.
- Teach the installer cross-domain knowledge — a citation like
testing:testing-layers.md, resolved and copied at install time. Cleanest for authors, most work, and it needs a decision about whether pulling one domain's knowledge into another is desirable at all.
I'd lean (1) or (3) over (2); duplicating a file that four skills depend on staying consistent seems like the worst of the three. But which of these is right depends on whether cross-domain knowledge is something this repo wants to support, which is a maintainer call rather than mine.
Guard already in place
test/cli.test.mjs now checks the corpus and fails on any new dangling citation. These six are listed in KNOWN_UNRESOLVED so the check could land green rather than red. A companion test fails if a listed citation starts resolving, so the list can only shrink — closing this issue means deleting entries from it.
Four skills cite
knowledge/testing-layers.md, a file that lives indomains/testing/knowledge/. Domainknowledge/is copied per domain, so a skill only ever receives its own domain's knowledge. These citations cannot resolve for any consumer, on any operator.The skills install fine and the reference dangles — nothing errors, the agent simply cannot open what the body points at.
Affected
domains/coding/skills/coding-guidelines/repos/metamask-mobile.md(3 sites)coding--repo metamask-mobiledomains/pr-workflow/skills/pr-guidelines/repos/metamask-mobile.mdpr-workflow--repo metamask-mobiledomains/pr-workflow/skills/pr-readiness-check/repos/metamask-mobile.mdpr-workflow--repo metamask-mobiledomains/perps/skills/perps-review-pr/skill.mdperpsFive of the six sites are in
repos/metamask-mobile.mdoverlays, which is plausibly why this went unnoticed — it only manifests on Mobile installs.The underlying question
Cross-domain knowledge isn't a supported concept today.
testing-layers.mdis genuinely useful to skills outsidetesting— the citations are reasonable, the delivery mechanism just doesn't exist. Options, roughly in increasing order of cost:testing-layersknowledge file" — so they stop promising a resolvable path. Cheapest, no installer change, but the agent still has no copy to read unless thetestingdomain was also installed.knowledge/. Resolves everywhere, at the cost of four copies drifting apart.testing:testing-layers.md, resolved and copied at install time. Cleanest for authors, most work, and it needs a decision about whether pulling one domain's knowledge into another is desirable at all.I'd lean (1) or (3) over (2); duplicating a file that four skills depend on staying consistent seems like the worst of the three. But which of these is right depends on whether cross-domain knowledge is something this repo wants to support, which is a maintainer call rather than mine.
Guard already in place
test/cli.test.mjsnow checks the corpus and fails on any new dangling citation. These six are listed inKNOWN_UNRESOLVEDso the check could land green rather than red. A companion test fails if a listed citation starts resolving, so the list can only shrink — closing this issue means deleting entries from it.