<blockquote> <p><strong>TL;DR.</strong> I built an Anthropic Agent Skill for <code>@ngrx/signals</code> and ran it through the full eval pipeline: capability A/B benchmarks, token and wall-time accounting, and a description-optimizer loop. The skill lifts pass rate from 84% to 100%. It also adds 14 seconds and ~12,000 tokens per invocation (about $0.04 at Sonnet 4.6 input pricing). The description optimizer ran for three iterations and never beat the description I started with. And my evals are now saturated at 100%, which is itself a problem. <strong>All four findings are useful, and most teams ship skills without measuring any of them.</strong></p> </blockquote> <h2> The two questions almost no one asks </h2> <p>You write a 200-line <code>SKILL.md</code>, drop it in <code>~/.claude/skills/</code>, restart Claude Code, and move on. Skill shipped.</p> <p>Two questions you didn't answer:</p> <p><strong>A) Does this skill actually outperform the base model on the same task,</strong> or are you shipping a glorified prompt that the model could already do without help?</p> <p><strong>B) Does the description match how real users phrase requests,</strong> so the model auto-loads the skill at the right time, and stays out of the way when it shouldn't?</p> <p>Both questions are invisible failures. The skill loads, the output looks fine, you assume it's working. You can do this for months.</p> <p>Anthropic <a href="https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills" rel="noopener noreferrer">ran their own description-optimization loop</a> across their <strong>six built-in document-creation skills</strong> and "saw improved triggering on 5 out of 6." If the team that designed the system has gaps in its own skills, your custom skills almost certainly do too.</p> <p>Stronger evidence still: in January 2026, Vercel published <a href="https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals" rel="noopener noreferrer"><em>AGENTS.md outperforms Skills in our agent evals</em></a>. They measured Skills against an inline <code>AGENTS.md</code> doc index on a Next.js 16 task suite:</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Configuration</th> <th>Pass rate</th> </tr> </thead> <tbody> <tr> <td>Baseline (no docs)</td> <td>53%</td> </tr> <tr> <td>Skills (default)</td> <td>53%</td> </tr> <tr> <td>Skills (with explicit instructions)</td> <td>79%</td> </tr> <tr> <td> <code>AGENTS.md</code> docs index</td> <td><strong>100%</strong></td> </tr> </tbody> </table></div> <p>Their finding: <strong>Skills remained uninvoked in 56% of cases despite the agent having access.</strong> Same under-triggering problem I'm about to show in my own data.</p> <p>Vercel concluded "skip Skills, inline the docs." I disagree for libraries the model already knows. Skills are still the right shape for <strong>encoded preference</strong>, your team's specific idioms, where progressive disclosure beats stuffing thousands of tokens of style guide into every conversation. But the <em>measurement</em> is the same: agents do not reliably consult skills on conversational prompts. Both teams converge on one thing. Without an eval suite you cannot tell whether your skill is doing what you think it's doing.</p> <p>In March 2026 Anthropic shipped an updated <code>skill-creator</code> that brings test/measure/refine discipline to skills. I used it on a real <code>@ngrx/signals</code> skill and wrote down everything that happened.</p> <h2> An eval suite for a skill: three parts, written before the skill </h2> <p>A skill eval has three parts:</p> <ol> <li> <strong>Test prompts.</strong> Realistic tasks a user would actually give.</li> <li> <strong>Assertions.</strong> Verifiable statements about good output, like <em>"HTTP is in a separate service, not inlined in the store."</em> </li> <li> <strong>Two configurations.</strong> The same prompt run <em>with</em> the skill loaded and <em>without</em> it. The delta is the skill's value.</li> </ol> <p>For my <code>@ngrx/signals</code> skill I wrote five tasks:</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>ID</th> <th>Task</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Build a <code>CartStore</code> with optimistic updates, request status, and rollback</td> </tr> <tr> <td>2</td> <td>Refactor a legacy <code>BehaviorSubject</code>-based service to Signal Store + API service split</td> </tr> <tr> <td>3</td> <td>Write a typed reusable <code>withSelectedEntity&lt;T&gt;()</code> custom feature</td> </tr> <tr> <td>4</td> <td>Build a typeahead <code>BookSearchStore</code> with <code>rxMethod</code>, debounce, and cancellation</td> </tr> <tr> <td>5</td> <td>Build a <code>TodosStore</code> using <code>@ngrx/signals/entities</code> updaters</td> </tr> </tbody> </table></div> <p>41 assertions total. Each was written <strong>before</strong> the skill was finalised. Assertions are the spec, not a confirmation. <em>(Caveat: my v2 skill ends up passing all 41. That's a problem in itself, and I come back to it at the bottom under "100% is a saturation signal".)</em></p> <blockquote> <p><strong>Methodology disclosure.</strong> I ran each (eval × configuration) pair <em>once</em>, not three times. The <code>± stddev</code> numbers below are dispersion <strong>across the 5 evals</strong>, not across repeated runs of the same eval. A more rigorous setup would be 3 runs per cell to absorb temperature noise. Treat the deltas as directional signal, not as p-values.</p> </blockquote> <h2> Failure mode A: the skill exists but adds no value </h2> <p>This is the embarrassing one. Your skill loads, costs tokens, and does nothing the base model couldn't do on its own.</p> <p>The benchmark viewer (generated by <code>skill-creator</code>'s <code>eval-viewer/generate_review.py</code>) shows the headline numbers and the per-eval breakdown side by side:</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fkrrlo3kxjshq1adewox9.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fkrrlo3kxjshq1adewox9.png" alt="Benchmark summary: 100% with skill vs 84% without, +13.7s and +12,416 tokens overhead, plus per-eval breakdown for eval 1 showing 100% vs 70%" width="800" height="500"></a></p> <p>Per-eval, base model vs. the same model with the skill loaded:</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Eval</th> <th>with_skill</th> <th>without_skill</th> <th>Δ</th> </tr> </thead> <tbody> <tr> <td>1. cart-store-optimistic</td> <td><strong>10/10 = 100%</strong></td> <td>7/10 = 70%</td> <td><strong>+30pp</strong></td> </tr> <tr> <td>2. refactor-behaviorsubject</td> <td><strong>8/8 = 100%</strong></td> <td>7/8 = 87.5%</td> <td>+12.5pp</td> </tr> <tr> <td>3. custom-feature-with-selected-entity</td> <td><strong>8/8 = 100%</strong></td> <td>7/8 = 87.5%</td> <td>+12.5pp</td> </tr> <tr> <td>4. rxmethod-debounced-search</td> <td>7/7 = 100%</td> <td>7/7 = 100%</td> <td><strong>±0</strong></td> </tr> <tr> <td>5. todos-entities-crud</td> <td><strong>8/8 = 100%</strong></td> <td>6/8 = 75%</td> <td>+25pp</td> </tr> <tr> <td><strong>Aggregate</strong></td> <td><strong>41/41 = 100%</strong></td> <td>34/41 = 84%</td> <td><strong>+16pp</strong></td> </tr> </tbody> </table></div> <p>The skill provides a real, measurable +16 percentage-point uplift across 41 assertions. Look at eval 4 though: zero uplift. The base model already aces the <code>debounceTime → distinctUntilChanged → switchMap → tapResponse</code> recipe. Keeping the rxMethod section of the skill in context costs tokens on every invocation while contributing nothing.</p> <p>This is what blind A/B benchmarking is for. <strong>If a skill section scores no better than baseline, that section is paying tokens for nothing. Trim it.</strong> Without the benchmark I would have happily kept that section in there forever.</p> <h3> Where the baseline failed and the skill caught it </h3> <p>The interesting question isn't "did the skill help," it's "where exactly did it help?" The viewer renders this side-by-side per assertion:</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F9wxjdjqbvukh78nxf1fg.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F9wxjdjqbvukh78nxf1fg.png" alt="Per-assertion comparison for eval 1: 10 rows, all green checkmarks in the With Skill column, three red Xs in the Without Skill column for explicit CartState typing, getState snapshot, and standalone setPending updaters" width="800" height="500"></a></p> <p>The green-and-red wall makes it obvious where the skill is doing real work. The recurring pattern across the 7 baseline failures:</p> <ol> <li> <strong>Explicit state typing.</strong> Base model writes <code>withState(initialState)</code> (inferred). Skill teaches <code>withState&lt;FooState&gt;(initialState)</code>. Catches patches with the wrong shape at compile time.</li> <li> <strong><code>getState</code>-based snapshot for rollback.</strong> Base model snapshots via <code>store.items()</code> directly. Skill teaches the <code>getState()</code> helper for full-state snapshots, the right tool when rollback needs to restore multiple slices.</li> <li> <strong>Standalone updaters vs. store-bound methods.</strong> Base model exposes <code>setPending</code>/<code>setFulfilled</code> as methods on the store. Skill teaches them as standalone functions returning <code>Partial&lt;State&gt;</code>, composable in a single <code>patchState(...)</code> call.</li> <li> <strong><code>updateEntity</code> function-form changes.</strong> Base model reads the entity, computes the toggle, passes a partial. Skill teaches <code>changes: (entity) =&gt; ({ ... })</code> for atomic state-dependent updates.</li> <li> <strong><code>removeEntities</code> predicate form.</strong> Base model filters and maps to ids and passes an id array. Skill teaches the predicate form.</li> <li> <strong>Typed <code>signalStoreFeature</code> prerequisite overload.</strong> Base model uses bare <code>signalStoreFeature(...)</code> with manual casts. Skill teaches <code>signalStoreFeature({ state: type&lt;EntityState&lt;T&gt;&gt;() }, ...)</code> so misuse is a compile error, not a runtime surprise.</li> </ol> <p>All six are <strong>encoded-preference</strong> failures. The model knows the API, but doesn't know which form is idiomatic. That distinction sets the skill's lifetime: a <em>capability uplift</em> skill (teaching the model something it didn't know) gets retired the moment the next model release closes the gap. An <em>encoded preference</em> skill stays useful as long as your team's idioms stay the same. For popular libraries like <code>@ngrx/signals</code>, you should expect to land in the second bucket, and the eval is what tells you you're there.</p> <h2> Failure mode B: the skill exists but doesn't trigger </h2> <p>Worse than failure mode A, because it's invisible. The skill never runs, you blame the model, you never discover the description was the bottleneck.</p> <p><code>skill-creator</code> ships a script called <code>run_loop.py</code> that handles description optimization with proper ML discipline:</p> <ul> <li>Generate ~20 synthetic prompts: half should-trigger, half should-NOT-trigger.</li> <li>The negatives deliberately share keywords with the skill, adjacent intent rather than random noise. This is what catches false positives.</li> <li>60/40 train/test split. 3 runs per query (single runs are too noisy to be a signal).</li> <li>Up to N iterations of: evaluate, propose new description, re-evaluate.</li> <li>Pick the description with the best <strong>test-set score</strong>, not train score. Standard ML hygiene applied to a YAML field.</li> </ul> <p>I drafted 20 queries: 10 substantive Signal Store scenarios and 10 near-misses (classic <code>@ngrx/store</code>, plain RxJS, plain <code>signal()</code> for component-local state, <code>@ngrx/effects</code> setup, the <code>Subject</code> vs. <code>BehaviorSubject</code> question, and so on). Then I let the loop run for 3 iterations.</p> <p>The HTML report is the most striking visual in the whole experiment:</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fqd14s02p6p1uxp98r662.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fqd14s02p6p1uxp98r662.png" alt="Description optimizer report: three iterations, three different proposed descriptions, all showing red Xs across nearly every test query column. Best score: 3/7 on the held-out test set" width="800" height="1783"></a></p> <p>The per-iteration scores:</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Iteration</th> <th>Description style</th> <th>Train (n=13)</th> <th>Test (n=7, held-out)</th> </tr> </thead> <tbody> <tr> <td>0 (original)</td> <td>Keyword-anchored + explicit exclusions</td> <td>6/13 = <strong>46.2%</strong> </td> <td>3/7 = <strong>42.9%</strong> </td> </tr> <tr> <td>1</td> <td>"Use for any Angular state management question…" (intent-driven, longer)</td> <td>6/13 = 46.2%</td> <td>3/7 = 42.9%</td> </tr> <tr> <td>2</td> <td>"Invoke this skill when…" (imperative, codebase-context cue)</td> <td>6/13 = 46.2%</td> <td>3/7 = 42.9%</td> </tr> </tbody> </table></div> <p>The optimizer ran exactly as designed. It proposed two alternatives, evaluated each over 60 model calls per iteration, and selected the description with the best test score. <strong>It picked the original.</strong> No proposed alternative beat the baseline.</p> <p>This is not a failure of the loop. It's the right answer when no improvement exists.</p> <h3> The recall ceiling no description rewrite can break </h3> <p>Two reasons the optimizer found nothing better, both diagnostic:</p> <ol> <li><p><strong>The model under-triggers conversational queries no matter what the description says.</strong> Several should-trigger queries used plain English with no <code>signalStore</code>/<code>withState</code> anchor, like <em>"what's the right pattern for an optimistic update with rollback?"</em> or <em>"I have an order detail page where the OrderEditStore should live for the duration of /orders/:id/edit"</em>. The model decides it can answer without consulting a skill. <strong>No description rewrite fixes that.</strong></p></li> <li><p><strong>Precision was already 100%.</strong> All three descriptions correctly avoided triggering on the 10 should-not-trigger queries. The only failure mode left was recall, and the model's under-triggering bias is hostile to recall improvements via prose alone.</p></li> </ol> <p>This is the kind of insight pure capability evals would never surface. Capability evals only describe the world where the skill loads. Trigger evals add the rest of the picture: even a perfect skill leaks value if the agent only consults it half the time it ought to. That leak is invisible from the capability side.</p> <blockquote> <p><strong>Independent confirmation.</strong> This isn't a quirk of my eval set. Vercel's January 2026 benchmark hit the same wall from a different angle: their Skills configuration was <em>uninvoked in 56% of cases</em> even when the agent had access. Different conclusion (drop Skills entirely), same root observation: agents do not reliably consult skills on conversational prompts.</p> </blockquote> <h2> What it costs: +14 seconds and ~$0.04 per invocation </h2> <p>Skills aren't free. Every invocation reads the <code>SKILL.md</code> body into context. Reference files are loaded on demand, but they still cost tokens when the model decides to read them.</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Metric</th> <th>with_skill (v2)</th> <th>baseline</th> <th>Δ vs baseline</th> </tr> </thead> <tbody> <tr> <td>Pass rate</td> <td>100% ± 0%</td> <td>84% ± 12%</td> <td><strong>+16 pp</strong></td> </tr> <tr> <td>Time per run</td> <td>62.7s ± 16.1s</td> <td>49.0s ± 4.8s</td> <td><strong>+13.7s</strong></td> </tr> <tr> <td>Tokens per run</td> <td>32,343 ± 2,737</td> <td>19,927 ± 394</td> <td><strong>+12,416</strong></td> </tr> </tbody> </table></div> <p>That's a 28% wall-time increase and a 62% token increase per invocation. At Sonnet 4.6 pricing ($3 / M input, $15 / M output) the per-call delta works out to about <strong>+$0.04</strong> at the headline rate, since the 12k delta is almost entirely additional input from reading the SKILL.md and references. With <a href="https://platform.claude.com/docs/en/build-with-claude/prompt-caching" rel="noopener noreferrer">prompt caching</a> on, repeat invocations of the same skill <strong>inside the 5-minute cache window</strong> read cached input at 10% of base ($0.30 / M), so each warm call drops to roughly <strong>+$0.004</strong>. Cold starts still pay the full +$0.04, and any edit to the skill body or the container's skills list breaks the cache. For a team running 500 skill-loading prompts a day, the realistic range is somewhere between ~$2/day if most calls hit a warm cache and ~$20/day if every call is cold. Either way it's the <strong>+14 second wall-time hit that's more painful than the dollar cost</strong> for an interactive coding assistant. That's the difference between "snappy" and "noticeably waiting."</p> <p>Two things make the trade-off worth it:</p> <ul> <li> <strong>The +16pp pass rate is concentrated on patterns that are hard to debug after the fact.</strong> A wrong-form <code>updateEntity</code> won't crash, it'll just race in production. A missed <code>getState</code> snapshot won't crash either, it'll just leak optimistic-update state. Catching these at generation time is genuinely valuable.</li> <li> <strong>You can iterate the skill to be cheaper.</strong> My initial v1 cost +20.6s and +13.3k tokens. After one iteration (adding a canonical scaffold and six "wrong → right" snippets inline) v2 dropped to +13.7s and +12.4k tokens, a <strong>33% time reduction and 6% token reduction</strong> while keeping the same 100% pass rate. The trick: inline corrections meant the model didn't need to read as many reference files per task.</li> </ul> <p><strong>Skill body length is a poor proxy for skill cost.</strong> What matters is how much <em>additional</em> content the model has to load on top of the body. v2 was 138 lines longer than v1 and still cost less in practice.</p> <h2> Wire benchmarks into PR CI before the model changes under you </h2> <p>Minimum viable eval setup for any custom skill:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>your-skill/ ├── SKILL.md ├── references/ └── evals/ ├── evals.json # 4-6 substantive tasks with assertions └── trigger-eval.json # 20 should-/should-not queries </code></pre> </div> <p>Then a CI job that re-runs both benchmarks after every model bump or skill PR. Minimal GitHub Actions shape:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight yaml"><code><span class="na">name</span><span class="pi">:</span> <span class="s">skill-evals</span> <span class="na">on</span><span class="pi">:</span> <span class="na">push</span><span class="pi">:</span> <span class="na">paths</span><span class="pi">:</span> <span class="pi">[</span> <span class="s1">'</span><span class="s">skills/your-skill/**'</span> <span class="pi">]</span> <span class="na">workflow_dispatch</span><span class="pi">:</span> <span class="na">schedule</span><span class="pi">:</span> <span class="pi">-</span> <span class="na">cron</span><span class="pi">:</span> <span class="s1">'</span><span class="s">0</span><span class="nv"> </span><span class="s">6</span><span class="nv"> </span><span class="s">*</span><span class="nv"> </span><span class="s">*</span><span class="nv"> </span><span class="s">1'</span> <span class="c1"># weekly, catches model-side drift</span> <span class="na">jobs</span><span class="pi">:</span> <span class="na">benchmark</span><span class="pi">:</span> <span class="na">runs-on</span><span class="pi">:</span> <span class="s">ubuntu-latest</span> <span class="na">steps</span><span class="pi">:</span> <span class="pi">-</span> <span class="na">uses</span><span class="pi">:</span> <span class="s">actions/checkout@v6</span> <span class="pi">-</span> <span class="na">name</span><span class="pi">:</span> <span class="s">Run capability benchmark</span> <span class="na">run</span><span class="pi">:</span> <span class="s">python -m scripts.aggregate_benchmark workspace/iteration-latest --skill-name your-skill</span> <span class="pi">-</span> <span class="na">name</span><span class="pi">:</span> <span class="s">Fail PR if pass rate drops below threshold</span> <span class="na">run</span><span class="pi">:</span> <span class="pi">|</span> <span class="s">jq '.run_summary.with_skill.pass_rate.mean' workspace/iteration-latest/benchmark.json \</span> <span class="s">| awk '{ if ($1 &lt; 0.95) { print "Pass rate below 95%"; exit 1 } }'</span> <span class="pi">-</span> <span class="na">name</span><span class="pi">:</span> <span class="s">Run description trigger optimizer</span> <span class="na">run</span><span class="pi">:</span> <span class="s">python -m scripts.run_loop --eval-set evals/trigger-eval.json --skill-path skills/your-skill --model claude-sonnet-4-6 --max-iterations </span><span class="m">1</span> </code></pre> </div> <p>The whole loop takes about 15 minutes of wall time (with executor and grader subagents running in parallel). The cost of <em>not</em> running it is the slow accretion of capability-uplift skills that became no-ops two model versions ago, and triggering descriptions that quietly stopped firing.</p> <h2> A footnote on my own evals: 100% is a saturation signal </h2> <p>My with-skill pass rate is 100% across both iterations. That sounds good. It isn't.</p> <p>In <em><a href="https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents" rel="noopener noreferrer">Demystifying evals for AI agents</a></em>, Anthropic put it bluntly:</p> <blockquote> <p><strong>"An eval at 100% tracks regressions but provides no signal for improvement."</strong></p> </blockquote> <p>Mine track regressions just fine. If <code>claude-opus-5</code> ships and pass rate drops, I'll know within 15 minutes. But for further skill iteration the suite is <strong>saturated</strong>. I can't tell whether v3 of the skill is better than v2, because both will hit 100%.</p> <p>Concrete next-round eval candidates that would <em>not</em> hit 100%:</p> <ul> <li>A multi-store coordination task where a <code>CheckoutStore</code> reads from <code>CartStore</code> <em>and</em> <code>UserStore</code> without violating the no-cross-store-injection rule.</li> <li>An entity store with a custom <code>idKey: 'uuid'</code> plus a named collection. The kind of thing that exposes whether the model knows the multi-collection updater syntax.</li> <li>A migration from <code>@ngrx/store</code> (classic NgRx with reducers/effects) to Signal Store, where the agent has to translate actions into store methods correctly.</li> <li>A route-scoped store with <code>withHooks({ onDestroy })</code> cleanup that triggers a pending HTTP cancel.</li> </ul> <p>Same skill, same idioms, harder ground truth. Without explicit pass-rate visibility I would happily keep iterating in the dark, congratulating myself on each "100%" run.</p> <h2> Where to go from here </h2> <p>For a popular library like <code>@ngrx/signals</code>, the base model knows the API. The skill's job is encoded preference: making the model produce <em>your team's</em> idiomatic forms, not just any working code. Without evals you can't tell whether the skill is actually doing that.</p> <p>Four findings, all worth carrying forward:</p> <ol> <li> <strong>Capability uplift is real</strong> (+16pp pass rate), but concentrated in 6 specific idiom corrections, not in API knowledge. As long as your idioms are the value, the skill survives model upgrades.</li> <li> <strong>Skill cost is real</strong> (+14s wall time, +12k tokens, ~$0.04 per call), and iteration can reduce it (v1 → v2 cut wall time by 33%).</li> <li> <strong>Triggering has a ceiling</strong> (~46% recall) that prose-only optimization can't break, independently confirmed by Vercel's 56% uninvoked rate.</li> <li> <strong>100% pass rate is a saturation signal.</strong> Time to add harder evals, not to declare victory.</li> </ol> <p>Concrete next steps if you want to do this on your own skills:</p> <ul> <li>The skill itself, with eval suite and per-skill README, is at <strong><a href="https://github.com/danielsogl/skills/tree/main/skills/ngrx-signals" rel="noopener noreferrer"><code>github.com/danielsogl/skills</code></a></strong>. Install with <code>npx skills add danielsogl/skills@ngrx-signals</code>.</li> <li>The <code>skill-creator</code> plugin and its <code>run_loop.py</code> script are at <a href="https://github.com/anthropics/skills/tree/main/skills/skill-creator" rel="noopener noreferrer"><code>anthropics/skills</code></a>. You can copy the eval scaffolding from there and adapt the assertions to whatever skill you maintain.</li> <li>After every Claude release, re-run the capability benchmark first (~5 minutes), then the description optimizer (~10 minutes). Track the deltas in a CHANGELOG next to your <code>SKILL.md</code>. That's how you catch the day a capability-uplift skill becomes redundant.</li> </ul> <h2> References </h2> <p><strong>Anthropic, Agent Skills</strong></p> <ul> <li> <a href="https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills" rel="noopener noreferrer">Improving skill-creator: Test, measure, and refine Agent Skills</a> (Mar 3, 2026): central announcement; "5 of 6 document-creation skills" comes from here.</li> <li> <a href="https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills" rel="noopener noreferrer">Equipping agents for the real world with Agent Skills</a> by Barry Zhang, Keith Lazuka, Mahesh Murag: engineering deep-dive on progressive disclosure.</li> <li> <a href="https://www.anthropic.com/news/skills" rel="noopener noreferrer">Introducing Agent Skills</a>: original Oct 2025 announcement.</li> <li> <a href="https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview" rel="noopener noreferrer">Agent Skills documentation</a>: current API and filesystem reference.</li> <li> <a href="https://claude.com/blog/seeing-like-an-agent" rel="noopener noreferrer">Seeing like an agent: how we design tools in Claude Code</a>: broader tool-design philosophy.</li> <li> <a href="https://github.com/anthropics/skills" rel="noopener noreferrer"><code>anthropics/skills</code> on GitHub</a>: official skills repo, including <code>skill-creator/run_loop.py</code>.</li> </ul> <p><strong>Anthropic, eval methodology</strong></p> <ul> <li> <a href="https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents" rel="noopener noreferrer">Demystifying evals for AI agents</a> (Jan 9, 2026) by Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares, Jiri De Jonghe: source of the "an eval at 100% tracks regressions but provides no signal for improvement" quote and the test-both-sides principle.</li> <li> <a href="https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents" rel="noopener noreferrer">Effective context engineering for AI agents</a>: context-window discipline that progressive disclosure is built on.</li> </ul> <p><strong>Vercel, counterpoint and eval framework</strong></p> <ul> <li> <a href="https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals" rel="noopener noreferrer">AGENTS.md outperforms Skills in our agent evals</a> (Jan 27, 2026) by Jude Gao: source of the 100% / 79% / 53% numbers and the "uninvoked in 56% of cases" finding.</li> <li> <a href="https://vercel.com/kb/guide/an-introduction-to-evals" rel="noopener noreferrer">An Introduction to Evals</a>: runner / scorer / dataset pattern; "20 well-chosen test cases &gt; 200 random examples."</li> <li> <a href="https://vercel.com/blog/the-no-nonsense-approach-to-ai-agent-development" rel="noopener noreferrer">The no-nonsense approach to AI agent development</a>: tighten-the-loop methodology before adding eval scaffolding.</li> <li> <a href="https://vercel.com/blog/ai-sdk-6" rel="noopener noreferrer">AI SDK 6 release notes</a>: Agent abstraction, ToolLoopAgent, MCP support.</li> </ul> <p><strong>Open standard</strong></p> <ul> <li> <a href="https://agentskills.io/skill-creation/optimizing-descriptions" rel="noopener noreferrer">agentskills.io: Optimizing skill descriptions</a>: train/validation split walkthrough.</li> </ul> <p><strong>Library under test</strong></p> <ul> <li> <a href="https://ngrx.io/guide/signals/signal-store" rel="noopener noreferrer">NgRx Signal Store official guide</a>.</li> <li> <a href="https://ngrx.io/guide/signals/signal-store/custom-store-features" rel="noopener noreferrer">Custom Store Features</a>.</li> <li> <a href="https://www.angulararchitects.io/blog/the-ngrx-signal-store-and-your-architecture/" rel="noopener noreferrer">Manfred Steyer: NGRX Signal Store and Your Architecture (AngularArchitects)</a>: store/service split rules used in the skill.</li> </ul> <p><strong>Framing</strong></p> <ul> <li> <a href="https://medium.com/@richardhightower/claude-code-how-to-build-evaluate-and-tune-ai-agent-skills-34afa808d1c9" rel="noopener noreferrer">Rick Hightower (Towards AI): Build, Evaluate, and Tune AI Agent Skills</a>: Capability Uplift vs. Encoded Preference framing this article borrows.</li> </ul>