DEV Community: vigneshwar

I Stayed Up Until 3 AM to Build a Better Claude Code Guide Than the One With 52,000 Stars — Here's What I Found

vigneshwar — Sun, 17 May 2026 04:43:57 +0000

One night. One obsession. One repo that changed how I think about AI-assisted engineering.

It started the way most dangerous ideas do — quietly, at night, when the world had gone to sleep and the only sound was the hum of my monitors and the distant pulse of a city that never really stops.

I was tired. Not the kind of tired that sleep fixes. The kind that builds up when you've been consuming other people's work for so long that you start to forget you're capable of creating something yourself. I'd been scrolling GitHub for weeks — studying repositories, reading READMEs, bookmarking things I told myself I'd "come back to." I was good at bookmarking. Not so good at building.

Then I found it.

A GitHub repository about Claude Code best practices. 52,800 stars. 5,300 forks. Trending number one globally. The kind of numbers that make you feel small just looking at them. I read through it — and it was good. Really good. Community-built, battle-tested, full of real workflows from real teams. The kind of thing that takes months and dozens of contributors to produce.

I closed my laptop.

Then I opened it again.

Because something wouldn't let me go. Not jealousy — something quieter than that. A question. What would happen if I tried to understand this so deeply that I could build something better? Not to compete. Not to steal their stars. Just to find out if I had it in me.

It was 11 PM. I made coffee I didn't need. I pulled up the repository again, opened a blank terminal, and typed git clone https://github.com/vignesh2027/claude-best-practice.git into an empty folder. The cursor blinked at me. Waiting.

I started writing.

I want to be honest about what those hours felt like — because most people only share the highlight reel. The clean commits. The polished README. The final product. They don't talk about the 1 AM moment when you've been writing for two hours and you're not sure if what you're making is actually good or if you're just too tired to tell the difference. They don't talk about reading the original repo again at 1:30 AM, feeling like maybe you should just close the laptop and accept that 52,000 people already found what they needed.

I kept going anyway.

I wrote about context management — the thing nobody explains properly, the thing that silently kills your Claude Code sessions while you wonder why the output is getting worse. I wrote about verification loops — Boris Cherny's single most impactful insight, that running tests automatically after every edit improves output quality by 2–3x. I wrote about plan mode and why skipping it is like starting a road trip without checking the map. I documented hooks with real, copy-paste-ready shell scripts. I built out 9 skill types from Thariq at Anthropic — a framework so clean it made me angry that I'd never seen it laid out this clearly before.

I studied how Superpowers ships with Claude Code. How BMAD turns a vague idea into a production feature through a structured sequence of phases. How the gstack team runs a 14-stage process where every stage is a command, not a meeting. How the creator of Claude Code himself runs 5 local sessions and 5 cloud sessions simultaneously, codes primarily by voice, and says the single best thing you can do is give Claude a way to verify its own work.

By 2 AM I had written more than I'd written in the previous month combined.

By 2:47 AM — the clock you can see in the cover image, the real clock, the one I photographed because I wanted to remember this night — I had something I was genuinely proud of. Not because it was perfect. Because it was mine. Built from obsession, not obligation. From curiosity, not a content calendar.

Here is what I learned that night — and I don't mean about Claude Code.

I learned that the gap between consuming and creating is smaller than you think, and larger than it feels. It's smaller because you already know more than you give yourself credit for. It's larger because actually sitting down and making something — not planning to make it, not bookmarking it, not talking about making it — requires a different kind of commitment than most people are willing to give at 11 PM on a Tuesday.

I learned that the 52,000-star repo isn't your competition — your own hesitation is. The community that built that repository didn't sit down one night and produce 52,000 stars. They started somewhere. With something. Probably something smaller and rougher than what I built in one session.

I learned that depth beats breadth every time. The original repo has volume — hundreds of community contributions, tips from dozens of engineers. What I built has something different: a thread. A single person's attempt to understand something completely, from first principles, all the way through. That's a different kind of value. Not better or worse — different. And different is worth making.

I learned that the work you do at 2:47 AM, when nobody is watching and nothing is guaranteed, is the most honest work you'll ever do. It's not for likes. It's not for followers. It's for the version of yourself that gets up the next morning and looks in the mirror and knows: I actually did it.

The repository has everything I wish existed when I started learning Claude Code seriously:

10 deep-dive best practice guides — context management, hooks, subagents, MCP servers, CLAUDE.md mastery, prompting, model selection
5 advanced pattern guides — multi-agent teams, cross-model routing, automated pipelines, security hardening, enterprise deployment
Ready-to-use hook scripts — copy, paste, and run. Verification loops, auto-formatting, secrets protection, audit logging
Boris Cherny's creator workflow — how the actual creator of Claude Code uses his own tool, in detail
Thariq's 9 skill types framework — the most systematic approach to building Claude Code skills I've ever seen
Real-world team patterns — Superpowers, BMAD, gstack 14-stage, Spec Kit, Debugging War Room
70 tips from the creators themselves — distilled, organized, with a top-10 synthesis
Batch migration scripts — parallelize 100-file migrations across worktrees
PR babysitter automation — /loop 5m /babysit-prs handles your PR queue while you sleep
It is, genuinely, the most comprehensive Claude Code resource I know of. I say that not to brag — I say it because I spent a full night making sure it was true.

The city is still glowing outside my window.

The clock has moved past 3 AM.

My coffee is cold and I haven't noticed until right now.

And I have something I didn't have yesterday — a repository that represents the outer edge of what I understand, pushed to its limit, built past the point where most people stop.

