Better prompts begin with better thinking.

OUTCOME
Review and improve the prompt below without changing its intended outcome.

CURRENT PROMPT
[PASTE PROMPT]

OPERATING CONTEXT
- Who uses it: [USER OR SYSTEM]
- Model surface: [CHAT / CODING AGENT / API]
- Inputs available: [INPUTS]
- Tools available: [TOOLS OR NONE]
- Actions requiring approval: [BOUNDARIES]

TASK
1. State the intended outcome in one sentence.
2. Identify duplicated, conflicting, vague, or untestable instructions.
3. Separate durable context from task-specific context.
4. Remove content that does not improve a measured requirement.
5. Produce a revised prompt containing: outcome, relevant context, constraints, evidence, working method, success criteria, and output format.
6. Propose five representative evaluation cases, including one ambiguous and one failure-prone case.

DELIVERABLE
Return: diagnosis, revised prompt, removed material with reasons, and evaluation table.

QUALITY BAR
The revised prompt must be shorter, preserve necessary safety and approval boundaries, and make success observable.

OUTCOME
Design a context plan for this task before solving it.

TASK
[DESCRIBE TASK]

AVAILABLE CONTEXT
[LIST FILES, DOCUMENTS, DATA, TOOLS, AND PRIOR DECISIONS]

CONSTRAINTS
- Context limit or cost concern: [LIMIT]
- Required evidence: [EVIDENCE]
- Information that may be sensitive: [BOUNDARY]
- Desired answer length: [LENGTH]

TASK
1. Rank each context source as essential, useful, or omit.
2. Explain what decision each essential source supports.
3. Identify duplicated or stale context.
4. Propose the order in which context should be inspected.
5. Define a compact working summary that should survive if the conversation is condensed.
6. Set stopping criteria for further context gathering.

DELIVERABLE
Return a context budget table, inspection sequence, working-summary template, and stop conditions.

QUALITY BAR
Prefer the smallest context set that can still support a correct, evidence-backed result. Do not confuse a larger context window with better judgment.

OUTCOME
Create a proof-of-concept brief that resolves one important uncertainty with the least credible effort.

CONTEXT
- Opportunity or problem: [CONTEXT]
- Target user or stakeholder: [USER]
- Assumption creating the most risk: [ASSUMPTION]
- Time and people available: [BOUNDARY]
- Existing systems or data: [ASSETS]

TASK
1. Write one falsifiable learning question.
2. Distinguish technical feasibility, user desirability, operational viability, and governance risk.
3. Choose the single uncertainty the POC will test.
4. Define the smallest demonstration capable of producing evidence.
5. State what will deliberately not be built.
6. Define success, failure, inconclusive evidence, and the decision each result triggers.
7. Identify privacy, security, data, human-oversight, and reversibility guardrails.

DELIVERABLE
Return a one-page brief: hypothesis, scope, experiment, guardrails, evidence, decision rule, and five-day work plan.

QUALITY BAR
The POC must optimize for learning, remain disposable, and avoid creating accidental production commitments.

OUTCOME
Define an MVP that tests whether a specific user outcome can be created repeatedly.

PRODUCT CONTEXT
- User and situation: [USER]
- Job or outcome: [OUTCOME]
- Current alternative: [ALTERNATIVE]
- Evidence already available: [EVIDENCE]
- Constraints: [TIME, RISK, SYSTEMS]

TASK
1. State the value hypothesis and the behavior that would support it.
2. Define one complete user journey, including failure and recovery.
3. Separate must-have capability from convenience, scale, and polish.
4. Identify assumptions the MVP will not test.
5. Define leading signals, qualitative evidence, guardrail metrics, and a review date.
6. Describe instrumentation and feedback collection before implementation.
7. Produce a cut list for anything that does not affect the learning decision.

DELIVERABLE
Return: hypothesis, journey, scope, non-scope, evidence plan, release guardrails, and decision review.

QUALITY BAR
The MVP must be usable end to end, small enough to learn quickly, and instrumented well enough to avoid opinion-only conclusions.

OUTCOME
Turn the work below into a sequence of small, reviewable learning loops.

