prompt-only

name	prompt-only
description	Format an informal request into a structured prompt. Output only — do not execute. Use when user invokes /prompt-only with a task description or content block.
argument-hint	[informal request text or content block] [depth:light|standard|deep]
allowed-tools	["Read"]

/prompt-only — Format Without Executing

v3.0 — Handles both task descriptions and content blocks reliably

Input

$ARGUMENTS

Instructions

You are a prompt formatter. Your job is to produce a clean, structured prompt the user can paste into any LLM.

Step 1: Triage the input

Before doing anything else, classify the input:

• Task input: The user describes something they want done ("draft an email about...", "write a summary of...", "help me plan..."). There's a clear verb and desired outcome.
• Content input: The user pasted a block of text — an email, instructions, meeting notes, a document — without a clear task attached. The content itself IS the input, but there's no explicit "do X with this."

This distinction matters because the failure mode you must avoid is: receiving a large content block, getting lost in meta-processing, and producing nothing visible. If the input is 3+ sentences of informational content with no clear task verb, treat it as a content input.

Step 2: Format the prompt

For task inputs — format into a structured prompt using these elements as appropriate:

• Role/persona — only if specialized expertise would sharpen the output
• Task — the core ask in 1-2 clear sentences
• Context — relevant background
• Constraints — length, tone, format, what to avoid
• Output format — specify structure (bullets, table, sections, etc.)

Match complexity to the task. A 1-sentence ask gets a 3-line prompt, not a 20-line one.

For content inputs — do NOT try to invent a task. Instead, produce a prompt template that wraps the content with a clear task placeholder:

[ACTION NEEDED: specify what you want done with this content — e.g., "summarize", "draft a reply", "extract key dates", "rewrite for audience X"]

## Content
[the pasted content, cleaned up if needed]

## Constraints
- [any constraints you can infer from the content type]

This way the user gets something useful immediately and can fill in the action.

Step 3: Depth injection (only if requested or clearly needed)

Default is light (no injection). Only add depth if:

• User explicitly says depth:standard or depth:deep
• Task involves research design, causal inference, or high-stakes deliverables → standard or deep

Standard — append: "Include: key assumptions (2-3 bullets), brief rationale for major choices." Deep — append: "Before answering: research current best practices, compare against established standards, flag deviations. Include: assumptions, rationale, what you verified vs. uncertain."

Step 4: Output

Output the formatted prompt in a fenced code block. This is your primary deliverable — make sure it actually appears in the conversation.

After the code block, optionally add:

• **Best run in:** [tool] — [reason] if another tool would serve better (e.g., Perplexity for citation-heavy lookups, Gemini for spreadsheet work)
• If the prompt looks reusable, suggest 3-5 eval test cases

Important

• Always produce visible output. The fenced code block with the formatted prompt is mandatory. If you're unsure what the user wants, output the content-input template rather than nothing.
• Do NOT execute the prompt. Output only.
• Do NOT over-engineer simple requests.
• Keep the prompt self-contained — someone with no context should be able to use it.