Enhance Prompt

Rewrite the user's prompt into a more effective version before it is submitted to the model. Show the user what changed and why. Make the expansion visible and editable, never silent.

The point of this skill is not to make every prompt longer. It is to surface the implicit assumptions in a short prompt and turn them into explicit instructions, so the model produces what the user actually wanted on the first try rather than after several rounds of clarification.

When this skill applies

Apply when:

1. The user has invoked Enhance Prompt explicitly (button click, skill attachment, or trigger phrase).
2. The application has Enhance Prompt's auto-expand toggle enabled and the user has just submitted a prompt.

In auto-expand mode, also apply the skip conditions in the next section before producing an expansion. Auto-expand should not be aggressive — many prompts do not need expansion, and producing an expansion when one is not needed is friction rather than value.

When NOT to apply (skip conditions)

Skip the expansion and let the original prompt through unchanged when:

• The prompt is already well-structured. If the user has already specified role, task, constraints, and output format, expansion adds noise. Heuristic: if the prompt is over ~80 words and contains explicit instructions about format, audience, or scope, skip.
• The prompt is conversational or interpersonal. "thanks," "what did you mean by that," "go ahead," "skip that point" — these are conversational moves, not new tasks. Do not expand.
• The prompt is a follow-up question continuing a prior task. When chat_history shows the user is iterating on a previous answer ("can you also add X," "shorter please," "what about California"), the prior turn supplies context; expansion would discard it. Do not expand.
• The prompt is operational rather than substantive. "summarize the document I just uploaded," "translate this," "format this as a table" — these are direct operational asks; expansion adds friction without adding clarity.
• The user has explicitly opted out for this prompt. If the user has typed --no-enhance-prompt, [skip enhance prompt], or similar, honor it.
• A skill is attached that already expands the prompt itself. If attached_skills includes a skill whose description shows it handles prompt expansion or rewriting, skip — let the attached skill drive.

When skipping, return the skip decision explicitly (see Output section) so the application can pass the original prompt through.

What a good expansion does

A good expansion makes implicit elements explicit. The implicit elements that most often need surfacing in legal prompts are:

1. Role. What kind of lawyer is the model adopting? "You are an in-house counsel reviewing X" anchors the response in the right voice and rigor. Default role is in-house counsel; adjust for context.
2. Jurisdiction. Legal answers depend on jurisdiction. If the prompt asks a question with jurisdiction-dependent answers and no jurisdiction is specified, fold in the user's configured jurisdiction if available, or note that the expansion assumed US-default and the answer should be re-asked if a different jurisdiction applies.
3. Audience. Is the output for the user, for forwarding to a business partner, for board consumption, for outside counsel? The audience changes the tone, length, and depth.
4. Scope. "Review this contract" can mean a 30-second triage or a two-hour substantive review. Surface the implicit scope. "Identify three to five most important issues" is a different ask than "comprehensive review."
5. Output format. Bulleted list? Memo with headings? Table? One-paragraph summary? Default to whatever the substance suggests, but make it explicit.
6. Constraints and exclusions. What should the response not do? "Without giving a final legal opinion," "without speculating about enforceability," "limited to issues observable in the document text" — these are the safety rails that keep the model in scope.
7. Citation expectations. When the prompt is about a document, specify whether responses should cite specific clauses or sections.

A good expansion adds these only where they are actually missing. Adding a role to a prompt that already specifies a role is noise. Adding a jurisdiction to a question that has no jurisdiction-dependent component is noise.

What a good expansion does NOT do

• Does not invent legal substance. The skill expands the prompt; it does not pre-answer it. If the user's prompt is "what's the standard term length for an NDA," the expansion clarifies role, audience, and format — it does not insert "the standard is 3 years" into the prompt.
• Does not narrow the user's intent. If the user's prompt is open-ended, the expansion preserves that openness. Specifying "give me three issues" when the user said "review this" substitutes the skill's judgment for the user's.
• Does not import skills the user did not attach. If there is no NDA-Review skill attached but the prompt is about an NDA, the expansion may note that NDA-Review exists in the library, but does not insert NDA-Review's review framework into the prompt.
• Does not contradict skill instructions. If a skill is attached, the expansion respects the skill's scope. The skill's frontmatter description tells you what the skill does; the expansion should complement, not override.
• Does not discard user wording. Preserve the user's substantive verbs and nouns. "Help me figure out" stays as-is; do not "improve" it to "Analyze comprehensively." The user's voice carries information about urgency, formality, and confidence — preserving it is part of preserving intent.
• Does not exceed reasonable length. A good expansion is typically 2–5x the length of the input. A 10-word prompt becoming a 200-word prompt is a sign the expansion has overreached.

Workflow

1. Read the input. Parse the raw_input. Identify what the user is asking for (the substantive task) and how the user is asking for it (voice, formality, urgency).

2. Check skip conditions. Run through the skip conditions in the section above. If any apply, return a skip decision (see Output section). Stop here.

3. Read the context. If attached_skills, attached_files, chat_history, or jurisdiction are provided, read them. Identify what is already established and should not be re-established.

4. Identify the gaps. Walk through the seven elements (role, jurisdiction, audience, scope, output format, constraints, citation expectations) and identify which are implicit in the prompt and worth surfacing. Skip elements that are already explicit, and skip elements that are not relevant to this prompt (e.g., citation expectations are irrelevant if no document is in scope).

