Audit Design Rules in Claude Code

Audit how UI design rules reach Claude Code and test their enforcement.

Introduction

30 Second Summary

Design rules can look complete on paper while your coding assistant sees only part of them. That hidden gap can turn small interface decisions into inconsistent code. Every check can pass while the rules never reach the place the work happens. NextWork is free. Claude Code needs a paid plan.

In this project, you will audit whether Claude Code can reach 10 important design rules in your existing UI repository. The finished audit combines repository evidence with one conflict decision plus one controlled enforcement test.

What You'll Build

A teammate can scan your finished one-page table to trace every recommendation back to loaded context, repository code, or an enforcement check.

By the end of this project, you'll have:

A 10-rule reach map that distinguishes Loaded, Discoverable, and Absent guidance.
A five-rule code sample that shows exact file references plus observed Pass or Violation results.
An evidence-backed recommendation for every rule based on a resolved conflict plus a controlled violation.
Secret Mission: Cross-check one existing screen with Dessn's dessn-audit skill to add one corroborating note.

Are there any prerequisites?

You need an existing UI repository with written design rules plus one tracked UI file suitable for a temporary test. Your Mac needs a signed-in Claude Code installation. Git is required.

Before We Start

Before any hands-on work, this is your moment to commit to auditing your existing UI repository as it stands. Naming the repository and the design decision that matters most gives your audit a clear target without replacing its tools, rules, or design system.

Set Up the One-Page Audit

A rules audit needs evidence you can trust. Existing edits could be overwritten by the controlled restore later in the project.

You will use macOS Terminal to establish a clean Git baseline. You will start Claude Code from the repository root.

A single Markdown table will keep every finding reviewable on one page.

In this step, get ready to:

Confirm the repository has a clean tracked working tree.
Start Claude Code from the repository root.
Create the one-page audit file.

Confirm a clean starting point

This clean-state check protects work you already care about before the later restore. A blank short status proves that the audit begins without unrelated changes.

In Finder, navigate to your existing UI repository folder.
Skip the next two bullets if the path bar is already visible at the bottom of Finder.
Click View in the Finder menu bar.
Click Show Path Bar.
Control-click your repository folder in the path bar.
Click Open in Terminal.
Confirm the repository has no staged files by running this command:

git status --short

What should I see?

A clean tracked working tree produces no output. The empty result gives the later restore a safe baseline.

See files in the output?

Pause the audit if the command prints any path.
Protect every listed change with your normal repository workflow.
Run the same status check again after the working tree is clean.

Need help deciding what a listed change means? Help me review my Git status safely.

Start Claude Code from the repository root

The launch location defines the project directory for the interactive session. Capturing the installed version makes the audit reproducible.

Check the installed Claude Code version by running this command:

claude --version

What should the version check show?

The output contains a version number followed by (Claude Code). This is the version you will place in the audit metadata.

Record the version shown in Terminal here: your printed Claude Code version.
Start interactive Claude Code from the repository root by running this command:

claude

What does this launch do?

Interactive mode starts with your current repository as its project directory. Claude Code can now work with the audit file in the correct repository.

Claude Code does not start?

Close the failed launch attempt.
Confirm that the version check completed successfully.
Return to the Terminal window opened from your repository folder.

Still stuck? Help me start Claude Code from my repository root.

Create the audit file

One table forces every rule to carry its source plus its evidence. The fixed structure also prevents the audit from expanding into separate reports.

Claude Code may ask for permission before it writes the file.

Create the audit file by pasting this prompt into Claude Code:

Create a file named claude-rules-reach-audit.md in this repository.

Include only a short metadata block with these values:
- Repository: [[REPOSITORY_NAME="your UI repository name"]]
- Date: [[CURRENT_DATE="today's date"]]
- Claude Code version: [[CLAUDE_CODE_VERSION="your printed Claude Code version"]]

