[Discussion] How the pack lands on Claude 5-generation models

I've been using this pack for a few months (Claude Code, plus the Cursor links from `install.sh`). Last week I reviewed my whole `~/.claude` setup against Anthropic's recent article on context engineering for Claude 5 models (https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models), and this pack ended up being the biggest single thing I removed. I'd rather report the mechanism than just quietly drop it, because maybe something is fixable in the pack itself and not really about my setup

To be clear up front: I'm not saying the skills are wrong or that they don't help on ther models. I ran the review on one machine, and I don't yet have "before/after" data, I only removed things a few days ago.

*The measurements below are from Claude against the repo at `main`*

> **Unconditional cost.** The 20 skill descriptions total ~4.7 KB, and they load into the system prompt of every session, including sessions that never touch code. The bodies are ~207 KB in total.
>
> **Pre-empting model judgement.** 18 of the 20 carry a "Common Rationalizations" section, which exists to catch the model talking itself out of the prescribed process. The Anthropic article argues the opposite direction for this model generation — give rules, then let the model use judgement.
>
> **Overlap with host built-ins.** On current Claude Code, `code-review-and-quality`, `security-and-hardening`, `code-simplification` and `planning-and-task-breakdown` each duplicate a built-in command (`/code-review`, `/security-review`, `/simplify`, `/plan`).

On the last point, #423 reports `using-agent-skills` stacking on GPT-5.6's built-in router. The same thing happens on Claude Code, which also routes skills natively. So that's the same mechanism on a second host, which I think supports the "don't load our router where the host already has one" note you suggested there.

My question is whether this is worth handling in the pack rather than each user discovering it? Would versioning skills per model generation work ? (e.g. a leaner variant for Claude 5-class models that keeps the process content but drops the rationalization/red-flag scaffolding.)

I asked more or less the same question about our own internal skills repo, so I'm genuinely unsure what the right answer is :-)