# Spec Capstone Course: [Intent Engineering](https://www.devtutorials.ai/learn/intent-engineering) · Section: Review and Scale Source: https://www.devtutorials.ai/learn/intent-engineering/review-scale/capstone > Spec a new feature from scratch, or a feature in your own product, and pass every check from the course: intent, EARS, zero guesses, acceptance criteria, scope, health and decision rights. Then download your spec kit. ## One Ticket, Everything You Know A **capstone** is the final project of a course. You use everything you learned, all at once. In this lesson, there is nothing new to learn. You write one complete spec for one new ticket. The agent gets only the ticket. React app: ```text Add a Clear all filters button to the Orders grid. ``` ASP.NET Core app: ```text Add an endpoint to delete orders. ``` You already know what happens next. The ticket leaves many details out. So the agent will guess, unless your spec answers every one. **Simple lesson:** the capstone checks if you can put every lesson together in one file. ### A Real-World Example Think about a driving test. - One lesson taught mirrors. - One lesson taught parking. - One lesson taught roundabouts. The test teaches nothing new. It checks if you can do all of it together, without help. The capstone is your driving test for specs. Click the button and open the exercise. - **Start:** the file `capstone.md` is full of TODO lines. - **Check:** press **Check my spec** and read the first problem. - **Fix:** work through the file one part at a time, until every check passes. **Simple lesson:** write one file that leaves the agent nothing to guess, and has a check for every rule. ## TL;DR 1. **Capstone** = the final project. It uses everything from the course. 2. You write one file: `capstone.md`. 3. It has two parts: - `# Intent` → who it is for, the problem, the goal and the owner - `# Spec` → the rules, the checks and the limits 4. Your file must have: - a user, a problem with a cost, an outcome with a number and an owner - requirements written in EARS - no guesses left - an acceptance criterion for every requirement - at least one non-goal - at least one health metric - a rule for the risky action 5. **Readiness** = a score out of 100 for how ready your spec is. You need 85 or more. 6. You can use the practice ticket or your own product idea. 7. At the end, you download your spec as a kit for your own tool. ## What You Will Learn In this lesson, you will learn how to: 1. Write a full intent and spec in one file. 2. Follow the note from your own stakeholder. 3. Remove every guess. 4. Give every requirement a check. 5. Pass the hidden checks and the health check. 6. Download your finished spec kit. **About the checks in this lesson** - The agent and the checks follow fixed rules. - They give the same result every time. - No AI model marks your work. ## The Shape of capstone.md ### Two Parts, One File Every capstone file has the same shape: ```text # Intent User: … Problem: … Outcome: … Owner: … # Spec ## Requirements - REQ-1: When …, the … shall …. ## Acceptance criteria - AC-1 (REQ-1): Given …, when …, then …. ## Non-goals ## Health metrics ## Decision rights - Ask first: … ``` Look at the start of each acceptance criterion: ```text AC-1 (REQ-1) ``` The part in brackets names the requirement this check proves. **Coverage** = how many requirements have a check. The checker counts it from these brackets. If one requirement has no check, coverage is below 100%, and the capstone fails. **Simple lesson:** every REQ needs its own AC, with the REQ name in brackets. ## Work Through It Watch a capstone file fill up, one part at a time. Each step adds one part. The checks run again each time. The readiness score can drop for a moment. New requirements without checks cost points, until you add their ACs. ### Start With Intent Begin with the `# Intent` part. The stakeholder note already has what you need: - who the user is - what is hard for them today - what it costs them - what success looks like, as a number Copy those facts into the four Intent lines. If one line is missing, the agent guesses who it is for or what "done" means. ### Then the Decisions Next, write the requirements. Your stakeholder's note lists some decisions. For example: keep the sort, or reset it? - Write one EARS requirement for each decision. - A line that fails the EARS check does not count. It is treated as missing. **Important:** there are three stakeholders, called A, B and C. Each one wants some things done differently. Watch one finished spec, written for stakeholder A, checked against all three. The spec is right for A. It is wrong for B and C, because they asked for different things. **Simple lesson:** read your own stakeholder's note. Do not copy someone else's answer. ### Then Scope, Health and Rights Three short parts finish the file. - **Non-goal** = something the agent must leave alone. Example: "Do not change saved views." - **Health metric** = something that must not get worse, with a number. Example: "The grid re-renders in under 200 ms." - **Decision rule** = a risky action the agent must ask about first. Example: "Ask first: the migration that adds the DeletedAt column." These parts stop the agent from doing more than you asked. **Readiness loses points for every gap.** - A TODO left in the file - A requirement with no acceptance criterion - No health metric You need 85 or more. One big gap can be enough to fail. Open **Preview & Checks** after each check. The biggest point losses are listed first. Fix them from the top. **Simple lesson:** fill the parts in order, and fix the biggest problem first. ## Your Own Product ### From Answers to a Starting File You can use your own product instead of the practice ticket. Nothing leaves your browser. First, you answer nine short questions. For example: - your product name - who the user is - your feature idea - the outcome you want, with a number - the file the agent should copy, called the **pattern path** - the code the agent must not change, called **frozen APIs** Your answers then become a starting `capstone.md` file. Watch the whole path, from answers to a finished spec. Some lines are filled in from your answers. The pattern path becomes a constraint. Your frozen APIs become "Do not change" lines. The rest of the lines still say TODO. ### Never Ship a File You Did Not Finish The starting file is only a start. The TODO lines are there on purpose. They make you read and write every part yourself. A file can look finished but still leave gaps. Then the agent guesses. The check fails until every TODO is replaced. **Simple lesson:** a file made for you still needs your review, line by line. ## Download Your Spec Kit When your capstone passes, open the **Export** tab. Pick where the spec comes from, and pick your tool. The download has: - `intent.md` - `spec.md` - `plan.md`, if you made one earlier - a review skill and templates - rules for your tool - starter templates for your next feature - the files your tool reads in a repo - example prompts for using the spec with your tool You can use this kit in a real project, outside this course. ## What Changes per Tool The ideas stay the same. Only the folder changes. | Tool | Where the capstone kit goes | |---|---| | Claude Code | `docs/specs//` plus `CLAUDE.md` | | Codex | `docs/specs//` plus `AGENTS.md` | | Cursor | `docs/specs//` plus `.cursor/rules/specs.mdc` | | Spec Kit | `specs/001-/spec.md` and constitution files | | Kiro | `.kiro/specs//requirements.md` and steering files | ## Common Mistakes | Mistake | Wrong idea | Correct idea | What goes wrong | |---|---|---|---| | Writing for the wrong stakeholder | "Every stakeholder wants the same thing." | Read the note for your own stakeholder. | The hidden checks fail. | | A REQ with no AC | "That one is obvious." | Write AC-n (REQ-n) for every REQ. | Coverage is below 100%. | | A vague REQ | "Behave sensibly when it is empty." | Write an EARS line that names the choice. | The agent does not understand it, so it guesses. | | No health metric | "The feature works, so we are done." | Name what must not get worse, with a number. | The hidden health check fails. | | No decision rule | "The agent will ask me." | Write "Ask first:" for the risky action. | The agent runs the migration alone. | | Shipping the starting file | "It looks complete." | Replace every TODO yourself. | Readiness fails, and the agent guesses. | ## Exercises These exercises help you practise putting a full spec together. Press **Check** when you are ready. Use **Show Hint** if you get stuck. ## What to Remember - The capstone uses everything from the course. - Start with the intent, then write the requirements. - Every requirement needs its own acceptance criterion. - Coverage must reach 100%. - Readiness must reach 85 or more. - Each stakeholder wants different things. Read your own note. - A spec should remove every guess before any code is written. - A file made for you still needs your review. - You can use your exported kit in a real project. ## Further Reading - [The Intent Engineering cheat sheet](/learn/intent-engineering/reference/cheat-sheet): every template and rule on one page. - [GitHub Spec Kit](https://github.com/github/spec-kit): run your exported spec through Spec Kit. - [Kiro specs](https://kiro.dev/docs/specs/index): run your exported spec through Kiro. Next: **Spec Cheat Sheet**. Every template, checklist and rule from the course, on one page.