Prompt generator
Turns a vague ask into a rigorous, grounded, token-efficient prompt: role + objective, testable done criteria, anti-hallucination (verify or say "I don't know"), anti-tokenmaxing (lead with the answer, output budget), strict agent discipline. Use proactively when the user hands over a prompt or task spec destined for another agent or LLM. Also on "write a prompt", "improve this prompt", "prompt for an agent". Not for human-facing prose or work you'll execute yourself this session.From its SKILL.md
npx -y skills add alonbaron/claude-skills --skill prompt-generatorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.5 KB, as published. Nobody here has run it
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.
Process
- 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.
- Draft using the section menu — include only the sections the task needs (a one-shot classifier doesn't need "When blocked").
- Self-check against the rubric below. Cut anything that doesn't change the model's behavior.
- Output the finished prompt in a fenced block, then ≤3 lines on key choices and what to tune.
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.
- 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-datefirst" into its steps. - The task behind the prompt is a whole build → suggest
architectfor 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.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most docs writing skills give
Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06
- Use third-person for skill descriptionsin 54 of 1951, across 35 files
- Start descriptions with Use whenin 43 of 1951, across 29 files
- Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
- Use active voicein 40 of 1951, across 36 files
- Map file responsibilities before defining tasksin 36 of 1951, across 29 files
- Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
- Ask one question at a timein 35 of 1951
- Offer execution options after saving the planin 33 of 1951, across 24 files
- Include complete code in every stepin 33 of 1951, across 27 files
- Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
- Announce the skill usage at the startin 30 of 1951
- Verify agent compliance after adding the skillin 29 of 1951, across 17 files
Said here and by no other author read
- Draft prompt using required sections
- Self-check prompt against rubric
- List assumptions in one line
- Include testable success criteria
- Set an output budget
- Flag claims that need checking
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.