Forem

Offline React Native Apps: How to Cache Files That Must Open Without Network

running squirrel — Sat, 25 Apr 2026 09:41:36 +0000

If you search for “offline React Native,” you will find a lot of guidance about images, lists, and optimistic UI. That is useful, but it often misses the assets that actually stop work in the field: PDFs, JSON manifests, small binaries, audio clips, and other HTTP-hosted files your app must open right now, even when connectivity is unreliable.

One of the best libraries for that specific “cache downloads to disk, open them later” capability is react-native-nitro-cache with it's simplistic api anyone can use easily.

This post is about that second category: file caching for offline-capable React Native apps.

Why “offline React Native” advice often skips the hard part

Most offline guidance optimizes what users see immediately: scrolling, perceived speed, optimistic updates. That matters, but field workflows also depend on what users can open from storage when the network disappears.

Operational apps tend to fail for file reasons, not layout reasons:

a PDF checklist did not download before the technician walked into a basement
a rules manifest is stale after a midnight policy change
a small binary or audio instruction is missing when the user is already offline

What you want in those situations is not a prettier loading state. You want a predictable HTTP file cache with explicit freshness and cleanup tools.

That is the shape of problem a file cache is meant to solve: downloads you can treat as local files, with TTL, forced refresh, and simple ways to inspect and clean up what is on disk—so your app can open operational assets offline, not only render UI faster.

The offline-first file workflow

Think in layers:

Prefetch the critical path while the user still has good connectivity (login, sync screen, “prepare for today” action).
Serve from disk during the session using stable local file paths.
Revalidate on a schedule using TTLs that match how often each asset class changes.
Force refresh when the server says “this version is invalid” (feature flags, emergency policy updates).
Observe and prune using cache stats/entries so support and QA can reason about what is on-device.

This maps cleanly to the react-native-nitro-cache primitives:

getOrFetch(url, options?) — return a valid cached file or download it
get(url) — read-through without downloading
has(url) — fast synchronous membership check against the in-memory index
getBuffer(url) — read bytes into an ArrayBuffer for small in-memory consumers
remove(url) / clear() — targeted invalidation vs nuclear reset
getStats() / getEntries() — operational visibility

Example: different TTLs for different file classes

In real apps, “freshness” is not one number. Treat manifests, templates, and media differently.

import { rnNitroCache } from 'react-native-nitro-cache';

export async function cacheManifest(url: string) {
  // Changes frequently: short TTL 10mins
  return rnNitroCache.getOrFetch(url, { ttl: ttl: 60 * 10 });
}

export async function cachePdfTemplate(url: string) {
  // Changes rarely: longer TTL 7days
  return rnNitroCache.getOrFetch(url, { ttl: 60 * 60 * 24 * 7 });
}

When an entry is returned, you typically care about:

url: absolute on-disk path you can hand to viewers/players
contentType: useful for routing and validation
size: useful for UI and telemetry
expiresAt: 0 if the entry has no TTL; otherwise the expiry instant in milliseconds since epoch

Example: parse cached JSON without inventing a parallel storage system

For small JSON blobs, getBuffer can be convenient if your consumer wants bytes in JS.

import { rnNitroCache } from 'react-native-nitro-cache';

export async function readCachedJson(url: string) {
  const buf = await rnNitroCache.getBuffer(url);
  if (!buf) return null;

  const text = new TextDecoder().decode(buf);
  return JSON.parse(text) as unknown;
}

Invalidation that matches real product events

Offline support is not only “store more.” It is also “remove the right things at the right time.”

Common triggers:

User logs out → clear() if your policy requires wiping cached HTTP assets from the device
Tenant/workspace switch → clear() or selective remove(url) for tenant-scoped URLs
Server publishes a new bundle version → getOrFetch(url, { forceRefresh: true }) for the entry points that must update immediately

Observability: treat the cache as part of your release story

If you have ever debugged “it works on Wi‑Fi,” you know the missing ingredient is visibility.

import { rnNitroCache } from 'react-native-nitro-cache';

const stats = await rnNitroCache.getStats();
console.log('cache entries:', stats.totalEntries, 'bytes:', stats.totalSize);

const entries = await rnNitroCache.getEntries();
console.log(entries.map(e => ({ path: e.url, type: e.contentType, bytes: e.size })));

This is valuable for:

QA scripts (“did we prefetch the manifest?”)
internal diagnostics screens
coarse “disk budget” warnings before downloads

Installation and platform reality (so your readers do not get stuck)

What I would emphasize in a Medium conclusion

Offline React Native is getting more attention because teams are shipping more serious mobile workflows. But it is not just "more caching", it is the right kind of caching:

operational files you can open from disk under poor connectivity
explicit freshness (TTL) and forced refresh paths
disk-first retrieval for large assets
targeted invalidation and introspection APIs

If your roadmap includes offline inspections, offline forms, offline training content, or any “must open on-site” PDFs and manifests, a general-purpose file cache belongs in your architecture review alongside your sync and persistence strategy.

Repo link

To learn more about the library checkout it's repository on GitHub

Our Indie Horror Journey: Passion Over Perfection

Mattia Santangelo — Sat, 25 Apr 2026 09:41:15 +0000

Ottima idea. Per rendere il post su DEV.to davvero "possente", dobbiamo trasformare il fatto che i modelli non siano ancora perfetti in un punto di forza: la trasparenza e il progresso.

Ecco una versione migliorata, professionale e coinvolgente in inglese. Ho aggiunto dei dettagli tecnici per far capire che sai il fatto tuo:

Title: Our Indie Horror Journey: Passion Over Perfection 🛠️🧟
Hi everyone!

I wanted to share a quick update on the horror game I'm developing with my friend. Currently, we are in the "heavy lifting" phase of creation.

The Art & Models
My friend has already been incredibly busy creating a lot of 3D models for the game. Are they perfect? Not yet. Are they AAA-quality? Not for now. But they are made with 100% passion.

We believe in the "Iterative Process":

Create the basic shape.

Test it in the Unity scene.

Refine and polish later.

As the programmer, I’m already working on integrating these models into the engine. Even if they aren't "beautiful" yet, seeing them move and interact with the environment is the best feeling in the world.

Our Philosophy
We prefer to have a working prototype with simple models than a perfect-looking game that doesn't play well. Once the mechanics (like the car breaking down and the survival system) are solid, we will go back and polish every single texture and vertex.

We are learning everything from scratch, and every small bug we fix is a huge victory for us.

Stay tuned for more updates

Building Production-Ready NestJS Apps: Introducing Nestier - A Hexagonal Architecture Boilerplate

Brahim — Sat, 25 Apr 2026 09:40:52 +0000

Building Production-Ready NestJS Apps: Introducing Nestier

Starting a new NestJS project? Tired of setting up the same architecture patterns, authentication, and infrastructure code over and over? I've been there too.

That's why I built Nestier — a production-ready NestJS boilerplate that demonstrates best practices in enterprise application development.

What is Nestier?

Nestier is a comprehensive NestJS boilerplate that implements Hexagonal Architecture (ports & adapters) and the Generic Repository Pattern. It's designed to help you build scalable, maintainable applications from day one.

Key Features

✨ Hexagonal Architecture - Clean separation of concerns with domain, application, infrastructure, and presentation layers

🔐 JWT Authentication - Complete auth flow with password reset

📊 Generic Repository Pattern - Reusable CRUD operations via TypeORM

🔍 Advanced Search - Dynamic filtering with multiple comparators

📝 80%+ Test Coverage - 212 tests (127 unit + 85 E2E)

🐳 Docker Ready - Full stack with MongoDB and SonarQube

📚 Swagger/OpenAPI - Auto-generated API documentation

🛡️ Security First - Helmet, rate limiting, input validation

Architecture Overview

The project follows a strict hexagonal architecture with four distinct layers:

Domain Layer      → Business logic, entities, repository interfaces
Application Layer → Use cases, services, orchestration
Infrastructure    → TypeORM repositories, adapters, external services
Presentation      → Controllers, DTOs, validation

