Documentation Index
Fetch the complete documentation index at: https://mintlify.com/nidhinjs/prompt-master/llms.txt
Use this file to discover all available pages before exploring further.
Task patterns and context patterns are the two earliest failure points in any prompt. Task failures happen before the model even begins generating: the instruction is structurally incomplete, so the model fills the gaps with assumptions. Context failures happen because the model has no memory between sessions — every assumption you leave unstated becomes a coin-flip the model makes silently on your behalf. Together, these thirteen patterns account for the majority of re-prompting loops. Each one listed below includes the exact before/after that Prompt Master applies, and a brief explanation of the credit cost.
Task Patterns
Pattern 1 — Vague Task Verb
A task verb that commits to no specific action gives the model full discretion over what “help” means. The model is not wrong when it produces a general overview instead of a targeted fix — you asked for help, and an overview is help. The problem is that you wanted a specific action, and you did not say so.
Why it wastes credits: The first output is almost never the format you needed, triggering one to three follow-up prompts to narrow down the actual deliverable.
| Prompt |
|---|
| Before | help me with my code |
| After | Refactor getUserData() to use async/await and handle null returns |
refactor to async/await), and defines the edge case to cover (null returns). The model has no discretion to fill — it has a precise instruction.
Pattern 2 — Two Tasks in One Prompt
Combining two distinct tasks in a single prompt forces the model to prioritize one over the other, and it will do so without telling you. Explanation tasks and transformation tasks require fundamentally different output shapes — prose for one, code for the other. Mixing them degrades both.
Why it wastes credits: You receive a partial explanation and a partial rewrite, neither done well. Two clean prompts produce two clean outputs at the same total token cost.
| Prompt |
|---|
| Before | explain AND rewrite this function |
| After (Prompt 1) | Explain what this function does, why it currently fails on null input, and what the correct approach is |
| After (Prompt 2) | Rewrite the function using the approach described above: async/await pattern, null guard on line 3 |
Pattern 3 — No Success Criteria
Without a definition of done, the model decides when it is finished. “Make it better” is grammatically valid but operationally empty — better by what measure, validated how, and compared to what baseline?
Why it wastes credits: The model finishes when its output looks plausible to itself, not when it has met your actual requirement. You then spend credits describing what you actually needed.
| Prompt |
|---|
| Before | make it better |
| After | Done when the function passes all existing unit tests and handles null input without throwing |
Pattern 4 — Over-Permissive Agent
Telling an agent to “do whatever it takes” removes all guardrails. The model will interpret this permission at its broadest — deleting files it considers redundant, installing packages it prefers, modifying configs it thinks are wrong. All of those actions may be outside what you intended.
Why it wastes credits: Recovering from an agent that acted on broad permission is more expensive than specifying the permission explicitly upfront.
| Prompt |
|---|
| Before | do whatever it takes to fix this |
| After | Allowed: edit files in src/, add console.log statements, refactor function signatures. Forbidden: edit package.json, touch .env, delete any file, install dependencies. |
Pattern 5 — Emotional Task Description
Describing a bug emotionally (“it’s totally broken”) tells the model nothing actionable. The model cannot use frustration as a diagnostic signal. It still needs the error type, the location, and the condition that triggers it.
Why it wastes credits: The model either asks clarifying questions (adding a round-trip) or guesses the bug type and produces a fix for the wrong problem.
| Prompt |
|---|
| Before | it's totally broken, fix everything |
| After | Throws uncaught TypeError on line 43 when user object is null. Fix the null guard in handleUser() in src/auth.js |
Pattern 6 — Build-the-Whole-Thing
Asking a model to build an entire application in one prompt exceeds the effective instruction horizon for any model. The model will produce something, but it will be a scaffold with placeholders, missing error handling, and inconsistent patterns — because no single prompt can carry all the architectural decisions a full app requires.
Why it wastes credits: You receive a large output with hidden gaps. Finding and fixing those gaps costs more than building incrementally would have.
| Prompt |
|---|
| Before | build my entire app |
| After (Prompt 1) | Scaffold a Node.js/Express project: folder structure, package.json, empty route files, middleware setup. No implementation yet. |
| After (Prompt 2) | Implement the /users endpoint in src/routes/users.js: GET all, GET by ID, POST create. Use the scaffold from Prompt 1. |
| After (Prompt 3) | Add input validation and error handling to all three /users routes. Follow the pattern established in Prompt 2. |
Pattern 7 — Implicit Reference
Referring to “the other thing we discussed” or “that approach from earlier” assumes the model has memory of the conversation. In a new session it has none. In the same session it may have lost early context if the thread is long.
Why it wastes credits: The model either hallucinates a plausible “thing you discussed” (confident, wrong) or asks what you meant (adds a round-trip).
| Prompt |
|---|
| Before | now add the other thing we discussed |
| After | Add rate limiting to the /login endpoint using the token-bucket algorithm we established in the architecture decision above: 5 requests per minute per IP, 429 response with Retry-After header |
Context Patterns
Pattern 8 — Assumed Prior Knowledge
Opening a new prompt with “continue where we left off” is the most common context failure. Claude has no memory between sessions. Even within a long session, early decisions scroll out of the active context window. The model will either hallucinate continuity or produce something that contradicts prior work.
Why it wastes credits: You discover the contradiction after reviewing the output — at which point you have already spent the tokens.
| Prompt |
|---|
| Before | continue where we left off |
| After | Include a Memory Block at the top of every prompt: the stack, the architecture decisions made so far, the current file being worked on, and any constraints established in prior turns. |
[MEMORY BLOCK]
Stack: Node.js 20, Express 4, PostgreSQL 15, Prisma ORM
Architecture decisions:
- Auth: JWT with 15-min access token, 7-day refresh token
- Error handling: centralized error middleware in src/middleware/error.js
- No external logging services — console.error only
Current file: src/routes/auth.js
Last completed: POST /login endpoint
Next task: POST /register with duplicate email check
Pattern 9 — No Project Context
A prompt with no background forces the model to invent a plausible context. For writing tasks, that invented context is almost never a match for your actual situation — industry, seniority level, audience, and constraints are all guessed.
Why it wastes credits: The first output is built on fictional assumptions. You spend the next prompt correcting those assumptions instead of refining the actual content.
| Prompt |
|---|
| Before | write a cover letter |
| After | Write a cover letter for a Senior Product Manager role at a B2B fintech company. Applicant background: 2 years as SWE, shipped 3 features as tech lead, no prior PM title. Tone: confident, not boastful. Length: 3 paragraphs. |
Pattern 10 — Forgotten Stack
Starting a new prompt without restating your tech stack is how you end up with a React component that uses a library you banned, or a database query that targets the wrong ORM. The model does not retain your earlier constraint — it defaults to whatever is most common in its training data.
Why it wastes credits: You get working code that uses the wrong tools and must be rewritten from scratch.
| Prompt |
|---|
| Before | (New prompt that implicitly contradicts a prior tech choice) |
| After | Always include a Memory Block with your stack constraints at the top of every new prompt. |
[STACK CONSTRAINTS]
Frontend: React 18, TypeScript strict mode, Tailwind CSS only (no external component libraries)
Backend: Node.js 20, Express 4, Prisma with PostgreSQL
Testing: Vitest only (no Jest)
Linting: ESLint + Prettier — do not modify .eslintrc or .prettierrc
Pattern 11 — Hallucination Invite
Asking the model what “experts say” or what is “commonly recommended” creates an open invitation to confabulate citations. The model will produce a confident, well-formatted answer populated with plausible-sounding names, papers, and statistics that may not exist.
Why it wastes credits: Verifying fabricated citations costs more time than asking the question correctly in the first place.
| Prompt |
|---|
| Before | what do experts say about database indexing strategies? |
| After | Explain the trade-offs between B-tree and hash indexes for a read-heavy PostgreSQL workload. Cite only sources you are certain of. If uncertain about a specific claim, say so explicitly rather than naming a source. |
Pattern 12 — Undefined Audience
Writing for “users” or “the audience” without specifying who they are produces prose calibrated to the model’s default reader — typically a technical generalist. Your actual audience may be non-technical executives, junior developers, or domain experts who need different vocabulary, depth, and framing.
Why it wastes credits: The writing is technically correct but wrong for the reader. You spend credits rewriting for tone and depth instead of for content.
| Prompt |
|---|
| Before | write something for users |
| After | Audience: non-technical B2B buyers at director level, no coding knowledge, evaluating software vendors. Avoid technical jargon. Lead with business outcome, not feature description. Decision-maker framing throughout. |
Pattern 13 — No Mention of Prior Failures
Submitting a new attempt at a problem without telling the model what you already tried causes it to suggest the same approach you already discarded. It does not know you tried it. From its perspective, the most obvious solution is still on the table.
Why it wastes credits: You receive a re-suggestion of a failed approach, formatted as a new answer, and spend another prompt eliminating it again.
| Prompt |
|---|
| Before | (No mention of prior attempts — model suggests the same approach again) |
| After | I already tried using a debounce wrapper on the input handler — it reduced the issue but did not eliminate it because the problem occurs on the initial mount, not repeated input. Do not suggest debounce. The bug is in the initialization path. |
These thirteen patterns are the most common source of re-prompting loops in everyday AI use. The fixes listed here are the exact transformations Prompt Master applies during its silent audit. For format, scope, reasoning, and agentic patterns, see Format & Scope and Reasoning & Agentic. 