Follow the metadata with one empty Markdown table containing exactly 10 body rows.
Use these columns in this order: Rule | Decision it controls | Rule source | Claude reach | Code evidence | Conflict and winner | Check result | Recommendation
Do not add any separate report sections.

What does this prompt create?

The metadata ties the audit to your repository.
The metadata records the audit date.
The metadata records the Claude Code version.
Ten blank body rows reserve one evidence slot for each rule.

Allow the write if Claude Code requests permission to create claude-rules-reach-audit.md.
Ask Claude Code to display the audit file by pasting this prompt:

Show the full contents of claude-rules-reach-audit.md without changing the file.

What does the readback prove?

The readback confirms that Claude wrote one metadata block followed by one table. It also exposes extra sections before they spread across the audit.

Use the tabs below to compare the displayed file with the required structure.

✔️ Awesome, I've got everything!

Great. Your file matches the required one-page structure.

ⓧ I'd like to double check the full code

Repository: [[REPOSITORY_NAME="your UI repository name"]]
Date: [[CURRENT_DATE="today's date"]]
Claude Code version: [[CLAUDE_CODE_VERSION="your printed Claude Code version"]]

| Rule | Decision it controls | Rule source | Claude reach | Code evidence | Conflict and winner | Check result | Recommendation |
| --- | --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |

Why this shape?

The metadata anchors the audit to this run. The 10 blank rows become the evidence slots you fill during the next steps.

Before Claude runs the final check, do you expect Git to report a tracked edit or one untracked file?

Ask Claude Code to run the final status check with this command:

git status --short

What should I see?

You should see exactly ?? claude-rules-reach-audit.md. The marker shows that the audit exists as an untracked file.

See another path in the status?

Pause before continuing if any additional path appears.
Ask Claude Code to identify which action created the unexpected change.
Protect any pre-existing work before removing an unwanted change.

Need help isolating the audit file? Help me explain the extra Git status entries.

That is the baseline locked in. Claude Code is running from your repository root. The audit file is isolated as the single untracked path.

Your audit shell is ready. Next, you will map which design rules are Loaded, Discoverable, or Absent in the current Claude Code session.

Map Rule Reach

Your clean audit shell now gives every rule the same evidence structure. Claude Code is still running from the repository that owns those rules.

A rule can sit on disk without reaching the current session. You need to separate loaded context from available capabilities before code evidence can mean anything.

In this step, get ready to:

Identify the instruction files that reached the current Claude Code session.
Inspect skills, plugins, hooks, MCP servers, and settings for discoverable guidance.
Classify exactly 10 decision-bearing UI rules with source paths and command evidence.

Inspect loaded instruction sources

A rule is Loaded when its source already reached the session before you manually point Claude at it. The context breakdown exposes that starting point.

Expand the current context breakdown by entering this command in the running Claude Code session:

/context all

What does this context check show?

The output expands the categories that currently consume context.
Instruction files or rule sources shown in this output are candidates for the Loaded classification.
Skills or tools shown here have already contributed context to this session.

Inspect memory file locations across user and project scopes by entering this command:

/memory

What does the memory check add?

The memory output lists instruction file locations across user and project scopes. A source shown in the current session results provides evidence that the guidance was loaded before this audit.

That baseline is now visible. You can distinguish sources already in context from sources Claude can only reach through another capability.

Context or memory output unclear?

Some repositories expose only a small set of instruction sources. Sparse output still provides valid evidence about what reached the session.

Need help reading the results? Help me interpret my Claude Code context and memory output.

Inventory discoverable guidance

Discoverable guidance is available through a capability or configuration surface even when it has not entered the active context. Absent guidance has no evidence in the inspected surfaces before the audit.

Inspect each capability surface by entering these commands one at a time:

/skills
/plugin list
/hooks
/mcp
/status

What do these capability checks show?