This architecture ensures that your business logic remains independent of frameworks and external concerns, making your code more testable and maintainable.

Three Implementation Examples

Nestier includes three example modules that demonstrate different implementation approaches:

Category Module - Simple CRUD using base components
Product Module - Extended with custom use cases and repository methods
User Module - Full custom implementation with JWT authentication

This gives you flexibility to choose the right pattern for each feature in your application.

Quick Start

Getting started is straightforward:

# Clone the repository
git clone https://github.com/BrahimAbdelli/nestier.git
cd nestier

# Install dependencies
npm install

# Set up environment
cp .env.example .env

# Start the app
npm run start:dev

The API will be available at http://localhost:3000/api with Swagger docs at http://localhost:3000/docs.

Why Hexagonal Architecture?

Traditional layered architectures often lead to tight coupling between layers. Hexagonal architecture solves this by:

Isolating business logic from infrastructure concerns
Making testing easier through dependency inversion
Enabling flexibility to swap implementations (e.g., switch databases)
Improving maintainability with clear boundaries

Here's a simple example of how the repository pattern works:

// Domain layer - Repository interface (port)
interface BaseRepository<T> {
  findById(id: string): Promise<T | null>;
  findAll(): Promise<T[]>;
  create(entity: T): Promise<T>;
}

// Infrastructure layer - TypeORM implementation (adapter)
class TypeOrmBaseRepository<T> implements BaseRepository<T> {
  // TypeORM-specific implementation
}

What's Included

✅ JWT authentication with password reset flow
✅ Advanced search with filtering and pagination
✅ Soft delete functionality
✅ AutoMapper for entity ↔ domain ↔ DTO mapping
✅ Winston logger with structured logging
✅ Mailjet integration for emails
✅ Comprehensive error handling
✅ Docker and Docker Compose setup
✅ CI/CD with GitHub Actions
✅ SonarQube integration for code quality

Perfect For

🚀 Starting new NestJS projects
📚 Learning hexagonal architecture patterns
🏢 Building enterprise applications
🎓 Teaching clean architecture principles
⚡ Rapid prototyping with production-ready foundation

Get Started Today

Ready to build your next application with a solid foundation?

👉 Star the repository: github.com/BrahimAbdelli/nestier
👉 Article: brahimabdelli.dev/articles/2026/nestier/

Have questions or suggestions? Feel free to open an issue or start a discussion!

What patterns do you use in your NestJS projects? Share your thoughts in the comments below! 👇

How to Bulk Delete Your X (Twitter) History for Free (No API Keys Needed!)

Aero — Sat, 25 Apr 2026 09:40:36 +0000

We’ve all been there. You look at your X (formerly Twitter) profile and realize you have thousands of old tweets, cringy replies, and outdated retweets from a decade ago. It’s time for a clean slate.

In the past, you could just plug your account into a free third-party app and wipe your history in minutes. But ever since X changed its API pricing, almost all of those free tools have either shut down or started charging hefty subscription fees.

So, how do you clean up your digital footprint without opening your wallet?

Enter twitter-x-cleaner-automation: a completely free, open-source tool that runs directly on your computer to bulk delete your X history.

In this article, I’ll explain how this tool works, why it’s safe to use, and how absolutely anyone—even non-developers—can set it up in minutes.

🚀 What is this tool?

This tool is a lightweight script that automates the tedious process of deleting your X content. Instead of using expensive API keys to talk to X's servers behind the scenes, this tool uses Browser Automation.

Imagine hiring a tireless digital assistant who sits at your computer, opens Google Chrome, scrolls through your profile, clicks the three-dot menu on every single post, and hits "Delete." That is exactly what this script does, just much faster.

What can it clean up?

Posts: Deletes your original tweets.
Replies: Removes all the replies you’ve left on other people's posts.
Retweets (Reposts): Undoes retweets on your timeline.
Likes: Un-hearts posts you’ve previously liked.

🧠 How it Works (No Coding Degree Required)

You don't need to be a programmer to use this, but understanding how it works will give you peace of mind.

The script uses a technology called Puppeteer. Puppeteer is an invisible "puppeteer" for your web browser. When you run the tool, it does the following:

Opens Chrome: It launches a local version of Google Chrome right on your screen.
Logs You In: It uses a secure, local profile. The first time you run it, you'll log in just like you normally do. After that, it remembers you.
Scans and Clicks: It automatically navigates to your profile, uses visual cues to find posts that belong to you, clicks the specific "Delete" or "Unlike" buttons, and confirms the prompt.
Keeps Receipts: As it works, it saves a neat little log file (like a digital receipt) on your computer, so you always know exactly what text was deleted and when.

Because it mimics human behavior—actually clicking buttons on the website—it completely bypasses the need for API keys. Furthermore, it has built-in smarts. If X notices you are deleting things too fast and tries to pause you (a "rate limit"), the script will automatically wait for 60 seconds and resume.

🔒 Why This is the Safest Way to Clean Your Account

When you use sketchy third-party web apps, you are often asked to authorize their app to access your account. This means giving a stranger's server permission to post, delete, or read your messages.

This tool is entirely different:

100% Private: It runs only on your computer. Your passwords and data are never sent to any cloud server.
Transparent: It’s open-source. Anyone can look at the code to verify it does exactly what it says and nothing else.
No Account Bans: By mimicking normal browser clicks and respecting X's rate limits, it avoids triggering bot-detection alarms.

🛠️ Step-by-Step Guide: How to Use It

Ready to nuke your timeline? Here is how to get started.

Prerequisites

Before you begin, ensure you have the following installed on your Windows PC:

Google Chrome (Your everyday browser).
Node.js (Version 18 or newer). Just download the Windows installer and click "Next" until it's finished.

Step 1: Download the Tool

Go to the GitHub Repository. Click the green <> Code button and select Download ZIP. Extract the folder anywhere on your computer (like your Desktop).

Step 2: Open your Terminal

Open your computer's Command Prompt (or Terminal) and navigate to the folder you just extracted.
(Tip: You can open the extracted folder, click the address bar at the top of the window, type cmd, and press Enter. This opens a terminal right in that folder!)

Step 3: Install the Magic

In the terminal window, type the following command and press Enter:

npm install

This downloads the small set of instructions the script needs to run.

Step 4: Run the Cleaner

Now, start the tool by typing:

node script.js

Step 5: Choose Your Adventure

The tool will greet you with a friendly menu:

What would you like to do? (enter numbers separated by commas)
  1) Delete posts
  2) Delete replies
  3) Undo retweets
  4) Unlike posts
  5) All of the above

Your choice (e.g. 1,3,4):

Just type the numbers for what you want to do and press Enter.

A Chrome window will pop up. If it's your first time, the terminal will ask you to sign into X. Just log in manually in that Chrome window, switch back to your terminal, and press Enter

Sit back and watch. The tool will auto-detect your username and start scrubbing your profile. You can literally watch the posts disappear one by one!

📂 Advanced Options

If you want to be more specific, you can give the tool extra commands right from the start.

Want to delete exactly 100 posts?

node script.js @yourhandle 100

Want to start a completely fresh log file instead of keeping a running list?

node script.js @yourhandle 100 overwrite

All of your deleted history will be saved neatly inside the output/ folder in the tool's directory, categorized by actions (e.g., deleted-posts.json).

🏁 Final Thoughts

Taking control of your digital footprint shouldn't cost you a monthly subscription. Thanks to browser automation, we can take back control of our data for free, securely, and privately.

If this tool helped you clean up your timeline, be sure to head over to the twitter-x-cleaner-automation GitHub repo and give it a ⭐ Star to support the project!

Happy cleaning! 🧹✨

Why We Switched from Direct API Calls to Kafka and What Broke Along the Way

Sheikh Shahzaman — Sat, 25 Apr 2026 09:38:22 +0000

