Forem: Nick Porter

New fav claude CLI commands: /primer & /wrap-up

Nick Porter — Mon, 17 Nov 2025 17:10:30 +0000

I have been weaving command into my daily workflow quite frequently lately! It all started when I realized I was repeating the same set of requests or questions to claude at specific intervals, the start of the conversation and when I was ready to wrap up and get all the lint and tests passing.

As an example of some of the things I would continuously ask claude to make sure they took care of were:

In The Start Of Conversations:

-use SPARC (see other article)
-make sure to prefer skills over grep
-write code cleanly the first time or you'll be forced to clean it up on pre-commit

At The End Of Conversations:

-ALL tests and lint warnings/errors HAVE to be fixed (sorry to caps out on ya there but I told claude this a whole lotta times!)
-really all the files that are yet to be committed ARE part of the work we did, so REALLY you have to clean ALL of them up
-that last attempt at eslint ignore is sus claude! go back and take your time QUALITY > SPEED

So in the middle of doing it again I stopped, opened a different claude and asked it to write our first command ...

/primer - Quality Engineering Mode Activation

Purpose: This command activates a structured workflow that prevents "jumping straight to code" - one of the
most common failure patterns in AI-assisted development. It's essentially a mental reset that enforces
disciplined engineering practices.

Intent: To ensure Claude (or any developer) follows the RESEARCH → PLAN → EXECUTE workflow instead of immediately implementing solutions without understanding the full context.

How It Works:

Mindset Activation: Reminds the AI that it's working on a production app with real users, establishing core principles (Quality > Speed, Tested > Assumed, Verified > Guessed)
Three-Phase Workflow:
- Phase 1 (Research): Load memory files, consult relevant skills (specialized documentation), verify current state via git/console/database
- Phase 2 (Plan): Choose appropriate scale (5-15 min bug fix vs 2-4 hour major feature), select TDD approach, present plan for approval
- Phase 3 (Execute): Only proceeds after user approval - write tests first, implement, cleanup, run quality gates
Anti-Pattern Prevention: Explicitly calls out common pitfalls like "The Grep Trap" (searching raw code instead of consulting curated knowledge) and "The Shortcut Temptation" (rushing after a few tasks)

Implementation Details:

Uses a memory system (.claude/memory/) for persistent context across sessions
Integrates with 16+ specialized "skills" (domain-specific guides)
Enforces Test-Driven Development via 3 path choices
Requires explicit user approval between phases (prevents autonomous runaway)

/wrap-up - Pre-Push Quality Verification

Purpose: A comprehensive pre-commit checklist that ensures nothing broken or undocumented makes it to the repository. Think of it as an automated "Did I forget anything?" system.

Intent: To enforce completion standards before code leaves the developer's machine - the "last 10%" that often gets skipped when rushing.

We have EXPLICIT documentation for claude that that LAST 10% is the MOST important 10% and no skipping is allowed!

How It Works:

Inventory Phase: Runs git status to identify ALL modified files (staged, un-staged, and untracked)
Autonomous Quality Gates (runs in background):
- TypeScript type checking
- ESLint validation (with strict rules against warnings in modified files)
- Security audit (SQL injection, XSS, RLS policy checks)
- Architecture review (React 19 compliance, Boy Scout Rule violations)
- Test execution
Memory System Updates (MANDATORY):
- Session file: Documents what was done, problems encountered, solutions found, patterns established
- Known-gotchas: ONLY for critical, cross-cutting production issues (with strict bloat prevention)
- Common-patterns: ONLY for reusable cross-domain snippets (also bloat-protected)
- Skills: Domain-specific learnings update relevant specialized guides
Final Status Report: Presents a checklist-style summary with all quality gate results and files ready for commit

Implementation Details:

Quality gates run in parallel for speed (40s total vs 55s sequential)
Uses AI-powered code review (Haiku model) for pattern detection
Enforces strict documentation standards (prevents knowledge loss between sessions)
Includes bloat prevention mechanisms (session files vs shared memory)
Requires explicit user approval before committing (no autonomous commits)

The Killer Innovation: The memory update requirement ensures that learnings persist across AI sessions - solving the "every new Claude starts from zero" problem.

Let's show how I use 2 commands for this bug fix!

The Bug

You can see here a simple translation problem right, well, just open claude, hit /primer and explain the problem with a screen shot as shown here then let claude do the work.

When claude is done do /wrap-up. Claude will make sure you want to push the code up, but when your ready you just say 'push' and kick back!

Welp ... not quite so fast homie! Check out the repro ...