The skills result lists available skills from project, user, and plugin sources.
The plugin result identifies installed plugins that may provide design guidance.
The hooks result lists registered automation grouped by event.
The MCP result shows configured servers and their connection states.
The status result shows active settings sources for the current session.

Prompt audit can add evidence about outdated references or contradictions in instruction sources. Its report leaves files unchanged until you explicitly request edits.

Compare the Claude Code version in your audit metadata with v2.1.283.
Skip the prompt audit command if your version is earlier than v2.1.283.
Inspect the instruction sources when your version is supported by entering this command:

/doctor prompt-audit

What does prompt audit check?

Prompt audit checks instruction sources for outdated content. It also reports nonexistent file references or command references.

The report can identify contradictions across instruction sources. These findings support your reach map without changing the repository.

You now have evidence from every planned session surface. An unsupported prompt audit remains a valid result when the recorded Claude Code version explains why it was skipped.

One of the inspection commands unavailable?

Confirm that you entered the command inside the running Claude Code session. Shell commands and Claude Code slash commands use different input environments.

If only prompt audit is unavailable, use the version already recorded in the metadata as the reason. Help me diagnose an unavailable Claude Code inspection command.

This classification can feel fiddly because Claude is about to read sources that were outside the original session evidence. Preserve the pre-read baseline when you assign each label.

How should each reach label be assigned?

Use Loaded when the context or memory results showed that the source had already reached the session.
Use Discoverable when an inspected skill, plugin, hook, MCP server, or settings source exposed guidance that was not already loaded.
Use Absent when a written rule has a specific source path but none of the inspected surfaces exposed it before the manual audit read.

Classify 10 decision-bearing rules

The manual repository read supplies the content for your 10 rules. Each rule should control a concrete UI implementation choice such as token use, component selection, spacing, typography, or state behavior.

Ask Claude Code to read the repository's written rule sources and update only the existing audit file by pasting this prompt:

Read this repository's written design-rule sources now.

Use the evidence already collected from these checks:
/context all
/memory
/skills
/plugin list
/hooks
/mcp
/status
/doctor prompt-audit when supported

Update only claude-rules-reach-audit.md.
Keep the existing metadata.
Keep exactly 10 table rows.
Do not add separate report sections.

Select exactly 10 rules that control specific UI implementation decisions.
For every row, fill Rule.
For every row, fill Decision it controls.
For every row, fill Rule source with a specific repository path or Claude Code source path.
For every row, classify Claude reach as Loaded, Discoverable, or Absent.
Preserve the baseline from before this manual repository read.
Include the supporting command and a concise observation in Claude reach.
Keep every cell concise enough for a one-page audit.
Leave Code evidence unfinished.
Leave Conflict and winner unfinished.
Leave Check result unfinished.
Leave Recommendation unfinished.

What does this audit prompt control?

The prompt limits Claude Code to the existing audit file.
The pre-read baseline prevents the manual repository scan from turning every rule into Loaded.
The unfinished columns preserve the work assigned to later steps.
The one-page constraint keeps the result reviewable with a teammate.

Before you run the review, do you expect every selected rule to have both a concrete source path and evidence for its reach label?

Ask Claude Code to review the reach map without editing it by pasting this prompt:

Review claude-rules-reach-audit.md without editing it.
Confirm it has exactly 10 table rows.
Confirm every Rule cell names a decision-bearing UI rule.
Confirm every Decision it controls cell names a specific UI choice.
Confirm every Rule source cell contains a specific source path.
Confirm every Claude reach cell uses Loaded, Discoverable, or Absent.
Confirm every Claude reach cell cites supporting command evidence.
Confirm the later audit columns remain unfinished.
Display the current table after the checks.
Report each failed check.

What does the final review prove?

This review checks the table against the required structure without changing it. Displaying the table gives you a visible result for every classification.

You should see exactly 10 table rows. Every row should contain a rule, its controlled decision, a specific source path, one reach label, and command evidence for that label.

Table review found a gap?