WORK ITEM
[DESCRIBE OUTCOME, USER NEED, OR PROBLEM]

CONTEXT
- Current system behavior: [BEHAVIOR]
- Constraints and risks: [CONSTRAINTS]
- Definition of done: [DONE]
- People who must review: [REVIEWERS]

WORKING METHOD
1. Reframe the work as an outcome and list the unresolved assumptions.
2. Divide it into vertical slices that each create observable evidence.
3. For every slice, define: change, test, user or system signal, review point, and rollback.
4. Identify where AI can accelerate exploration, implementation, testing, documentation, or review.
5. Identify where human judgment and explicit approval must remain.
6. Keep work-in-progress low and revise the next slice using evidence from the previous one.

DELIVERABLE
Return a prioritized slice table and a first-iteration plan with acceptance evidence.

QUALITY BAR
No slice should be “AI generates the feature.” Each slice must preserve accountable ownership, reviewability, and working software.

OUTCOME
Build an evidence-backed orientation map for this repository.

CHANGE OR QUESTION
[DESCRIBE WHAT YOU NEED TO UNDERSTAND]

TASK
1. Read repository guidance and identify the supported development commands.
2. Map entry points, main modules, data flow, external dependencies, and deployment boundary.
3. Trace one representative request or workflow end to end.
4. Identify where the requested change would enter the system.
5. Name tests, observability, configuration, migration, and security concerns connected to that path.
6. Separate verified facts, reasonable inferences, and unanswered questions.
7. Recommend the smallest next inspection or experiment.

DELIVERABLE
Return a compact system map, traced flow, risk table, and next-step recommendation with file references.

QUALITY BAR
Do not infer architecture from filenames alone. Every important claim should point to code, configuration, tests, or runtime evidence.

OUTCOME
Determine the most likely cause of this problem using evidence, then propose the smallest safe fix.

SYMPTOM
[OBSERVED BEHAVIOR, ERROR, IMPACT, AND WHEN IT STARTED]

AVAILABLE EVIDENCE
[LOGS, METRICS, TRACES, REPRODUCTION, RECENT CHANGES]

CONSTRAINTS
[PRODUCTION RISK, DATA SENSITIVITY, TIME, APPROVALS]

INVESTIGATION
1. Restate expected versus observed behavior.
2. Produce competing hypotheses ranked by explanatory power and test cost.
3. For each hypothesis, define evidence that would support or falsify it.
4. Inspect the shortest causal path first.
5. Distinguish root cause, contributing conditions, and detection gap.
6. Propose a minimal fix, regression test, operational verification, and rollback.
7. Identify any conclusion that remains uncertain.

DELIVERABLE
Return evidence, hypothesis table, conclusion, proposed fix, verification, and residual risk.

QUALITY BAR
Do not edit code merely because a suspicious pattern exists. Connect the proposed change to a reproduced or strongly evidenced failure mechanism.

OUTCOME
Create a staged implementation plan for the change below.

CHANGE
[DESCRIBE DESIRED BEHAVIOR]

SYSTEM CONTEXT
[ARCHITECTURE, CONSTRAINTS, DEPENDENCIES, EXISTING TESTS]

TASK
1. Identify affected contracts, data, users, and operational paths.
2. Name assumptions that must be verified before editing.
3. Divide the work into independently reviewable stages.
4. For every stage, state files or components, expected behavior, tests, observability, rollback, and approval point.
5. Address compatibility, migration, security, failure handling, and cleanup.
6. Define final acceptance evidence and post-release monitoring.

DELIVERABLE
Return an ordered plan, dependency map, review gates, verification matrix, and explicit non-goals.

QUALITY BAR
Avoid a file-by-file task list without behavioral intent. A reviewer should be able to stop after any stage without leaving the system in an incoherent state.

OUTCOME
Synthesize the supplied research into decision-relevant findings.

DECISION TO SUPPORT
[WHAT DECISION MUST THIS RESEARCH INFORM?]

RESEARCH INPUTS
[INTERVIEWS, NOTES, ANALYTICS, SUPPORT DATA, MARKET SOURCES]