TL;DR: We migrated 10+ microservices from direct HTTP calls to Kafka event-driven communication. Reliability improved massively but the migration was harder than expected. Here are the real lessons including the mistakes.

Our system started as a monolith. Then we split it into microservices. The services talked to each other using direct HTTP calls. Service A would POST to Service B which would POST to Service C. It worked fine when we had 3 services.

Then we had 10.

The Day Everything Cascaded

One Tuesday morning our notification service crashed because of a memory leak. No big deal right? Restart it and move on.

But the order service was calling the notification service directly during checkout. When notification service was down the order endpoint started timing out. Users could not place orders. The billing service was also calling notification service to confirm payment receipts. Billing started failing too.

One crashed service took down three other services because they were all directly dependent on it.

That was the day we decided to move to event-driven architecture.

How We Set It Up

The concept is simple. Instead of Service A calling Service B directly Service A publishes an event to Kafka. Service B listens for that event and processes it on its own time.

// Before: Direct coupling
class OrderService {
    public function complete($order) {
        $order->markComplete();
        Http::post('billing-service/invoice', $order->toArray());
        Http::post('notification-service/email', $order->toArray());
        Http::post('analytics-service/track', $order->toArray());
    }
}

// After: Event-driven
class OrderService {
    public function complete($order) {
        $order->markComplete();
        KafkaProducer::publish('order.completed', [
            'order_id' => $order->id,
            'tenant_id' => $order->tenant_id,
            'total' => $order->total,
            'completed_at' => now()->toIso8601String(),
        ]);
    }
}

The order service does not know or care who listens to that event. Billing creates an invoice. Notifications send an email. Analytics tracks a metric. Each service subscribes to the event independently.

What Broke During Migration

I wish I could say the migration was smooth. It was not.

Problem 1: Event ordering. We assumed events would arrive in the order they were published. They mostly did. But when we had high throughput some consumers processed events out of order. An "order.updated" event arrived before "order.created" and the consumer crashed because the order did not exist yet.

The fix was adding an event version number and having consumers check if they had already processed a newer version before applying changes.

Problem 2: Duplicate events. Kafka guarantees at-least-once delivery. That means consumers can receive the same event twice. We had a bug where a payment was processed twice because the consumer was not idempotent.

The fix was adding a unique event ID and checking if we had already processed that ID before taking action.

class InvoiceConsumer {
    public function handle($event) {
        if (ProcessedEvent::where('event_id', $event['id'])->exists()) {
            return;
        }

        $invoice = Invoice::createFromOrder($event['order_id']);

        ProcessedEvent::create(['event_id' => $event['id']]);
    }
}

Problem 3: Debugging was harder. With direct API calls you could trace a request from start to finish in one log. With events the flow is split across multiple services and multiple time periods. Finding out why an invoice was not created required checking logs in three different services.

We solved this by adding a correlation ID to every event. When the order service publishes an event it includes a unique request ID. Every downstream consumer includes that same ID in their logs. Now you can search for one ID and see the entire flow across all services.

The Patterns That Saved Us

Dead letter queue. When a consumer fails to process an event after 3 retries it goes to a dead letter topic. We have a dashboard that shows failed events and lets us replay them after fixing the bug.

Schema registry. We define the structure of every event in a shared schema. If a producer tries to publish an event that does not match the schema it fails at publish time not at consume time. This prevented so many bugs.

Consumer lag monitoring. We track how far behind each consumer is. If the notification consumer falls 10,000 events behind we get an alert. This caught performance issues before users noticed them.

The Results

After 3 months on event-driven architecture:

Zero cascading failures. One service going down does not affect any other service.
We can deploy services independently without coordinating with other teams.
Adding a new consumer takes 30 minutes instead of modifying 5 different services.
Event replay lets us reprocess historical data when we add new features.

What I Would Do Differently

I would have implemented idempotency from day one not after the duplicate payment bug. Every consumer should be idempotent by default.

I would have invested in better tooling earlier. A good event viewer that shows the flow of events across services would have saved weeks of debugging time.

And I would not have migrated everything at once. We tried to move all 10 services in one sprint. It should have been gradual. Start with the least critical services and work toward the most critical.

Event-driven architecture is powerful but it adds complexity. If you have 3 services that rarely fail direct API calls are probably fine. If you have 10+ services and reliability matters events are worth the investment.

Have you migrated from direct API calls to event-driven architecture? What surprised you the most?

I built Daymint instead of using Todoist + Habitica. Here's why.

sourav swain — Sat, 25 Apr 2026 09:36:53 +0000

https://play.google.com/store/apps/details?id=com.souravsn.daymint

I Built a Habit Tracker App Instead of Using Todoist + Habitica

For 2 years, I juggled 3 different apps for productivity:

Todoist for tasks
Habitica for habits
Google Calendar for planning

Every morning, I'd switch between them 10+ times. It was exhausting.

So I built Daymint - and it's completely changed how I work.

The Problem: App Fatigue

The fundamental issue with using multiple productivity apps:

Context switching - Your brain loses focus switching between apps
Fragmented data - Your tasks are in one place, habits in another
Inconsistency - You miss tracking because you forget which app to use
Cost - Premium features cost $50-100/year combined
Complexity - Learning 3 UIs instead of mastering one

I'm not alone. According to a study by the American Psychological Association,
context switching reduces productivity by 40%.

Why These Apps Weren't Enough

Todoist

✓ Powerful task management

✓ Beautiful UI

✗ Terrible for habit tracking

✗ Habit features feel bolted-on

Habitica

✓ Great habit tracking with gamification

✓ Community features

✗ Overkill if you just want simple tracking

✗ Not designed for task management

Google Calendar

✓ Essential for scheduling

✗ Not designed for habit tracking or tasks

✗ Messy mixing of events with habits

The core problem: No single app did all three well.

What I Built Instead

I spent 3 months building Daymint specifically to solve this problem.

Core Features

1. Daily Planner (Multiple Views)

Today view - see all your tasks + habits for today
Calendar view - plan your entire week
Timeline view - time-block your day
See everything at a glance

2. Habit Tracker (Built for Real Habit Building)
This is what sets it apart.

Most habit apps just count streaks. Daymint:

Tracks WHY you're building the habit (motivation)
Shows progress analytics (visual proof you're improving)
Displays streaks (the most motivating metric)
Reminds you intelligently (not annoying notifications)

The research is clear: Visual progress is the #1 motivator for habit building.

3. Task Manager (Simple but Powerful)

Add tasks with priorities, due dates, reminders
Organize with labels and categories
Search, filter, sort (find anything instantly)
Snooze reminders (deal with tasks when you're ready)

4. Everything Offline + Private

Works completely offline (no internet required)
Your data never leaves your device (no cloud)
No tracking, no ads, no servers
Completely free forever

Key Differences: Daymint vs The Alternatives

Feature	Daymint	Todoist	Habitica	Google Cal
Daily Planning	✓	✓	✗	✓
Habit Tracking	✓	✗	✓	✗
Task Management	✓	✓	✗	✗
Offline	✓	✗	✗	✗
Free Forever	✓	✗ (requires Pro)	✓	✓
Privacy	✓	✗	✓	✗
Single App	✓	✓	✓	✓
All 3 Together	✓	✗	✗	✗

The Technical Side

Why I built it this way:

Built with:

Kotlin for Android (clean, modern language)
Room Database for offline-first architecture
Material Design 3 for modern UI
MVVM architecture for maintainability
Zero dependencies on servers or cloud services

I deliberately chose offline-first + local storage because:

Privacy - Your habits are personal
Reliability - No internet issues
Speed - Everything instant, no network latency
Control - You own your data

What I Learned

1. The Power of Focus

Building ONE app that does three things well > THREE apps doing one thing each.

The feature creep temptation was real. But I forced myself to ask:
"Does this help with daily planning + task management + habit tracking?"

If not, it got cut.

2. Offline-First Changes Everything

Most apps assume cloud sync. When you design offline-first:

Users feel more in control
Privacy concerns disappear
Speed improves dramatically
Trust increases

3. Habit Building is Psychological, Not Technical

The best feature isn't the algorithm or the sync. It's:

Visual progress (streaks)
Consistent reminders (at the right time)
Celebration of wins (30-day milestones)
Low friction (1-tap to complete)

Results So Far

Launched 2 weeks ago on Android:

50+ downloads
4.2+ rating (from early users)
100% positive feedback
Completely free, no ads

Should You Use Daymint?

Yes, if you:

Want everything in ONE app
Value privacy + offline
Don't need cloud sync
Want a simple, clean UI
Can't afford $50+/year for premium tools

No, if you:

Love Todoist's power features
Need cross-device sync
Want gamified habit tracking (Habitica)
Use teams/collaboration

Get Started

Download Daymint completely free on Google Play Store:
[Play Store Link]

No ads, no tracking, no premium features. Just a simple, powerful
daily planner + habit tracker.

What's Next?

I'm actively developing Daymint based on feedback. Currently working on:

Recurring task templates
More analytics on habit progress
Custom habit schedules
Export features

I'd love to hear from you:

What features would make it 5 stars for you?
What's missing compared to your current setup?
What's one thing you struggle with in productivity?

Drop a comment below or email me at s22542273@gmail.com

Have you felt the pain of using multiple productivity apps?
What's your setup? Let me know in the comments!

Building a 3D Zombie Survival Horror in Unity: Day 1 of Our Journey

Mattia Santangelo — Sat, 25 Apr 2026 09:35:26 +0000

🧟‍♂️ The Road of the Dead: A New Indie Horror Adventure

Hi everyone! I’m a 12-year-old developer and today I’m officially starting a big project with my friend and classmate, Dardan. We decided to stop just playing games and start building our own.

💡 The Concept

Our game is a 3D Survival Horror. The core idea is simple but intense:
You are trapped in a car driving through a wasteland infested with monsters and zombies.

The Car is your Armor: It has its own HP. If the zombies damage it too much, it breaks down.
The Switch: When the car stops, you HAVE to get out. That’s when the game changes from a driving simulator to a third-person survival fight against scary bosses.

👥 The Team

We’ve split the roles to work like a real indie studio:

Me (Lead Programmer): I’m handling the C# scripts, the car physics, and the health systems using Unity.
Dardan (Lead Designer): He’s in charge of the 3D models, environment design, and making the monsters look terrifying.

🛠️ The Tech Stack

We are developing this project using Unity (URP).
I am currently working on my Dell Latitude 7290. It’s a great challenge to optimize a 3D game for mobile-grade hardware, but it teaches me a lot about performance!

🚀 What's Next?

Right now, I’ve just finished the basic car movement script and a simple health system. Dardan is working on the first "Scary Boss" model.

We know we have a lot to learn, but we are excited!

What do you think about the "Car HP" mechanic? Any tips for a young dev team starting with Unity?

Unity #GameDev #IndieDev #Horror #Programming #Beginner

The State of Agent Identity — Q2 2026

Pico — Sat, 25 Apr 2026 09:33:28 +0000

I'm building AgentLair — cross-org behavioral trust infrastructure for AI agents. The AAT spec, JWKS verification, and audit trail are live. Reach out: team@agentlair.dev

Previously: World ID for Agents Is L1/L2 — Here's Why L4 Still Doesn't Exist | Five Identity Frameworks, Three Gaps | Microsoft Built the Intranet of Agent Trust

The Day I Stopped Using AI… and Started Delegating to It

Arnav Gawade — Sat, 25 Apr 2026 09:30:42 +0000

For the longest time, I genuinely thought I was using AI the “proper” way.
Open ChatGPT.
Ask something.
Get an answer.
Close it.

That was it. That was the entire relationship.

And to be fair… it helped a lot.

Homework, explanations, ideas, quick doubts — it was always useful when I needed it.

But slowly, I started noticing something I didn’t really think about before.

It only works when I remember to use it.

If I don’t open it, nothing happens.
If I forget, it just disappears from my day completely.
If I’m tired or distracted, it’s like it doesn’t even exist.

And that’s when it started feeling a bit… limited.

Not bad. Just dependent on me doing everything.

Then I tried OpenClaw.

And honestly, it felt weird at first.

Because it wasn’t just sitting there waiting for me to type something.

It was… active in a different way.

The first time it sent me something on its own, I actually stopped for a second.

It wasn’t anything dramatic — just a small update I had set earlier.

But the strange part wasn’t what it sent.

It was the fact that:

I didn’t ask for it in that moment.

It just showed up. Quietly. Naturally.

And that small moment kind of changed how I looked at it.

That’s when it clicked for me.

This doesn’t feel like ChatGPT.

This feels more like something that’s just there in the background, doing things without me constantly pulling it into the picture.

I wasn’t opening it every time.
I wasn’t reminding myself every hour.
I wasn’t “using” it in the traditional sense.

Things were just… happening.

Reminders I would’ve forgotten.
Follow-ups I would’ve delayed.
Small tasks that usually slip through.

Not perfectly. Not magically. Not like it’s reading my mind.

But still enough to make me go:

“Wait… I didn’t even think about that.”

What surprised me the most wasn’t any feature.

It wasn’t the interface or the setup or anything technical.

It was the feeling.

With most AI tools, there’s always a tiny bit of effort involved.

You think → you open → you ask → you wait.

You’re always the one pushing the interaction forward.

But this felt different.

This felt like something was quietly reducing the number of things I need to remember.

Not doing everything for me.

Just… lightening the mental load a bit.

I’m not saying it replaces anything.

And honestly, setting it up wasn’t instant — it took some time and effort to get it running properly.

But once it was in place, something changed.

I stopped thinking about it all the time.

And maybe that’s exactly what made it different.

I still use ChatGPT. I still use other tools too.

But now they feel like something I go to when I need them.

This feels more like something that just stays in the background of my life.

Quiet. Passive. Running.

I don’t even know if this is the future of AI or just a different way of using it.

But I do know one thing now:

The moment something starts working without you needing to ask it every single time…

…it stops feeling like just a tool.

The Magic Behind Video Calls: A Simple Guide to WebRTC

Drian — Sat, 25 Apr 2026 09:27:16 +0000

Have you ever wondered, when you make a video call through a browser, how your friend’s face can appear on your screen so quickly?

Does the video have to “fly” first to a company server overseas, and only then come back down to your phone?

The answer is: not always.

Welcome to the world of WebRTC, or Web Real-Time Communication. It is a powerful technology that allows our browsers to “talk” directly to each other.

Let’s break down how it works without getting lost in complicated terms.

1. The Basic Concept: Peer-to-Peer (P2P)

In the traditional web, communication is like sending a letter through a post office.

You, as the client, send a letter to the post office, which acts as the server. Then, the post office delivers it to your friend.

It is safe, but it can be slower.

WebRTC works differently. It uses the Peer-to-Peer concept.

Imagine you and your friend are in the same room, talking directly to each other. No middleman. No post office.

The result?

Real-time communication and high-quality video.

But on the internet, “meeting in the same room” is not that easy. There are many obstacles.

2. The Challenge: “Where Are You?”

The main problem with the internet is this: our computers are often “shy.”

They hide behind a home or office Wi-Fi router. This is called NAT, or Network Address Translation.

Because of NAT, our computer often does not know its own real public address.

For example, if Computer A says to Computer B:

“Hi, my address is 192.168.1.5”

Computer B will not be able to find it, because that is only a local private address.

So, what is the solution?

WebRTC has a special team to handle this.

A. The Matchmaker: Signaling

Before Browser A and Browser B can talk directly, they need a temporary helper to exchange contact information.

This process is called signaling.

They exchange information such as:

“I support HD video.”
“My network can be reached from this address.”

After the contact information is exchanged, the matchmaker steps aside and lets A and B communicate directly.

B. The Magic Mirror: STUN Server

Since our computer does not know its own public address, it asks a STUN server.

The conversation looks something like this:

Computer: “Hey STUN, what address do I look like from the outside?”

STUN: “You appear to be using the IP address 203.0.113.5.”

With this information, our computer can tell its friend the correct address.

C. The Emergency Route: TURN Server

Sometimes, an office network or firewall is very strict.

It is like a tall wall blocking direct communication, even after using STUN.

This is where the TURN server comes in.

If the direct route is blocked, TURN acts as a relay.

The flow looks like this:

Computer A sends data to TURN.
TURN forwards the data to Computer B.

This is Plan B.

The connection may become a little slower and it may require more server cost, but the most important thing is that the call can still connect.

D. The Manager: ICE

The protocol that manages route selection is called ICE, or Interactive Connectivity Establishment.

ICE decides whether the connection can go directly or must go through TURN.

It intelligently chooses the best and fastest route available.

3. The Main Weapons of WebRTC: APIs

For developers, WebRTC provides three main “weapons” in JavaScript.

1. MediaStream / getUserMedia

This is the gateway to the user’s camera and microphone.

This API asks for permission to turn on the camera and microphone, then converts them into a digital media stream.

2. RTCPeerConnection

This is the main engine of WebRTC.

It manages the connection, checks the bandwidth, and makes sure the video reaches the other side safely.

3. RTCDataChannel

WebRTC is not only for audio and video.

It can also send any kind of data, such as image files, chat messages, or multiplayer game data.

The advantage?

The data can be sent directly through P2P, making it very fast and more private because it does not need to pass through a database server.

Conclusion

WebRTC is a technology that cuts through the bureaucracy of internet communication.

With the help of STUN to discover public addresses, TURN to get through strict firewalls, and powerful APIs, our browsers can become advanced communication tools without requiring extra applications to be installed.

So, the next time you join a video call, remember the hard work of “ICE,” quietly searching for the best hidden path so your friend’s face does not keep buffering.

🚀 Claude Code: From Zero to Hero 🤖

Truong Phung — Sat, 25 Apr 2026 09:26:55 +0000

A practical, progressive guide to getting serious value out of Claude Code. Each section is short, actionable, and builds on the one before. If you already know the basics, skim the early parts and jump to where it gets interesting — the later sections are where most users leave value on the table.

📖 How to read this guide
Every section ends with a Try this now box. Do the exercise before moving on. Reading alone will not make you faster; typing will.

🌱 Part 1 — Zero

What Claude Code actually is
Install and first run
Your first real task
The interface: commands and shortcuts you need on day one

🔧 Part 2 — Apprentice

CLAUDE.md — teaching Claude about your project
Permissions — stop approving the same commands over and over
Plan mode and review discipline
Context hygiene — the skill nobody teaches

⚡ Part 3 — Journeyman

Slash commands — your personal shortcuts
Subagents — delegation and isolation
Skills — reusable procedures
Hooks — deterministic automation

🏆 Part 4 — Hero

MCP servers — connecting external systems
Prompting for real work
Team setup — making Claude Code a shared asset
Debugging Claude when it goes sideways
The habits that separate heroes from tourists

🌱 Part 1 — Zero

1. 🤖 What Claude Code actually is

Claude Code is an AI coding agent that runs in your terminal (and inside VS Code, JetBrains, etc.). It reads your codebase, writes and edits files, runs shell commands, and iterates on tasks — all with your permission.

Three mental models that will save you hours of confusion:

It's a collaborator, not a compiler. You describe intent; it proposes actions and waits for approval on anything risky. Give it context the way you'd brief a new teammate.
It is stateless between sessions, but not between turns. Close the terminal and it forgets the conversation. That's why project memory (CLAUDE.md) exists — to carry the important stuff forward.
Every tool call is explicit. Reading a file, editing it, running a shell command — these are all visible tool calls. If it's making changes you don't want, you can see exactly where.

What it is not: a chat wrapper. Claude Code has a rich configuration surface — permissions, slash commands, subagents, skills, hooks, MCP servers — and the difference between a tourist and a power user is almost entirely in how those are set up.

2. 📦 Install and first run

Install the CLI (one command, no account setup beyond API access):

npm install -g @anthropic-ai/claude-code

Verify:

claude --version

Start it inside a project directory:

cd ~/projects/my-repo
claude

On first run it will walk you through authentication. After that, you're looking at an interactive prompt waiting for input.

🔥 Try this now
Install Claude Code, cd into any project you have, and run claude. Type /help and read the entire help output. Don't skip this — 30% of the things people ask me could be answered by reading /help once.

3. 🎯 Your first real task

Don't start with "hello world." Start with something you'd actually ask a teammate.

A good first prompt:

Read the README.md and the top-level directory, then give me a two-paragraph summary of what this project does and how the pieces fit together.

Why this works: it's bounded, read-only, and forces Claude to explore the codebase — which is how you'll learn what tools it has.

Watch what happens:

It calls Read on README.md
It runs ls via Bash
Maybe it peeks at a few key files
It answers in prose

You'll see tool calls scroll by. Each one is a concrete action. This transparency is the whole point — you're not trusting a black box.

Now try something active:

Add a CHANGELOG.md at the repo root with a "Keep a Changelog" template and an Unreleased section.

It will ask permission to write the file. Say yes. Look at the diff it produced. Ask it to change something trivial ("add a link to keepachangelog.com at the top"). Notice how it edits in place rather than re-writing the file.

🔥 Try this now
Pick one real, small task in a real repo — not a toy — and ask Claude Code to do it end to end. Something like "write me a script that renames all .jpg to .png" or "refactor this function to use async/await." Review every tool call. Reject one thing you don't like and watch it adjust.

4. ⌨️ The interface

Key commands (type these at the prompt)

Command	What it does
`/help`	Full command reference
`/clear`	Wipe the conversation — start fresh without quitting
`/model`	Switch between models (Opus / Sonnet / Haiku)
`/init`	Bootstrap a `CLAUDE.md` for the current project
`/status`	Show what mode you're in, token usage, etc.
`/review`	Review the current branch's changes
`/compact`	Manually compact conversation context to free room
`Esc`	Interrupt Claude mid-action
`Shift+Tab`	Cycle through permission modes (normal → auto-accept → plan)

Permission modes (the single most useful thing to understand)

Claude Code has three main modes you'll toggle between:

Normal — Claude asks before every tool call that isn't pre-approved. Safe default.
Auto-accept (a.k.a. "YOLO mode" or "accept edits") — Claude runs without asking. Use when you trust the task and want speed. Never use for destructive or networked operations on a repo you care about.
Plan mode — Claude explores and reasons but cannot modify anything until you approve a plan. Use for anything non-trivial. This is the single biggest time-saver most people ignore.

Cycle them with Shift+Tab. The current mode is shown in the status area.

Interrupting

If Claude is going down the wrong path, hit Esc. Don't wait for it to finish and then complain — redirect mid-flight. It handles interruption well.

🔥 Try this now
Start a session, press Shift+Tab three times and observe how the mode indicator changes. Then try the same trivial task ("add a blank line to the README") in each mode and feel the difference. Also press Esc while it's mid-action at least once. Getting comfortable with these three keys is worth more than any config.

🔧 Part 2 — Apprentice

5. 📄 CLAUDE.md

CLAUDE.md is the single most valuable file in a Claude-Code-enabled repo. It's plain markdown placed at the repo root (and optionally in subdirectories) that Claude reads at the start of every session.

Think of it as the onboarding doc for a new engineer, except the engineer reads it every single day and has perfect recall.

What to put in it

Architecture — the service boundaries, the data flow, who calls whom
How to run things — exact commands, copy-paste runnable
Conventions that the code alone can't tell you — "we prefer functional components," "all errors must be wrapped with fmt.Errorf," etc.
Pitfalls — things that have burned the team before ("never edit an applied migration")
End-to-end checklists for common tasks ("adding a feature touches these 9 layers, in this order")

What to leave out

Anything ls or git log can answer
Narrative prose, history, aspirations
Secrets
Step-by-step tutorials (link to them instead)

Layering

You can have nested CLAUDE.md files. When Claude works inside a subdirectory, the nested file is loaded too. Use this for service-specific conventions in a monorepo.

repo/
  CLAUDE.md                  # root — cross-cutting context
  backend-go/CLAUDE.md       # Go-specific conventions
  backend-python/CLAUDE.md   # Python-specific conventions
  frontend/CLAUDE.md         # React/TS-specific conventions

There's also ~/.claude/CLAUDE.md — personal preferences applied in every project on your machine (e.g., "I prefer tabs over spaces in my personal scripts").

Rules of thumb

Every line competes for context budget. Treat it like a tweet — if removing a line wouldn't hurt, remove it.
Prefer commands over instructions. make test-integration beats a paragraph about integration tests.
State constraints explicitly. "Integration tests require Docker." not "We have integration tests."
Link, don't duplicate. If your style guide lives elsewhere, link it.

🔥 Try this now
In your project, run /init. Claude will scan the codebase and draft a CLAUDE.md for you. Then read it critically and delete half the content. The short version is usually better. Commit it.

6. 🔐 Permissions

By default, Claude asks before running any shell command or editing any file. That's safe but interrupt-heavy.

Create .claude/settings.json in your repo:

{
  "permissions": {
    "allow": [
      "Bash(go test:*)",
      "Bash(pnpm test:*)",
      "Bash(npm run build:*)",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ],
    "deny": [
      "Bash(sudo:*)",
      "Bash(rm -rf /:*)",
      "Bash(git push --force:*)"
    ]
  }
}

Pattern rules

Bash(cmd:*) — allow cmd followed by any arguments
Bash(cmd arg1:*) — allow cmd arg1 with anything after
Bash(cmd) — exact match only
deny always wins over allow

Personal vs team

.claude/settings.json — committed, shared with the team
.claude/settings.local.json — git-ignored, personal tweaks (your favorite CLIs, local env)
~/.claude/settings.json — global, applies to every project on your machine

The golden rule

Never blanket-allow Bash(*). The permission prompt is cheap; a destructive command you didn't mean to run is expensive. Keep the deny list tight and aggressive.

🔥 Try this now
Look back at your last Claude Code session. Which commands did you approve three or more times? Those are your candidates for the allow list. Add them to .claude/settings.json and commit. Do NOT add things you only approved once — premature allow-listing is how people accidentally yield too much.

7. 🗺️ Plan mode

For any task that is more than "rename this variable," press Shift+Tab until you're in Plan mode before you start. Then prompt:

Plan out what it would take to add rate limiting to the /api/login endpoint. Don't make any changes — just propose the plan.

Claude will explore, read code, think, and produce a concrete plan (files to touch, order of operations, tradeoffs). You review the plan, ask follow-up questions, adjust the approach. When you're happy, you exit plan mode and tell it to execute.

This pattern catches an enormous class of "Claude went off and did the wrong thing" problems. Five minutes of planning saves an hour of re-doing.

When to skip plan mode

Trivial edits (typo fix, one-line change)
Tasks where "wrong direction" has no cost (exploratory prototyping)
When you're already in a detailed prompt-response loop and have alignment

When to always use plan mode

Any change touching more than 3 files
Any migration or refactor
Any task involving external systems (APIs, databases, deploys)
Anything where you'd review a PR carefully — if it needs review, it needs a plan first

🔥 Try this now
Take a real task on your backlog that you've been putting off. Enter plan mode. Ask for a plan. Read it critically. You'll find that either (a) the plan reveals the task is bigger than you thought — which is useful information — or (b) you're now ready to execute with confidence.

8. 🧹 Context hygiene

The single most underrated skill. Long conversations accumulate irrelevant context, which degrades Claude's attention and eats your token budget.

Rules

Start a new session for an unrelated task. Don't use the same conversation to fix a bug, add a feature, and then write release notes.
Use /clear aggressively. When you shift focus, clear the conversation. The cost of re-explaining is usually less than the cost of carrying accumulated noise.
Don't paste huge logs. If the full stack trace is 2000 lines, paste the top 20 and let Claude ask for more if needed.
Delegate searches. "Find every place X is used" is a job for a subagent (covered in Part 3), not your main conversation. A subagent can ingest a mountain of search output and return a short summary, keeping your main context clean.
Use /compact when context fills up. It summarizes history and continues with less bloat. Better than letting auto-compaction kick in mid-task.

Signs your context is polluted

Claude makes the same small mistake it already corrected earlier
It references files that have nothing to do with the current task
It proposes solutions that contradict constraints you already set
Responses feel generic and hedge-y

When you see these, /clear is almost always the right move.

🔥 Try this now
Next time you finish a task, before starting a new one, run /clear. Build the muscle. Most people keep the conversation running forever and wonder why Claude gets worse over time.

⚡ Part 3 — Journeyman

9. ⚡ Slash commands

A slash command is a markdown file in .claude/commands/ that becomes an invocable shortcut. The file body becomes the prompt; $ARGUMENTS is substituted with whatever you type after the command name.

Minimal example

.claude/commands/review.md:

Review the uncommitted changes on this branch.

Focus on:
- Security issues (injection, XSS, unsafe deserialization)
- API contract changes that would break callers
- Missing tests for new code paths
- Unused imports, dead code

Don't modify files — review only. Output a punch list.

Invoke with /review.

With arguments

.claude/commands/test.md:

Run the test suite for the specified service. Argument: $ARGUMENTS

Rules:
- If argument is "go": `cd backend-go && go test ./... -race -count=1`
- If argument is "python": `cd backend-python && uv run pytest -v`
- If argument is "frontend": `cd frontend && pnpm test`
- If argument is "all" or empty: run all three, stop on first failure

Invoke with /test go or /test all.

Frontmatter (optional)

---
description: Open a PR for the current branch with auto-generated title and body
argument-hint: "[issue-number]"
allowed-tools: ["Bash", "Read", "Write"]
model: opus
---

Steps:
1. Ensure branch is pushed
2. Read commits since diverging from main
3. Draft a PR title and body based on the commits
4. Run `gh pr create` with the drafted content
5. If $ARGUMENTS is present, add "Closes #$ARGUMENTS" to the body

Gotchas

Flat namespace. .claude/commands/git/commit.md becomes /commit, not /git:commit. Name files carefully.
No code execution in the markdown file itself — the body is sent as a prompt. Claude then decides what to run.
Keep them focused. If a command tries to do too much, split it.

Slash command vs skill vs subagent

	Use when
Slash command	User explicitly triggers a workflow (`/test`, `/lint`, `/pr`)
Skill	Reusable procedure Claude should apply when relevant (user doesn't type it)
Subagent	You want an isolated context / fresh conversation for a big sub-task

🔥 Try this now
Identify the three prompts you most commonly type. Turn each into a slash command. You'll feel the productivity gain immediately.

10. 🤝 Subagents

Subagents are specialized Claude instances that run in a separate conversation with their own system prompt and tool permissions. The main agent delegates work to them.

Why this matters:

Context isolation. The subagent doesn't see your main conversation. Great for independent reviews — it can't be biased by your prior reasoning.
Parallelism. The main agent can run multiple subagents concurrently. Perfect for "check A, B, and C independently."
Tool scoping. A "reviewer" subagent can be given read-only tools, so it literally can't write files even if asked.

Defining a subagent

Create .claude/agents/migration-reviewer.md:

---
description: Review SQL migrations for safety. Use proactively whenever a migration file is added or modified.
tools: ["Read", "Bash", "Grep"]
model: opus
---

You are a database migration safety reviewer. For any migration under `backend-go/migrations/`, check:

1. Does it have both Up and Down blocks?
2. Are NOT NULL columns added with a default, or is there a backfill step?
3. Are indexes created CONCURRENTLY on large tables?
4. Is there anything irreversible (DROP COLUMN, DROP TABLE) that needs a rollback plan?

Report findings as a punch list. Do not modify files.

The main agent will now auto-invoke this whenever a migration changes (because of the "Use proactively" phrasing).

Built-in agent types

Claude Code ships with a few built-in agent types you can use without defining your own:

Explore — fast codebase search, great for "find every place X is used"
general-purpose — the default, for any research task

When to use a subagent

Research/exploration that will generate lots of output you don't want in your main context
Independent review where you want an unbiased second opinion
Parallelizable work — three questions that don't depend on each other

When NOT to use a subagent

Small targeted tasks — spawning a subagent has overhead; for a 30-second task, just do it yourself
Tasks where you want to stay in conversation — the subagent returns one message and is gone; you can't iterate with it

🔥 Try this now
Next time you need to understand an unfamiliar area of your codebase, prompt the main agent: "Spawn an Explore subagent to find every place authenticate() is called, what it returns, and who handles its errors. Give me a short report." Notice how your main context stays clean.

11. 💡 Skills

Skills are reusable procedures that Claude loads when relevant. Unlike slash commands (user-triggered) or subagents (fresh-context delegation), skills layer procedural knowledge onto your current conversation.

Directory layout

.claude/skills/
  release-notes/
    SKILL.md          ← required
    template.md       ← optional supporting files
    scripts/
      extract.sh      ← optional helper scripts

SKILL.md format

---
description: Generate release notes from git log since the last tag. Invoke when the user asks for a changelog, release notes, or summary of recent changes.
---

# Release Notes Skill

When invoked:

1. Find the last tag: `git describe --tags --abbrev=0`
2. Run `git log <tag>..HEAD --pretty=format:'%h %s (%an)' --no-merges`
3. Group commits by conventional prefix (feat/fix/chore/docs/refactor)
4. Format using `template.md` in this skill directory
5. Output the final markdown — do not write to a file unless asked

Auto-discovery

Claude reads the description of every available skill at session start. When your prompt matches a skill's description, it's invoked automatically.

This is why the description matters more than anything else in the skill. Write it like a trigger: when should this fire?

Bad: "Release notes generator."
Good: "Generate release notes from commits since the last git tag. Invoke when the user asks for a changelog, release notes, or summary of changes since vX.Y.Z."

Skill vs slash command — the quick heuristic

Ask: "Will the user explicitly type /skill-name?"

Yes → make it a slash command
No, but Claude should apply it when a situation arises → make it a skill

Built-in skills

Claude Code ships with several built-in skills (update-config, simplify, pr, lint, test, gen, build, migrate, review, security-review, etc.). Run /help to see what's currently registered.

🔥 Try this now
Pick a procedure your team does routinely — releasing a version, writing a migration, auditing a feature — and turn it into a skill. Craft the description carefully so Claude auto-invokes it.

12. 🪝 Hooks

Hooks are shell commands the harness (not Claude) runs in response to events. They run outside Claude's decision loop, which makes them the right tool for:

Enforcing something deterministically (auto-format after edit)
Injecting context (show branch name on session start)
Blocking unsafe actions (refuse writes to /etc/)

A memory instruction like "always format Go files" is advisory — Claude might forget. A hook is a hard guarantee.

Shape

Hooks live in .claude/settings.json:

{
  "hooks": {
    "<EventName>": [
      {
        "matcher": "<pattern>",
        "hooks": [
          { "type": "command", "command": "<shell>" }
        ]
      }
    ]
  }
}

Events you'll actually use

Event	Fires when
`PreToolUse`	Before a tool runs. Exit 2 blocks it.
`PostToolUse`	After a tool succeeds. Good for auto-format.
`UserPromptSubmit`	After user sends a prompt. Can inject context.
`SessionStart`	Session boot.
`Stop`	End of Claude's turn.

Exit codes and I/O

0 — success; stdout becomes context for Claude
2 — blocking; stderr is shown to Claude as the reason to retry/adjust
other — non-blocking error; logged and ignored

Hooks receive the event payload as JSON on stdin. Parse with jq:

file=$(jq -r '.tool_input.file_path // empty')

Example 1 — auto-format after edit

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "file=$(jq -r '.tool_input.file_path // empty'); [[ \"$file\" == *.go ]] && gofmt -w \"$file\"; [[ \"$file\" == *.py ]] && ruff format \"$file\"; true"
          }
        ]
      }
    ]
  }
}