If you're reading this and you've been bookmarking things without building them — I see you. I was you. The only thing that changed was one decision, one night, one refusal to close the laptop.

Dream it. Build it. Break limits.

⭐ The repository is live. Everything is free. No newsletter. No paywall. Just the work.

Github :(https://github.com/vignesh2027/claude-best-practice.git).

If this helped you, a star means more than you know. And if you build something with it — tell me. That's the only reward that matters.

I watched AI destroy 3 weeks of work in 4 minutes. So I built something 😭

vigneshwar — Sun, 17 May 2026 03:03:35 +0000

I still remember the exact moment.

It was 11pm. My team had been sprinting for 3 weeks building
a new payments feature. Deadline tomorrow. I handed the final
implementation task to our AI coding agent and said:

"Finish this up. Make it production ready."

I went to make coffee.

I came back to a deployed codebase with:

No input validation on the payment amount field
The API key hardcoded directly in the source file
Zero tests
No rollback procedure
User card numbers being logged to the console

-In 4 minutes, the AI had built something that would have
destroyed us if it had reached real users.

The worst part? The code looked fine. Clean functions.
Good variable names. It even had comments.

It just had none of the things that actually matter in production.

The thing nobody talks about

We spend so much time talking about what AI agents can do.

We don't talk enough about what they skip.

Here's what I've watched AI coding agents skip — over and over —
across my own projects and teams I've talked to:

They skip writing specs.
"The task is obvious."

They skip writing tests.
"I'll add them later."

They skip security checks.
"It's an internal API."

They deploy without a rollback plan.
"It's a small change."

They ship ML models without safety evaluation.
"The eval numbers look good."

They build data pipelines without quality gates.
"The source data is reliable."

And the worst part is — they sound confident while doing it.

No hesitation. No "are you sure?" Just fast, clean, wrong.

What I realized

The problem isn't that AI agents are bad at writing code.

They're genuinely incredible at writing code.

The problem is they have no discipline.

A senior engineer doesn't just know how to write code.
They know when to stop and write a spec first.
They know which shortcuts will cost you three weeks of debugging.
They know that "I'll add tests later" never happens.

That discipline — built from years of being burned —
is exactly what AI agents are missing.

You can't just tell an agent "be a senior engineer."

You have to show them the exact steps a senior engineer takes.
The exact things they verify before calling something done.
The exact excuses they refuse to accept from themselves.

So I built something

After that 11pm incident, I spent the next month building
AI Agent Skills — an open source framework of 40+ structured
workflow files that AI coding agents load before doing work.

Not prompts. Not vague instructions.

Structured skills — each one encoding exactly how a senior
engineer approaches a specific task:

What to do first
What to verify at each step
What evidence to produce before calling it done
What excuses to refuse

And — this is the part I'm most proud of — each skill has an
anti-rationalization section.

These are the exact shortcuts agents try to take, written out
explicitly, with a direct rebuttal for each one.

For example, the spec-driven-development skill includes:

"This feature is obvious — I don't need to write it down"
If it's obvious, the spec takes 10 minutes. If it's not obvious,
the spec saves days. Either way: write it.

"We'll iterate quickly — the spec will be wrong anyway"
Iterating on code without a spec means iterating in circles.

The agent sees these. It can't pretend the shortcut is reasonable.

What's covered

I wanted this to be the most complete skill framework ever built
for AI coding agents. So I went far beyond what others cover:

Standard engineering:
Spec writing · Planning · TDD · API design · Code review ·
Security · Performance · Git workflow · CI/CD · Documentation

AI/ML Engineering (nobody else covers this)
Training pipelines · Evaluation harnesses · Safety evaluation ·
Prompt injection testing · RAG system design · LLM evaluation ·
Agent orchestration · Distribution shift monitoring

Data Engineering (nobody else covers this)
Data contracts · Pipeline quality gates · Lineage tracking ·
Late-arriving data · Dead letter queues · GDPR compliance

Mobile Development (nobody else covers this)
Offline-first design · Main thread discipline · Battery efficiency ·
Crash rate targets · App store compliance

Incident Response (nobody else covers this)
5-phase structured response · Blameless post-mortems ·
Status page communication · Rollback-first philosophy

Plus 8 specialist agent personas — dedicated agents for:
Code Review · Security Auditing · Test Engineering ·
Performance · ML Engineering · Data Engineering ·
DevOps · Technical Writing

The moment it clicked for me

The first time I ran the framework on a real project, I gave
the agent a task and said /spec first.

It stopped.

It wrote a spec.

It listed functional requirements. It identified open questions.
It asked me to confirm before writing a single line of code.

I sat there staring at the screen thinking:

-This is what I actually wanted the whole time.*

Not faster code. Smarter code.

Code written by an agent that behaves like it's been burned before.
Like it has something to lose.

It's free. It's open source. It's yours.

I built this because I needed it. I'm sharing it because
I know I'm not the only one who's had the 11pm moment.

GitHub:

Works with Claude Code, Cursor, Gemini CLI, GitHub Copilot,
Windsurf, Kiro, OpenCode — and any agent that reads instructions.

MIT license. No strings.

One ask

If this resonates with you — if you've had your own version
of my 11pm moment — share this article.

There are millions of developers right now trusting AI agents
with production code. Most of them haven't been burned yet.

This framework is for the ones who want to learn from my mistake
instead of making their own.

⭐ Star it if it helps you.
🤝 Contribute if you have a skill to add.
💬 Comment if you've had your own AI disaster story.

I read every comment.

— Built at 11pm, after coffee, with lessons learned the hard way.