Prompt engineering
Skill Amey-Thakur/AI-SKILLS/skills/llm-engineering/prompt-engineering
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill prompt-engineeringAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 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.
What its author says it does
Copied from the file, not written here
Build prompts that get accurate, reliably-shaped output from any LLM, choosing the right technique for the task. Use when writing, improving, or debugging a prompt.
SKILL.md
2.8 KB, as published. Nobody here has run it
Prompt engineering
A prompt is a specification. Vague specs get confident garbage; the fix is almost never "more words", it is the right words in the right structure.
Method
- Write the success criteria first. What does a correct output contain, in what shape, and what would make it wrong? If you cannot check an output, you cannot prompt for it.
- Pick the technique for the task type:
- Classification / extraction → 2–5 worked examples (few-shot) showing input → exact expected output, including one tricky case. Examples teach format and edge handling better than any description.
- Reasoning / math / multi-step → instruct step-by-step thinking before the answer, and separate the reasoning from the final answer so it can be parsed.
- Creative / stylistic → role and audience ("you are a…, writing for…"), two or three constraints that define the voice, and one example of the tone if you have it. Constraints beat adjectives.
- Structured output → show the exact schema with a filled example.
State what to do when a field is unknown (empty string?
null? omit?) or the model will invent.
- Structure the prompt in blocks, clearly delimited: role/context →
task → rules → examples → the input (fenced or tagged, e.g.
<document>…</document>) → output format. Data always arrives below instructions and marked as data, so instructions embedded in the data stay data. - Turn unknowns into named variables.
{audience},{tone},{max_length}: never invent a specific the user did not give. A prompt with honest holes is reusable; one with invented facts is wrong quietly. - State the negative space. What to do when the input is empty, contradictory, or outside scope ("say 'not found', do not guess"): the unhandled edge is where hallucination lives.
- Test on the ugly cases, then tighten. Run the empty input, the ambiguous one, the adversarial one. Every failure becomes either a rule or an example. Prompts are debugged, not authored.
Settings guidance
Temperature ~0–0.3 for extraction, classification, and code; ~0.7+ for divergent creative work. When output must parse, say so and set the format and the temperature: one without the other fails intermittently, which is worse than always.
Boundaries
No prompt fixes a task the model lacks the context or capability for , missing information is fetched or asked for, not conjured. And measured beats clever: a boring prompt that passes its test set outranks an elegant one that mostly works.