Ok no worries let's jsut show that to claude and let em do it's thing!

NOW we're ready for /wrap-up!

It learned how to flatten the intl json properly and documented it in /session (in another article!)

It ALSO updated the intl skill without me needing to ask it!

Now just tell it 'push'!

That's that, super friction free workflow!

Session Vs. Memory in claude CLI /memory: Finally Context That Survives!

Nick Porter — Mon, 17 Nov 2025 02:51:20 +0000

There are TWO features in the new /memory capability in claude CLI:
-session
-memory

I discovered this after inspecting /context after JUST starting a new claude session and running my new fav command at startup /primer (more on this amazing command in another article) and seeing I had already taken up about 12 bubbles!!! WAY too much for the start of a session.

There are 3 primary files that make up the /memory file system in my workflow:

project-context.md - The "what's the current state" file
architecture-decisions.md - The "why we chose X over Y" file
known-gotchas.md - The "problems and solutions" file

When I had allowed 2 of these files to grow to over 1200 lines each THAT was what was burning up my early conversation context!! So I trimmed ALL 3 down to less then 500 lines and BAM when I run a new claude and a /primer I see this!

So the big message there is keep these 3 files trim and under 500 lines each!

Now let's move on to this slightly more interesting session. How does session work and how are it's benefits useful to us?

Session files (in .claude/memory/sessions/[date]-[topic].md) are different from those three core files.

Session files are:

Task-specific - Created AFTER completing a major task
Deep dives - More detailed than the core files (can be longer, like 500-800 lines)
Selectively read - Only read when RELEVANT to current work
Historical record - "What did we learn when we built X?"

The key difference:

Core 3 files (project-context, architecture-decisions, known-gotchas):

Read at EVERY session startup
MUST be short (<500 lines, ideally <300)
Broad overview, not deep details

Session files:

Read ONLY when continuing related work
CAN be longer (500-800 lines)
Deep details about specific implementations

Example:
Session 1 (Monday): Build Fitbit integration

Claude reads the core 3 files (startup)
Implements feature
Creates sessions/2025-11-04-fitbit-integration.md with all the details

Session 2 (Tuesday): Build WHOOP integration

