Skip to main content

prompt-master

Generates optimized prompts for AI tools. Activates only when the user explicitly asks to write, fix, improve, or adapt a prompt for a specific AI tool (LLM, Cursor, Midjourney, image AI, video AI, coding agents, etc.). Does not activate for general conversation, coding tasks, document writing, or other non-prompt-engineering work.

Source facts

Repository
nidhinjs/prompt-master
Last source activity
October 22, 2026 at 13:26
Detected SKILL.md language
English
Stars
15,066
Forks
1,745

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
prompt-master
version
1.8.2
description
Generates optimized prompts for AI tools. Activates only when the user explicitly asks to write, fix, improve, or adapt a prompt for a specific AI tool (LLM, Cursor, Midjourney, image AI, video AI, coding agents, etc.). Does not activate for general conversation, coding tasks, document writing, or other non-prompt-engineering work.
## 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 examples, grounding anchors, and explicit verification criteria) 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 - Never request hidden chain-of-thought, private reasoning, or a verbatim reasoning trace from any model. Ask for conclusions, assumptions, evidence, concise rationale, and verification results instead. - 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. ### Model Recency Gate Model names, defaults, controls, and availability change quickly. When the user asks for the "latest" model, names a model not covered below, or needs exact API settings: 1. Verify the current model and supported controls in the provider's official documentation when browsing or retrieval is available. 2. Distinguish the consumer product from the API or coding-agent surface; the same model family may expose different picker options, tools, and parameters. 3. Prefer stable family-level prompting guidance over brittle claims about defaults. 4. If current documentation cannot be checked, say that model-specific details are unverified and use the closest durable route. Never invent a model slug, context size, parameter, or product capability. --- **Claude (claude.ai, Claude API, Claude 5.x / current Claude models)** Do not assume one universal Claude default. When unsure, start with the **Opus 5** family for complex agentic coding and enterprise work, **Fable 5** for the highest-capability long-running agents, **Sonnet 5** for speed plus frontier intelligence, and **Haiku** for fast, economical workloads. Ask which model only when the distinction changes the prompt. Always verify the current model slug against official Anthropic documentation — version numbers change frequently. *Durable across current Claude models:* - Be clear and direct. State the desired output, constraints, and scope explicitly; explain why when the reason affects judgment. - Use XML tags such as `<context>`, `<task>`, `<constraints>`, and `<output_format>` for complex mixed-content prompts; use a few relevant, diverse examples when format or tone must be locked. - For long context, put source documents before the query and wrap documents plus metadata in descriptive XML tags. - Prefer positive instructions that describe the desired result over long lists of prohibitions. - Do not request hidden reasoning or reproduce thinking. Ask for a concise rationale, evidence, and verification results. - Current Claude 5 models use adaptive thinking and an effort control. Do not hardcode manual thinking budgets; recommend an effort level only when the user controls API or harness settings. - Use Template M for complex or agentic tasks. *Fable 5.1 (and Fable 5):* - Fable 5.1 is optimized for the hardest long-horizon autonomous work. Give it a complete outcome-focused specification, explicit action boundaries, and infrastructure suitable for long asynchronous runs. - Ground every long-run progress claim in actual tool results. Delegate independent workstreams to subagents when useful and establish interval-based verification for long builds; cap concurrency or spend when cost matters. *Opus 5.5 (and Opus 5):* - Opus 5.5 is the recommended starting point for complex agentic coding and enterprise work. Keep scope tight: "Deliver what was asked. Do not add features, refactors, or abstractions beyond the task." - Opus 5.5 already self-verifies strongly. Avoid redundant "double-check everything" instructions and verifier subagents for routine work; delegate only genuinely independent, sizeable tracks. *Sonnet 5.5 (and Sonnet 5):* - Sonnet 5.5 follows instructions literally, especially at lower effort. State when a rule applies to every item or section. - Raise effort for difficult multi-step work rather than compensating with elaborate reasoning prompts. Use explicit style and design direction instead of non-default sampling parameters. *Claude 4.8 and earlier selectable models:* - Existing explicit, front-loaded prompts remain compatible. If the model is 4.7 or later, use adaptive thinking and effort rather than `budget_tokens`. --- **ChatGPT / OpenAI GPT models** Identify the surface (ChatGPT, Codex, or API), preserve the selected model, and use the Model Recency Gate for availability and exact controls. - Route GPT-6 Luna (`gpt-6-luna`) to focused, high-volume tasks; GPT-6.1 Sol (`gpt-6.1-sol`) to complex coding, computer use, and professional work; GPT-6 Astra (`gpt-6-astra`) to demanding reasoning, research, coding, and document work. - Preserve GPT-5.6 choices: Sol (`gpt-5.6-sol`, alias `gpt-5.6`) for flagship capability, Terra (`gpt-5.6-terra`) for balanced everyday work, and Luna (`gpt-5.6-luna`) for fast, repeatable tasks. ChatGPT availability depends on the user's plan. - Start lean; use Template N for complex tasks and omit irrelevant sections. As heuristics to evaluate, narrow Luna tasks, give Sol implementation context and acceptance criteria, and give Astra decision criteria and evidence requirements. - State domain context, constraints, approval boundaries, success criteria, and when ambiguity requires a question. Honor existing authorization, allow routine in-scope work, and specify milestones, delegation limits, and proportionate verification when relevant. - For GPT-6 API tools, use Responses: Astra and GPT-6.1 Sol do not support tool calling through Chat Completions; Luna supports function calling there only with `reasoning_effort: "none"`. - Use the lowest reasoning effort that meets the quality bar; verify supported values for the exact model and endpoint. Do not transfer GPT-5.6-specific controls to newer models without verification. - Keep runtime settings outside the copyable prompt. For GPT-5.6, use higher effort, `reasoning.mode: "pro"`, or Responses multi-agent beta only when measured quality justifies cost and latency; pro mode is not a separate model slug. - Treat ChatGPT/Codex controls such as Sol Pro, Max, or Ultra as surface-specific; do not translate them into API parameters. Prompt text does not change the selected model or runtime settings. - State tool-use expectations and evidence requirements; use orchestration only for bounded, divisible work. Ask for conclusions, assumptions, evidence, and checks, never hidden reasoning; control visible length with the output contract (and API `text.verbosity`). --- **OpenAI reasoning models (o3, o4-mini, and successors)** - 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 instructions concise while preserving necessary context, constraints, examples, and verification. Do not impose an arbitrary word limit. --- **Grok / Grok 4.6 / xAI** - Use `grok-4.6` for current general chat, coding, agentic, and knowledge-work prompts. It supports text and image input, configurable reasoning, function calling, web search, X search, and code execution. - Keep the task outcome-focused: Goal, Context/Input, Constraints, Tools/Permissions, and Done. Grok 4.6 is OpenAI-API compatible, but the prompt must still name the tools and evidence the task requires. - Choose reasoning effort intentionally: `low` for scoped or latency-sensitive work, `medium` for balanced work, `high` (the API default) for difficult tasks, and `xhigh` only when deeper exploration is worth the cost. Grok 4.6 reasoning cannot be disabled. Do not ask for chain-of-thought. - For current facts, explicitly require Web Search or X Search and citations. Grok's base model does not have realtime knowledge without search tools enabled. - For long, tool-heavy agent loops, define stop conditions, approval boundaries, retry limits, and context-compaction checkpoints. Keep stable instructions at the front to preserve prompt-cache reuse. - For API setup notes, recommend `prompt_cache_key` on the Responses API or `x-grok-conv-id` on Chat Completions for reliable cache routing; do not place secret values in the prompt. - Consumer Grok and the xAI API expose different controls. If the user is in grok.com or X and cannot set model parameters, encode only behavioral requirements in the prompt rather than API settings. --- **Gemini / Google AI models (Gemini 4 Argon, Gemini 3.x Flash, and current Gemini family)** - Gemini 4 Argon is the current flagship — built for deep reasoning, long-horizon agentic work, coding, and multimodal tasks. 1M token context window. Verify the current model slug against Google AI documentation before recommending one. - 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." - Gemini 4 Argon supports tunable thinking levels (low, medium, high) — do not hardcode reasoning steps, set thinking level instead --- **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 `<think>` 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 `<think>` 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 - Do not assume the Claude Code model. Apply the matching current Claude route above; when model-specific behavior matters, ask which model is selected. - Front-load intent, relevant paths, constraints, acceptance criteria, and verification commands. Explicitly request tool use when inspection is required. - Current Fable/Opus models can over-scope and delegate readily. Add "Only make changes directly requested" and reserve subagents for independent, sizeable investigation or implementation tracks. - Do not force a separate verifier on Opus 5.5 for routine work; request concrete tests and tool-backed evidence instead. For long Fable 5.1 runs, require progress claims to cite actual tool results. - 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" - For complex tasks, use Template M. It handles scope, criteria, action boundaries, and progress evidence in one structured block. --- **Codex CLI / ChatGPT Work / Codex IDE** - Apply the matching OpenAI model route above, including GPT-6 Luna, GPT-6.1 Sol, GPT-6 Astra, or GPT-5.6 when selected. Do not infer the model from the Codex product name. Use Template N for complex OpenAI tasks. - Structure implementation prompts as Goal, Context, Scope, Constraints, Approval Boundaries, and Done. Include concrete verification commands when known. - Start with a supported default reasoning setting and adjust based on task results. Verify available Codex controls before recommending Max, Ultra, or other UI labels; do not map them directly to API settings. - Keep one primary agent responsible for synthesis. Name each subagent's bounded deliverable and cap concurrency rather than requesting an open-ended swarm. - Ask for a concise rationale, evidence, changed-file summary, and verification results—not hidden reasoning. --- **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 ---
View on GitHub
This SKILL.md is very large, so SkillsMP previews the first section here. View on GitHub