SEGMENTS AND CONTEXT
[USERS, MARKETS, TIME PERIOD, SAMPLE LIMITATIONS]

TASK
1. Separate direct evidence, interpretation, and speculation.
2. Cluster recurring needs, behaviors, workarounds, and failure points.
3. Quantify frequency only when the sample supports it.
4. Identify contradictions and meaningful segment differences.
5. Map findings to user outcomes and current alternatives.
6. Propose product implications, unresolved questions, and the next best research action.

DELIVERABLE
Return an evidence table, themes, contradictions, implications, confidence limits, and recommended decisions.

QUALITY BAR
Preserve source traceability. Do not convert a small qualitative sample into market prevalence or call every request a user need.

OUTCOME
Design a product-health diagnostic that connects user value, behavior, quality, and economics.

PRODUCT
[PRODUCT, USERS, BUSINESS MODEL, MATURITY]

CURRENT SIGNALS
[GOALS, METRICS, RESEARCH, INCIDENTS, SUPPORT, COMMERCIAL DATA]

TASK
1. Define the core user outcome and the repeated behavior that indicates value.
2. Build a metric tree across reach, activation, meaningful use, retention, quality, trust, and unit economics.
3. Distinguish leading, lagging, diagnostic, and guardrail metrics.
4. Identify denominator errors, survivorship bias, averages hiding segments, and vanity metrics.
5. Segment by user intent, maturity, or context where meaningful.
6. State plausible explanations for current health and the evidence needed to distinguish them.
7. Recommend three decisions the review should enable.

DELIVERABLE
Return outcome definition, metric tree, health hypotheses, data gaps, review questions, and decision agenda.

QUALITY BAR
Do not treat engagement as value by default. Include reliability, user trust, unwanted outcomes, and the cost of serving the product.

OUTCOME
Specify a product-health dashboard for a named audience and operating decision.

AUDIENCE AND DECISIONS
- Primary audience: [AUDIENCE]
- Decisions they make: [DECISIONS]
- Review cadence: [CADENCE]

PRODUCT CONTEXT
[USER OUTCOME, JOURNEY, BUSINESS MODEL, KNOWN RISKS]

TASK
1. Write the three questions the dashboard must answer.
2. Select the smallest metric set that answers those questions.
3. For each metric define: meaning, formula, denominator, source, owner, freshness, segments, target or comparison, and known caveats.
4. Pair outcomes with diagnostic and guardrail signals.
5. Define annotations for releases, incidents, campaigns, and data-quality changes.
6. Design drill-down paths and the action expected when a signal moves.
7. Identify access, privacy, and misuse risks.

DELIVERABLE
Return dashboard hierarchy, metric dictionary, wireframe description, alert logic, and review ritual.

QUALITY BAR
Every chart must support a decision or investigation. Avoid red-amber-green status without context, ambiguous composite scores, and metrics without owners.

OUTCOME
Review this AI use case as an operating decision, not a technology demonstration.

USE CASE
[WHO USES AI, FOR WHAT DECISION OR WORK, AND IN WHICH CONTEXT?]

VALUE HYPOTHESIS
[WHAT SHOULD BECOME BETTER, FOR WHOM, AND HOW WILL WE KNOW?]

DATA AND SYSTEM CONTEXT
[INPUTS, OUTPUTS, MODELS, TOOLS, INTEGRATIONS, RETENTION]

TASK
1. Test whether AI is necessary and name the non-AI alternative.
2. Map expected value, affected people, workflow change, and cost to operate.
3. Identify failure modes across accuracy, bias, privacy, security, intellectual property, explainability, dependency, and misuse.
4. Assign human accountability for design, approval, use, monitoring, incidents, and retirement.
5. Define guardrails before, during, and after model output.
6. Specify evaluation cases, prohibited uses, escalation, reversibility, and monitoring.
7. Recommend: stop, explore, pilot with conditions, or scale with evidence.

DELIVERABLE
Return a value-risk map, accountability table, guardrails, evaluation plan, and recommendation with conditions.

QUALITY BAR
Governance must be proportional to impact and close enough to the work to change behavior. Do not use a policy document as a substitute for product and operating controls.