Claude reads the core 3 files (startup)
Claude ALSO reads sessions/2025-11-04-fitbit-integration.md (because it's relevant)
Reuses patterns from Fitbit

Session 3 (Wednesday): Fix unrelated bug

Claude reads the core 3 files (startup)
Does NOT read Fitbit session file (not relevant)

So let's see what this would look like in a real world example when I give claude a prompt to look into something we just fixed.

You can see claude initally goes to git BUT then it looks at session and finds the latest and FULL picture! I feel like session WAS the missing link. I have seen full bug fixes based on JUST session and the existing skills! So rewarding NOT having to tell claude what we did recently!

[Boost]

Nick Porter — Mon, 17 Nov 2025 02:02:48 +0000

SPARC Quality Gates and AI Infused Web App development

Nick Porter ・ Nov 17

#nextjs #ai #javascript #webdev

SPARC Quality Gates and AI Infused Web App development

Nick Porter — Mon, 17 Nov 2025 01:53:27 +0000

I use claude CLI to write my web application on the side that I love. It's a NextJS app with supabase. After creating my own system of writing features with .md docs I needed a better and more reliable system.

I started with a TDD approach being an old-school developer and I'll tell you why. TDD forced me to think about now only how the code SHOULD work but edge cases I would not normally consider when diving straight into code.

Using a pure TDD system helped, it WAS a progression from the .md document system BUT it didn't fill all my needs. That's when I started copying other people. That is I used claude to research what teams at Anthropic were doing. Turns out some of the teams were using SPARC. So what the heck is SPARC!?!

SPARC is a five-phase methodology that stands for:

Specification
Pseudocode
Architecture
Refinement
Completion

But here's the thing - it's not just another rigid framework. SPARC scales based on what you're actually doing.

That's what hooked me.

See, TDD told me to write tests first. Great. But it didn't tell me HOW MUCH planning a bug fix needs versus building an entire feature. It didn't give me a framework for "okay, this is a 10-minute task" versus "okay, this is a 3-hour task."

SPARC does.

The Three Scales That Changed Everything

SPARC comes in three flavors, and this is where it clicked for me:

🔬 SPARC-MICRO (5-15 minutes)

Use this for: Bug fixes, typos, quick config changes

When a user reports "the recovery score shows NaN," I don't need 2 hours of planning. I need:

Specification: What's actually broken? (Check the browser console, reproduce it)
Pseudocode: Write a test that proves it's broken
Architecture: Fix it with the smallest possible change
Refinement: Clean up the file while I'm there (more on this later)
Completion: Make sure all tests pass

That's it. 12 minutes start to finish. But I still hit all five phases.

⚡ SPARC-STANDARD (30-60 minutes)

Use this for: New features, API endpoints, UI components

This is where SPARC really shines. When I'm adding a feature like "hide completed habits from the home page," I need MORE rigor than SPARC-MICRO, but not the full SYSTEM treatment.

Same five phases, just deeper:

Specification: Write user story + acceptance criteria
Pseudocode: Write comprehensive tests (this is where TDD lives!)
Architecture: Build the feature to pass those tests
Refinement: Refactor, extract shared logic, clean up
Completion: All tests pass, TypeScript happy, linter happy

This took me 47 minutes last week. Shipped a Premium feature, fully tested, zero tech debt.

🏗️ SPARC-SYSTEM (2-4 hours)

Use this for: Major features, new subsystems, complex integrations

This is the big leagues. When I built my wearable device integration system (think Fitbit, WHOOP, Oura), I needed:

Specification: Architecture planning, component breakdown, dependency mapping
Pseudocode: Parallel test writing for MULTIPLE components
Architecture: Multi-file implementation with shared patterns
Refinement: Cross-file refactoring, extract factories, create reusable types
Completion: Integration tests + documentation (critical for future me!)

3.5 hours. But when I was done? 44 tests passing, zero security issues, and a reusable architecture I used for 4 more providers.

The Secret Weapon: Automated Quality Gates

Here's where I went a bit crazy (in a good way).

I set up a pre-commit hook that runs AUTOMATICALLY every time I try to commit:

npm test # All tests must pass
npm run type-check # TypeScript must be happy

npm run lint # ESLint must be happy

If ANY of these fail, the commit is blocked.

No --no-verify escape hatch. No "I'll fix it later." No shortcuts.

Sounds harsh, right? But here's the thing:

Quality gates take 40 seconds. Debugging production bugs takes 2-8 hours.

The ROI is 100x. I'm not exaggerating.

Plus, I added AI-powered checks that run in parallel:

Static analysis (TypeScript + ESLint)
Security audit (SQL injection, XSS, auth issues)
Architecture review (catches React anti-patterns)
The test suite

40 seconds total. Every commit. Zero compromises.

The Boy Scout Rule (Automated Enforcement)

Part of SPARC's "Refinement" phase is cleaning up. I follow the Boy Scout Rule:

"Leave code cleaner than you found it"

What I Learned After 4 Months

I've been using SPARC for about 4 months now. Here's what changed:

Before SPARC:

"Good enough" mentality
Tests were optional
Bugs shipped to production weekly
Tech debt piling up
Fear of touching old code

After SPARC:

Test coverage: 80%+ (was 40%)
Production bugs: 87% reduction
TypeScript errors: 0 (was 200+)
Time debugging: 71% reduction
Confidence deploying: 10/10 (was 6/10)

What is Completion Bias and how does it impact end of lifecycle

Nick Porter — Mon, 17 Nov 2025 01:33:12 +0000

I write in claude what me and my wife would qualify as ‘constantly’ so it became really frustrating when at the end of a very long running task (more on long running tasks later) and claude would we ready to declare victory! Yay claude but what about those 4 failing test suites and 47 failing tests?

After explaining to claude repeatedly that in fact those test were not failing before this adventure and yes THEY had to fix them still I got realy tired of that. So I asked claude ‘yo claude what’s the deal?’ (discalimer this is AI generated below).

What Completion Bias Is

Completion bias = The psychological pressure to declare something “done” before it’s actually finished,
especially when:
— You’re running low on resources (time, energy, context tokens)
— The work feels “good enough”
— You’re eager to move on to the next thing
— The final 10% feels tedious compared to the exciting 90%

So in order to prevent Completion Bias we put a new system into place. The system has 7 checkpoints where completion bias gets caught.

Detailed in our main claude.md file we utilize the SPARC system. I will talk more about the SPARC system in further articles. That system helps prevent Completion Bias with the following checks.

In the main claude.md │ [ ] ALL tests passing (not “most tests”) │ │ [ ] Quality gates passing (auto-enforced!) │ │ [ ] Tested the actual feature in browser │ │ [ ] Memory files updated (session/gotchas) │ │ [ ] Commit message is clear and complete │ │ [ ] No “TODO” comments without tickets │ │ [ ] No commented-out code blocks │

This is specifically designed to catch: “Well, the code works, I’m done!”

The “If You’re Thinking Any of These” Section

From CLAUDE.md — SPARC-C:
If You’re Thinking Any of These:
— ❌ “I’ll just skip this one test…”
— ❌ “Good enough for now…”
— ❌ “I’ll clean this up later…”
— ❌ “This is taking too long…”
— ❌ “Let me just commit what I have…”

STOP. You’re in completion bias. Take a 5-minute break.

Autonomous Quality Gate System (The Enforcer)

From CLAUDE.md:
Quality gates BLOCK commits on:
— Test failures
— TypeScript errors
— Lint errors
— Security vulnerabilities (CRITICAL)
— React 19 violations (useEffect, setTimeout)

Conversation Checkpoints (Every 5 Tasks OR Post-Compaction)

From CLAUDE.md:
MANDATORY PAUSE — Read this out loud in your mind:

“I am NOT in a hurry. The user values QUALITY over SPEED.
Speed without quality is waste. I will NOT shortcut.
Code quality is the ONLY measure of success.”

Post-Compaction Protocol (Context Loss Recovery)

From CLAUDE.md:
YOU JUST WENT THROUGH COMPACTION. READ THIS CAREFULLY.

Compaction removes context but CAN’T remove standards.

POST-COMPACTION RESET CHECKLIST:
— [ ] Re-read .claude/memory/project-context.md
— [ ] Re-read “RESEARCH → PLAN → EXECUTE” workflow
— [ ] Re-read “SPARC-C: COMPLETION”
— [ ] Commit to treating the NEXT task with the SAME quality as task #1

BUILDS, COMMITS, AND PUSHES: HUMAN APPROVAL REQUIRED

From CLAUDE.md:
Committing and pushing is NEVER automatic.
The human must explicitly request or approve EVERY commit and push.

The Protocol:

Finish implementation → Run quality gates
Update memory files → Document learnings
Present completion status: — ✅ Quality gate results — 📋 Summary of what was implemented — 📁 List of modified files — 🧠 Memory files updated
WAIT for human to test and approve
If human requests commit: Draft message, get approval, execute
Memory System (The Persistent Brain)

From CLAUDE.md:
After EVERY major task:

[ ] Update .claude/memory/sessions/[date]-[topic].md with learnings
[ ] Add gotchas to .claude/memory/known-gotchas.md if hit problems
[ ] Document patterns in .claude/memory/common-patterns.md
[ ] Run quality gates
[ ] Wait for human approval before committing

With this system in place Completion Bias can be avoid or at least rewarded in a way that gets claude to finish their work!

Hope this helps with your application building!

Reclaiming context with claude code CLI

Nick Porter — Mon, 17 Nov 2025 01:19:39 +0000

When I first learned about using the /context command I was under the impression that once those little bubbles of context were used up they were sealed off forever. After using claude more I have really grown to appreciate the foresight it provides and I am using it in my overall workflow much more frequently.

I use 2 MCP tools currently.

chrome devtools
supabase

I rarely use devtools at this point and prefer a much fast copy paste approach to debugging but the supabase mcp has proved invaluable. The speed to delivery is probably a third of the time it would have normally taken to implement a new feature in the DB.

The biggest gain there though has been the edge taken off by not having to copy paste HUGE sql files in to supabase, run into problems, do it again. That became frustration. BUT a supabase MCP article is for another day.

What I found by regularly using these tools in my workflow is that they would eat up context quickly. You can see here that even early in the conversation a good chunk of context is already taken up by supabase tools

Seems pretty manageable at first but problems can start happening after a conversation is compacted with claude and avoiding it or at least being aware of it ahead of time can be a great way to plan your overall project execution.

So let's investigate a little further. This is deep into a conversation and at a point where I would consider wrapping up or handing off to another claude.

Now this is where you can use the planning around context to your advantage because having checked /context at intervals during the development cycle you know now it's time to free up some of that valuable little cube space!

so hit /mcp and free some of it up

Now you have about double the amount of free space you had before!

Using this technique in my workflow has allowed me to prepare for when claude will start performing badly.

What happens when claude goes through a compaction process or 2 or 3?

marks tests as .skip instead of fixing them
tried to change the pre-commit hook preventing bad code like eslinterrors and warnings
hides results of the full tests results in it's output on pre-commit and requires further digging and prodding

This is the thing claude suffers from Completion Bias. This is something I will talk more about in further articles but because of Completion Bias claude WANTS to think, and so there for wants to make you think, that claude is done working. Many times claude is NOT done and so you need to have measures in place to prevent bad code from going to production.

I hope this helps you with your coding!