5. Draft the expansion. Write the expanded prompt. Preserve the user's substantive verbs and nouns. Add the elements identified in step 4. Keep total length to 2–5x the input length.

6. Write the reasoning section. Three to six bullet points, one per element you added or modified. Each bullet names what was added and why in plain language. The user will read this; write for the user, not for a developer.

7. Return the structured output. See Output section.

Output

The skill returns a structured object:

expansion_applied: true | false
expanded_prompt: <the expanded prompt text, or the original if skipped>
reasoning:
  - <bullet on what was added or modified, and why>
  - <one bullet per substantive change>
skip_reason: <if expansion_applied is false, the reason from the skip conditions list, or null>
preview_to_user: |
  <a single rendered string the application can show in the "review before sending" UI, combining the expanded prompt and the reasoning, formatted for human reading>

The skill is responsible for: - Producing the expansion content and reasoning. - Returning the structured output the application consumes.

The application is responsible for: - Showing preview_to_user to the user with edit/submit/skip controls. - Submitting expanded_prompt to the model when the user confirms. - Submitting the original raw_input if the user chooses skip. - Providing a "view this skill" affordance on the review screen so the user can inspect the skill itself if they want to (see Transparency below).

The skill itself does not invoke the model with the expanded prompt; it returns the expansion for the application to handle.

Transparency

This skill is designed to be inspectable by the user. The application should make the skill's contents (this SKILL.md and its supporting files) viewable from the review-before-sending screen. Users who want to understand exactly how their prompts are being enhanced — including the patterns this skill applies, the constraints on what is added, and the principles for preserving voice — should be able to read the skill itself.

Transparency is a feature, not a leak. The skill's instructions are not a trade secret; they are open-source work product. Users who can read the skill can also disagree with it, fork it, or replace it. That is the right relationship between users and the tools that shape their work.

Edge cases and refusals

• Empty or near-empty input. If the user submitted only whitespace, "?", "test," or similar, return expansion_applied: false with skip_reason: "input too short to expand meaningfully".
• Multilingual input. Preserve the language of the input. A prompt in French expands to a French expanded prompt with French reasoning. If the input mixes languages or the language is unclear, expand in the dominant language and note the ambiguity in reasoning.
• Prompts that contain confidential information in the prompt itself. Do not extract or paraphrase the confidential content into the reasoning section. The reasoning section talks about structure, not content.
• Prompts that are clearly outside legal practice. If the user's prompt has nothing to do with legal work (e.g., "what's a good restaurant in Boston," "write a haiku about my dog"), expand using general role/audience/format heuristics rather than legal-specific ones. Do not refuse — Enhance Prompt is a general expansion skill that is calibrated for legal work but still useful elsewhere.
• Prompts asking the skill to do something other than expand. If the user's prompt is "what does Enhance Prompt do" or "skip Enhance Prompt," route to the skip path and return the original.

Reference materials

• reference/expansion_patterns.md — common patterns for legal-prompt expansion across categories of legal work (contract review, drafting, research, advice).
• reference/preserve_user_voice.md — the principles for keeping the user's voice intact through expansion.
• examples/example_short_prompt.md — short prompt expanded to a full structured prompt.
• examples/example_skipped.md — example of a prompt that should be skipped, with reasoning.
• examples/example_with_skill.md — expansion when a skill is already attached, showing how the expansion respects the attached skill's scope.

Privilege treatment

The user's raw_input and the resulting expanded_prompt may both contain privileged matter. The expanded prompt is a derivative of the user's input — it inherits whatever privilege status the original had. Treat the expansion as you would treat the original communication.

Concretely:

• Both artifacts retain the original's privilege status. If the raw_input was a privileged attorney-client communication or attorney work product, the expanded_prompt is too. Privilege does not strip away by virtue of the skill rewriting the surface form.
• Do not store the expanded prompt outside the privilege circle. Hosts implementing this skill must not log, retain, transmit, or share the expanded_prompt, preview_to_user, or reasoning outside the same trust boundary that would apply to the user's original prompt. Analytics pipelines, training-data collection, third-party model endpoints, and shared review queues are common leak paths and must be inside-the-circle or excluded.
• The reasoning section is also derivative. Even though the reasoning talks about structure rather than content, it can name the subject matter of the prompt and therefore carry the same privilege status. Do not treat reasoning as safe-to-log just because it does not quote the input verbatim.
• Host responsibility. The user is responsible for not embedding privileged content in raw_input where the host application is not configured to handle it; the host application is responsible for not logging, retaining, or transmitting the expanded artifact outside the privilege circle. This skill itself writes nothing — but it produces an artifact that downstream systems will be tempted to log.

QA Remediation (LegalQuants, 2026-05)

This skill was reviewed against the Legal Skill Design Framework on 2026-05-11 (verdict: SOME CONCERN). The substantive gap identified was that privilege implications of the expanded-prompt artifact were not addressed — every legal prompt this meta-skill touches becomes a rewritten artifact that the host application may log or retain, and the original SKILL.md addressed confidentiality only at the reasoning-section level. The "Privilege treatment" section above was added in remediation to make explicit that (a) the user's input prompt and the expanded version may both contain privileged matter, (b) both retain whatever privilege status the original had, and (c) the expanded prompt must not be stored, logged, or shared outside the privilege circle. Frontmatter was updated with version, last_reviewed, and last_reviewed_by, and authorship was reconciled to credit Kevin Keller (matching the registry README). The technical workflow, skip conditions, expansion patterns, and output schema were left intact.