/ratel-decompose-prompt — split a monolithic system prompt into a lean core + retrievable skills

A system prompt that has grown to thousands of tokens is paying for every responsibility on every turn. Most of it is dormant most of the time: the refund-flow procedure sits in context while the user asks about shipping; the SQL-generation playbook loads while the user is editing a form. Ratel's skills mechanism exists precisely for this — a procedure becomes a retrievable playbook that only enters context when a turn calls for it. This skill is the fix that turns one giant prompt into a small stable core plus a SkillCatalog of extracted skills.

The deliverable is a markdown plan at <repo>/.ratel/ratel-decompose-prompt.md: the proposed lean core prompt, a skill inventory table, and a per-skill SKILL definition ready to drop into a Ratel-managed skills folder. The plan is implementable by the customer; this skill does not rewrite their prompt in place.

This skill is the fix that the /ratel-assessment "Prompt Decomposition" dimension routes to. It pairs with:

/ratel-tune-definitions — every skill you extract needs a retrievable description and tags. The decomposition produces the skills; tune-definitions sharpens their wording so search_capabilities actually surfaces them. Run it after this one on the extracted set.
/ratel-assessment — the front-door audit that identifies an over-stuffed prompt and points here.

Philosophy

Three rules. Break any of them and you've either moved bloat around without removing it, or you've gutted the prompt's stable contract and made the agent unreliable.

The core prompt keeps what must hold every turn; skills hold what's situational. Stable role, safety rules, and the output-format contract stay in the core — the model must never be without them. Recurring procedures, task-specific playbooks, and few-shot examples are situational and belong in skills. The test for each section: "if this is absent on an unrelated turn, does the agent become unsafe or off-contract?" If yes, it stays in core. If no, it's a skill candidate.
A skill must be self-contained and worth retrieving. An extracted skill is loaded cold via get_skill_content with no surrounding prompt context. If a section only makes sense glued to three other sections, it's one skill, not four. Don't shatter a coherent procedure into fragments that can't stand alone.
Retrievability is a design constraint, not an afterthought. A skill that never gets surfaced is dead weight in the catalog and a hole in the agent's behavior. Every extracted skill must carry a description and tags that match the natural-language intent of the turns that need it. If you can't write triggers for it, it probably belongs in the core or doesn't deserve to be a skill.