plugin/skills/migration-core/SKILL.md is assembled from roughly 11 files under knowledge/. Nothing checks that it stays in sync with them.
This already caused a real defect
In #45, the first commit added an anti-fabrication rule and an annotated-tag correction to migration-core/SKILL.md and not to its source, knowledge/migration-guardrails.md.
Result: cloud agents kept weaker guidance on the most security-relevant instruction in the product, while CLI users got the better version. A PR whose stated purpose was closing cloud/CLI divergence quietly widened it.
The parity checker could not catch it. It diffs the 18 one-to-one copied files, and migration-core is the one fan-in it does not cover. The gap sat in exactly the file being edited.
It was caught by an architecture review, not by CI. Next time there may not be a review.
Suggested approach
A full fan-in equality check is genuinely hard. A cheap staleness check is not:
- Add provenance frontmatter to
migration-core/SKILL.md listing its source files
- In
scripts/check-content-parity.sh, assert each listed source exists and that migration-core/SKILL.md is not older than any of them (git log -1 --format=%ct per file)
That catches "knowledge changed, skill didn't" in about ten lines. It is noisy on rebases, but noisy and present beats silent and absent.
An alternative is section-level anchors (<!-- src: knowledge/migration-guardrails.md#action-version-verification -->) with a check that each anchor resolves. Either is acceptable.
Why this is the first follow-up
It is the only gap that lets wrong security guidance ship silently. Everything else on the list fails loudly.
plugin/skills/migration-core/SKILL.mdis assembled from roughly 11 files underknowledge/. Nothing checks that it stays in sync with them.This already caused a real defect
In #45, the first commit added an anti-fabrication rule and an annotated-tag correction to
migration-core/SKILL.mdand not to its source,knowledge/migration-guardrails.md.Result: cloud agents kept weaker guidance on the most security-relevant instruction in the product, while CLI users got the better version. A PR whose stated purpose was closing cloud/CLI divergence quietly widened it.
The parity checker could not catch it. It diffs the 18 one-to-one copied files, and
migration-coreis the one fan-in it does not cover. The gap sat in exactly the file being edited.It was caught by an architecture review, not by CI. Next time there may not be a review.
Suggested approach
A full fan-in equality check is genuinely hard. A cheap staleness check is not:
migration-core/SKILL.mdlisting its source filesscripts/check-content-parity.sh, assert each listed source exists and thatmigration-core/SKILL.mdis not older than any of them (git log -1 --format=%ctper file)That catches "knowledge changed, skill didn't" in about ten lines. It is noisy on rebases, but noisy and present beats silent and absent.
An alternative is section-level anchors (
<!-- src: knowledge/migration-guardrails.md#action-version-verification -->) with a check that each anchor resolves. Either is acceptable.Why this is the first follow-up
It is the only gap that lets wrong security guidance ship silently. Everything else on the list fails loudly.