Ask Claude Code to correct only the cells named by the failed check.
Keep the table at exactly 10 rows after the correction.
Preserve unfinished cells that belong to later steps.

Need help with a disputed classification? Help me classify this rule using my baseline evidence.

Strong result. Your table now shows which design rules can actually reach Claude Code. Next, you will test five of those rules against concrete UI code.

Inspect Five Rules in Code

Your reach map now shows which design rules are Loaded, Discoverable, or Absent in Claude Code. You also have command evidence supporting every classification.

Reach shows what Claude can access. Direct repository evidence reveals whether the current UI follows each rule.

In this step, get ready to:

Select five rules that can be checked objectively in the existing UI code.
Add concrete implementation evidence to each sampled row.
Mark the remaining five rows as Not sampled.

Choose five objective rules

Objective rules produce evidence that another reviewer can verify from the same file. Tokens, component usage, spacing, typography, and state behavior are strong candidates.

Ask Claude Code to review the 10 rules in claude-rules-reach-audit.md.
Ask Claude Code to rank the rules by how directly they can be checked in existing UI code.
Select the five highest-ranked rules for sampling.
Tell Claude Code to keep its repository inspection read-only.
Tell Claude Code to edit only claude-rules-reach-audit.md during this step.

What Makes a Rule Objective?

An objective rule has an implementation value you can point to. A reviewer can inspect the same location to confirm the result.

A token rule can be checked against the token name or literal value used by the UI.
A component rule can be checked against the component imported or rendered.
A spacing or typography rule can be checked against the concrete style value.
A state rule can be checked against the behavior implemented for that state.

You now have five rules that can produce repeatable evidence. The other five remain part of the reach audit without receiving unsupported implementation claims.

Gather concrete code evidence

Each sampled row needs enough detail for a teammate to retrace the check. The evidence must connect the written rule to one observed implementation.

Ask Claude Code to inspect the relevant implementation files for all five selected rules.
Ask Claude Code to compare each observed implementation value with its corresponding rule source.
Ask Claude Code to update the five matching Code evidence cells in claude-rules-reach-audit.md.
Review each sampled cell for a concrete repository file path.
Review each sampled cell for a line reference.
Review each sampled cell for the observed implementation value.
Review each sampled cell for a result of Pass or Violation.

What Belongs in Code Evidence?

The file path identifies where the implementation lives.
The line reference narrows the evidence to a reviewable location.
The observed value records what the code actually uses.
The result states whether that value follows the selected rule.

You should now see five rows with traceable code evidence. Each result is grounded in the repository instead of an assumption.

Is the Evidence Too Vague?

Narrow a subjective rule to one implementation decision that appears directly in code.
Replace a general folder reference with the specific file that contains the observed value.
Ask Claude Code to recheck any line reference that no longer points to the cited implementation.
Use Help me make this code evidence specific and reproducible.

Mark the unsampled rows

An empty evidence cell leaves its status ambiguous. The explicit Not sampled label records the audit boundary without guessing.

Ask Claude Code to enter Not sampled in the Code evidence cells for the five rules that were not inspected.
Ask Claude Code to count the rows containing a Pass or Violation result.
Ask Claude Code to count the rows containing Not sampled.
Ask Claude Code to confirm that the table still contains exactly 10 rule rows.

Before you inspect the finished table, what split do you expect between sampled rows and unsampled rows?

Ask Claude Code to display the complete table from claude-rules-reach-audit.md.
Ask Claude Code to report every file it edited during this step.

You should see exactly five rows with a file path, line reference, observed value, and Pass or Violation. You should see Not sampled in the other five rows.

Claude Code should report claude-rules-reach-audit.md as the only edited file from this step. Your tracked UI code remains unchanged.

Your audit now connects rule reach to real implementation evidence. Next, you will resolve one case where two sources give different answers.

Resolve a Rule Conflict

