Prompt Clarity Engine

Prompt Clarity Engine

Author: TABARC-Code Repository: https://github.com/TABARC-Code/

Purpose

Language models are not mind readers. A prompt built from vague, all-purpose verbs — ingest, process, understand, improve — feels clear to the human who wrote it, because the human instinctively fills in the missing intent. The model has to guess it instead, and it doesn't always guess well.

This skill takes a rough prompt and rebuilds it around verbs that describe an action a reader could actually observe in the output, so the model has somewhere specific to go rather than a vague direction and a shrug.

Reference file

references/instruction-keyword-taxonomy.md holds the full categorised verb tables (twenty categories, from reading and extraction through to planning and output modifiers), the weak-verb upgrade patterns, and the compound prompt templates. Consult the category that matches the operation you're choosing a verb for — you don't need to read the whole file for every prompt, just the sections relevant to the stages you've identified for this particular one.

Workflow

Step 1 — Read the submitted prompt

Take it at face value first. Don't assume the person wrote it badly on purpose; most vague prompts are vague because the writer knows exactly what they mean and hasn't noticed that the model doesn't share that context.

Step 2 — Diagnose

Check the prompt against the weak-verb list below and against the six questions. A prompt is weak wherever a question has no answer and nothing in the wording implies one.

Common weak verbs and what they're usually standing in for:

The six questions (from the taxonomy's closing principles) — a prompt that can't answer most of these is the one that needs this skill most:

1. What material should be used?
2. What operation should be performed?
3. What must be preserved?
4. What should be excluded?
5. What should the output look like?
6. How should the result be checked?

Step 3 — Reconstruct in instruction order

Rebuild the prompt following this progression. Each stage narrows the next, which is why the order matters more than any individual word choice:

1. Input action — what to inspect (read, review, retrieve, inspect)
2. Reasoning action — what to do with it (analyse, compare, classify, evaluate, synthesise)
3. Transformation action — what to produce (rewrite, consolidate, integrate, design, implement)
4. Constraints — what must survive or stay out (preserve, limit, omit, use only)
5. Output form — how the result should be presented (table, report, JSON, checklist)
6. Validation — how it should be checked (verify, test, audit, cross-check)

Not every prompt needs all six — a one-line factual question doesn't want a validation clause bolted on for the sake of completeness. Include the stages that the original request actually implies, and no more. Matching output complexity to input complexity is part of the job, not an afterthought.

If the request already matches one of the seven worked shapes in the reference file's "Compound prompt patterns" section (research, document review, integration, coding, design, writing, audit), start from that shape rather than building the sequence from scratch — it's already the right order for that kind of task.

Step 4 — Handle genuine ambiguity

If the reconstruction genuinely can't proceed without one specific missing fact — the format is wide open across several very different options, say — ask one targeted question. Otherwise, choose the most reasonable reading, state the assumption in a single line, and go ahead. Don't turn a simple rewrite into an interrogation; most gaps have an obvious best-guess fill.

Step 5 — Present the result

This branches on what Step 4 produced.

If reconstruction completed, present two things, no more:

1. Rewritten prompt — the deliverable itself, ready to paste into a model. This is the point of the exercise, so it comes first and it comes clean — no surrounding commentary embedded in it.
2. What changed — a short list (rarely more than three or four lines) naming the specific weak spots that were fixed: the vague verb that got replaced, the constraint that got added, the output form that got specified. Skip this section entirely for trivial one-line rewrites where there's nothing worth narrating.

If Step 4 instead produced a targeted question, the question itself is the result — don't also force out a guessed rewrite alongside it. Frame it so the person can see what each answer would produce: name the two or three directions the answer would fork the rewrite into (as with the onboarding-email example — open rate versus structure versus call-to-action are three different rewrites, not shades of the same one). Where the environment offers a quick-select input for a single question, prefer it over free text; the question is bounded to a small set of options, so it's a natural fit.

Either way: don't reproduce the full taxonomy or explain the six questions back to the person unless they asked how the method works. The output is the improved prompt (or the one question standing in its way), not a lecture on prompt engineering.

Invocation

The user will either name the skill directly (/prompt-clarity-engine, "use prompt-clarity-engine on this") or describe the need in plain language — "make this prompt more specific", "why isn't the model doing what I want", "turn this into something an LLM will understand". Both trigger the same workflow above.

Related skills

This skill sharpens a single prompt. If the diagnosis reveals the person is solving the same kind of prompt repeatedly — a recurring workflow rather than a one-off ask — that's a skill-builder job, not another rewrite; say so rather than quietly rewriting the same shape a fourth time.

Constraints

• Preserve the original goal and subject matter. This skill sharpens a request; it does not substitute a different one.
• Do not pad a short, already-clear prompt with unnecessary structure for its own sake.
• Where the source prompt is a single simple factual question, a light touch (or no rewrite at all, with a note that it's already clear) is the correct output.
• Keep the voice of the rewritten prompt as an instruction, not as a description of an instruction — write "Analyse the attached transcript for..." not "The user wants the model to analyse...".

Kaizen log

• v1.0.0 — Initial build, drawn directly from the "LLM Instruction Keywords" reference guide (twenty verb categories, the six questions, and the instruction-order progression).
• v1.0.1 — First live run surfaced an undefined output path: Step 4's ambiguity branch had no matching output shape in Step 5. Fixed by branching Step 5 explicitly. Also: wired Step 3 to the reference file's compound patterns (built but previously unreferenced); added an Invocation section and a Related skills handoff note to skill-builder, matching conventions already established elsewhere in the library; corrected an overclaim in description.md about the reference file duplicating the weak-verb table. Flagged, not yet actioned: possible over-triggering on requests for creative (not clarity) prompts — needs eval evidence before a description change, not a guess.