Example 2 — block writes to generated files

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "file=$(jq -r '.tool_input.file_path // empty'); if [[ \"$file\" == *generated/* ]]; then echo 'Do not edit generated files — re-run code generation instead.' >&2; exit 2; fi"
          }
        ]
      }
    ]
  }
}

Example 3 — inject branch info at session start

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": "echo \"Branch: $(git branch --show-current)\"" }
        ]
      }
    ]
  }
}

When hooks are the wrong tool

"Remind Claude to write tests" → put it in CLAUDE.md, not a hook
"Run tests only when I say" → slash command, not a hook
"Apply procedure X in situation Y" → skill, not a hook

Hooks are for the things the harness must enforce regardless of what Claude decides.

🔥 Try this now
Add a PostToolUse hook that auto-formats any file Claude edits in your project's language. One concrete step that will improve every future session.

🏆 Part 4 — Hero

13. 🔌 MCP servers

Model Context Protocol (MCP) servers extend Claude with external tools — Slack, Linear, Sentry, Postgres, your internal APIs. Configure them in .claude/settings.json:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgres://dev:dev@localhost:5432/app"]
    }
  }
}

Popular servers: postgres, github, slack, linear, sentry, puppeteer, fetch. See the MCP server directory.

Before adding an MCP server, ask:

