Reference
AIDLC Prompt Library
Prompts for every phase of the life cycle, written to be adapted rather than pasted. Each one is a structure - replace the bracketed placeholders with your real context, because the specificity you add is what determines the quality of what comes back.
Last reviewed: August 2026
How to Use These
- Replace every bracket before you send it. A prompt that still contains a placeholder is a prompt asking the AI to invent your context, and it will.
- Give the agent the real files where your tool can reach them. Pointing at a path beats pasting a fragment - a fragment forces the agent to guess about everything you left out.
- Ask for assumptions and questions before implementation on anything non-trivial. A wrong plan costs a sentence to correct; a wrong diff costs a morning.
- Review the output against the spec, not against your hopes. Where the result is wrong, the fix is usually upstream - sharpen the context and run it again.
Analyze
Phase 01Prompts for requirements, research, and risk - the work that happens before anything is designed. Full detail on the Analyze phase.
Extract requirements from a stakeholder brief
Read the material below and extract the requirements it implies.
Source material: [paste the transcript, brief, ticket thread, or email chain]
Group what you find into functional requirements, non-functional requirements, and constraints. For each one, note whether it was stated outright or inferred by you.
List any statements that contradict each other, and any requirement you could not pin down without asking a person. Do not resolve a contradiction by picking a side - surface it and stop there.Surface the questions nobody has asked yet
Here are the requirements as they stand today: [paste the current requirements]
Before we move to design, list every question that still needs a human answer. For each one, say who is likely to know and what we would build wrong if we guessed instead.
Rank the questions by how expensive the wrong guess would be, and flag any assumption you are already carrying that nobody has validated.Name the technical risks before committing
What we are building: [short description]
Stack and constraints: [languages, platforms, hosting, compliance, team size, deadline]
Identify the technical risks in this work - dependencies, unknowns, integration points, capacity limits, and anything that could not be undone cheaply. For each risk give the trigger that would make it real, the likely impact, and the cheapest way to reduce it now.
State the assumptions your assessment rests on. Where you do not have enough information to judge, say so rather than estimating.Compare approaches before choosing one
Decision to make: [e.g. which authentication approach to use]
Candidates: [option A], [option B], [option C]
What matters to us, in priority order: [security, cost, team familiarity, time to ship, operational burden]
Compare the candidates against those criteria, including the drawbacks of the one you end up recommending.
Note where the comparison depends on facts you do not have, and tell me what to go verify before I treat this as decided.Ideate
Phase 02Prompts for architecture, contracts, and specifications - turning agreed requirements into something an agent can execute. Full detail on the Ideate phase.
Generate competing designs instead of one
Requirements and constraints: [paste what came out of the Analyze phase]
Propose three genuinely different architectures for this - not three variations of the same idea. For each: the shape of the solution, what it optimizes for, what it gives up, and the conditions under which it would be the wrong choice.
Do not recommend one until the end, and when you do, name the requirement that drove the call and the assumption that would overturn it.Compare two architectural approaches
We are deciding between [approach A] and [approach B] for [system or component].
Our constraints: [scale, latency, team experience, existing infrastructure, budget]
Compare them on complexity, operational burden, failure modes, testability, and the cost of reversing the decision later. Be specific to our situation rather than listing generic pros and cons.
Flag any point where the honest answer is that it depends on something we have not measured, and say what to measure.Design the API contract
Design the interface for [feature or service].
Consumers: [who calls it and from where]
Data it works with: [entities and relationships]
Non-negotiables: [auth model, versioning policy, error format, pagination, rate limits]
Produce the contract - resources or operations, request and response shapes, status codes, and error cases.
Then list the design decisions you made that the brief did not cover, so I can confirm or overrule each one before anything is built against it.Write a spec an agent can execute
Turn the following into a specification precise enough for a coding agent to implement without guessing: [the design or feature]
Include the goal, the files or modules involved, the interfaces that must not change, acceptance criteria written as things I can check, what is explicitly out of scope, and a diagram of the flow in a text-based diagram format.
Finish with the open questions the spec does not answer. A spec that hides an unknown is worse than one that names it.Develop
Phase 03Prompts for scoping, implementing, reviewing, and debugging - where the agent does the typing and you stay accountable for the diff. Full detail on the Develop phase.
Plan the work before any code is written
Task: [what needs to change]
Relevant code: [file paths, or point at the repository if your tool can read it]
Constraints: [patterns to follow, files not to touch, tests that must keep passing]
Before changing anything, tell me how you would do it: the files you would touch, in what order, and where the risk is.
List your assumptions and any question whose answer would change the plan. Do not start until I approve it.Hand off a scoped implementation task
Implement [feature] in [file paths or module].
Follow the patterns already used in [reference file] rather than introducing new ones.
It is done when: [acceptance criteria, including the tests that must pass]
Do not touch: [files, directories, or behavior that must stay as-is]
Run the tests and the linter when you are finished and fix what you broke. Then show me the full diff plus a short list of anything you decided that these instructions did not cover.Review a diff you did not write
Review this change as though you did not write it and are accountable for it in production: [paste the diff, or name the branch or commit range]
What it is supposed to do: [intent]
Look for correctness bugs, unhandled errors, security issues, race conditions, and behavior that changed without being asked to change.
Separate what is actually wrong from what is only a matter of taste, and mark which findings you are confident about and which are guesses. If the change does not do what it claims, lead with that.Debug from the evidence, not a guess
Symptom: [error message, stack trace, or observed behavior]
When it happens: [reproduction steps, frequency, environment]
Relevant code: [file paths or pasted source]
Already ruled out: [what has been checked]
Work out the most likely root causes, ordered by how well each explains all of the evidence rather than the loudest part of it. For each, give me the cheapest way to confirm or eliminate it.
Do not propose a fix until we agree on the cause.Launch
Phase 04Prompts for tests, pipelines, and the path to production - including the way back out. Full detail on the Launch phase.
Generate tests worth trusting
Write tests for [module, endpoint, or user flow] using [test framework].
Behavior under test: [what it is supposed to do, including the rules that are easy to get wrong]
Cover the normal path, the boundaries, the error cases, and the cases where the input is valid but the state is not. Match the structure of the existing tests in [reference test file].
List the behaviors you could not meaningfully test and why, instead of writing a test that passes without asserting anything.Build the pipeline
Write a CI pipeline for [the CI platform we already use].
Repository: [language, package manager, build command, test command]
It should: [install, lint, test, build, and deploy to [environment] on [trigger]]
Keep secrets out of the file and name the ones the pipeline will need from me.
Call out any step that will be slow or flaky, and any step that could fail silently instead of failing the build.Write the deploy path and the way back
We deploy [application] to [target environment and hosting].
How it works today: [current process, manual steps included]
Write the deployment procedure and, beside it, the rollback procedure - what to run, how to tell it worked, and how long the rollback takes.
Flag every step that is irreversible or that changes data, and mark the points where a human should confirm before continuing.Validate the release after it ships
We are releasing [change] to [environment].
Critical paths that must keep working: [flows, endpoints, integrations]
Write a post-deployment check that proves the release is healthy - what to call, what a good response looks like, and how long to watch before declaring success.
Then tell me what this check would not catch. I want the blind spots named before I rely on a green result.Curate
Phase 05Prompts for monitoring, incidents, and keeping the written record honest as the system moves. Full detail on the Curate phase.
Triage what the logs are actually saying
Here is [time window] of logs from [system]: [paste the logs, or point at the source]
Normal for this system: [baseline traffic pattern, known noisy errors]
Group the entries into recurring patterns, identify what changed against that baseline, and separate genuine anomalies from noise we already know about.
Quote the evidence for anything you flag. Where a pattern is ambiguous, say so rather than assigning it a cause.Run a root cause analysis
Incident: [what users saw, when it started, whether it is still happening]
Evidence: [logs, traces, metrics, recent deploys, config changes]
System context: [architecture, dependencies, anything unusual that day]
Work backward from the symptom. Give the candidate causes in order of how well each one fits the whole timeline, what would confirm it, and which contributing factors made the failure possible at all.
Keep what the evidence shows separate from what you are inferring.Find the performance problem
[Metric] has degraded from [before] to [after], starting [when].
Data available: [profiling output, query plans, traces, resource metrics]
Relevant code: [file paths or pasted source]
Identify the likely bottlenecks in order of expected impact. For each, give the change that would address it and the risk of making that change.
Say which conclusions come from the data and which are educated guesses. Do not optimize anything I have not confirmed is the bottleneck.Keep the written record current
These changed since the documentation was last updated: [file paths, commit range, or a summary of the changes]
Documentation to review: [README, API docs, runbooks, and the project context file the agents read]
Identify every place the docs now contradict the code and propose the correction for each.
Also note the corrections I have been making by hand more than once - those belong in the project context file so the next task starts from them.
Flag anything documented that no longer exists, and anything that exists but was never documented.Frequently Asked Questions
Treat each one as a starting structure, not a magic phrase. Replace the bracketed placeholders with your real context - the actual file paths, constraints, and acceptance criteria - because the specificity you add is what determines the quality of the result.
Yes. They are written to be tool-agnostic and carry no vendor-specific syntax, so they work in a chat assistant or a coding agent alike. What changes between tools is how much context the tool can reach on its own, not how you should ask.
Because the most expensive failure mode is an agent confidently building the wrong thing. Asking it to surface assumptions and gaps before it acts turns a silent mistake into a cheap conversation, which is much of the point of the Analyze and Ideate phases.
A Prompt Is Only the Opening Move
The context you supply around it, and the review you apply to what comes back, are what make the result shippable.