PodLabsTech prompt library

Use when a team has a noisy opportunity and needs a defensible next decision.

You are a product strategy partner. Using only the evidence below, write a decision brief with: (1) target user and job, (2) observed evidence, (3) assumptions, (4) business constraints, (5) three options, (6) recommendation, (7) smallest test, and (8) what would change the recommendation. Label every statement as known, inferred, or missing. Do not invent metrics or customer quotes.

Evidence:
[PASTE EVIDENCE]
Constraints:
[PASTE CONSTRAINTS]

Output: A concise decision brief with an explicit next test.

Guardrails: Separate facts from assumptions · Do not invent customer evidence

Use when a feature list is growing faster than the team can learn.

Act as an MVP scope editor. Convert this product idea into one target user, one consequential decision, one end-to-end workflow, and three risks to test. Propose a smallest credible MVP that can produce evidence within [TIMEFRAME]. For every proposed scope item, explain the learning it enables and mark it as required, useful later, or exclude. Finish with acceptance criteria and a stop/continue decision rule.

Product idea:
[PASTE IDEA]
Audience:
[PASTE AUDIENCE]
Known constraints:
[PASTE CONSTRAINTS]

Output: A bounded MVP scope, risk map, acceptance criteria, and decision rule.

Guardrails: Do not call unfinished software an MVP without a learning goal · Keep one primary workflow

Use when product requests need to become an operating rhythm rather than a static backlog.

Design a 90-day product operating cadence from the inputs below. Create outcome themes, discovery checkpoints, delivery checkpoints, evidence reviews, owners, and a revisit date for every bet. Identify dependencies and decisions that must stay reversible. Return a table with: outcome, hypothesis, signal, owner, next review, confidence, and escalation path. Include a short note on what the backlog must not become.

Current requests:
[PASTE REQUESTS]
Evidence:
[PASTE EVIDENCE]
Team shape:
[PASTE TEAM SHAPE]

Output: A roadmap operating cadence with ownership and review points.

Guardrails: Do not present uncertain dates as promises · Keep decisions and outputs separate

Use before implementation or a usability test to expose experience risks.

Review this product flow as a senior product designer. Evaluate comprehension, hierarchy, accessibility, input effort, empty states, errors, recovery, and mobile behavior. Return: (1) the user goal, (2) the five highest-risk moments, (3) one high-confidence change per moment, (4) questions that require research, and (5) a lightweight acceptance checklist. Cite the exact screen or copy being discussed.

Flow description or screenshots:
[PASTE FLOW]
Audience and context:
[PASTE CONTEXT]

Output: Prioritised UX findings and an acceptance checklist.

Guardrails: Do not infer user preferences without evidence · Separate usability risk from visual taste

Use when a team needs a technical decision that preserves the right future options.

Act as a principal engineer. Compare the architecture options below against the stated workload, team skills, security needs, deployment model, data boundaries, cost, latency, failure modes, and migration path. Recommend one option for now and explain which decision it keeps reversible. Return a decision record with assumptions, trade-offs, operational checklist, and five validation tests. Do not invent benchmark numbers; mark unknowns.

Product context:
[PASTE CONTEXT]
Options:
[PASTE OPTIONS]
Constraints:
[PASTE CONSTRAINTS]

Output: A technical decision record with validation tests.

Guardrails: Do not fabricate benchmarks · Call out security and operational unknowns

Use when adding AI to an existing product without losing product, data, or operational boundaries.

Design an AI integration contract for this product. Define the user job, model responsibility, application responsibility, approved context, data retention, tool surface, fallback behavior, latency budget, cost ceiling, human review, and evaluation set. Return an API-facing contract with request fields, response fields, error states, and audit events. Flag anything that needs legal, security, or product approval before implementation.

Product context:
[PASTE CONTEXT]
Existing systems:
[PASTE SYSTEMS]
Data boundaries:
[PASTE DATA RULES]

Output: A bounded integration and API contract.

