agentleFS
Sign inStart free
witi-projectswiti-projects/Skills/prompt-engineering/SKILL.md

prompt-engineering

Skill2 starsChanged 6 months agoMITView on GitHub

Write effective prompts for LLMs — structure, few-shot examples, chain-of-thought, system prompts, and output parsing. Use when the user says "/prompt-engineering", "prompt engineering", or asks about prompt engineering.

We split this skill into the rules it gives an agent

4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 70 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write prompts that get reliable, high-quality output from LLMs.

    line 9
  2. Distinctive:

    Ask the model to reason step by step:

    line 61
  3. Distinctive:

    Test prompts with edge cases, not just the happy path

    line 135
  4. Distinctive:

    Use structured output (JSON) when parsing the response programmatically

    line 137

“Common” is measured: kept by at least 6 in 10 of the 70 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Prompt Engineering

Write prompts that get reliable, high-quality output from LLMs.

Core Principles

  1. Be specific — vague prompts get vague results
  2. Show, don't tell — examples beat instructions
  3. Structure the output — tell the model exactly what format you want
  4. Iterate — prompts are code; test and refine them

Techniques

System Prompts

Set the model's role and constraints:

You are a senior code reviewer. Review the provided code for:
1. Security vulnerabilities
2. Performance issues
3. Readability problems

For each issue found, provide:
- Severity (critical/warning/info)
- Line number
- Description
- Suggested fix

If no issues are found, respond with "No issues found."

Few-Shot Examples

Provide 2-3 examples of input → output:

Convert the user's natural language query to a SQL query.

Example 1:
Input: "How many users signed up last month?"
Output: SELECT COUNT(*) FROM users WHERE created_at >= DATE_TRUNC('month', NOW() - INTERVAL '1 month') AND created_at < DATE_TRUNC('month', NOW());

Example 2:
Input: "Show me the top 5 products by revenue"
Output: SELECT p.name, SUM(o.amount) as revenue FROM products p JOIN orders o ON o.product_id = p.id GROUP BY p.name ORDER BY revenue DESC LIMIT 5;

Now convert this query:
Input: "{user_query}"
Output:

Chain-of-Thought

Ask the model to reason step by step:

Analyze this error and suggest a fix. Think step by step:
1. What does the error message mean?
2. What could cause this error?
3. What is the most likely root cause given the code context?
4. What is the fix?

Structured Output

Request JSON or a specific format:

Respond with a JSON object matching this schema:
{
  "summary": "string - one sentence summary",
  "sentiment": "positive | negative | neutral",
  "key_topics": ["string"],
  "confidence": 0.0-1.0
}

Constraints and Guardrails

Rules:
- Only use information from the provided context
- If you don't know the answer, say "I don't know" — do not guess
- Keep responses under 200 words
- Do not include any PII in your response

Patterns for Code

Code generation:

Write a TypeScript function that {description}.

Requirements:
- {requirement 1}
- {requirement 2}

Use these libraries: {libraries}
Follow this pattern from the codebase: {example}

Code transformation:

Refactor this code to {goal}. Keep the same behavior.
Do not change the public API (function signatures, exports).

Bug fixing:

This code has a bug: {description of bug}

Error: {error message}

Fix the bug. Explain what caused it in a comment.

Anti-Patterns

  • Too vague: "Make this better" → Be specific about what "better" means
  • Too long: Giant prompts with everything → Split into focused prompts
  • Contradictory: "Be concise but thorough" → Pick one or define the tradeoff
  • No examples: Complex formatting without showing what you want → Add 1-2 examples
  • Prompt injection risk: Including raw user input without delimiting → Use clear delimiters like <user_input>...</user_input>

Tips

  • Temperature 0 for deterministic tasks (code, classification), 0.7+ for creative tasks
  • Test prompts with edge cases, not just the happy path
  • Version control your prompts — they're as important as code
  • Use structured output (JSON) when parsing the response programmatically
  • Shorter prompts often outperform longer ones if they're precise enough

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free