# AI Coding Starter Kit: Free Sample > **This is a free sample** of the AI Coding Starter Kit by 100mil.org. It contains 8 prompts written for this sample, not taken from the kit's prompt library, plus a summary of the debugging loop taught in the workbook. You are welcome to use them. **The full kit contains:** - **A workbook (PDF):** 8 chapters on how AI coding assistants work and where they fail, setting up, planning, prompting, reading code you did not write, debugging, safety and quality, and shipping. Each chapter ends with an exercise and a checklist, and a glossary closes the book. - **A starter project:** "Link Shelf", a small working web app in plain HTML, CSS, and JavaScript (add, edit, delete, tags, search, saved in the browser), with no build step and no dependencies. Its README has a code tour and 10 graded exercises that extend it. - **A prompt library:** 40 reusable prompts in 8 groups: planning, explaining, writing code, debugging, testing, refactoring, accessibility, and security review. - **Three checklists:** launch, security basics, and debugging. ## How to use these prompts Replace each `[BRACKETED VARIABLE]` with your own text. Paste real code rather than describing it. Never paste passwords, API keys, or other people's personal data. Test every answer before you keep it. --- ## 1. Check code against my project brief **When to use:** An assistant just wrote code for you, and you want to know whether it followed your rules. ```text Here is my project brief: [PROJECT BRIEF] And here is code an assistant just wrote for me: [PASTE CODE] Check the code against the brief, rule by rule. For each rule (technology, files, data shape, validation, accessibility, how user text is displayed), answer "followed", "broken", or "not applicable", and quote the line that shows it. Then list anything the code adds that the brief did not ask for. Do not fix anything yet. ``` ## 2. Explain a change before I accept it **When to use:** You are looking at a diff, or before-and-after code, and are about to accept it. ```text Here is a change I am about to accept: [PASTE DIFF, OR THE CODE BEFORE AND AFTER] In plain language: 1. What does this change do, in one or two sentences? 2. Which functions, files, or stored data does it affect? 3. What could it break that is not obvious from the diff? 4. What should I test by hand to be confident it works? ``` ## 3. Be my rubber duck **When to use:** You are stuck on a bug and want to find the cause yourself, with guidance. ```text I am stuck on a bug and I want to find the cause myself. Bug: [ONE-SENTENCE DESCRIPTION] Act as a rubber duck that asks good questions. Ask me one question at a time about what I expected, what I observed, and what I have already checked, and wait for my answer each time. Do not suggest causes or fixes unless I write "hint". After [NUMBER] questions, summarize what we have learned so far. ``` ## 4. Pick the smallest next step **When to use:** You have a list of unfinished features and do not know where to start. ```text Here is my project brief: [PROJECT BRIEF] What already works: [WORKING FEATURES] What is left for version 1: [REMAINING FEATURES] Pick the single smallest next step that moves the app forward and can be tested in the browser on its own. Explain why it should come first, which files it will touch, and give a one-line manual test for it. Do not write the code yet. ``` ## 5. Write empty states and error messages **When to use:** Your app needs messages for empty lists, failed searches, invalid input, or errors. ```text My app: [ONE-SENTENCE DESCRIPTION] These are the situations where the app needs to show a message: [LIST OF SITUATIONS, e.g. no items yet, search finds nothing, invalid web address, saving failed] Write the message for each: short, plain language, no blame, and telling the user what to do next. Give two options per situation, each at most [NUMBER] words, and say which you prefer and why. ``` ## 6. Write a commit message **When to use:** A change works and you are about to commit it with Git. ```text Here is the diff of the change I am about to commit: [PASTE OUTPUT OF git diff] Write a commit message: a summary line of at most 60 characters in the imperative mood (for example "Add duplicate address warning"), a blank line, then up to three short lines explaining why the change was made. Do not describe anything that is not in the diff. ``` ## 7. Turn this session into a learning note **When to use:** At the end of a working session, to keep what you learned. ```text Here is what I worked on today: [SHORT DESCRIPTION, OR THE KEY CODE AND QUESTIONS FROM THE SESSION] Write a learning note for my future self, under 200 words, with: - the concepts I used, each explained in one sentence - one mistake I made and how I found it - two questions I should be able to answer next time without help Use plain language and the names from my code. ``` ## 8. Draft a README for my project **When to use:** Your app works and you want a short description for anyone who opens the project. ```text Here is my project brief and the list of files in my project: [PROJECT BRIEF] [FILE LIST] Draft a README.md with these sections: what the app does (two sentences), how to run it locally, how to use it (3 to 5 steps), where data is stored, known limitations, and a short file overview. Write for someone who has never seen the project. Do not invent features that are not in the brief. ``` --- ## The debugging loop (summary) The workbook's debugging chapter teaches this loop in full, with a worked example and a bug-hunt exercise. The short version: 1. **Reproduce.** Write the exact steps that trigger the bug. Check that it happens every time. 2. **Observe.** Read the browser console. Write what you expected and what actually happened, one sentence each. 3. **Isolate.** Find where expected and actual first differ, using `console.log`, breakpoints, and the storage panel. Shrink it to the smallest steps and code that still show the bug. 4. **Hypothesize.** Write down one possible cause and how you will test it. 5. **Ask with evidence.** Give your assistant the steps, expected and actual results, the exact error, the minimal code, and what you already ruled out. Ask for likely causes and how to check each, not only for a fix. 6. **Change one thing.** Commit first, then make the smallest change that tests your best hypothesis. 7. **Verify.** Repeat the original steps, then test the features nearby. Remove temporary logs. 8. **Record.** Commit with a message that names the bug, and note what caused it. If two or three fixes in a row have failed, stop. Go back to your last working version and start a fresh conversation with only the smallest example of the problem. --- 100mil.org is a brand of TAKE OVER ALL LLC. Product names mentioned are trademarks of their respective owners; 100mil.org is not affiliated with or endorsed by them. Version 1.0 · November 2026 · support@100mil.org