| PromptSharp Dev | SAMPLE ISSUEPRO EDITION |
Copy-paste AI prompts for code review, debugging, design docs, and tests that matter. Wednesday, July 8, 2026 · For Software Engineers · Tech Leads & Staff Engineers · Platform & DevEx Teams | SAMPLE ISSUE — a representative edition of PromptSharp Dev prepared for launch. This is what every issue looks like. Your full brief — all five sections’ prompts, ready to paste into your own LLM. Plus the searchable archive of every prompt we’ve shipped. One ready-to-run prompt a day for the exact work engineers do — PR review sweeps, root-cause investigations, design docs, risk-ranked test plans, and toil audits. Paste into your own LLM. No news, no fluff. | Ship Fewer Regressions Code Review & Quality For: Engineers reviewing PRs — or pre-reviewing their own Pre-review sweep: your own PR through a security-and-edge-case lens The PR is 'done'. Run the pre-review sweep so human reviewers spend their attention on design — not on nits and the missed null check. You are a staff engineer reviewing a pull request. I will paste the diff and its context. Produce:
A) REVIEW TABLE — columns: file/line reference, severity (blocker / major / nit), category (correctness, security, performance, readability, tests), the issue in one sentence, and a suggested fix as a concrete code change.
B) EDGE-CASE LIST — inputs and states the diff does not handle: empty, null, concurrent access, oversized input, malformed input, permission-denied.
C) VERDICT — approve or request-changes, plus the 2 highest-risk lines in the diff and why.
Inputs: [PASTE DIFF] · [WHAT THE CHANGE DOES + WHY] · [LANGUAGE/FRAMEWORK + TEAM CONVENTIONS]
Rules: Do not invent code that is not in the diff — reference only pasted lines. Any claim about behavior you cannot see (callers, config, upstream state) must be marked "verify in repo". Never echo secrets or keys, and do not include proprietary code beyond what I pasted. Why it works: LLM review works best as a filter before human review — the machine catches the mechanical 80% so humans argue about design. Severity plus category forces triage instead of a wall of nits, and the 'verify in repo' rule prevents confident-but-wrong claims about code the model cannot see. | | Fix the Cause, Not the Symptom Debugging & Root-Cause For: Engineers investigating production bugs under time pressure Root-cause interrogation: a hypothesis ladder from a bug report Prod bug, vague repro, clock ticking. Structure the investigation before you start changing code at random. You are a senior engineer running a structured root-cause investigation. I will paste the symptoms and every piece of evidence I have. Produce:
A) HYPOTHESIS LADDER — 5 ranked hypotheses. For each: the mechanism, which pasted evidence supports or contradicts it, and the cheapest discriminating test (a log line to add, a git bisect range, a feature-flag toggle, a minimal repro).
B) EVIDENCE GAPS — what I have not given you that would most change the ranking, in priority order.
C) PREVENTION — run 5-whys on the top hypothesis and name the class-level fix (test, lint rule, alert, type change) that prevents the whole category from recurring.
Inputs: [SYMPTOM + WHEN FIRST SEEN] · [PASTE LOGS / STACK TRACE / RECENT DIFFS] · [ENVIRONMENT + RECENT DEPLOYS]
Rules: Do not invent stack frames, log lines, or code behavior not in my paste — every hypothesis must cite the evidence line it rests on, and pure speculation must be labeled as such. Verify the discriminating test's result before acting on any hypothesis. Strip credentials and user PII from anything you echo back. Why it works: Ranked hypotheses with discriminating tests is how senior engineers actually debug — it converts panic into a binary-search plan. The prevention step turns one fix into a class fix, which is the difference between closing a ticket and improving the system. | | Decide in Writing Architecture & Design Docs For: Engineers proposing systems, migrations, and big refactors Design doc skeleton with the alternatives you'll actually be asked about New system or big refactor. Draft the design doc with real alternatives and failure modes before the review meeting drafts it for you. You are a principal engineer drafting a design document. I will describe the problem and constraints. Produce:
A) DOC SKELETON — context and problem, goals and explicit non-goals, proposed design (components, data flow, API sketch), and capacity/scale assumptions with each number labeled measured or estimated.
B) ALTERNATIVES TABLE — at least 2 genuinely considered alternatives, columns: option, why it is plausible, why rejected (cost, risk, ops burden), and reversibility if we are wrong.
C) FAILURE MODES — a table: failure, blast radius, how we detect it (alert or metric), mitigation. Include the rollout and rollback plan.
D) OPEN QUESTIONS — each with an owner and a decide-by date.
Inputs: [PROBLEM + CONSTRAINTS] · [CURRENT ARCHITECTURE NOTES] · [SCALE: QPS / DATA SIZE / TEAM SIZE]
Rules: Do not invent load numbers, SLAs, or dependency behavior — mark every unknown "verify with owner". Alternatives must be real options someone would defend, not strawmen. Keep proprietary identifiers out beyond what I pasted. Why it works: Design reviews go sideways on missing alternatives and unstated failure modes. Writing rejected-because with reversibility does the reviewers' job for them, and honest measured-vs-estimated labels on scale numbers are what separate a design doc from a pitch. | | Break It Before Users Do Testing For: Engineers writing test plans for new features and risky changes Test-plan generator: risk-ranked cases from a diff or spec Feature complete, coverage thin. Generate the test plan ranked by what would actually hurt in production. You are a test engineer designing a risk-based test plan. I will paste the spec or the diff. Produce:
A) TEST MATRIX — columns: behavior under test, case type (happy path / boundary / error / concurrency / security / regression), priority (P0 = data loss or crash, P1 = wrong result, P2 = cosmetic), suggested level (unit / integration / e2e), and a one-line sketch of the assertion.
B) BOUNDARY ANALYSIS — for each input in the spec: the min, max, empty, null, unicode, and oversized cases that apply.
C) NON-DETERMINISM CHECKLIST — time, ordering, retries, clock, locale, randomness: which apply here, and the seam to control each in a test.
Inputs: [PASTE SPEC OR DIFF] · [STACK + TEST FRAMEWORK] · [WHAT IS ALREADY COVERED]
Rules: Do not invent existing coverage or code behavior — every case must trace to the pasted spec or diff, and assumptions about the implementation must be marked "verify against implementation". No secrets or production data in fixture sketches. Why it works: Coverage percentages lie; risk-ranked behavior coverage does not. Priority-by-blast-radius keeps the suite lean enough to maintain, and the non-determinism checklist targets the exact flake sources that quietly destroy a team's trust in CI. | | Compound Your Hours Dev Productivity For: Engineers and leads reclaiming time from toil and context switches Toil audit: find the hours a week your workflow is leaking You suspect the week disappears into builds, reviews, and context switches. Audit it and get an automation plan with paybacks. You are a developer-productivity engineer auditing one engineer's week. I will paste a work log. Produce:
A) TOIL TABLE — columns: recurring task, frequency, minutes per occurrence, weekly cost, automation candidate (script / alias / CI change / template / bot), build-cost estimate, payback in weeks — sorted by payback, fastest first.
B) QUICK WINS — the top 3 automations buildable in under an hour each, with an implementation sketch (tool, trigger, rough logic).
C) CONTEXT-SWITCH MAP — the 3 worst interrupt patterns in the log and one calendar or process change for each.
Inputs: [PASTE A 1-WEEK WORK LOG OR HONEST RECONSTRUCTION] · [STACK + TOOLING] · [TEAM PROCESS CONSTRAINTS]
Rules: Do not invent time data — compute only from my log and label anything reconstructed as an estimate. Verify the payback math before I commit build time. Name no colleagues and keep personal data out of the tables — this audits systems, not people. Why it works: Payback-sorted toil is the difference between automation as procrastination and automation that compounds. Capping quick wins at an hour forces starts instead of plans, and systems-not-people keeps the audit honest and safe to share with the team. | | | | Prompt of the Week (Pro) This week's bonus: a legacy-code characterization prompt that wraps an untested module in behavior-pinning tests before you touch it — with a strict no-invented-behavior rule so the tests document what IS, not what should be. | Your searchable archive Every prompt we’ve shipped, organized by section and task. Open archive → | Prompts reflect real engineering workflows. We make no correctness guarantees — you own the output; review and test everything before it ships. Never paste secrets, credentials, or proprietary code you are not authorized to share into any LLM. PromptSharp Dev is part of the PromptSharp family — an educational product. Prompts are templates: not investment advice, legal advice, tax advice, or professional advice of any kind. You are responsible for verifying every output. SAMPLE ISSUE — a representative edition prepared for the PromptSharp launch, not a record of a previously sent issue. Subscribe · Prompt archive · Go Pro · Unsubscribe |
|