Treat the skills as living documents. When a review turns up the same mistake twice, that's a missing line in a skill, not a Claude problem.
If a skill isn't triggering, make its description: list the words developers actually type, not the words the official documentation uses.
See Skills Introduction.
The Packagist snapshot behind dependency-policy goes stale silently — re-run .claude/skills/dependency-policy/scripts/sync-dotkernel-packages.sh when a dot-* package is abandoned or superseded.
dot-annotated-services → dot-dependency-injection is exactly the kind of thing a stale manifest gets wrong.
See Dependency Policy.
Before adapting this configuration to a Dotkernel application it hasn't been used against yet, spend an hour reading that repo and correcting the skills against what's actually there. A skill written from framework documentation rather than the real codebase produces confident wrong answers — worse than no skill at all, because it doesn't look uncertain.