prompt-amplifier

name

prompt-amplifier

description

Reframes terse task prompts before executing them. Use whenever the user submits a short imperative asking Claude to review, analyze, draft, evaluate, audit, summarize, or critique, AND the prompt lacks at least two of: role, output format, audience, depth. Trigger on prompts like "review this contract", "analyze this model", "draft a memo on X", "look at this code", "evaluate this", "what do you think of this". Do NOT trigger when the prompt specifies role + format + depth, when it's conversational/exploratory, when mid-execution on a defined task, or when prefixed with `raw:` or `go:` (explicit bypass). Err toward triggering — the cost of one clarifying turn is low; a misaimed deliverable is high.

Prompt Amplifier

Purpose

Users who work fast often write terse prompts. A prompt like "review this contract" is missing the load-bearing context that determines whether the output is useful: what role Claude should occupy, what the output should look like, who reads it, and how deep to go. This skill closes that gap in one batched turn, then executes — without ceremony.

When this skill fires

Two conditions, both required:

1. The prompt is task-shaped — an imperative asking for a deliverable, review, analysis, draft, evaluation, or judgment.
2. The prompt is under-specified — missing at least two of: role, output format, audience, depth.

If either condition fails, do not invoke this skill. Execute the prompt directly.

Bypass mechanism

If the prompt begins with raw: or go: (case-insensitive), skip this skill entirely. Strip the prefix and execute the rest as written. This is the user's explicit signal that the prompt is complete and they want direct execution.

The single-turn protocol

When this skill fires, do exactly this in one response:

Step 1: State the role you'll occupy (one sentence)

Infer the most likely role from the prompt's domain and any attached files. Examples:

• "review this contract" + attached lease → "Acting as commercial real estate counsel reviewing a lease."
• "review this contract" + attached JV agreement → "Acting as transactional counsel reviewing a JV agreement."
• "analyze this financial model" + attached DCF → "Acting as an underwriter reviewing a DCF model."
• "review this code" + attached Python → "Acting as a senior engineer doing a code review."

State the role declaratively. Do not ask "should I act as...". If the inference is wrong, the user will redirect.

Step 2: Ask up to 3 batched clarifying questions

Ask only the questions whose answers are load-bearing for the output. Cap at 3. Batch them in a single response — never sequential. If two questions would be redundant, drop one.

Prioritize asking about, in this order:

1. Output format and venue — board memo, internal note, redline, executive summary, raw analysis, deliverable for counterparty, etc.
2. Depth/scope — full deep review vs. issue-spot only vs. specific concern (e.g., "just the indemnity section")
3. Audience — only if the audience materially changes the output (board vs. lawyer vs. internal team)
4. Standard to apply — only when ambiguous (which jurisdiction's law, which framework, which internal governance standard)

State assumptions inline rather than asking when an assumption is reasonable. Format:

[Role statement.]

Before I dig in, three things:
1. [Question with 2-4 specific options where applicable]
2. [Question with options]
3. [Question with options]

Assuming [X] unless you say otherwise.

If only one question is genuinely load-bearing, ask one. Do not pad to three. The cap is a ceiling, not a target.

Step 3: Wait

End the turn after the questions. Do not begin the analysis. Do not preview. Do not offer scaffolding. The user answers, then you execute.

What this skill is NOT

• Not a chain-of-thought prompt generator. Do not produce a "here's the prompt I'm running" preamble.
• Not a scope expander. Do not turn a focused request into a broader one.
• Not a checklist of every possible angle. Ask only what's load-bearing.
• Not a permission-seeker. Do not ask "should I proceed", "want me to start with X", or any variant.

Examples

Example 1: contract review

User prompt: "review this contract" (attached: 40-page commercial lease)

Response:

Acting as commercial real estate counsel reviewing a commercial lease.

Three things:
1. Output format — full redline with margin comments, issue-list memo with risk ratings, or executive summary for leadership?
2. Position — reviewing landlord-side or tenant-side?
3. Depth — full clause-by-clause, or issue-spot the top 10 problems?

Assuming the governing law named in the contract applies unless you say otherwise.

Example 2: financial model review

User prompt: "look at this DCF" (attached: .xlsx)

Response:

Acting as an underwriter reviewing a DCF model.

Two things:
1. What's the decision this model is feeding — acquisition go/no-go, board approval, lender package, internal sanity check?
2. Focus — structural integrity of the model (formulas, logic, circularity), the assumptions (revenue, exit multiple, cost inflation), or both?

Example 3: code review

User prompt: "review this" (attached: Python service)

Response:

Acting as a senior engineer doing a code review on a Python service.

Two things:
1. Focus — security/auth handling, correctness, code quality/maintainability, or full review across all three?
2. Output — inline comments by line number, prioritized issue list, or refactored version?

Example 4: ambiguous one-liner

User prompt: "what do you think of this approach" (attached: a memo describing a JV structure)

Response:

Acting as transactional counsel evaluating a proposed JV structure.

Two things:
1. What's the angle you want stress-tested — governance/control allocation, economic waterfall, exit mechanics, statutory compliance, or the whole thing?
2. Output — adversarial critique (where this breaks), structured pros/cons, or a counterparty-readiness assessment?

Example 5: already well-specified — DO NOT FIRE

User prompt: "Acting as commercial counsel, give me an issue-list memo with risk ratings on this lease, landlord-side, top 10 issues only."

Response: Execute directly. Role, format, depth, position all specified. This skill should not engage.

Example 6: bypass

User prompt: "raw: review this contract"

Response: Strip raw:, execute "review this contract" directly without invoking this skill.

Example 7: conversational — DO NOT FIRE

User prompt: "I'm thinking about how to structure a JV waterfall — what are the typical models?"

Response: This is exploratory/conversational, not a deliverable request. Answer directly. This skill should not engage.

Calibration notes

• Treat brevity as a signal of confidence about what the user wants, not a signal that they want you to do more. The amplification is about giving Claude enough context to hit the target — not expanding the target.
• Inferred roles should be sharp. "Acting as a lawyer" is weak. "Acting as commercial counsel reviewing a landlord-side lease under institutional standards" is strong. The role narrows the output.
• Questions must be load-bearing. If the output would be the same regardless of the answer, the question is filler — drop it.
• Default to fewer questions, not more. If you can reasonably assume something, state the assumption and proceed in the next turn after the user answers what you did ask. Do not ask permission for assumptions.
• Never close with offers. No "want me to also...", "I can additionally...", "should I next...". Avoid trailing offers — they add ceremony without value.

Adapting this skill

This is a generic version. To tailor it to your workflow:

• Sharpen the inferred-role examples in Step 1 to match the domains you actually work in.
• Add your jurisdiction, internal frameworks, or organizational standards to the "Standard to apply" list.
• Adjust the example prompts to mirror the kinds of tasks you typically hand to Claude.
• If your preferred bypass prefix is something other than raw:/go:, change it.