Your five sampled rows now show what the UI repository actually does. However, two sources can still give Claude Code different answers for the same decision.

An audit cannot guide implementation until one source has authority. This step documents one conflict in the existing table before naming the winning source.

In this step, get ready to:

Identify two competing answers for one objective UI decision.
Determine which source controls that decision.
Record the resolution in one existing table row.

Find two answers to one decision

A useful conflict compares two answers to the same objective UI decision. Good candidates include a token value or a component rule.

Return to the five sampled rows in claude-rules-reach-audit.md.
Ask Claude Code to compare each sampled rule with its implementation evidence.
Ask Claude Code to include loaded instructions when they address the same decision.
Ask Claude Code to include checker behavior when it addresses the same decision.
Focus the comparison on tokens or component usage.

The comparison has two possible outcomes. Choose the tab that matches what Claude Code finds.

✔️ I found a real conflict

Use this path when two repository sources give different answers for the same UI decision.

Choose one sampled rule with two concrete answers.
Assign the first answer to Answer A.
Name the source beside Answer A.
Assign the second answer to Answer B.
Name the source beside Answer B.

ⓧ No natural conflict exists

Use a simulated drill when the repository gives one consistent answer for every sampled decision.

Choose one sampled rule with objective code evidence.
Use its repository answer as Answer A.
Define one hypothetical competing value as Answer B.
Label the conflict Simulated drill.
Keep the actual repository evidence unchanged.

What counts as the same decision?

Both answers must control the same implementation choice. A spacing rule and a typography rule belong to separate decisions.

A simulated answer is evidence of the resolution process only. Its label prevents teammates from mistaking the drill for a repository defect.

Resolve the source of truth

A source of truth is the authority that settles a disputed implementation decision. The repository may declare this hierarchy in its written guidance.

Ask Claude Code to search the repository guidance for an explicit authority hierarchy.
Follow the declared hierarchy when one exists.
Adopt one decision for this audit when no hierarchy exists.
Flag the missing authority hierarchy as the root issue when no hierarchy exists.

Conflict Cell Structure

Start with Answer A plus its exact source.
Follow with Answer B plus its exact source.
Name the authoritative winning source.
Finish with a one-sentence reason for the decision.

Ask Claude Code to update only the chosen row's Conflict and winner cell with that structure.
Ask Claude Code to preserve every Code evidence cell.
Ask Claude Code to display the updated row for review.

You should see both answers beside their sources. The row should also show one winning source with a concise reason.

Can't Identify the Winning Source?

Check the repository guidance for language that names an authoritative rule source. Use that declaration to settle the conflict.

When no hierarchy exists, record the decision adopted for this audit. Flag the missing hierarchy as the root issue.

Still unsure which source should win? Help me resolve this rule conflict without changing the repository evidence.

Verify the resolved audit

The resolution must preserve the audit's original evidence shape. This final review checks that one conflict was added without changing the other conclusions.

Before you ask for the final review, do you expect every original evidence count to remain unchanged?

Ask Claude Code to count the table rows.
Ask Claude Code to count the rows with complete code evidence.
Ask Claude Code to count the rows marked Not sampled.
Ask Claude Code to display the resolved conflict row.
Ask Claude Code to confirm that the file contains only its metadata block and table.

You should see exactly 10 table rows. Five rows should still contain complete code evidence.

The other five rows should still say Not sampled. Exactly one row should identify Answer A with its source.

That same row should identify Answer B with its source. It should name the winning source.

The row should finish with a one-sentence reason. A missing authority hierarchy should be named as the root issue when applicable.

You have turned an ambiguous rule into a reviewable decision. Next, you'll test whether the repository can enforce one rule when the code deliberately violates it.

Test Enforcement and Finish the Audit

Your audit now shows how design guidance reaches Claude Code. It also records implementation evidence for five sampled rules.

Reach evidence remains advisory until a repository check reacts to a deliberate violation. A controlled test reveals whether one rule has deterministic enforcement.

