Reviewing AI-generated Code for iOS

In the last lesson, we put the Tokens Dashboard through a proper review. Two prompts sorted out what was worth fixing and applied the changes. We changed 10 files and we had clean build.

If you open the starter project for this lesson, you will notice it already has all those fixes in place. We are picking up exactly where we left off.

But think about what happens next time you ask Claude to write something new for this project. It has no memory of any of that. The standards we established, the review process we built up, none of it carries over. Every new session starts as fresh.

So instead of fixing the same things over and over, I want to write them down once in a way Claude actually read and follows. Two things today.

First, coding rules. These go into a file called CLAUDE.md that sits at the root of your project. Claude reads this file at the start of every session, so anything you put in there becomes a standing instruction. Think of it as a note you leave for Claude every time it opens a project. Your standards written down once, applied automatically from that point on.

Second, a skill. A skill is a saved workflow you can trigger with a simple ask instead of typing out the full review prompt every time. Seven categories, seven levels, merge recommendations. You write it once as a skill file, and Claude loads it whenever you ask for a review. Think of it as saving your process, not just your code.

We already have a basic CLAUDE.md in this project from lesson one. Just project context, no rules yet, and we don’t have a review skill at all. Let’s fix both of those now.

Open CLAUDE.md file. Right now it only has basic project information, but we are going to add a coding rule section for the standards we found through our review written down so they don’t need to be discovered again.

Now, below the structure, I want you to write these coding rules. If you want to follow along or reference this later, the full CLAUDE.md content for this lesson is in the prompt script inside this lesson. These aren’t new decisions. Every one of these came directly from what we found in the review. We are just making them permanent. Now let’s check if it actually work.

I’m going to ask Claude to write something new for this project. Assemble data store with a date. But I’m not going to mention any of the rules we just typed. I just want to see what comes back.

Write a new mock data store called TeamBudgetStore that includes a date property built from DateComponents for January 1, 2026.

Now let’s check the results from this prompt. Let’s open TeamBudgetStore. Look at the date construction. It’s using nil coalescing as a fallback instead of a force unwrap. I didn’t mention force unwraps in the prompt at all. It reads CLAUDE.md, saw the rule, and applied it on its own.

Not guard let specifically, but the point is it avoided the force unwrap and used a safe fallback instead, which is exactly what the rule asks for. This is what making a standard permanent looks like. Not reminding Claude every time, just writing it down once in the right place.

Now, let’s do the same thing for the review process.

I’m going to create the skill file manually. Go to the project root folder. Then you can create it using the terminal with this command.

In your project root, you create a new folder called .claud. Note the dot at the start, which makes it a hidden folder. Inside that, create another folder called skills, and inside skills, create another folder called iOS-PR-review, and inside that, create a new file called SKILL.md.

Now, by default, the project root is hidden, but you can toggle this using Command + Shift + Dot to toggle it to be hidden or unhidden.

Now open SKILL.md in Xcode and you are ready to add the content.

Add the skill here. The full skill file content is also in the prompt script inside this lesson, including the exact terminal command to create the folder structure if you want to set this up in your own project. A skill file has two parts. At the top, a short description that tells Claude when to load it. This is how it knows to use this skill when you ask for a review. Then below it, you have the actual instructions. Seven categories in order, the same severity level we used in last lesson, and a clear merge recommendation at the end. Everything you built across two lessons of reviewing are written down once in a file. Now let’s see if it works.

Add a new conversation and type this only. Review this project.

For the results of this prompt, note at the top it shows which skill it loaded, the iOS PR review. That confirms it found the file and it’s running your process. Not a generic review, but exactly what you typed in this skill. If you go down, you will see it has the same structure as last lesson. Categories in order, severity label on each, and finally, you have a recommendation at the end. But look at what I typed. I just typed, “Review this project.” Three words, no category lists, no severity scale, no instructions at all. The skill carried the whole process. That’s the point of writing these down.

You built a review process over two lessons through your own judgment, your own decision about what matters and what doesn’t. That process now lives in a file, and every future review starts from the same standard without you having to build it from scratch each time.