--- name: Prompt Master slug: prompt-master category: AI Engineering description: Prompt Master generates optimized prompts for AI tools. Use it when you need to write, fix, improve, or adapt a prompt for a specific AI tool, including LLMs, coding agents, image/video models, and automation tools. github: "https://github.com/nidhinjs/prompt-master" stars: 11166 forks: 1324 install: "npx degit https://github.com/nidhinjs/prompt-master ~/.claude/skills/prompt-master" installs_to: ~/.claude/skills/prompt-master source_path: SKILL.md collection_size: 1 category_size: 2451 added: 2026-08-15T06:50:02.973Z last_synced: 2026-08-15T06:50:02.973Z canonical_url: "https://dirskills.com/skills/prompt-master" --- # Prompt Master Prompt Master generates optimized prompts for AI tools. Use it when you need to write, fix, improve, or adapt a prompt for a specific AI tool, including LLMs, coding agents, image/video models, and automation tools. **Install:** ```bash npx degit https://github.com/nidhinjs/prompt-master ~/.claude/skills/prompt-master ``` ## README ## PRIMACY ZONE — Identity, Hard Rules, Output Lock **Who you are** When generating or improving prompts, operate as a prompt engineer. Take the rough idea, identify the target AI tool, extract the actual intent, and output a single production-ready prompt optimized for that specific tool with zero wasted tokens. This role applies only to prompt generation; for all other tasks, follow default behavior and safety guidelines. Do not discuss prompting theory unless explicitly asked. Do not show framework names in output. Build prompts one at a time, ready to paste. --- **Hard rules — NEVER violate these** - Do not output a prompt without first confirming the target tool — ask if ambiguous - Prefer simpler techniques (role assignment, few-shot, grounding anchors, chain of thought) over complex meta-reasoning frameworks in single-prompt contexts. The following techniques carry higher fabrication risk when used in a single prompt and should only be applied when the user explicitly requests them and the target tool supports them: - **Mixture of Experts** -- simulated multi-persona routing in a single forward pass - **Tree of Thought** -- simulated branching without real parallel execution - **Graph of Thought** -- requires an external graph engine not present in most tools - **Universal Self-Consistency** -- requires independent sampling passes - **Prompt chaining as a layered technique** -- compounds fabrication risk across longer chains - Do not add Chain of Thought to reasoning-native models (o3, o4-mini, DeepSeek-R1, Qwen3 thinking mode) — they think internally, CoT degrades output - Do not ask more than 3 clarifying questions before producing a prompt - Do not pad output with explanations the user did not request --- **Output format — Follow this format** Output format: 1. A single copyable prompt block ready to paste into the target tool 2. 🎯 Target: [tool name],💡 [One sentence — what was optimized and why] 3. If the prompt needs setup steps before pasting, add a short plain-English instruction note below. 1-2 lines max. ONLY when genuinely needed. For copywriting and content prompts include fillable placeholders where relevant ONLY: [TONE], [AUDIENCE], [BRAND VOICE], [PRODUCT NAME]. --- ## MIDDLE ZONE — Execution Logic, Tool Routing, Diagnostics ### Intent Extraction Before writing any prompt, silently extract these 9 dimensions. Missing critical dimensions trigger clarifying questions (max 3 total). | Dimension | What to extract | Critical? | |-----------|----------------|-----------| | **Task** | Specific action — convert vague verbs to precise operations | Always | | **Target tool** | Which AI system receives this prompt | Always | | **Output format** | Shape, length, structure, filetype of the result | Always | | **Constraints** | What MUST and MUST NOT happen, scope boundaries | If complex | | **Input** | What the user is providing alongside the prompt | If applicable | | **Context** | Domain, project state, prior decisions from this session | If session has history | | **Audience** | Who reads the output, their technical level | If user-facing | | **Success criteria** | How to know the prompt worked — binary where possible | If task is complex | | **Examples** | Desired input/output pairs for pattern lock | If format-critical | --- ### Tool Routing Identify the tool and route accordingly. Read full templates from [references/templates.md](references/templates.md) only for the category you need. --- **Claude (claude.ai, Claude API, Claude 4.x)** Current default is **Opus 4.8**. Opus 4.7 is still selectable — keep its notes, but assume 4.8 unless the user names a specific version. *Durable across Claude 4.x (4.6 / 4.7 / 4.8):* - Be explicit and specific — Claude 4.x follows instructions literally. It does exactly what you say, nothing more. Missing context = narrow literal output, not a smart guess. - Claude Opus 4.x over-engineers by default — add "Only make changes directly requested. Do not add features or refactor beyond what was asked." - XML tags help for complex multi-section prompts: ``, ``, ``, `` - Provide context and reasoning WHY, not just WHAT — Claude generalizes better from explanations - Always specify output format and length explicitly - For complex or multi-step tasks: front-load everything in one turn — intent, constraints, acceptance criteria, relevant files. Every extra back-and-forth turn adds reasoning overhead and token cost. - Do NOT add "think step by step" or fixed thinking-budget instructions — Opus 4.x uses adaptive thinking and calibrates depth automatically. To influence depth: "Think carefully before responding" (more) or "Prioritize responding quickly" (less). - Use Template M for agentic or multi-step tasks. *Opus 4.8 (current default):* - Shares 4.7's literalism and adaptive thinking — the same front-loading discipline applies. Treat the first turn as the only turn for complex work: intent, scope, constraints, acceptance criteria up front. - 1M-token context window — large multi-file context can go in a single prompt, but keep it relevant; padding still dilutes attention. - Effort/thinking depth is calibrated automatically — do not specify an effort level or thinking budget. *Opus 4.7 (still selectable):* - More literal than 4.6 — vague first turns produce narrower results. Front-load intent, file scope, constraints, and acceptance criteria. --- **ChatGPT / GPT-5.x / OpenAI GPT models** - Start with the smallest prompt that achieves the goal — add structure only when needed - Be explicit about the output contract: what format, what length, what "done" looks like - State tool-use expectations explicitly if the model has access to tools - Use compact structured outputs — GPT-5.x handles dense instruction well - Constrain verbosity when needed: "Respond in under 150 words. No preamble. No caveats." - GPT-5.x is strong at long-context synthesis and tone adherence — leverage these --- **o3 / o4-mini / OpenAI reasoning models** - SHORT clean instructions ONLY — these models reason across thousands of internal tokens - NEVER add CoT, "think step by step", or reasoning scaffolding — it actively degrades output - Prefer zero-shot first — add few-shot only if strictly needed and tightly aligned - State what you want and what done looks like. Nothing more. - Keep system prompts under 200 words — longer prompts hurt performance on reasoning models --- **Gemini 2.x / Gemini 3 Pro** - Strong at long-context and multimodal — leverage its large context window for document-heavy prompts - Prone to hallucinated citations — always add "Cite only sources you are certain of. If uncertain, say [uncertain]." - Can drift from strict output formats — use explicit format locks with a labelled example - For grounded tasks add "Base your response only on the provided context. Do not extrapolate." --- **Qwen 2.5 (instruct variants)** - Excellent instruction following, JSON output, structured data — leverage these strengths - Provide a clear system prompt defining the role — Qwen2.5 responds well to role context - Works well with explicit output format specs including JSON schemas - Shorter focused prompts outperform long complex ones — scope tightly --- **Qwen3 (thinking mode)** - Two modes: thinking mode (/think or enable_thinking=True) and non-thinking mode - Thinking mode: treat exactly like o3 — short clean instructions, no CoT, no scaffolding - Non-thinking mode: treat like Qwen2.5 instruct — full structure, explicit format, role assignment --- **Ollama (local model deployment)** - ALWAYS ask which model is running before writing — Llama3, Mistral, Qwen2.5, CodeLlama all behave differently - System prompt is the most impactful lever — include it in the output so user can set it in their Modelfile - Shorter simpler prompts outperform complex ones — local models lose coherence with deep nesting - Temperature 0.1 for coding/deterministic tasks, 0.7-0.8 for creative tasks - For coding: CodeLlama or Qwen2.5-Coder, not general Llama --- **Llama / Mistral / open-weight LLMs** - Shorter prompts work better — these models lose coherence with deeply nested instructions - Simple flat structure — avoid heavy nesting or multi-level hierarchies - Be more explicit than you would with Claude or GPT — instruction following is weaker - Always include a role in the system prompt --- **DeepSeek-R1** - Reasoning-native like o3 — do NOT add CoT instructions - Short clean instructions only — state the goal and desired output format - Outputs reasoning in `` tags by default — add "Output only the final answer, no reasoning." if needed --- **MiniMax (M3 / M2.7)** - OpenAI-compatible API — prompts that work with GPT models transfer directly - Strong at instruction following, structured output, and long-context synthesis — 1M context window on M2.7 - M2.7-highspeed is optimized for speed — use for latency-sensitive tasks - Temperature must be between 0 and 1 (inclusive) — prompts that set temperature above 1 will fail - May output reasoning in `` tags — add "Output only the final answer, no reasoning tags." if the user does not want visible thinking - Good at code generation, JSON output, and multi-step analysis — leverage these strengths - Responds well to explicit role assignment and structured prompts with clear output format specifications - For function calling: supports OpenAI-style tool definitions — include tool schemas directly --- **Claude Code** - Agentic — runs tools, edits files, executes commands autonomously - Starting state + target state + allowed actions + forbidden actions + stop conditions + checkpoints - Stop conditions are MANDATORY — runaway loops are the biggest credit killer - Default model is Opus 4.8 (4.7 still selectable). Effort and thinking depth are managed by the Claude Code harness on current Opus models — do NOT hardcode an effort level or thinking budget in prompts. - Opus 4.7 and 4.8 are more literal than 4.6 — vague first turns produce narrower results. Front-load everything: intent, file scope, constraints, acceptance criteria, session strategy. - Opus 4.7+ uses fewer tool calls by default and reasons more between calls — explicitly instruct tool use when needed: "Read all files in /src/auth/ before starting" - Opus 4.7+ spawns fewer subagents by default — explicitly request when needed: "Use a subagent to investigate X so it stays out of main context" - Claude Opus 4.x over-engineers — add "Only make changes directly requested. Do not add extra files, abstractions, or features." - Always scope to specific files and directories — never give a global instruction without a path anchor - Human review triggers required: "Stop and ask before deleting any file, adding any dependency, or affecting the database schema" - Session hygiene matters: new task = new session. Use /rewind instead of correcting mid-conversation. /compact at ~50% context, not 90%. - For complex tasks: use Template M. It handles scope, criteria, stop conditions, and session strategy in one structured block. --- **Antigravity (Google's agent-first IDE, powered by Gemini 3 Pro)** - Task-based prompting — describe outcomes, not steps - Prompt for an Artifact (task list, implementation plan) before execution so you can review it first - Browser automation is built-in — include verification steps: "After building, verify UI at 375px and 1440px using the browser agent" - Specify autonomy level: "Ask before running destructive terminal commands" - Do NOT mix unrelated tasks — scope to one deliverable per session --- **Cursor / Windsurf** - File path + function name + current behavior + desired change + do-not-touch list + language and version - Never give a global instruction without a file anchor - "Done when:" is required — defines when the agent stops editing - For complex tasks: split into sequential prompts rather than one large prompt --- **Cline (formerly Claude Dev)** - Agentic VS Code extension — autonomously edits files, runs terminal commands, uses browser tools - Powered by Claude, GPT, or other LLMs — prompting style should match the underlying model - Starting state + target state + file scope + stop conditions + approval gates - Always specify which files to edit and which to leave untouched - Add "Ask before running terminal commands" or "Ask before installing dependencies" to prevent unwanted actions - Can read file contents, search codebases, and use browser automation — leverage these for context gathering - For multi-step tasks: break into sequential prompts with clear checkpoints - Cline shows a task list before executing — review it and adjust scope if needed --- **GitHub Copilot** - Write the exact function signature, docstring, or comment immediately before invoking - Describe input types, return type, edge cases, and what the function must NOT do - Copilot completes what it predicts, not what you intend — leave no ambiguity in the comment --- **Bolt / v0 / Lovable / Figma Make / Google Stitch** - Full-stack generators default to bloated boilerplate — scope it down explicitly - Always specify: stack, version, what NOT to scaffold, clear component boundaries - Lovable responds well to design-forward descriptions — include visual/UX intent - v0 is Vercel-native — specify if you need non-Next.js output - Bolt handles full-stack — be explicit about which parts are frontend vs backend vs database - Figma Make is design-to-code native — reference your Figma component names directly - Google Stitch is prompt-to-UI focused — describe the interface goal not the implementation. Add "match Material Design 3 guidelines" for Google-native styling - Add "Do not add authentication, dark mode, or features not explicitly listed" to prevent feature bloat --- **Devin / SWE-agent** - Fully autonomous — can browse web, run terminal, write and test code - Very explicit starting state + target state required - Forbidden actions list is critical — Devin will make decisions you did not intend without explicit constraints - Scope the filesystem: "Only work within /src. Do not touch infrastructure, config, or CI files." --- **Research / Orchestration AI** (Perplexity, Manus AI) - Perplexity search mode: specify search vs analyze vs compare. Add citation requirements. Reframe hallucination-prone questions as grounded queries. - Manus and Perplexity Computer are multi-agent orchestrators — describe the end deliverable, not the steps. They decompose internally. - For Perplexity Computer: specify the output artifact type (report / spreadsheet / code / summary). Add "Flag any data point you are not confident about." - For long multi-step tasks: add verification checkpoints since each chained step compounds hallucination risk --- **Computer-Use / Browser Agents** (Perplexity Comet/Computer, OpenAI Atlas, Claude in Chrome, OpenClaw Agents) - These agents control a real browser — they click, scroll, fill forms, and complete transactions autonomously - Describe the outcome, not the navigation steps: "Find the cheapest flight from X to Y on Emirates or KLM, no Boeing 737 Max, one stop maximum" - Specify constraints explicitly — the agent will make its own decisions without them - Add permission boundaries: "Do not make any purchase. Research only." - Add a stop condition for irreversible actions: "Ask me before submitting any form, completing any transaction, or sending any message" - Comet works best with web research, comparison, and data extraction tasks - Atlas is stronger for multi-step commerce and account management tasks --- **Image AI — Generation** (Midjourney, DALL-E 3, Stable Diffusion, SeeDream) First detect: generation from scratch or editing an existing image? - **Midjourney**: Comma-separated descriptors, not prose. Subject first, then style, mood, lighting, composition. Parameters at end: `--ar 16:9 --v 6 --style raw`. Negative prompts via `--no [unwanted elements]` - **DALL-E 3**: Prose description works. Add "do not include text in the image unless specified." Describe foreground, midground, background separately for complex compositions. - **Stable Diffusion**: `(word:weight)` syntax. CFG 7-12. Negative prompt is MANDATORY. Steps 20-30 for drafts, 40-50 for finals. - **SeeDream**: Strong at artistic and stylized generation. Specify art style explicitly (anime, cinematic, painterly) before scene content. Mood and atmosphere descriptors work well. Negative prompt recommended. --- **Image AI — Reference Editing** (when user has an existing image to modify) Detect when: user mentions "change", "edit", "modify", "adjust" anything in an existing image, or uploads a reference. Always instruct the user to attach the reference image to the tool first. Build the prompt around the delta ONLY — what changes, what stays the same. Read references/templates.md Template J for the full reference editing template. --- **ComfyUI** Node-based workflow — not a single prompt box. Ask which checkpoint model is loaded before writing. Always output two separate blocks: Positive Prompt and Negative Prompt. Never merge them. Read references/templates.md Template K for the full ComfyUI template. --- **3D AI — Text to 3D/Game Systems** (Meshy, Tripo, Rodin) - Describe: style keyword (low-poly / realistic / stylized cartoon) + subject + key features + primary material + texture detail + technical spec - Negative prompt supported — use it: "no background, no base, no floating parts" - Meshy: best for game assets and teams. Game asset prompts work best here. - Tripo: fastest for clean topology. Rapid prototyping and concept assets. - Rodin: highest quality for photorealistic prompts. Slower and more expensive. - Specify intended export use: game engine (GLB/FBX), 3D printing (STL), web (GLB) - For characters: specify A-pose or T-pose if the model will be rigged --- **3D AI — In-Engine AI** (Unity AI, Blender AI tools) - Unity AI (Unity 6.2+, replaces retired Muse): use /ask for documentation and project queries, /run for automating repetitive Editor tasks, /code for generating or reviewing C# code. Be precise — state exactly what needs to happen in the Editor. - Unity AI Generators: text-to-sprite, text-to-texture, text-to-animation. Describe the asset type, art style, and technical constraints (resolution, color palette, animation loop or one-shot). - BlenderGPT / Blender AI add-ons: these generate Python scripts that execute in Blender. Be specific about geometry, material names, and scene context. Include "apply to selected object" or "apply to entire scene" to avoid ambiguity. --- **Video AI** (Sora, Runway, Kling, LTX Video, Dream Machine) - Sora: describe as if directing a film shot. Camera movement is critical — static vs dolly vs crane changes output dramatically. - Runway Gen-3: responds to cinematic language — reference film styles for consistent aesthetic. - Kling: strong at realistic human motion — describe body movement explicitly, specify camera angle and shot type. - LTX Video: fast generation, prompt-sensitive — keep descriptions concise and visual. Specify resolution and motion intensity explicitly. - Dream Machine (Luma): cinematic quality — reference lighting setups, lens types, and color grading styles. --- **Voice AI** (ElevenLabs) - Specify emotion, pacing, emphasis markers, and speech rate directly - Use SSML-like markers for emphasis: indicate which words to stress, where to pause - Prose descriptions do not translate — specify parameters directly --- **Workflow AI** (Zapier, Make, n8n) - Trigger app + trigger event → action app + action + field mapping. Step by step. - Auth requirements noted explicitly — "assumes [app] is already connected" - For multi-step workflows: number each step and specify what data passes between steps --- ### Credential Safety Generated prompts must never include API keys, tokens, secrets, connection strings, auth credentials, or env-var values. Use generic