Given a skill file with a description and body, apply both stages:

Markdown
BEFORE (verbose, 82 tokens):
---
description: This skill helps you write, format, and validate JSON schemas
for API responses, including generating examples, checking compliance with
JSON Schema Draft 7, and providing helpful error messages when validation
fails. Use this whenever you need to work with JSON schemas in any context.
---

AFTER (1-minimal, 19 tokens):
---
description: Validates and generates JSON Schema (Draft 7) for API
responses. Use when checking schema compliance or validation errors.
---

Markdown
BEFORE (monolithic body, 3,200 tokens — all loaded every time):

Progress checklist for processing one skill:

• Stage 0: Tokenize description and body (cl100k_base); flag missing/short descriptions (<20 tokens) and oversized bodies
• Stage 1: Compress/generate description via delta-debugging against a routing oracle
• Stage 2a: Classify body paragraphs into taxonomy (core rule / background / example / template / redundant)
• Stage 2b: Restructure into tiered architecture (core rules inline, rest in on-demand reference files)
• Validate: faithfulness check + task-based functional test
• Report: compression ratio, retained pass rate, any regressions

Stage 1 — Description Optimization (Routing Layer)

If description is missing or <20 tokens: Generate one by distilling the skill body into the minimal set of semantic clauses that distinguish this skill from plausible competing skills. A good description states: (a) what domain/task the skill handles, (b) concrete trigger phrases/conditions for invocation. Avoid feature lists, examples, or redundant phrasing.

If description exists: Apply delta-debugging minimization:

1. Decompose the description into independent semantic clauses (split on commas, "and", enumerated items).
2. Construct an adversarial oracle: a set of representative user queries this skill SHOULD match, and near-miss queries it should NOT match (from competing/similar skills).
3. Binary-partition the clause set; test whether each half alone preserves correct routing against the oracle.
4. Recursively discard clauses that don't affect routing outcomes, keeping only the 1-minimal set — every remaining clause is individually necessary for routing.
5. Stop when no further clause can be removed without breaking at least one oracle query.

Stage 2 — Body Restructuring (Progressive Disclosure)

1. Segment the body into paragraph-level items (headers, bullet groups, code blocks treated as atomic units).
2. Classify each item into one of five categories:
   • core_rule — actionable instruction the agent must follow (ALWAYS keep inline)
   • background — explanation/rationale/history (defer)
   • example — code snippets, I/O pairs, worked demonstrations (defer)
   • template — boilerplate/scaffolding (defer unless directly copy-pasted by agent every time)
   • redundant — duplicates another item (delete)
3. Cross-validate classifications by re-checking each item's label against its neighbors' labels (catches misclassified transitional content); run up to 2 correction passes.
4. Restructure:
   • Keep only core_rule items in the main body (always loaded).
   • Move background, example, template items into separate reference files (e.g. references/examples.md, references/background.md), linked from the main body with a one-line pointer ("See references/X.md for Y").
   • Delete redundant items entirely.
5. Faithfulness check: verify no core rule was dropped and no reference file is orphaned (unreferenced) or unreachable.
6. Task-based validation: run the skill against representative tasks; if pass rate drops vs. baseline, restore the highest-uncertainty-classification items (self-correcting feedback loop) and re-test.

File Composition Cleanup

If the skill bundles reference files/scripts:

• Audit total reference token count; if it exceeds ~5-10x the core body size, confirm each reference is reachable via an explicit on-demand load path (not auto-injected).
• Scripts (executable, not injected as context) are out of scope for token reduction — leave as-is.

Example 1 — Missing description: Input: A skill body about generating React component boilerplate with no description field. Output: description: Generates React functional component boilerplate with TypeScript props and hooks. Use when scaffolding new React components or converting class components to functional.

Example 2 — Verbose description minimization: Input: description: This skill is for all things related to database migrations, including creating migration files, running migrations up and down, checking migration status, rolling back failed migrations, and generating migration reports for teams, use this for any Postgres or MySQL related schema change work. Output: description: Creates and runs database migrations (up/down/status/rollback) for Postgres/MySQL. Use for schema change tasks. (Delta-debugging removes "reports for teams" since it didn't affect routing outcomes against the oracle query set.)

Example 3 — Body restructuring: Input: A 4,500-token skill body: 30% core rules, 45% background on why the approach works, 20% examples, 5% redundant repetition of the same warning. Output: Core body reduced to ~1,350 tokens (core rules only + brief pointers); references/background.md (~2,025 tokens) and references/examples.md (~900 tokens) created; redundant warning repetition deleted. Net default-load reduction: ~70%.