Skip to main content

Someone wanted to learn this too, so Grasp built them a personal learning path.

You can keep exploring this one or create your own

Prompting Claude Code for New Feature Adherence

Welcome back to your advanced Claude Code course.

In our last lesson, you designed a CLAUDE.md file to implement specific architectural rules for a FastAPI project, focusing on a domain-driven file structure and Pydantic schema conventions. You essentially created a blueprint for how code should be written.

Today, we'll close that loop. The learning outcome for this lesson is to test the CLAUDE.md file by prompting Claude Code to generate a new feature and verifying its adherence to the specified rules. This is the critical "Trust, but Verify" step that separates basic use from professional, reliable AI-driven development. You'll learn how to validate that your architectural vision is being followed and what to do when it's not.

1. The Prompt-and-Verify Cycle

Think of your CLAUDE.md file as a test suite for Claude's code generation. Each prompt you write is a test case designed to exercise the rules you've defined. The process is a continuous cycle:

  1. Define a Rule: You specify a convention in CLAUDE.md. (You did this in the last lesson).
  2. Craft a Prompt: You ask Claude to perform a task that should trigger that rule.
  3. Execute & Observe: You let Claude generate the code.
  4. Verify the Output: You inspect the generated files to see if they adhere to the rule.
  5. Refine (if necessary): If Claude deviates, you refine the rule in CLAUDE.md for more clarity.

Let's watch a clear, practical example of this cycle in action.

Claude Code Tutorial #2 - CLAUDE.md Files & /init

The following video from the Net Ninja YouTube channel demonstrates this test-and-verify cycle. The presenter adds a rule, prompts Claude, and then checks the output.

Watch from 04:12 to 06:26. Notice how he first adds a rule about a hooks folder to CLAUDE.md. He then gives a prompt to create a hook and carefully checks if Claude creates the new folder and places the file inside it, as specified.

This simple example illustrates the core feedback loop. You provide guidance, then you validate the result.

2. Crafting an Effective Test Prompt

The key to a good test is a prompt that is specific enough to activate your rules but not so prescriptive that it does the thinking for Claude. You want to test if Claude can apply the rules, not just follow a checklist.

Let's assume your CLAUDE.md file from the previous lesson contains the rules for a users domain. A good test prompt to verify those rules would be:

"Using the established project structure and Pydantic conventions, please add the API functionality for managing products. A product has an id (int), name (str), description (str, optional), and price (float)."

This prompt is effective because it tests multiple rules simultaneously:

  • File Structure: Does it create a src/products/ directory containing router.py, schemas.py, etc.?
  • Pydantic Conventions: In schemas.py, does it generate ProductBase, ProductCreate, and ProductResponse models?
  • Field Validation: Does it use Field() from your examples?
  • Model Separation: Does it correctly separate request and response models?

3. Advanced Verification: Automating the Review

Manually checking every file works, but it doesn't scale. As a power user, you can leverage Claude to help verify its own work. This involves defining checklists and "review" commands within your CLAUDE.md file.

The following article presents a professional-grade workflow that formalizes this self-verification process.

The ULTIMATE AI Coding Guide for Developers (Claude Code)

Manually reviewing every change can be tedious. A more advanced approach is to create custom commands that instruct Claude to review its own work against your defined standards. Sabrina Ramonov's guide provides an excellent template for this.

First, read the section 'Remember Shortcuts' to see examples of custom commands like QCHECK, QCHECKF, and QCHECKT. These commands reference checklists defined elsewhere in the CLAUDE.md. Then, read the 'AI Coding Process' section, specifically steps 8 and 9, to see how these verification commands are integrated into a real-world development workflow.

By creating a /check or /review command that points to a quality checklist in your CLAUDE.md, you can simply prompt Claude to "/review the code you just wrote" and get a structured analysis of its own adherence to your rules.

4. Practical Exercise: Putting Your CLAUDE.md to the Test

It's time to test the CLAUDE.md file you created in the previous lesson.

Your Task (approx. 25 minutes):

  1. Navigate to the root of your FastAPI project where your CLAUDE.md file is located.
  2. Start a fresh Claude Code session (/clear).
  3. Provide the following prompt to Claude:

    "I need to add a new organizations domain to our API. An organization has an id, a name, and an owner_id that references a user. Please implement the necessary files, schemas, and a basic router for this new domain, following all conventions defined in our CLAUDE.md."

  4. Allow Claude to generate the plan and the code. Do not intervene. Let it complete the task.
  5. Verify the Output:
    • File Structure: Did Claude create a src/organizations/ directory? Does it contain router.py and schemas.py?
    • Schema Conventions: Open src/organizations/schemas.py.
      • Did it use the Base/Create/Response pattern (e.g., OrganizationBase, OrganizationCreate)?
      • Are the fields correctly typed?
      • Does the OrganizationResponse schema correctly configure from_attributes=True to work with ORM models?
    • Router Implementation: Open src/organizations/router.py. Does the generated APIRouter use the Pydantic schemas you just inspected for its endpoints?
  6. Reflect and Refine:
    • If Claude followed all rules perfectly, congratulations! Your instructions are clear.
    • If Claude made a mistake (e.g., put all schemas in one model, or created files in the wrong place), analyze why. Was your rule in CLAUDE.md ambiguous? Could the example be improved? Make a small, targeted edit to your CLAUDE.md file to prevent this mistake in the future. This refinement step is crucial for building a robust, self-improving workflow.

Conclusion

You have now completed the full cycle of defining and testing architectural rules, moving from a passive user to an active architect of your AI development system.

Key Takeaways:

  • CLAUDE.md is Testable: Treat it like a configuration file that you can and should write tests for using targeted prompts.
  • Verification is Key: Always verify that the generated code meets your standards. You are the final quality gate.
  • Automate Your Reviews: For a scalable workflow, create custom review commands (/check, /review) within your CLAUDE.md to have Claude assist in the verification process.
  • Iterate for Clarity: When Claude deviates, it's often a signal that your instructions can be clearer. Use these moments to refine your CLAUDE.md and strengthen your guardrails.

As you've seen, CLAUDE.md is incredibly powerful for providing guidance. But what about enforcing hard, non-negotiable rules? You may have noticed that even with perfect instructions, the AI's behavior isn't always 100% deterministic.

Next Up:
This limitation of CLAUDE.md provides the perfect entry point to our next module, Declarative Automation: Custom Commands & Hooks. We will start by learning how to create custom slash commands that can scaffold code with dynamic arguments. These commands, combined with the hooks we'll explore later, give you the deterministic control needed to enforce your most critical rules with absolute certainty.

To frame your thinking for this next topic, consider the following.

How to actually force Claude Code to use the right CLI (don't use CLAUDE.md)

As you test, you might notice Claude sometimes deviates from instructions. Why does this happen, and what's the solution? This short video from Matt Pocock brilliantly explains the limitations of CLAUDE.md and introduces the more powerful, deterministic alternative we'll be covering next.

Watch from 00:52 to 02:45 to understand why CLAUDE.md isn't foolproof (it consumes the 'instruction budget' and isn't deterministic). Then, watch from 05:27 to 06:16 to hear the summary of why deterministic hooks are a superior solution for enforcing hard rules. This sets the stage perfectly for our next module.

Can't find a good explanation? Sign up and we'll make it for you

Sign up