Layer precedence ordering disagrees between READ and Entry

[JeremyVyska]

cc @JesperSchulz

Noticed while walking the routing flow for a community-layer PR: the two contracts that specify layer precedence disagree on the middle tier.

READ (skills/read.md, knowledge files)

1. /custom/ wins over /microsoft/ and /community/.
2. /microsoft/ wins over /community/.

Ordering: custom > microsoft > community.

Entry (skills/entry.md, action skills)

Skill layer precedence is /custom/ over /community/ over /microsoft/ — the same ordering READ defines for knowledge files.

Ordering: custom > community > microsoft. The inline claim that this matches READ is incorrect.

Why it matters

• Both orderings are individually defensible. Knowledge prefers authority (/microsoft/ wins). Skills plausibly prefer local customization (/community/ overrides Microsoft defaults). But the two contracts shouldn't silently disagree, and Entry's comment shouldn't assert an alignment that doesn't hold.
• This becomes a real bug when a community contributor ships a skill with the same id as a Microsoft skill: under Entry's current rule the community skill wins, which is a surprising outcome given READ's framing.

Options

1. Align on READ's ordering (custom > microsoft > community for both) — skills layer behaves the same as knowledge; Microsoft-endorsed skills always win unless a consumer fork overrides in /custom/.
2. Keep Entry's ordering and fix the text — keep skills as custom > community > microsoft with an explicit rationale, and correct READ's claim of equivalence.
3. Document both and explain the split — if the asymmetry is intentional, call it out in both files.

No preference from me — just flagging before the first community skill lands, since a community al-performance-review under today's rule would supersede the Microsoft one.