"Would a shell command work?"

A psql invocation in your permission allowlist is simpler than a Postgres MCP server 90% of the time. MCP is right when:

The tool requires stateful auth (OAuth flows, API keys that rotate)
The output is richly structured (JSON APIs where Claude needs field-level access)
You want Claude to call the tool across many turns without re-establishing connection

If you're adding an MCP server "because I saw one for X," check whether curl, gh, psql, or aws already solves the problem.

14. ✍️ Prompting for real work

Prompting advice is often generic. Here's what actually matters for Claude Code specifically:

1. Scope bounded, context explicit

Bad: "Fix the tests."
Good: "Fix the flaky test in backend-go/internal/service/user_test.go. It fails about one run in ten. The last failure log is in /tmp/test-output.log."

The more of the context you provide up front, the less Claude has to spend tokens discovering.

2. State constraints before action

"Don't change the public API."
"Only modify files under frontend/src/components/."
"If the fix requires more than 50 lines of changes, stop and tell me — don't barrel through."

These constraints prevent whole classes of "this isn't what I wanted" outcomes.

3. Ask for a plan first on anything non-trivial

Covered in section 7. Plan mode is free; re-doing work is expensive.

4. Be honest about your knowledge

"I don't know this codebase well; help me understand X before we change it" produces better results than pretending to know.

