All 26 numbered prompts from AI Augmented DevSecOps, Level 1 - Foundry, ready to copy into Claude or Codex.
Replace anything in [square brackets] with your own details before you paste. Tap a highlighted placeholder to type your details right here, then tap Copy. What you type stays on this page: it is not saved or sent anywhere.
About me: I am not a developer. I work in [your field].
My idea: [your idea in one sentence].
Who it helps: [who would use it, and how often].
Goal: help me understand what building this would involve.
Why: I want to judge whether this is worth building before anyone writes code.
How:
1. Ask me three questions first, one at a time. Offer options I can pick from.
2. Then explain, in simple numbered steps, what I would need.
3. Explain in words only for now. We build later.
Good looks like: plain words, under 200 words, every technical term explained in a few words.
Tell me which parts you are unsure about, and why.
About me: I am a beginner, not a developer. I work in [your field].
My idea: [one sentence]. Its main shape is [collect, route or combine].
Version 1 is a [prototype or pilot].
<canvas>
[paste your Idea Canvas here]
</canvas>
Goal: a one-page intent.md I can keep in my project folder.
Why: you and other AI tools will read this file before every build,
so it must say what I want in my words, not yours.
How:
1. Interview me one question at a time. Offer options I can pick from.
2. Cover: the problem, who it is for, what "done" looks like,
what data it touches, what could go wrong, what is out of scope,
and whether version 1 is a prototype or a pilot.
3. Under "what could go wrong", include the opponent I named.
4. Write the file only. We build later.
Good looks like: headings, short bullets, one page at most.
Tell me which sections are still guesses.
About me: I am a beginner, not a developer. I work in [your field].
<intent>
[paste your intent.md here]
</intent>
Goal: show me how my idea moves through the DevSecOps loop.
Why: I want to see where security and human approval fit before I start building.
How:
1. Make a table with the eight stages: Plan, Code, Build, Test,
Release, Deploy, Operate, Monitor.
2. For each stage, one plain sentence on what happens to my idea,
and one on what could go wrong for security.
3. Mark the stages where a human must approve before going on.
4. Explain in words only. We build later.
Good looks like: one table, plain words, every technical term explained in a few words.
Tell me which rows are guesses, and why.
About me: I am a beginner. I just created a project folder.
Goal: confirm you are working in the right place.
Why: everything you create will land in this folder, so it must be the right one.
How:
1. Check, then tell me the full path of the folder you are working in.
2. List the files in it. It may be empty.
3. Only look for now. Leave every file as it is.
Good looks like: one line for the path, then a short list.
If you are unsure which folder is active, say so rather than guess.
About me: I am a beginner testing the browser extension.
Goal: see how you control my browser.
Why: I want to watch what you can do on a page before I trust you with one that matters.
How:
1. Use the browser extension to open the public home page of [a news or government site].
2. Read the page. Summarize its main sections in five bullets.
3. Only read. Leave every button, form and sign-in alone.
Good looks like: five short bullets, and a one-line note of each step you took.
Tell me anything on the page you could not read.
About me: I am a beginner connecting my AI tool to GitLab and Azure.
Goal: find out which accounts you can reach right now.
Why: I keep work and personal accounts apart, and I want to see which ones you would use.
How:
1. Check whether you can reach GitLab and Azure. Only look; change nothing.
2. For each, tell me the account name you are signed in as. Check rather than guess.
3. If you are not signed in, suggest the CLI with device login, and explain the steps first.
Good looks like: a short table: service, signed in (yes or no), account, method.
Secrets stay out of this chat: never ask me to paste a password or token.
Tell me anything you could not check.
About me: [role]. I am new to building software with AI.
Goal: a set of custom instructions so you understand me in every chat.
Why: you start each chat knowing nothing about me, and I do not want to repeat myself.
How:
1. Ask me up to eight questions, one at a time. Offer options for each.
2. Cover: who I am, my goals, how I like answers, words to avoid, and my safety rules.
3. Draft the instructions. Then show me three ways to improve them.
Good looks like: under 300 words, bullet points, written in my voice.
Include this rule: "Stop and ask me before anything hard to undo, shared or public."
Tell me what you assumed without asking.
Prompt 5.2: beginner safety profile (paste into instructions)
Chapter 5: Teach the AI Who You Are
I am a beginner learning to build and host a simple site on the Azure free tier.
I learn by understanding each step, and a mistake here can cost money or expose my data.
- Explain each step simply before you do it.
- Use only free-tier or trial services. Show me the cost before creating anything.
- Keep secrets out of chat: never ask me to paste a password or token.
- Stop and ask me before anything hard to undo, shared or public:
publishing, deleting, paying, merging or sending.
- Check before you answer. If you could not check something, say "I could not check".
Goal: record this session so a new session can continue.
Why: a new session starts with no memory of this one.
Save: what we built, which accounts and folders we use, my preferences,
decisions we made and why, and what is still open.
Leave out every secret, token and password.
Then show me exactly what you saved.
Prompt 5.4: how I work (paste into CLAUDE.md or AGENTS.md)
Chapter 5: Teach the AI Who You Are
How I work:
- Work through my task list in order. Take each task all the way to done.
- Then start the next task without asking "shall I continue?"
- Stop only if: the list is done, I say stop, you are blocked, or you reach a gate.
- If blocked, write down why, tell me, and move to the next task.
- A gate is anything hard to undo, shared or public: publishing, deleting, paying, merging, sending.
- At a gate, stop and ask me. Wait for my clear yes.
- Keep each change as small as the task needs. Add nothing I did not ask for.
- Give me a one-line update as you finish each task.
- Call a task done only after you open the result and look. A green check is not proof.
- If you could not check something, say "I could not check".
Chapter 6: What You Can Build: The Volunteer Platform
Chapter 6: What You Can Build: The Volunteer Platform
About me: I am a beginner. I do not own a Mac. My idea: [one sentence].
Who uses it: [who, and on what device].
Goal: help me choose between a website, an Android app and an iPhone app.
Why: each path has different costs, reviews and hardware needs, and I can afford one first.
How:
1. Ask me two questions first. Offer options I can pick from.
2. Then compare the three paths in a table: cost, time, who reviews it,
and what hardware or accounts each step needs.
3. Recommend one path to start with, and say why.
4. Explain in words only. We build later.
Good looks like: one table and a short recommendation, under 250 words.
Mark every fee or rule you are not sure is current.
Tell me what you are unsure about, and why.
About me: beginner. I am about to host a personal website.
Goal: confirm which accounts you would use, before we build anything.
Why: my site must go into my personal accounts, never my work ones.
How:
1. Check, then tell me which GitLab user you are signed in as.
2. List the Azure subscriptions you can see, by name, and whether each is work or personal.
3. Tell me which one you would use for this site, and why.
4. Only look. Change nothing.
Good looks like: a short list I can check in one glance.
Keep tokens and keys off the screen. Tell me what you could not check.
About me: beginner. My public profile: [paste text you are happy to publish, not a login].
Goal: a personal one-page website, public on the Azure free tier, deployed by a GitLab pipeline.
Why: this is my first public site, so I want to see each step and approve the moment it goes live.
How:
1. First show me a short plan and the cost (should be zero). Wait for my OK.
2. Build the page in this project folder. Keep it simple: one page, nothing I did not ask for.
3. Set up the pipeline. Wait for me to say "go" before you deploy.
4. Give me a one-line update after each step.
Good looks like: loads on a phone, no personal data I did not provide, a public URL at the end.
After deploying, open the live page and tell me what you actually see.
Tell me what you could not check.
Goal: give the pipeline permission to deploy to Azure, safely.
Why: anyone who sees this credential could change my site, so it must never appear in a file or on screen.
Rules:
1. Store the deployment credential as a masked, protected GitLab CI/CD variable.
2. Set it directly with the command line, and keep the value off the screen.
3. Keep it out of every file in this folder.
4. Give it the least access that works.
Stop and ask me before anything hard to undo, shared or public.
Tell me where you stored it, by name only, and what you could not check.
Goal: record this session so a new session can continue.
Why: a new session starts with no memory of this one.
Save: what we built, which accounts and folders we use, my preferences,
decisions we made and why, and what is still open.
Leave out every secret, token and password.
Then show me exactly what you saved.
About me: I am a beginner. My project folder holds my personal website.
Goal: add a "last updated" date to the footer of my site, and publish it.
Why: I want to see exactly where you would stop, before you do anything I cannot take back.
How:
1. Show me your plan first. Wait for my OK.
2. Make the change in this folder only.
3. Stop and ask me before anything hard to undo, shared or public, including publishing.
Good looks like: a short numbered plan that marks each stop point with "STOP".
Tell me what you are unsure about, and why.
Goal: help me understand why you stopped, so I can choose a safe next step.
How:
1. Tell me exactly what was blocked, and by what: you, my account, or the service.
2. Tell me why, in two sentences.
3. Offer me two or three safe options I can pick from.
Rules: treat the block as a signal. Help me decide; look for no way around it.
Good looks like: plain words, under 150 words.
Tell me what you are unsure about, and why.
Prompt 8.3: my stop rules (paste into instructions)
Chapter 8: Why the AI Says No
- Stop and ask me before anything hard to undo, shared or public:
publishing, deleting, paying, merging or sending.
- Accepting terms, passing a human check and granting permissions are mine to do.
Show me the step and wait.
- When you refuse, say what blocked you, why, and what safe options I have.
About me: I am a beginner. My GitLab token is stored in Azure Key Vault.
Vault: my-book-vault. Secret name: gitlab-pat.
Goal: connect to my GitLab project using that secret.
Why: a token that appears on screen or in a file can be copied and used by anyone.
Rules:
1. Fetch the secret from the vault only when a command needs it.
2. Keep it out of output, logs and files.
3. Fetch it yourself; never ask me to paste it.
Good looks like: you list my GitLab projects, and the token never appears on screen.
Tell me what you are unsure about, and why.
Goal: add a basic static security scan (SAST) to my GitLab pipeline before it deploys.
Why: I want every change checked for common security mistakes before it reaches the live site.
How: explain what the scan checks in two sentences, then add it. Keep the change minimal.
Rules: if the scan fails, fix the cause or tell me. Keep every scan switched on.
Good looks like: the pipeline runs the scan on every change; show me where to read the results.
Tell me what this scan does not catch.
About me: I am a beginner. I host a small personal website on Azure.
Goal: [the change you want, for example "add a contact form"].
Why: I am on a free account and I want no surprise bills.
How:
1. Check, then tell me which account and subscription you will use. Wait for my OK.
2. List every Azure resource you would create or change.
3. For each one, say whether it is on the free services list, and what it costs if I go over the free limit.
4. Say what keeps charging if I forget about it.
5. Plan only for now; create nothing yet. Stop and ask me before anything hard to undo, shared or public.
Good looks like: a short table, then one line: "Expected monthly cost: X".
Tell me which prices you could not confirm, and why.
About me: I am a beginner cleaning up after a lab.
Goal: remove Azure resources I no longer need, and keep my live website.
Why: forgotten resources keep charging, but deleting the wrong one takes my site down.
How:
1. Check, then confirm which account and subscription you are using.
2. List every resource group and every resource in this subscription.
3. For each one, say what it is, what it costs, and whether my live website needs it.
4. Mark the ones you suggest deleting. Explain why in one line each.
5. Stop and ask me before deleting anything. I will approve each item by name.
6. After I approve, delete only those items, with a one-line update for each.
Then list what remains, as evidence.
Good looks like: a table I can read in two minutes; nothing deleted without my OK.
Tell me what you are unsure about, and why.
About me: I am a beginner. My personal website is live and deployed by a GitLab pipeline.
Goal: add a small line to the footer: "Last updated: [date of the last deploy]".
Why: the date proves the live page shows my latest change, not an old copy.
How:
1. Show me the change before you make it. Keep it to that one line.
2. Make the date update on every deploy, not by hand.
3. Use a merge request. Stop and ask me before merging, because merging publishes the site.
Good looks like: one line in the footer, readable on a phone.
After it deploys, open the live page and tell me the exact text you see.
Tell me what you could not check.
About me: I am a beginner. My site deploys through a GitLab pipeline.
Goal: find out why the latest pipeline on my practice branch failed, and fix it properly.
Why: a check that is switched off hides the problem instead of fixing it.
How:
1. Read the failed job log before you answer. Explain the cause in two plain sentences.
2. Propose the smallest fix. Show it to me before you change anything.
3. Keep every check switched on and as strict as it is.
4. Push the fix to the same branch. Stop and ask me before merging, because merging publishes the site.
Good looks like: the pipeline passes for the right reason, and you tell me what the reason was.
Tell me what you are unsure about, and why.
Prompt 11.3: add the live-site rule to my instructions
Chapter 11: Is It Up? Watching Your First Site
Rule: a green pipeline is not proof that a change is live.
After every deploy, open the live page and tell me exactly what you see,
including the "Last updated" date. If you could not open it, say "I could not check".
These prompts match the first edition (2026). If a prompt here differs from your copy, use this version: it has been checked against the current tools.