In this step, get ready to:

Identify the repository’s exact check for one safe sampled rule.
Test the check with one controlled violation in a tracked UI file.
Restore the tracked file before completing the one-page audit.

Identify the repository’s real check

A deterministic check turns a rule into repeatable evidence. Its command must come from checked-in configuration or documentation.

That source keeps the audit specific to your repository. It also prevents a guessed command from creating false confidence.

Ask Claude Code to choose one safe rule from the five rows with concrete code evidence.
Ask Claude Code to select one tracked UI file cited in that row.
Ask Claude Code to confirm that the selected file has no existing tracked changes.
Ask Claude Code to identify the exact relevant check command from checked-in configuration or documentation.
Ask Claude Code to cite the checked-in source that defines the command.
Ask Claude Code to state No deterministic check exists when those sources define no relevant command.

Why does the repository choose the check?

Repositories use different tools for linting, tests, type checks, or design-system validation. Checked-in configuration proves which command this repository actually supports.

An absent command is also useful evidence. It exposes a rule that currently depends on human or model judgment.

Run one controlled violation

A controlled violation creates a known bad example. Comparing that example with the repository check shows whether the rule is advisory or enforced.

Changing a working UI file can feel risky. The clean baseline makes this small tracked edit fully reversible.

Ask Claude Code to make one minimal deliberate violation of the selected rule in the chosen tracked UI file.
Ask Claude Code to show the resulting diff without changing claude-rules-reach-audit.md.
Review the displayed diff.
Confirm the diff contains only the intended tracked change.

Does the diff touch too much?

Stop before running the check if Claude changed unrelated lines. Ask Claude to revert the extra changes while preserving only the smallest controlled violation.

Need help narrowing the edit? Help me reduce this diff to one safe controlled design-rule violation.

Before you test the violation, do you expect the repository to detect it automatically?

Ask Claude Code to run the exact verified check when one exists.
Avoid running a guessed command when no verified check exists.

✔️ The check caught the violation

The repository has a deterministic signal for this sampled rule.

Enter the exact command in the sampled row’s Check result cell.
Add the exact result produced by the check.
State that the check caught the deliberate violation.

ⓧ The check missed the violation

The command ran successfully despite the known violation. This rule currently lacks effective deterministic enforcement.

Enter the exact command in the sampled row’s Check result cell.
Add the exact result produced by the check.
State that the check did not catch the deliberate violation.

ⓧ No deterministic check exists

The checked-in repository sources define no relevant command for this rule. The missing check is the enforcement result.

Enter No deterministic check exists in the sampled row’s Check result cell.
Avoid adding a command inferred from another repository.

Restore the repository and complete the table

The violation was intentionally temporary. Restoring the tracked file can feel severe.

Your untracked audit remains outside this Git restoration.

Switch back to the macOS Terminal session at your UI repository root.
Remove the temporary tracked edit by running this command:

git restore .

What does this command restore?

The command restores tracked files under the current directory to their indexed state.
The untracked claude-rules-reach-audit.md file remains untouched.

The Recommendation column turns each finding into a next action. Every row must use one of the three approved values.

How should each recommendation read?

Use Keep as guidance when the rule reaches Claude Code reliably. Advisory treatment fits the rule’s risk.

Use Improve reach when a useful rule exists but remains Discoverable or Absent in the relevant session.

Use Add enforcement when the rule needs deterministic protection. This also fits a check that missed the controlled violation.

Ask Claude Code to fill every Recommendation cell with exactly one approved value.
Ask Claude Code to tighten the metadata plus table wording until the file fits on one page.
Ask Claude Code to remove any separate report sections outside the metadata block plus table.

Before you run the final checks, which file do you expect Git to report? How many rule rows should the audit contain?

Verify the restored repository state by running this command:

git status --short

What should the final status show?

