$npx -y skills add girijashankarj/cursor-handbook --skill prompt-engineeringCraft effective prompts and instructions for AI coding assistants. Use when creating rules, agents, skills, or system prompts for Cursor or other LLM-based tools.
| 1 | # Skill: Prompt Engineering |
| 2 | |
| 3 | ## Trigger |
| 4 | When the user needs to write, improve, or review prompts, system instructions, agent definitions, Cursor rules, or any text intended to guide AI behavior. |
| 5 | |
| 6 | ## Steps |
| 7 | |
| 8 | 1. **Clarify the goal** — Identify what the prompt should make the AI do (generate code, review, explain, follow a pattern). |
| 9 | 2. **Define the persona** — Specify the role, expertise level, and constraints (e.g. "You are a senior backend engineer specializing in Node.js"). |
| 10 | 3. **Structure the prompt** — Organize with clear sections: |
| 11 | - **Context**: Background the AI needs |
| 12 | - **Instructions**: What to do (use imperative mood) |
| 13 | - **Constraints**: What NOT to do (use NEVER/ALWAYS for hard rules) |
| 14 | - **Output format**: Expected shape of the response (code, bullet points, table) |
| 15 | - **Examples**: One good and one bad example when possible |
| 16 | 4. **Apply prompt patterns** — Use established techniques: |
| 17 | - **Few-shot**: Provide 2–3 examples of desired input/output |
| 18 | - **Chain of thought**: Ask the AI to think step-by-step for complex reasoning |
| 19 | - **Negative constraints**: Explicitly state anti-patterns to avoid |
| 20 | - **Structured output**: Specify exact format (JSON, markdown, code block) |
| 21 | 5. **Review and iterate** — Test the prompt; refine based on output quality. |
| 22 | |
| 23 | ## Rules |
| 24 | - Use imperative mood for instructions ("Use X", "Never do Y") |
| 25 | - Bold critical constraints: **ALWAYS**, **NEVER**, **CRITICAL** |
| 26 | - Keep instructions atomic — one rule per bullet point |
| 27 | - Order from most important to least important |
| 28 | - Use tables for structured data (comparisons, configurations) |
| 29 | - Include escape hatches: what to do when the instruction doesn't apply |
| 30 | - Avoid vague language ("try to", "maybe", "consider") — be decisive |
| 31 | - Test with edge cases: what happens if the user asks something unexpected? |
| 32 | |
| 33 | ## Prompt Quality Checklist |
| 34 | - [ ] Clear role/persona defined |
| 35 | - [ ] Specific, actionable instructions (not vague guidance) |
| 36 | - [ ] Hard constraints marked with ALWAYS/NEVER |
| 37 | - [ ] Output format specified |
| 38 | - [ ] At least one example (good or bad) |
| 39 | - [ ] Edge cases addressed |
| 40 | - [ ] No conflicting instructions |
| 41 | - [ ] Concise — removes filler without losing meaning |
| 42 | |
| 43 | ## Anti-patterns |
| 44 | - Walls of text without structure — use headers and bullet points |
| 45 | - Conflicting rules (e.g. "be concise" AND "explain everything in detail") |
| 46 | - Too many rules — prioritize; AI follows top rules more reliably |
| 47 | - Vague instructions: "write good code" vs "use TypeScript strict mode, define interfaces for all inputs" |
| 48 | - Missing context: assuming the AI knows your project without telling it |
| 49 | |
| 50 | ## Prerequisites |
| 51 | - [ ] Clear understanding of the desired AI behavior |
| 52 | - [ ] Knowledge of the target audience (developer, reviewer, end user) |
| 53 | - [ ] Examples of good and bad outputs |
| 54 | |
| 55 | ## Completion Checklist |
| 56 | - [ ] Prompt has clear structure (context, instructions, constraints, format) |
| 57 | - [ ] Critical rules use ALWAYS/NEVER |
| 58 | - [ ] Tested with at least one real scenario |
| 59 | - [ ] No conflicting instructions |
| 60 | - [ ] Concise (< 500 words for rules, < 1000 words for agents) |
| 61 | |
| 62 | ## If Step Fails |
| 63 | - **AI ignores a rule**: Move it higher in the prompt; bold it; add "CRITICAL" |
| 64 | - **Output is wrong format**: Add an explicit example of the expected format |
| 65 | - **AI hallucinates**: Add "Only use information from the provided context" |
| 66 | - **Too verbose**: Add "Keep responses under N sentences/lines" |
| 67 | - **Too terse**: Add "Explain your reasoning" or "Include code examples" |
| 68 | |
| 69 | ## Example |
| 70 | Task: Create a Cursor rule for error handling. |
| 71 | 1. Persona: "You are a backend engineer ensuring consistent error handling." |
| 72 | 2. Structure: Section for error classes, section for HTTP mapping, section for logging. |
| 73 | 3. Constraints: "NEVER expose stack traces to API consumers", "ALWAYS include correlationId". |
| 74 | 4. Format: `.mdc` file with YAML frontmatter, markdown body. |
| 75 | 5. Test: Apply to a sample handler and verify output matches expectations. |