Guardrails: Never grant model authority by default · Separate draft, read, and write actions · Escalate sensitive data questions

Use before building an agent so autonomy is earned by a clear job and control model.

Create a bounded AI agent brief. Define: job, trigger, inputs, approved knowledge, tools, permission levels, state, expected outputs, escalation triggers, human hand-off, audit events, recovery behavior, and success metrics. Include three examples, two edge cases, and one unsafe request the agent must refuse. End with a recommendation for the smallest tool surface to launch.

Workflow context:
[PASTE CONTEXT]
Systems and tools:
[PASTE TOOLS]
People involved:
[PASTE ROLES]

Output: An agent brief with permissions, hand-offs, and evaluation cases.

Guardrails: Default to read-only tools · Require approval for consequential writes · Name refusal and recovery behavior

Use when automation ideas need to become a safe operating system rather than a demo.

Redesign this repetitive process as a supervised workflow. Map current steps, decisions, data sources, hand-offs, exceptions, and measures. Propose what software should automate, what an AI system may suggest, what a person must approve, and what should remain manual. Return a state machine, event log, recovery path, and rollout plan in three stages.

Current process:
[PASTE PROCESS]
Systems:
[PASTE SYSTEMS]
Risk tolerance:
[PASTE RISK CONTEXT]

Output: A staged, observable workflow design.

Guardrails: No silent automation of high-consequence actions · Preserve a human recovery path

Use before production launch or after a prompt, tool, or model change.

Build an evaluation set for this AI workflow. Generate representative inputs, boundary cases, adversarial or prompt-injection cases, and missing-context cases. For each case define expected behavior, acceptable variation, unsafe behavior, required citations or tool calls, and a reviewer rubric. Recommend which failures block release and which become monitored follow-ups.

Agent job:
[PASTE JOB]
Tools and permissions:
[PASTE TOOLS]
Known failures:
[PASTE FAILURES]

Output: A release-ready evaluation set and review rubric.

Guardrails: Include malicious and ambiguous inputs · Do not use hidden reasoning as the evaluation target

Use when keyword, competitor, and content-gap data needs a prioritised action plan.

Act as a supervised search intelligence analyst. Convert this dataset into a prioritised opportunity brief. Group terms by user intent and business relevance, identify the evidence behind each cluster, flag cannibalisation or weak evidence, recommend the page or experiment to create, and define the measurement event. Keep recommendations separate from facts and include a human approval checklist before publishing.

Search data:
[PASTE DATA]
Business priorities:
[PASTE PRIORITIES]
Existing pages:
[PASTE PAGES]

Output: Prioritised search opportunities with evidence and measurement.

Guardrails: Do not infer demand from a keyword alone · Do not auto-publish

Use for a technical and content review before a page is published or refreshed.

Review this page for crawlability, intent match, visible evidence, internal links, structured data, accessibility, page experience, and AI discoverability. Return findings grouped by blocker, high-impact improvement, and monitor. For every recommendation include the exact page element, reason, implementation note, and validation method. Never recommend hidden or misleading text.

Page URL or HTML:
[PASTE PAGE]
Target query and audience:
[PASTE INTENT]
Known sources:
[PASTE SOURCES]

Output: A technical SEO and AI discoverability action list.

Guardrails: Structured data must describe visible truth · Do not suggest cloaking or keyword stuffing

Use when ad and landing-page changes need an evidence-led experiment brief.

Create a PPC experiment brief from the campaign inputs below. Check alignment between query, ad promise, landing page, audience, conversion event, budget guardrail, and experiment duration. Define the hypothesis, variants, primary metric, diagnostic metrics, stop conditions, and approval owner. Do not recommend increasing spend without conversion-quality evidence.

Campaign data:
[PASTE DATA]
Landing page:
[PASTE PAGE]
Budget and risk limits:
[PASTE LIMITS]

Output: An approval-ready PPC experiment brief.

Guardrails: Do not change spend automatically · Treat conversion quality as more important than click volume