Video coming soon
Re-run the same infinite scrolling prompt from Section 2 with your new project memory and compare the results side by side.
This is the payoff. We're going to run the exact same prompt from Section 2, the one that produced a hand-rolled spinner, zero tests, hardcoded colours and default exports, and see what changes when Claude has your project memory loaded.
First, make sure you're starting from the same point as Section 2. If you still have the infinite scroll code from before, reset it:
git stashOr if you committed that work to a branch, switch back to your clean state before the infinite scroll feature was added. The goal is to give Claude the same starting codebase but with your new memory files in place.
Give Claude the exact same prompt from Section 2:
The prompt library is growing and we need pagination on the homepage. Add infinite scrolling so prompts load progressively as the user scrolls. Show a loading state while new prompts are being fetched, and handle the case where there are no more prompts to load.
Now watch what happens.
As Claude works, look for the same seven things we checked in Section 2:
Before: Hand-rolled SVG spinner with hardcoded opacity values and inline animation.
After: Claude should reach for the shadcn Skeleton component. If it's not installed, Claude should suggest installing it (bunx shadcn@latest add skeleton) and build skeleton placeholders that match the card layout.
Before: Zero test files.
After: Claude should create test files alongside the new components. Look for the AAA pattern, descriptive test names ("should load next batch when scrolling to bottom") and mock data prefixed with mock.
Before: Raw Tailwind for everything. No component library.
After: Claude should use shadcn/ui components where they exist: Card for prompt cards, Skeleton for loading states, Button if there's a "load more" fallback.
Before: export default function PromptList()
After: export function PromptList(). Named exports, consistent with the rest of your conventions.
Before: border-zinc-800, bg-zinc-900, text-zinc-400 scattered throughout.
After: Semantic tokens: bg-card, text-muted-foreground, border-border. No raw colour values in the component.
Before: Template literals or inline ternaries for conditional classes.
After: cn() from lib/utils.ts for all class merging and conditional logic.
Before: PAGE_SIZE = 12 and 300ms delays with no explanation.
After: Named constants with comments explaining why those values were chosen. Configuration extracted to a central location.
The feature is the same. Infinite scrolling still works. Prompts still load progressively. The end-of-list state still appears. Functionally, nothing changed.
But the implementation is fundamentally different. Every decision Claude made, the loading pattern, the component library, the export style, the test coverage, now aligns with your project standards. This is code that belongs in your project, not code that happens to work in your project.
Let's step back and look at the full system you've created in this section:
This is your project's AI memory. It turns Claude from a capable stranger into a teammate that knows your standards. And because it's committed to git, the entire team gets it for free.
If you're happy with the results, commit the infinite scroll implementation:
git add .
git commit -m "feat: add infinite scrolling with project conventions applied"Compare this commit to what Section 2 produced. Same feature, different quality of decisions. That's the power of project memory.
Checkpoint: This is the end of Section 3. The
checkpoint/s4branch has the project in this exact state.