The command displays the repository state in short format.
The ?? marker identifies an untracked path.
You should see only ?? claude-rules-reach-audit.md.

Do you still see a tracked change?

Ask Claude Code to inspect the remaining diff before restoring anything else. Confirm the path belongs to the controlled test.

If the audit file is missing from the output, confirm it still exists at the repository root. Help me diagnose this unexpected Git status without overwriting unrelated work.

Return to the Claude Code session from earlier.
Ask Claude Code to open claude-rules-reach-audit.md.
Ask Claude Code to count exactly 10 rule rows.
Ask Claude Code to confirm that exactly five rows contain concrete code evidence.
Ask Claude Code to confirm that the other five rows say Not sampled.
Ask Claude Code to confirm that one row contains the complete conflict decision.
Ask Claude Code to confirm that one sampled row contains the controlled-enforcement result.
Ask Claude Code to confirm that every row contains one approved recommendation.

✔️ Awesome, I've got everything!

Strong finish. Your one-page table now separates reachable guidance from rules that need deterministic enforcement.

ⓧ I'd like to double check the full audit

Confirm exactly 10 rule rows appear beneath the header.
Confirm every row contains source evidence plus Claude reach evidence.
Confirm exactly five rows contain concrete code evidence.
Confirm the other five rows say Not sampled.
Confirm one row records the complete two-answer conflict decision.
Confirm one sampled row records the controlled-enforcement result.
Confirm every recommendation uses an approved value.
Confirm the short metadata block is the only content outside the table.

Secret mission

Cross-Check One Screen with Dessn

Your repository audit is complete. Now compare one sampled rule with a rendered screen through existing Dessn access, or record why the optional check was skipped.

Clean Up Your Resources

Your audit lives entirely inside your local UI repository, so keeping it creates no ongoing project costs. No cloud resources or paid services were created during the project.

Resources you used:

The untracked claude-rules-reach-audit.md file containing your completed 10-row audit table.

Keep everything running

No action needed. Choose this if you want to review the audit with your team or use its recommendations in future repository work.

Leave claude-rules-reach-audit.md in the UI repository.
Add the audit to your normal version-control workflow when you are ready to preserve it.

Pause - I'll come back to this later

Close your current Claude Code session to free the macOS Terminal window. The untracked audit remains available when you return.

Close the current terminal session after you finish reviewing the audit.
Leave claude-rules-reach-audit.md unchanged inside the UI repository.

Delete - I don't want to use this again

Remove the project output when you no longer need the findings. Your tracked UI repository stays intact.

Deleting the audit is permanent. The command targets only the named untracked file.

Copy claude-rules-reach-audit.md elsewhere if you want to keep its findings.
Delete the untracked audit file by running this command:

rm -rf claude-rules-reach-audit.md

What does this remove?

The command removes only claude-rules-reach-audit.md from the current repository folder. It does not modify tracked UI files.

Couldn’t remove the audit?

Confirm that your terminal prompt is still at the UI repository root.
Help me safely remove the untracked audit file without changing tracked repository files.

Confirm that the repository has no remaining changes by running this command:

git status --short

What should I see?

You should see no output. That confirms the audit file is gone. That is your cleanup complete: the tracked repository remains clean.

Nice Work!

You did it! Your compact claude-rules-reach-audit.md now proves which design rules reach Claude Code. It gives your team a clear next action for every rule.

You've learned how to:

Build a 10-rule reach map that classifies guidance as Loaded, Discoverable, or Absent. Every row includes source evidence.
Test five rules against your repository using a concrete file path for each sample. Record the line reference. Capture the observed value. Mark the result as Pass or Violation.
Resolve a two-answer conflict by naming the winning source. Test deterministic enforcement through a controlled violation. Restore the tracked working tree after the test.
Secret Mission: Added a screen-level cross-check with Dessn when existing access was available. Otherwise, documented why the optional check was skipped.

Ready to quiz yourself?