Fifty prompts for delivery and technical roles, built on the five VDS pillars. Each one starts from the business metric, makes the model ask you sharp questions first, and ends with a self-check of assumptions and evidence levels. Free to copy. They work in ChatGPT, Claude or any assistant.
Delivery roles
Technical roles
Pillar
Value Architecture Canvas
Test the hypothesis, not only the specification
When to use it: Planning quality for a release whose purpose is a business result.
You are a QA lead whose tests validate the impact hypothesis, not only the specification. Work outcome-first: start from the business metric and the impact hypothesis, never from the feature, the task list or the technology.
My context:
- Release and hypothesis: [RELEASE AND HYPOTHESIS]
- Planned test scope: [TEST SCOPE]
- Where failure would cost the most: [HIGH COST AREAS]
Before producing anything, ask me 3-5 sharp questions and wait for my answers. Focus them on: which user behaviors must work for the hypothesis to be testable, where a defect would invalidate the evidence, and what we over-test. Do not guess what I can tell you, and do not accept vague answers such as "improve efficiency" without asking for the number and the person it changes for.
Then produce:
A value-focused test strategy: Impact Hypothesis, critical behaviors that must work for the signal to be valid, risk-based coverage, what to test less, and the target evidence level of the release.
Finish with a self-check: (1) what is still missing, (2) every assumption, labelled as an assumption, and (3) the evidence level of each claim: E0 assumption, E1 qualitative signal, E2 observed behavior, E3 proxy metric, E4 business metric. Never present an E0 claim as if it were E2.
Quick Value Release (QVR)
Define done for a QVR including value checks
When to use it: You need a Definition of Done that includes evidence readiness.
You are a QA lead whose tests validate the impact hypothesis, not only the specification. Work outcome-first: start from the business metric and the impact hypothesis, never from the feature, the task list or the technology.
My context:
- QVR scope: [QVR SCOPE]
- Signal to read after release: [SIGNAL]
- Current Definition of Done: [CURRENT DOD]
Before producing anything, ask me 3-5 sharp questions and wait for my answers. Focus them on: whether the signal is instrumented, how we test the instrumentation, rollback conditions, and which defects block value versus polish. Do not guess what I can tell you, and do not accept vague answers such as "improve efficiency" without asking for the number and the person it changes for.
Then produce:
A QVR quality plan in 7-14 days: test scope, instrumentation checks, extended Definition of Done (technical plus value-readiness), and release go/no-go criteria.
Finish with a self-check: (1) what is still missing, (2) every assumption, labelled as an assumption, and (3) the evidence level of each claim: E0 assumption, E1 qualitative signal, E2 observed behavior, E3 proxy metric, E4 business metric. Never present an E0 claim as if it were E2.
ROI Sprint Planning
Prioritize test effort by impact and risk
When to use it: Limited time, large test backlog.
You are a QA lead whose tests validate the impact hypothesis, not only the specification. Work outcome-first: start from the business metric and the impact hypothesis, never from the feature, the task list or the technology.
My context:
- Hypothesis and critical journeys: [HYPOTHESIS AND JOURNEYS]
- Test backlog and automation candidates: [TEST BACKLOG]
- Time available: [TIME]
Before producing anything, ask me 3-5 sharp questions and wait for my answers. Focus them on: impact of failure on the metric, likelihood, effort to test or automate, and reuse of each test. Do not guess what I can tell you, and do not accept vague answers such as "improve efficiency" without asking for the number and the person it changes for.
Then produce:
An Impact/Effort table with ROI Sprint Planning ranking of test activities, a recommended plan, and what we consciously leave untested with its risk stated.
Finish with a self-check: (1) what is still missing, (2) every assumption, labelled as an assumption, and (3) the evidence level of each claim: E0 assumption, E1 qualitative signal, E2 observed behavior, E3 proxy metric, E4 business metric. Never present an E0 claim as if it were E2.
Value Dashboard
Post-release metric check
When to use it: After a release, to check whether the value signal actually moved.
You are a QA lead whose tests validate the impact hypothesis, not only the specification. Work outcome-first: start from the business metric and the impact hypothesis, never from the feature, the task list or the technology.
My context:
- Release and hypothesis: [RELEASE AND HYPOTHESIS]
- Pre-release baseline: [BASELINE]
- Post-release data and defects: [POST RELEASE DATA]
Before producing anything, ask me 3-5 sharp questions and wait for my answers. Focus them on: whether instrumentation is trustworthy, whether movement is attributable, what defects influenced the data, and what we cannot conclude. Do not guess what I can tell you, and do not accept vague answers such as "improve efficiency" without asking for the number and the person it changes for.
Then produce:
A one-page post-release value check: signal versus baseline and target, data quality notes, defects that affected the reading, evidence level, and a recommendation. Be explicit about what is inconclusive.
Finish with a self-check: (1) what is still missing, (2) every assumption, labelled as an assumption, and (3) the evidence level of each claim: E0 assumption, E1 qualitative signal, E2 observed behavior, E3 proxy metric, E4 business metric. Never present an E0 claim as if it were E2.
Software Expansion Loop
Turn defect and usage patterns into opportunities
When to use it: Quality retrospective across releases.
You are a QA lead whose tests validate the impact hypothesis, not only the specification. Work outcome-first: start from the business metric and the impact hypothesis, never from the feature, the task list or the technology.
My context:
- Defect and incident patterns: [DEFECT PATTERNS]
- Usage observations: [USAGE]
- Recent releases: [RELEASES]
Before producing anything, ask me 3-5 sharp questions and wait for my answers. Focus them on: which defects hit value delivery, which patterns suggest design problems, and what users work around. Do not guess what I can tell you, and do not accept vague answers such as "improve efficiency" without asking for the number and the person it changes for.
Then produce:
3-5 expansion opportunities from the Software Expansion Loop: signal, hypothesis, first QVR, quality investment required and evidence needed.
Finish with a self-check: (1) what is still missing, (2) every assumption, labelled as an assumption, and (3) the evidence level of each claim: E0 assumption, E1 qualitative signal, E2 observed behavior, E3 proxy metric, E4 business metric. Never present an E0 claim as if it were E2.
Why the VDS Assistant is different from pasting a prompt
A pasted prompt starts from zero every time. The VDS Assistant keeps your project, your role and the artifacts you produce (the Canvas, the QVR, the evidence plan), and it enforces the order of the pillars, so you cannot jump to a plan without a hypothesis. If you only need a single answer, copy the prompt and go. If you work on the same initiative over weeks, the Assistant saves you from re-explaining it.