The problem with the super-prompt
The instinct, when a model is capable, is to hand it everything: every practice area, every style rule, every exception, in one enormous prompt. It feels efficient. It fails quietly. Instructions conflict, the model loses the thread in a long context, routing becomes guesswork, and nothing is testable.
What is a “skill” in this context?
A skill is a small instruction card — a compact operating manual — that tells the model when a recognizable class of request applies and what narrow set of rules to load for it. A discovery summary loads summary rules; a settlement draft loads settlement rules. Each skill makes a bounded promise: a recognizable input, a named handoff, and a defined output discipline.
The description is a classifier, not decoration
The single most important line in a skill is its description, because that is what decides whether the skill fires. Write it like a specification with four parts: the job, the language that should trigger it, the boundaries that should not, and the one thing that distinguishes it from its nearest neighbor.
“Helps with documents” is useless. “Drafts a review-required response letter from verified facts and an approved position; use for formal correspondence that explains a position or requests action; excludes ordinary email, negotiated offers, and filing-ready submissions” is a skill that catches the right requests and declines the wrong ones.
Skills route; they do not secretly execute
A good skill says what to load, what to require, and where to hand off. It does not embed long scripts or operational code. The reason is discipline: prose instructions cannot be type-checked or tested, and code that matters belongs in one auditable place — a registered workflow — not scattered across Markdown cards a model might misread.
The payoff: when a request arrives, a router loads only the one narrow skill that applies. Context stays small, instructions stop conflicting, and every routing decision can be tested against real examples.
How skills compose
Skills combine by naming handoffs and typed artifacts, not by concatenating prompts and hoping the model reconciles them. A packet-preparation skill might coordinate three registered workflows — gather, draft, assemble — while the confidentiality rule, the citation rule, and the external-send policy live once in a shared card every skill references. That is progressive disclosure: universal safeguards first, domain guidance after the route is known, long reference material only when a step truly needs it.
The result is a system where adding a new capability means writing a small, testable card and wiring a workflow — not editing a monolith and praying nothing else breaks.
This article is general information from a technology consultancy, not legal advice, and does not create an attorney-client relationship. Figures describing the founder’s own practice are illustrative, not a promise of results.