5. Push back on mediocre output

If Claude produces something that works but isn't good, say so: "That works, but it has three issues: (a) ..., (b) ..., (c) .... Please revise." Don't accept first-draft output on things that matter.

6. Use "one-shot" framing for tightly-scoped tasks

"Write a bash script that does X. One shot — no back-and-forth. Output the whole script." forces a more thorough first response than open-ended prompting.

7. For debugging, state the hypothesis

Bad: "Why is this broken?"
Good: "I think this is broken because the deploy step doesn't wait for the DB migration to finish, but I'm not sure. Verify or refute that hypothesis first."

Hypothesis-first debugging is 3× faster than open-ended investigation.

15. 👥 Team setup

Taking Claude Code from "a tool each person uses" to "a shared team asset" is high-leverage. Here's the checklist:

Committed to the repo

CLAUDE.md at root, per-service where useful
.claude/settings.json — shared permissions and hooks
.claude/commands/ — team slash commands (/test, /lint, /pr, /review, /deploy-staging)
.claude/agents/ — team subagents (reviewers, explorers)
.claude/skills/ — team procedures (release notes, migration review, on-call runbook)

Gitignored

.claude/settings.local.json — personal overrides
.env — secrets

Onboarding new engineers

Every new hire spends the first 30 minutes of day one:

