# PromptDev.help Prompt Handbook Version 1.1 · Verified 2026-09-10 ## P01 — Implementation plan **Category:** Coding **Purpose:** Turn a feature request into a safe implementation plan **Use when:** You need scope, dependencies, risks, and test strategy before editing code. **Variables:** FEATURE, STACK, CURRENT ARCHITECTURE, CONSTRAINTS ```text Act as a senior software engineer. Create an implementation plan for [FEATURE] in [STACK]. Context: [CURRENT ARCHITECTURE]. Constraints: [CONSTRAINTS]. Identify assumptions, affected components, data/API changes, failure modes, security implications, rollout and rollback. End with ordered tasks and acceptance tests. Do not invent repository facts; label unknowns. ``` ## P02 — Repository orientation **Category:** Coding **Purpose:** Map an unfamiliar codebase quickly **Use when:** You are starting work in an existing repository. **Variables:** GOAL ```text Analyze the supplied repository tree and key files for [GOAL]. Explain entry points, runtime flow, state/data boundaries, build/test commands, and conventions. Cite file paths for every claim. List the minimum files to inspect next and unresolved questions. ``` ## P03 — API design review **Category:** Coding **Purpose:** Review an API contract before implementation **Use when:** A new or changed endpoint needs compatibility and security review. **Variables:** REST/GRAPHQL/RPC, USE CASE, CONTRACT ```text Review this [REST/GRAPHQL/RPC] contract for [USE CASE]: [CONTRACT]. Check naming, types, pagination, idempotency, errors, auth, rate limits, versioning, observability, and backward compatibility. Return issues by severity, proposed revisions, and example requests/responses. ``` ## P04 — Refactor safely **Category:** Coding **Purpose:** Plan a behavior-preserving refactor **Use when:** Complex code needs simplification without changing public behavior. **Variables:** CODE, GOAL, PUBLIC BEHAVIOR ```text Refactor [CODE] to improve [GOAL]. Preserve [PUBLIC BEHAVIOR]. First state invariants and risks. Then propose the smallest staged change, show the patch, and add characterization tests covering current behavior and edge cases. ``` ## P05 — Write unit tests **Category:** Coding **Purpose:** Generate meaningful unit tests **Use when:** You need focused tests rather than snapshots or happy paths only. **Variables:** UNIT, FRAMEWORK, BUG ```text Write unit tests for [UNIT] using [FRAMEWORK]. Cover normal behavior, boundaries, invalid input, state transitions, and known regression [BUG]. Mock only external boundaries. Explain what each test proves and identify behavior that belongs in integration tests. ``` ## P06 — Performance review **Category:** Coding **Purpose:** Find likely hot paths **Use when:** Latency, throughput, or memory needs diagnosis. **Variables:** CODE/PROFILE, WORKLOAD ```text Analyze [CODE/PROFILE] for performance bottlenecks under [WORKLOAD]. Separate measured evidence from hypotheses. Rank issues by likely impact, propose instrumentation, give low-risk optimizations first, and define benchmarks that would confirm improvement without changing semantics. ``` ## P07 — Database migration **Category:** Coding **Purpose:** Design a reversible schema change **Use when:** A production schema needs to evolve safely. **Variables:** CURRENT SCHEMA, TARGET ```text Design a zero/low-downtime migration from [CURRENT SCHEMA] to [TARGET]. Include expand/migrate/contract steps, backfill batching, compatibility window, indexes, validation queries, monitoring, rollback, and handling for partial failure. State database-specific assumptions. ``` ## P08 — Minimal reproduction **Category:** Debugging **Purpose:** Reduce a bug to its essential case **Use when:** A bug report is noisy or environment-dependent. **Variables:** SYMPTOM, EVIDENCE ```text Help create a minimal reproduction for [SYMPTOM]. Given [EVIDENCE], separate facts from guesses, list variables to control, propose a binary isolation sequence, and produce the smallest standalone example plus expected vs actual behavior. ``` ## P09 — Stack trace triage **Category:** Debugging **Purpose:** Interpret an error without guessing **Use when:** You have a stack trace and runtime context. **Variables:** STACK TRACE, RUNTIME/VERSIONS ```text Triage this error: [STACK TRACE]. Environment: [RUNTIME/VERSIONS]. Identify the first actionable frame, likely root causes ranked with evidence, checks that discriminate between them, and the safest fix. Flag missing context and avoid assuming the last frame is the cause. ``` ## P10 — Regression bisect plan **Category:** Debugging **Purpose:** Locate when behavior changed **Use when:** A previously working feature now fails. **Variables:** FAILURE, VERSION/DATE, VERSION/DATE ```text Create a regression-isolation plan for [FAILURE]. Known-good: [VERSION/DATE]. Known-bad: [VERSION/DATE]. Include reproducible test, git bisect steps, environment pinning, logging to capture, and how to distinguish code, dependency, configuration, and data changes. ``` ## P11 — Async race analysis **Category:** Debugging **Purpose:** Diagnose intermittent concurrency issues **Use when:** Failures depend on timing or ordering. **Variables:** CODE/TIMELINE ```text Analyze this asynchronous flow for races, deadlocks, duplicate work, and stale state: [CODE/TIMELINE]. Build a happens-before timeline, identify unprotected shared state, propose deterministic reproduction, and recommend the smallest synchronization or idempotency fix with tests. ``` ## P12 — Memory leak investigation **Category:** Debugging **Purpose:** Find retention causes **Use when:** Memory grows over time. **Variables:** APP/RUNTIME, METRICS ```text Develop a memory-leak investigation for [APP/RUNTIME]. Evidence: [METRICS]. Distinguish cache growth from leaks, define heap/profile captures, likely retention paths, controlled load test, acceptance threshold, and safe remediation. ``` ## P13 — Production incident triage **Category:** Debugging **Purpose:** Stabilize first, diagnose second **Use when:** A live service is degraded. **Variables:** SYMPTOM, METRICS/LOGS/CHANGES ```text Act as incident commander for [SYMPTOM]. Inputs: [METRICS/LOGS/CHANGES]. Produce immediate containment, customer-impact statement, ranked hypotheses, read-only checks, rollback criteria, communication cadence, evidence log, and post-stabilization root-cause steps. Avoid irreversible actions. ``` ## P14 — Evidence matrix **Category:** Research **Purpose:** Compare claims across sources **Use when:** A decision needs traceable support. **Variables:** QUESTION ```text Research [QUESTION]. Build an evidence matrix with claim, source, publication date, source type, method/sample, supporting evidence, limitations, and conflicts. Prefer primary sources. Distinguish sourced fact, calculation, and inference. End with confidence and open questions. ``` ## P15 — Primary-source search **Category:** Research **Purpose:** Find authoritative evidence **Use when:** Search results are dominated by summaries. **Variables:** TOPIC ```text Design a search strategy for [TOPIC] prioritizing official documentation, standards, statutes, datasets, and peer-reviewed original research. Provide query variants, inclusion/exclusion criteria, recency needs, and a verification checklist for identity, date, version, and provenance. ``` ## P16 — Citation audit **Category:** Research **Purpose:** Verify whether citations support claims **Use when:** A draft may overstate sources. **Variables:** TEXT ```text Audit each claim and citation in [TEXT]. For every citation, report whether it directly supports the claim, only partially supports it, or does not support it. Note date/version mismatch, secondary sourcing, omitted caveats, and corrected wording. Do not fabricate citations. ``` ## P17 — Contradiction analysis **Category:** Research **Purpose:** Resolve conflicting sources **Use when:** Two credible sources disagree. **Variables:** SOURCE A, SOURCE B, CLAIM ```text Compare [SOURCE A] and [SOURCE B] on [CLAIM]. Check definitions, populations, dates, methods, incentives, versions, and uncertainty. Explain whether the conflict is real or contextual, what evidence would resolve it, and the most defensible provisional conclusion. ``` ## P18 — Deep research plan **Category:** Research **Purpose:** Plan a multi-stage investigation **Use when:** A broad question needs bounded research. **Variables:** QUESTION, AUDIENCE ```text Create a deep-research plan for [QUESTION] for [AUDIENCE]. Decompose subquestions, define evidence standards, source hierarchy, search queries, stopping criteria, fact-check pass, synthesis outline, and explicit treatment of uncertainty and contradictory evidence. ``` ## P19 — Fact-check a statement **Category:** Research **Purpose:** Test a specific factual claim **Use when:** A claim may be false, misleading, or outdated. **Variables:** CLAIM ```text Fact-check: “[CLAIM].” Identify its testable parts, original source if traceable, authoritative current evidence, relevant date and jurisdiction, missing context, and a verdict using true/mostly true/misleading/unsupported/false. Provide direct links and quote minimally. ``` ## P20 — Dataset evaluation **Category:** Research **Purpose:** Assess data fitness **Use when:** A dataset may be biased or unsuitable. **Variables:** DATASET, USE ```text Evaluate [DATASET] for [USE]. Examine provenance, license, collection period, coverage, missingness, label quality, leakage, representativeness, privacy, update cadence, and known limitations. Recommend validation tests and a go/no-go decision. ``` ## P21 — Executive brief **Category:** Business **Purpose:** Compress a complex issue **Use when:** Leaders need a decision-ready summary. **Variables:** TOPIC, AUDIENCE ```text Write a one-page executive brief on [TOPIC] for [AUDIENCE]. Lead with the decision, quantify impact where evidence exists, show 3 options with tradeoffs, risks, assumptions, recommendation, owner, cost range, and next milestone. Use plain language; label estimates. ``` ## P22 — Requirements interview **Category:** Business **Purpose:** Turn an idea into requirements **Use when:** A stakeholder request is underspecified. **Variables:** IDEA ```text Act as a product analyst. For [IDEA], infer what is safe, then ask only questions that materially change scope. Produce users, jobs-to-be-done, functional and nonfunctional requirements, exclusions, acceptance criteria, dependencies, risks, and unresolved decisions. ``` ## P23 — Vendor comparison **Category:** Business **Purpose:** Compare tools without brochure bias **Use when:** A purchase decision needs consistent criteria. **Variables:** VENDORS, USE CASE ```text Compare [VENDORS] for [USE CASE]. Use current first-party sources where possible. Score required capabilities, security, privacy, portability, support, implementation effort, limits, and total cost assumptions. Separate verified facts from unknowns and recommend pilots. ``` ## P24 — Meeting decision log **Category:** Business **Purpose:** Extract decisions and accountability **Use when:** Notes need to become actionable. **Variables:** MEETING NOTES ```text Transform [MEETING NOTES] into: decisions made, rejected alternatives, reasons, action items with owner/date, risks, dependencies, unanswered questions, and items requiring confirmation. Do not assign an owner or deadline that was not stated. ``` ## P25 — SOP writer **Category:** Business **Purpose:** Create an operational procedure **Use when:** A repeatable process must be teachable and auditable. **Variables:** PROCESS, ROLE ```text Write an SOP for [PROCESS] used by [ROLE]. Include purpose, prerequisites, permissions, numbered steps, decision points, expected evidence, failure handling, escalation, rollback, security cautions, and completion checklist. Mark organization-specific placeholders. ``` ## P26 — Risk register **Category:** Business **Purpose:** Surface delivery and operating risks **Use when:** A plan needs explicit risk ownership. **Variables:** PROJECT ```text Create a risk register for [PROJECT]. Include risk, cause, consequence, likelihood, impact, early indicators, mitigation, contingency, owner placeholder, and review date. Rank by exposure and distinguish risks from current issues. ``` ## P27 — Workflow design **Category:** Automation **Purpose:** Design a reliable automation **Use when:** A repetitive process spans systems. **Variables:** PROCESS, SYSTEMS ```text Design an automation for [PROCESS] across [SYSTEMS]. Specify trigger, inputs, validation, transformations, idempotency key, retries/backoff, rate limits, human approval gates, audit log, secrets handling, failure queue, monitoring, and manual recovery. ``` ## P28 — Webhook contract **Category:** Automation **Purpose:** Make event delivery resilient **Use when:** Systems exchange asynchronous events. **Variables:** EVENT ```text Design a webhook for [EVENT]. Provide versioned payload, signature verification, timestamp/replay defense, idempotency, retry policy, ordering assumptions, response behavior, observability, test vectors, and consumer migration plan. ``` ## P29 — Scheduled job review **Category:** Automation **Purpose:** Prevent duplicate or missed runs **Use when:** A recurring job must behave under failure. **Variables:** DESIGN/CODE ```text Review this scheduled job: [DESIGN/CODE]. Check overlap, locks, clock/timezone, retries, catch-up behavior, idempotency, pagination, partial commits, rate limits, alerting, and safe rerun. Return concrete changes and tests. ``` ## P30 — Data sync plan **Category:** Automation **Purpose:** Synchronize two systems safely **Use when:** Records must converge across APIs. **Variables:** ONE-WAY/TWO-WAY, SYSTEM A, SYSTEM B ```text Plan a [ONE-WAY/TWO-WAY] sync between [SYSTEM A] and [SYSTEM B]. Define source of truth per field, identity mapping, delta detection, deletions, conflicts, schema drift, batching, checkpoints, reconciliation, privacy, and recovery from partial failure. ``` ## P31 — Agent tool design **Category:** Automation **Purpose:** Define a safe callable tool **Use when:** An AI agent needs structured capabilities. **Variables:** ACTION ```text Design an agent tool for [ACTION]. Provide clear name/description, strict input/output schema, validation, permission boundaries, confirmation points, idempotency, error taxonomy, timeouts, audit fields, and examples that prevent ambiguous or destructive calls. ``` ## P32 — Human approval gate **Category:** Automation **Purpose:** Place review where it matters **Use when:** Automation includes consequential actions. **Variables:** FLOW ```text For workflow [FLOW], identify actions needing human approval based on reversibility, cost, external communication, access changes, deletion, and sensitive data. Design the review payload, approve/reject/edit paths, timeout, escalation, and audit trail. ``` ## P33 — Technical tutorial **Category:** Content **Purpose:** Teach a task accurately **Use when:** Readers need a tested, version-aware guide. **Variables:** TASK, VERSION/STACK, AUDIENCE ```text Write a tutorial for [TASK] using [VERSION/STACK] for [AUDIENCE]. Include prerequisites, verified steps, expected output, common errors, security notes, rollback, and a final validation. Do not hide essential steps behind vague phrases. ``` ## P34 — Documentation rewrite **Category:** Content **Purpose:** Make docs scannable and precise **Use when:** Existing docs are dense or inconsistent. **Variables:** DOCUMENT, AUDIENCE ```text Rewrite [DOCUMENT] for [AUDIENCE]. Preserve technical meaning, define prerequisites, use task-oriented headings, numbered procedures, examples, warnings near risky steps, expected results, troubleshooting, and links to authoritative references. Flag ambiguous source text. ``` ## P35 — Release notes **Category:** Content **Purpose:** Explain user impact, not commit history **Use when:** A product release needs clear communication. **Variables:** CHANGES ```text Draft release notes from [CHANGES]. Group by new, improved, fixed, deprecated, and known issues. Explain who is affected, required action, compatibility, rollout, and rollback. Exclude internal details and do not overclaim. ``` ## P36 — FAQ builder **Category:** Content **Purpose:** Answer recurring questions efficiently **Use when:** Support questions repeat. **Variables:** PRODUCT/TOPIC, SOURCE ```text Create an FAQ for [PRODUCT/TOPIC] from [SOURCE]. Prioritize real user intents, give direct answers first, include steps and limits, cross-link related questions, and mark answers that depend on plan, region, version, or policy. ``` ## P37 — Editorial accuracy pass **Category:** Content **Purpose:** Improve prose without changing facts **Use when:** A draft needs clarity and fact discipline. **Variables:** TEXT ```text Edit [TEXT] for clarity, structure, concision, terminology, and accessibility. Preserve supported facts and voice. Flag claims needing sources, stale dates, undefined acronyms, hidden assumptions, and language that implies certainty beyond the evidence. ``` ## P38 — Threat model **Category:** Security **Purpose:** Identify realistic abuse paths **Use when:** A feature handles data, identity, or external actions. **Variables:** SYSTEM/FEATURE ```text Threat-model [SYSTEM/FEATURE] using assets, actors, trust boundaries, entry points, and data flows. Enumerate threats, prerequisites, impact, existing controls, mitigations, residual risk, and validation tests. Prioritize plausible paths; do not provide exploit weaponization. ``` ## P39 — Secure code review **Category:** Security **Purpose:** Find actionable vulnerabilities **Use when:** Code needs defensive review. **Variables:** CODE ```text Review [CODE] for authentication, authorization, injection, SSRF, XSS, CSRF, path traversal, unsafe deserialization, secrets, dependency, logging, and race issues. Cite exact evidence, rate severity and confidence, propose minimal patches, and include negative tests. ``` ## P40 — Prompt injection review **Category:** Security **Purpose:** Harden an agent against untrusted content **Use when:** An agent reads webpages, files, or tool output. **Variables:** AGENT FLOW ```text Assess [AGENT FLOW] for prompt injection. Map trusted vs untrusted instructions, data/tool boundaries, exfiltration paths, excessive permissions, confirmation gaps, and indirect injection. Recommend allowlists, content isolation, least privilege, validation, and adversarial tests. ``` ## P41 — Secrets exposure audit **Category:** Security **Purpose:** Find credentials and unsafe handling **Use when:** A repository or workflow may leak secrets. **Variables:** SCOPE ```text Audit [SCOPE] for hard-coded secrets, verbose logs, build artifacts, client-side exposure, insecure storage, overbroad tokens, rotation gaps, and repository history. Report evidence without reproducing full secrets; give containment, rotation, and prevention steps. ``` ## P42 — Privacy review **Category:** Security **Purpose:** Assess personal-data handling **Use when:** A feature collects or sends user data. **Variables:** FEATURE ```text Review [FEATURE] data lifecycle: collection, purpose, minimization, consent, classification, storage, encryption, access, processors, retention, deletion, export, logging, and incident handling. Identify jurisdiction assumptions and questions for counsel. ``` ## P43 — Dependency triage **Category:** Security **Purpose:** Evaluate a vulnerable package alert **Use when:** A scanner reported a CVE or advisory. **Variables:** ADVISORY, DEPENDENCY/VERSION ```text Triage [ADVISORY] in [DEPENDENCY/VERSION]. Verify the primary advisory, vulnerable range, reachability, exploit prerequisites, runtime exposure, fixes, breaking changes, mitigations, and tests. Distinguish installed, bundled, and executed code. ``` ## P44 — Runbook generator **Category:** System administration **Purpose:** Create a safe operational runbook **Use when:** Operators need a reliable response path. **Variables:** ALERT/FAILURE, ENVIRONMENT ```text Create a runbook for [ALERT/FAILURE] in [ENVIRONMENT]. Include impact, access needed, read-only diagnosis, decision tree, mitigations ordered by reversibility, commands with placeholders, verification, rollback, escalation, and evidence to retain. ``` ## P45 — Log analysis **Category:** System administration **Purpose:** Extract signal from logs **Use when:** Large logs need structured triage. **Variables:** LOGS, SYMPTOM ```text Analyze [LOGS] for [SYMPTOM]. Normalize timestamps/timezone, group signatures, correlate request/user IDs, find first anomaly, quantify frequency, distinguish cause from cascade, and recommend the next highest-information check. Redact secrets and personal data. ``` ## P46 — Config diff review **Category:** System administration **Purpose:** Explain operational impact **Use when:** A configuration change needs review. **Variables:** SERVICE, DIFF ```text Review this configuration diff for [SERVICE]: [DIFF]. Explain behavior changes, precedence, environment assumptions, restart/reload needs, security and availability impact, invalid/deprecated keys, rollback, and verification commands. ``` ## P47 — Capacity plan **Category:** System administration **Purpose:** Estimate resources with uncertainty **Use when:** Expected load must map to infrastructure. **Variables:** SYSTEM, TRAFFIC/SIZES/SLO ```text Create a capacity plan for [SYSTEM]. Inputs: [TRAFFIC/SIZES/SLO]. Show assumptions, units, peak and growth factors, CPU/memory/storage/network estimates, bottlenecks, headroom, cost drivers, load-test design, scaling triggers, and sensitivity ranges. ``` ## P48 — Model selection **Category:** AI operations **Purpose:** Choose a model for a workload **Use when:** Quality, latency, privacy, and cost trade off. **Variables:** TASK ```text Design a model-selection evaluation for [TASK]. Define quality rubric, representative dataset, privacy constraints, context/tool needs, latency and cost measures, failure taxonomy, human review, statistical comparison, and routing/fallback policy. Use current official model information. ``` ## P49 — RAG evaluation **Category:** AI operations **Purpose:** Measure retrieval and answer quality **Use when:** A retrieval system gives plausible but unreliable answers. **Variables:** RAG SYSTEM ```text Evaluate [RAG SYSTEM]. Separate retrieval from generation. Define gold questions, recall/precision or ranking metrics, groundedness, citation accuracy, abstention, freshness, permissions, latency, and cost. Include error slices and regression gates. ``` ## P50 — Context compression **Category:** AI operations **Purpose:** Reduce tokens without losing decisions **Use when:** A long thread or document exceeds useful context. **Variables:** CONTENT ```text Compress [CONTENT] for continued work. Preserve goals, decisions, constraints, definitions, interfaces, evidence, unresolved questions, and next actions. Remove repetition and speculation. Clearly separate facts, assumptions, and discarded options. ``` ## P51 — System instruction audit **Category:** AI operations **Purpose:** Make instructions coherent and enforceable **Use when:** An agent has overlapping rules. **Variables:** INSTRUCTIONS ```text Audit [INSTRUCTIONS] for conflicts, ambiguity, unreachable requirements, priority confusion, unsafe autonomy, missing confirmation points, and poor testability. Propose a shorter hierarchy and adversarial scenarios that reveal failures. ``` ## P52 — Cost-control plan **Category:** AI operations **Purpose:** Reduce AI spend without hiding quality loss **Use when:** Usage costs are growing. **Variables:** AI WORKLOAD ```text Create a cost-control plan for [AI WORKLOAD]. Break down tokens, model mix, retries, tool calls, caching, batching, context growth, and failed requests. Rank savings by effort and quality risk; define guardrails, dashboards, budgets, and rollback thresholds. ```