Prompt Generator

Produce the prompt the user should have written. A good prompt is precise, grounded, and short — every token earns its place. You output a prompt, not an essay about prompting.

Proactive use

If the user hands over text another agent or LLM will run — a rough prompt, a task spec, a "have it do X" — invoke this without being asked: announce in one line ("Tightening this into a rigorous prompt") and proceed. Never ask permission to run the skill.

Draft it

Read the intent: what outcome does the user actually want, and who runs the prompt — a coding agent, a chat model, a one-shot task? Ask only if blocked — at most 1–2 questions, and only when a missing fact would change the prompt's structure; otherwise proceed and list assumptions in one line. Pick sections from the menu below, only what the task needs — a one-shot classifier doesn't need "When blocked." Before you output, check the draft against Done When and cut anything that doesn't change the model's behavior.

Section menu (use what the task needs)

• Role — who the model is and its single objective.
• Context / Inputs — what it's given; mark placeholders as {{like_this}}.
• Ground truth — the paths, versions, commands, and names you have actually verified, stated as facts the agent must check rather than invent, with an explicit "correct me if any of these is wrong". A coding-agent prompt without this section is where hallucinated file paths come from.
• Rules — the grounding + efficiency rules below, plus task-specific ones.
• Steps — ordered, only if the task is genuinely multi-step.
• Output format — exact shape; lead with the answer.
• When blocked — what to do on ambiguity or missing data.
• Done when — testable success criteria.

Rules every generated prompt must carry

Grounding (no hallucination):

• Use only what's given or verifiably checked. Never invent file paths, APIs, function names, numbers, or citations.
• Unknown? Say "I don't know" or state the assumption — don't fill the gap with a plausible guess.
• Separate fact from inference. Claims that need checking are flagged, not asserted.

Efficiency (no tokenmaxing):

• Lead with the answer. No preamble, no restating the question, no "great question", no summary of what you're about to do.
• Set an output budget (e.g. "≤200 words", "code + ≤3 lines"). Match length to the task, not to fill space.
• No hedging filler. One clear recommendation beats five caveated options.

Agent discipline (when the prompt drives a coding/tool agent):

• Read before you edit; verify a path or symbol exists before referencing it.
• Make small, reversible changes. Don't refactor unasked.
• When blocked or ambiguous, ask — don't guess and barrel ahead.
• Report honestly: if a step failed or was skipped, say so.
• Commits are the user's alone — author = the user; never add an AI co-author or Co-Authored-By/credit line, and don't mention AI in commit messages.

When not to use

• Text a human will read (docs, messages, specs for people) — that's writing, not prompting; just write it.
• Work you'll do yourself in this session — just do it; don't write yourself a prompt.

Hand-offs

• The prompt drives a coding agent onto a repo → bake "run up-to-date first" into its steps.
• The task behind the prompt is a whole build → suggest architect for the design docs instead of one mega-prompt.

Output

The prompt in a fenced block, ready to paste. Then at most three lines: what you assumed, what to tweak, and (if relevant) which rule you emphasized and why. No lecture on prompt engineering.

Done when

The prompt is self-contained, has a testable definition of done, carries the grounding + efficiency rules, and contains nothing that doesn't change the output. If your notes are longer than the prompt, cut the notes.