enhance-prompt

Files (13)

• SKILL.md
• already-structured.md · acceptance/fixtures/
• multi-task-prompt.md · acceptance/fixtures/
• vague-review-prompt.md · acceptance/fixtures/
• already-structured.golden.json · acceptance/snapshots/
• multi-task-prompt.golden.json · acceptance/snapshots/
• vague-review-prompt.golden.json · acceptance/snapshots/
• example_short_prompt.md · examples/
• example_skipped.md · examples/
• example_with_skill.md · examples/
• expansion_patterns.md · reference/
• preserve_user_voice.md · reference/
• test-plan.md

SKILL.md (first lines)

# 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:

```yaml
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.

From LegalQuants/lq-ai, Apache-2.0.

More from LegalQuants/lq-ai