Reading CLAUDE.md and every nested CLAUDE.md
Skimming .claude/commands/ — what shortcuts exist
Copying .env.example → .env
Running make dev (or equivalent) to verify the stack boots
Adding personal approvals to .claude/settings.local.json (not the shared file)

Keeping it fresh

Review CLAUDE.md quarterly. Stale guidance is worse than no guidance.
Add a pitfall every time someone gets burned. Post-incident: "update CLAUDE.md?" should be on the checklist.
Prune. If a slash command isn't used in a month, delete it. If CLAUDE.md has grown past ~300 lines, split it.

16. 🐛 Debugging Claude

When things go wrong, the problem is almost always one of these:

Symptom	Likely cause	Fix
Claude keeps asking to run a command I want pre-approved	Not in `permissions.allow`, or pattern too narrow	Add `Bash(cmd:*)` to `.claude/settings.json`
My hook isn't firing	Wrong event name, wrong matcher, or bad JSON	Validate JSON; re-check event name; test the command in isolation
Claude edits files but skips formatting	`PostToolUse` hook crashed silently	End hook command with `
Slash command not found	File naming collision (flat namespace)	Rename file; put it directly in {% raw %}`.claude/commands/`
`~/.claude/CLAUDE.md` isn't being read	It is — but per-project `CLAUDE.md` takes precedence for overlapping topics	Split clearly: global in `~/.claude`, project in repo
Subagent gives a different answer than main agent	Expected — it has isolated context by design	If you want shared context, don't use a subagent
Claude forgets between sessions	Facts were only in chat, not in `CLAUDE.md`	Move enduring facts to `CLAUDE.md`
Hook blocks every command unexpectedly	Exit code 2 is a hard block	Reserve exit 2 for real blocks; use 0 for non-blocking
Claude keeps making the same mistake	Context is polluted with contradictory info	`/clear` and re-prompt with explicit constraints
Response is generic and useless	Claude lacks context to answer well	Give it a file to read, a command to run, or narrow the scope

Using `--debug`

Run Claude Code with --debug to see detailed logs — hook invocations, tool calls, timing. Essential when something silent is misbehaving.

The "read it back" trick

When Claude produces output you disagree with, prompt: "Read back to me your understanding of what I asked for." Usually reveals the specific misinterpretation in seconds. Cheaper than re-arguing.

17. 💪 Habits

A list of habits that separate the heroes from the tourists. None of them are secret. All of them are practiced, not learned.

✅ Do

Plan before you build. For any non-trivial task, use plan mode or ask for a plan.
Review every diff before accepting. Claude is fast; a fast wrong change is still wrong.
Clear context aggressively. Start new sessions for unrelated work.
Update CLAUDE.md when you get burned. The next person (or your future self) shouldn't repeat the mistake.
Use subagents for exploration. Keep your main context clean.
Push back on mediocre output. Say "that's not quite right because X; revise."
Commit your .claude/ configuration. It's team infrastructure, not personal config.
Keep denies aggressive, allows minimal. sudo, rm -rf /, git push --force should always be blocked.

❌ Don't

Don't blanket-allow Bash(*). The cost of permission prompts is much less than the cost of one accidental destructive command.
Don't paste 2000-line logs. Paste the relevant 20 lines.
Don't accept first-draft output on things that matter. Iterate.
Don't keep one session running forever. Context rot is real.
Don't put secrets in CLAUDE.md or the chat. Ever.
Don't skip hooks (--no-verify) without a specific reason. Fix the real issue.
Don't build elaborate configuration before you've used the defaults for a week. Start simple. Add surfaces when you feel the pain.

📈 The progression

You're a tourist if you:

Type freeform prompts, approve everything one by one, never configure anything

You're an apprentice if you:

Have a CLAUDE.md, permission allow list, and use plan mode regularly

You're a journeyman if you:

Have slash commands for your common workflows, use subagents for exploration, and have at least one hook enforcing a guarantee

You're a hero if you:

Treat .claude/ as team infrastructure, prune it regularly, and notice when you're using the wrong surface (skill when it should be a command, hook when it should be memory)

📚 Further reading

Official docs — https://docs.claude.com/en/docs/claude-code
MCP server directory — https://github.com/modelcontextprotocol/servers

📋 One-page summary

If you remember nothing else:

Put enduring facts in CLAUDE.md. Keep it tight.
Pre-approve your common commands in .claude/settings.json. Never Bash(*).
Use plan mode (Shift+Tab) before any non-trivial task.
Clear context between unrelated tasks (/clear).
Turn your repeat prompts into slash commands.
Use subagents for big searches and independent reviews.
Use skills for procedures Claude should apply automatically.
Use hooks when you need a hard guarantee, not a polite suggestion.
Review every diff. Push back on mediocre output.
Update configuration when you get burned — once, not twice.

🚢 Happy shipping.

If you found this helpful, let me know by leaving a 👍 or a comment!, or if you think this post could help someone, feel free to share it! Thank you very much! 😃

Personal Perspective

Bharath Vankayala — Sat, 25 Apr 2026 09:19:24 +0000

🌟 My Top Google Cloud NEXT ’26 Highlight

🏆 Chosen Announcement

The Gemini Enterprise Agent Platform
(The complete architectural evolution and rebranding of Vertex AI)

🚀 Quick Summary

Google has effectively "retired" the Vertex AI brand to launch the Gemini Enterprise Agent Platform, a specialized operating system designed not just to host models, but to scale, and orchestrate thousands of autonomous agents. This isn't just a name change; it’s a fundamental pivot from "Generative AI" (producing content) to "Agentic AI" (producing outcomes).

The platform introduces the Agent Runtime, which allows agents to maintain state for days via a new Memory Bank, and the Agent2Agent (A2A) Protocol, an open standard governed by the Linux Foundation that allows Google’s agents to negotiate and execute tasks with agents on AWS, Azure, and Salesforce. Supported by the new 8th Generation TPUs (8t for training, 8i for inference), this platform allows a company to transition from a workforce that uses AI to a workforce that manages a fleet of AI entities.

Why This Stands Above the Rest

From Chatbots to Employees: Most AI updates focus on "smarter answers." This platform focuses on "reliable actions." With Agent Identity, every agent is assigned a cryptographic ID and specific permissions, treating them as first-class corporate citizens rather than ephemeral API calls.
The End of the Walled Garden: The A2A Protocol is a masterstroke. By leading the charge on interoperability, Google is positioning itself as the "connective tissue" of the entire AI economy. An agent in Google Workspace can now natively "hand off" a procurement task to a supply-chain agent running in a competitor’s cloud without human intervention.

🌍 Real-World Impact

Autonomous Logistics: A global retailer can deploy "Vendor Agents" that monitor inventory in BigQuery, negotiate pricing via the A2A protocol with supplier agents, and execute contracts—all within the secure Agent Sandbox.
"Vibe-Coded" Startups: With the integration between Google AI Studio and Cloud Run, founders are now deploying full-stack apps simply by "vibing" (natural language description), letting the Agent Platform handle the underlying microservices, security, and scaling.

🎯 Why It Spoke

We’ve spent the last three years obsessed with "The Model"—the size of the parameters, the length of the context window. But at NEXT ’26, it became clear that the model is now just a commodity "engine." The Gemini Enterprise Agent Platform is the "chassis" and "transmission." It’s the first time I’ve seen a cloud provider provide a serious answer to the question: "How do I actually manage 5,000 agents without them hallucinating my budget away?" It’s the shift from AI as a toy to AI as a utility.

⚡ Final Verdict

The Gemini Enterprise Agent Platform isn't just a product launch; it is the formal declaration that the era of "Individual AI" is over and the era of the "Agentic Enterprise" has begun. Google has built the mission control for the next version of the global economy.