The rubric

Your capstone is graded on a five-row rubric, ten points each, fifty total. 40/50 (80%) is a pass — the same 80% bar used in the Foundation course's 8/10 rubric. The rubric measures the quality of your prompting and the quality of your outputs that result from it — not whether the PR was eventually merged, which depends on factors beyond your control.

Row	What we measure	0	5	10
1. Issue selection	Did you pick a tractable issue with a clear definition of done?	Vague refactor request, no reproducer	Bug fix in 1 file with test coverage	Bug fix with reproducer, your familiarity with project, ≤ 1 day estimate
2. Codegen skeleton applied	Did your codegen prompt have INTENT, CONSTRAINTS, TESTS, FORMAT?	Used "write me X" with no skeleton	Used 3 of 4 blocks	All 4 blocks, with 4+ test cases
3. Self-review before push	Did you run a 3-category review prompt on your own diff and act on findings?	No self-review	Reviewed but didn't fix MED findings	Reviewed, addressed all HIGH and MED findings, included verdict line in your notes
4. PR description quality	Was your PR description prompted, not hand-written? Does it have Summary / Why / Test plan?	Hand-written 1-line description	Prompted but missing one of the three sections	Prompted, all 3 sections, root cause named in Why
5. Process artifact	Can someone else reproduce your prompt sequence from your notes?	No notes	Notes exist, partially reproducible	Notes include each prompt, the model output, and the iteration cycles

Total: 50.

The five rubric rows as a self-grading timeline:

Self-grading is honest. The point isn't to score well — it's to identify which patterns you reach for naturally and which you forget under time pressure. A 30/50 capstone with honest notes teaches you more than a 50/50 with rounded numbers.

A few traps to avoid:

Trap	What it looks like	Why it costs you
Skeleton washing	Adding INTENT: / CONSTRAINTS: / etc. as labels but the content is still vague	Row 2 — a labelled vague prompt scores no better than an unlabelled one
Skipping self-review	Pushing the PR after the codegen prompt because "the code looks fine"	Row 3 — code that looks fine often has SECURITY findings you'd catch in a 30-second review prompt
Hand-written PR description	Writing the PR description because "I know what changed"	Row 4 — half the value of the description is forcing yourself to articulate the why; the prompt extracts that
Vibe-only notes	"Used some prompts, got the PR open"	Row 5 — without artefacts, others can't learn from your run

The strongest capstones come from engineers who treat the rubric as a protocol, not a graveyard for points. Picking a good issue takes 30 minutes upfront and saves a week of dead-end work. Running a self-review prompt takes 60 seconds and catches the bug that would have been pushed to production. Writing a PR description prompt takes 30 seconds and produces a description maintainers will actually merge.

When you finish, save your run as a Markdown file: capstone-<issue-slug>.md. Include the issue link, the PR link, the system prompts you used, the codegen prompt sequence, the self-review output, and the PR description. That's your artifact, and it's also a portfolio piece — engineers who can show this kind of run get hired into AI-augmented roles faster than engineers who can't.

You started this course with Karim, who wanted prompts that produce code he'd accept in code review. You finish it with the same ask, met. The four-block skeleton, the lock list, the verdict line, the diff envelope — these aren't tricks. They're the shape of careful engineering, expressed in prompts.

Course complete. Go ship the PR. :::