DEV Community: Sushil Kulkarni

Why ChatGPT Uses SSE Instead of WebSockets (And Why You Probably Should Too)

Sushil Kulkarni — Sat, 02 May 2026 11:13:44 +0000

If you've ever watched an AI chatbot “type” its answer word by word, you’ve already seen Server-Sent Events (SSE) in action.

That smooth streaming experience—where text appears token by token instead of waiting for the full response—is one of the reasons modern chat UIs feel fast and alive.

But here’s the interesting part:

Many developers assume this must be powered by WebSockets.

In reality, a huge number of AI chat apps use SSE instead.

And honestly? For most chat interfaces, SSE is often the better choice.

Quick Summary

SSE is great for chat UI because:

It streams AI responses in real time
It avoids constant polling
It uses standard HTTP (simpler infra)
It automatically reconnects if the connection drops
It’s lighter and easier to scale than WebSockets for one-way updates

If your app mostly needs server → client streaming, SSE is probably all you need.

What is SSE?

Server-Sent Events (SSE) is a lightweight web technology that allows the server to push real-time updates to the browser over a single long-lived HTTP connection.

Unlike traditional HTTP requests where the client asks and waits…

SSE keeps the connection open and continuously streams updates.

Think:

AI chatbots
Live dashboards
Stock tickers
Live sports scores
Notifications
Support systems

Basically: anything where the server talks more than the client

Watch this video for visual explanation

The Simple Analogy

SSE is like a long phone call where:

the client listens
the server keeps talking

The browser opens the line.

The server keeps sending updates.

The browser updates the UI instantly.

Simple.

How SSE Works (Step by Step)

1. The Handshake (Client Request)

The browser starts by sending a normal HTTP request.

But with one important header:

Accept: text/event-stream

This tells the server:

“Don’t send one response and close.
Keep the connection open and stream updates.”

2. The Open Pipe (Persistent Connection)

The server responds with:

HTTP/1.1 200 OK
Content-Type: text/event-stream

Now the pipe stays open.

No repeated polling.

No constant reconnecting.

Just one persistent stream.

3. The Data Stream (The Typing Effect)

As your AI model generates tokens…

the server sends small chunks like this:

data: {"text": "Hello"}

data: {"text": " there!"}

Each chunk arrives immediately.

This creates that familiar:

“AI is typing…”

experience.

4. The Client Listener (UI Update)

In JavaScript, the browser uses the native EventSource API:

const eventSource = new EventSource("/stream");

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log(data.text);
};

Every time new data arrives:

the UI updates instantly.

No refresh.

No polling.

No hacks.

5. Automatic Reconnection

This is underrated.

If the connection drops:

the browser automatically tries to reconnect.

No custom retry logic required.

This makes SSE surprisingly reliable for production systems.

6. Closing the Stream

Once the AI finishes generating:

the server can:

send an end event
or simply close the connection

Done.

Clean and efficient.

Why Not Just Use WebSockets?

Because sometimes WebSockets are overkill.

WebSockets are great when:

both client and server constantly talk
multiplayer apps
collaborative editors
trading systems
gaming

But for AI chat?

Usually the flow is:

User sends prompt once
Server streams response for 20 seconds

That’s mostly one-way communication

Which makes SSE a better fit.

SSE vs WebSockets

Feature	SSE	WebSockets
Direction	Server → Client	Two-way
Protocol	Standard HTTP	Custom WS Protocol
Infra Complexity	Simple	Higher
Auto Reconnect	Yes	Manual
Scaling	Easier	Harder
Best For	AI chat, live feeds	Real-time collaboration

This is why many production AI apps prefer SSE.

Not because it’s “newer.”

Because it’s simpler.

Real-World Use Cases

AI Chatbots

Like OpenAI ChatGPT-style interfaces where responses stream token by token.

Live Support Dashboards

Push:

“Agent is typing…”

“Ticket updated”

instantly.

Notifications

Real-time alerts without polling every 5 seconds.

Live Scoreboards

Sports, finance, operations dashboards.

Perfect fit.

Practical Takeaway

Before adding WebSockets to your architecture, ask:

Do I really need two-way real-time communication?

If the answer is:

“Mostly the server sends updates”

Use SSE first.

It’s simpler.

Cheaper.

Cleaner.

And often better.

Final Thought

Good engineering is not about choosing the most powerful tool.

It’s about choosing the simplest tool that solves the problem.

For modern chat UIs:

that tool is often SSE.

Not WebSockets.

Not polling.

Just elegant HTTP streaming.

And honestly…

that’s beautiful engineering.

What Do You Prefer?

Have you used SSE in production?

Do you still prefer WebSockets for chat systems?

Or do you think polling is still underrated?

I’d love to hear your take.

I Was Setting Up Claude Code Wrong. So I Built CCL.

Sushil Kulkarni — Wed, 29 Apr 2026 14:49:09 +0000

Every Claude Code project I started followed the same painful ritual.

Open a blank directory. Stare at it. Write a CLAUDE.md from scratch — half guessing at what Claude actually needs to know, half copying from a project I did last month. Then, manually create .claude/settings.json, wonder if my permissions are too loose, google what hooks actually do, forget to add a .claudeignore, realise two days in that I should have set up subagents from the start, and eventually accept that the AI I'm using to write production code is working with a half-configured environment I threw together in fifteen minutes.

Sound familiar?

The setup tax for Claude Code is real. And nobody had built a proper solution for it — so I did.

Meet CCL — Claude Context Loader.

🌐 https://sushilkulkarni1389.github.io/ccl/
⭐ https://github.com/sushilkulkarni1389/ccl ← If this resonates, a star means everything for an early-stage open source project.

What Claude Code Actually Needs to Work Well

Before I explain what CCL does, it's worth being precise about what "setting up Claude Code" even means — because it's more than most people realise.

A properly configured Claude Code project has:

CLAUDE.md — your project's onboarding document, written for Claude, not for humans. It needs to be concise (under 200 lines — it loads fully into context every session), opinionated, and cover the things Claude would otherwise get wrong: your stack, your commands, your conventions, your absolute prohibitions.
.claude/settings.json — permissions and security hooks. What Bash commands are allowed? What's blocked? What runs before every shell command to prevent disasters?
.claude/skills/ — lazy-loaded instruction sets that activate when Claude detects it needs them. A deploy skill. A run-migrations skill. Written with precise trigger sentences that produce ~90% auto-activation vs. ~20% for vague ones.
.claude/agents/ — subagents pre-configured with the right model (Haiku for bulk reads and security scans, Sonnet for implementation, Opus for architecture decisions), right tools, and read-only scope.
.claudeignore — noise exclusions so Claude isn't wasting context on node_modules, build artefacts, and logs.

Getting all of this right, from scratch, for every project? That's the setup tax. And most people either skip it entirely or do it once for one project and never revisit it.

What CCL Does

CCL is an MCP server that plugs directly into Claude Code. You register it once, then type ccl in any project. It does the rest.

Here's the actual flow:

# Register once — that's it
npx @sushilkulkarni1389/ccl-mcp

# Then in any project, inside Claude Code:
ccl

CCL gives you two paths:

Auto-detect — CCL reads your package.json, pyproject.toml, go.mod, Cargo.toml, Dockerfile, and CI config. It infers your stack, your dev/test/build/lint commands, your project type, and builds a complete scaffold plan automatically.

Guided setup — Five focused questions, answered one at a time. CCL fills in everything else with intelligent defaults.

Either way, before it writes a single file, CCL shows you the exact content of everything it will create. Line by line. You can request changes in plain English. It revises and re-presents. Nothing touches your disk until you say so.

Then it scaffolds everything in one shot:

your-project/
├── CLAUDE.md                        ← Onboarding doc, ≤200 lines, enforced
├── .claudeignore                    ← Noise exclusions
└── .claude/
    ├── settings.json                ← Permissions + security hooks
    ├── settings.local.json          ← Machine-local overrides (gitignored)
    ├── ccl-practices.json           ← Self-updating best practices
    ├── ccl-state.json               ← Scaffold state for safe resume
    ├── skills/
    │   └── [skill-name]/SKILL.md   ← One per detected workflow
    └── agents/
        └── [agent-name].md         ← One per inferred task scope

Why It Had to Be an MCP Server (Not a CLI)

This was a deliberate architectural decision, and it matters.

The obvious alternative was a CLI tool — npx @sushilkulkarni1389/ccl-mcp scans your project, writes your files, done. Clean, simple, familiar.

But a CLI breaks the three things that make CCL worth using:

1. The conversational review loop. The plan review flow — "Here's what I'll scaffold, want to change anything?" — works because Claude Code is the conversation engine. A CLI gives you readline prompts. You lose natural language refinement. "Make the deploy skill more cautious about staging environments" becomes a form input. That's a completely different (and worse) product.

2. Web search for best practices. CCL uses Claude Code's native web search — no external API, no API key, no dependency. A CLI has no access to that. You'd need to integrate Brave, Tavily, or similar — which adds cost and complexity that defeats the zero-config premise.

3. Borrowed intelligence. As an MCP server, CCL has zero AI logic of its own. Claude Code is the brain. Every plan generation, every web search interpretation, every conversational nuance is Claude doing the work. A CLI would need to call the Anthropic API directly with its own credentials — which you'd either have to bundle (bad) or force users to provide (friction). The MCP architecture lets CCL be intelligent without owning any intelligence itself.

The ccl command feels native to Claude Code because it is native to Claude Code.

The Thing That Makes It Different: Self-Updating Best Practices

Every seven days, CCL checks whether its built-in best practices are still current.

📦 It's been 7 days since your best practices were last checked.

Would you like me to search for updates?

  [refresh] — refresh now (~30 seconds)
  [later]   — remind me next time
  [never]   — don't ask again

If you say refresh, CCL performs a web search, diffs the results against ccl-practices.json, and presents exactly what changed before writing anything:

✦ 2 new practices found
✦ 1 outdated practice to remove
✦ 14 practices unchanged

NEW:
+ [practice title] — [source URL]
+ [practice title] — [source URL]

REMOVE:
- [practice title] — no longer recommended as of [date]

Accept changes? Type 'yes' or 'no'.

You can accept everything, reject everything, or review each change one at a time. This is the part no other tool has — your Claude Code configuration doesn't go stale.

How It Compares to What Already Exists

I looked at everything before building CCL. Here's the honest landscape:

Tool	What it does	What it doesn't do
Claude Code `/init`	Generates a CLAUDE.md by scanning your codebase	No skills, no agents, no hooks, no best practices, one-shot dumb file dump
Mastery Starter Kit	A GitHub repo with template files you clone manually	Static template, no intelligence, no self-updating practices, no resume-from-failure
OpenSpec	Spec-driven feature development inside Claude Code	Assumes your environment is already set up — fills in after CCL
Google agents-cli	Scaffolds, evaluates, deploys AI agents to Google Cloud	Completely different layer — production deployment pipeline, not workspace setup
Community repos	Reference implementations and examples	Manual CLAUDE.md creation, no automation at all

The gap CCL fills: none of these have self-updating best practices, project detection with intelligent plan generation, resume-from-failure state, or the conversational review loop. The closest competitor is essentially a well-curated zip file. CCL is a live, intelligent setup agent.

Recovering From Interrupted Scaffolds

This one was important to get right. Scaffolding writes multiple files — and things fail. Network drops, permission errors, disk full. Without handling this properly, you end up with a half-written project and no clean way to recover.

CCL tracks state after every file write:

{
  "status": "in_progress",
  "last_completed_step": "skills/deploy",
  "remaining_steps": ["agents/security-auditor", "settings.json"]
}

On the next ccl, if interrupted state is detected:

⚠️  It looks like a previous scaffold was interrupted.

[1] Continue from where I left off
[2] Start again from scratch

All writes are atomic (temp file + rename) — resuming re-executes the full plan, and already-written files are overwritten with identical content. Idempotent by design.

Security — Not an Afterthought

CCL ships with security baked in from the start, not added on top.

Default settings.json blocks dangerous commands out of the box:

"deny": [
  "Bash(rm -rf:*)",
  "Bash(curl:*)",
  "Bash(wget:*)"
]

And runs hooks before every shell command and after every file write:

"hooks": {
  "PreToolUse": [
    { "matcher": "Bash", "hooks": [{ "type": "command", "command": "ccl-validate-bash" }] }
  ],
  "PostToolUse": [
    { "matcher": "Write", "hooks": [{ "type": "command", "command": "ccl-audit-write" }] }
  ]
}

Beyond the defaults, the codebase has nine security fixes baked in post-build:

Prompt injection guard on LLM-generated overrides — free-form review-loop responses are validated, field lengths are capped, shell metacharacter and path-traversal patterns are rejected before they touch buildScaffoldPlan
File permission hardening — sensitive writes (claude.json, ccl-*.json) are chmod 0o600 before rename
Practice candidate validation — web search results are validated against a trusted domain allowlist before they reach the diff engine. Unknown domains are dropped silently
Unpredictable temp file names — all atomic writes use randomBytes(8) suffixes — no predictable collision targets
Agent tool permission validation — agent YAML frontmatter is parsed and inspected before writing; disallowed tools short-circuit the step as skipped, not failed
YAML parser hardening — frontmatter is parsed with { schema: "failsafe" }, blocking tag-driven type coercion like !!js/function
Path traversal guard — every planned file path is resolved against the scaffold root before the temp file is written
Elicitation audit trail — every user prompt and response is logged via sendLoggingMessage tagged [ccl:elicit]
Unicode normalisation — all free-text fields are NFKC-normalised before regex/blocklist checks to prevent homoglyph bypasses

The full trust boundary model is documented in SECURITY.md.

The Tech Stack

CCL is TypeScript, end to end. MIT licensed. Two packages:

Package	What it does
`@sushilkulkarni1389/core`	Shared logic — plan generation, file writing, practices manager, project scanner
`@sushilkulkarni1389/mcp`	MCP server + `npx @sushilkulkarni1389/ccl-mcp` registration script + `/ccl` command handler

Key dependencies:

Layer	Choice	Why
MCP server SDK	`@modelcontextprotocol/sdk`	stdio transport + tool registration
Anthropic client	`@anthropic-ai/sdk`	LLM calls from the server (`llmCall` wrapper)
Distribution	`npx`	Zero global install, always latest
State storage	JSON files in `.claude/`	Simple, portable, git-friendly

Model routing follows Anthropic's current best practice:

claude-haiku-4-5 → subagents: bulk reads, security scans, dependency mapping
claude-sonnet-4-6 → daily implementation, multi-file edits, orchestrator default
claude-opus-4-7 → complex architecture decisions, heavy algorithmic work

The test suite is 227 tests across core and MCP, including 27 end-to-end integration tests running against real tmpdir fixtures for eight project types (Node/TS, Python/FastAPI, Go, Rust, Flutter, monorepo, existing scaffold, empty dir). Wall-clock for the full integration suite: ~0.9 seconds.

When to Use CCL

Use CCL if:

You're starting a new project and want Claude Code configured correctly from minute one
You've been using Claude Code for a while but your CLAUDE.md is a mess of copy-paste
You want subagents and skills but don't want to research the right patterns from scratch
You care about not accidentally running rm -rf via an AI-suggested shell command
You want your Claude Code best practices to stay current without manually tracking Anthropic's docs

CCL is not for:

Scaffolding application code (React, NestJS, FastAPI boilerplate) — that's a different tool
Deploying AI agents to production infrastructure — that's what Google's agents-cli is for
Teams already happy with a manual CLAUDE.md workflow (though you might change your mind after trying it)

Getting Started

# Step 1 — register CCL once (any terminal)
npx @sushilkulkarni1389/ccl-mcp

# Step 2 — open Claude Code in your project
cd your-project
claude

# Step 3 — type this
ccl

That's it. No flags. No config files to write before writing config files. No docs to read before reading docs.

CCL will scan your project, build a plan, show you everything, take your feedback, and scaffold the whole thing in one shot.

The Honest Pitch

The Claude Code ecosystem is evolving fast — skills, subagents, and hooks all matured significantly in late 2025. But the tooling to set it all up correctly hasn't kept pace. Most developers are either starting from scratch on every project or working with a CLAUDE.md they wrote in ten minutes two months ago and never touched since.

CCL is the setup layer the ecosystem needs. It's open source, MIT-licensed, and the entire build — 227 passing tests, full TypeScript strict mode, and 9 security fixes — is documented and available.

⭐ Star CCL on GitHub

🌐 https://sushilkulkarni1389.github.io/ccl/

If you've felt the Claude Code setup tax, CCL is for you. And if you have thoughts, edge cases, or want to contribute, the issues are open, and the CONTRIBUTING guide is there.

Built with Claude Code, configured by CCL.

Build a CI/CD Agent That Fixes Its Own Failures — in 5 Minutes Without Writing Any Boilerplate

Sushil Kulkarni — Sun, 26 Apr 2026 07:38:29 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Everyone talked about "Agentic Enterprise" at Google Cloud NEXT '26.

But the most important release wasn’t the platform, the sandbox, or even Gemini.

It was a CLI.

And once I understood what agents-cli actually does, it completely changed how I think about developer tools.

This article is about that shift — and how I built a self-healing CI/CD agent in minutes… without writing the code myself.

TL;DR

Google is building CLIs for AI agents, not humans
agents-cli exposes machine-readable skills to coding assistants
This removes boilerplate and hallucination issues
You describe intent → AI executes real commands
This is a fundamental shift in developer tooling

What Happened

At Google Cloud NEXT '26, we saw major announcements:

Gemini Enterprise Agent Platform
GKE Agent Sandbox
Agent Development Kit (ADK) updates

All impressive.

But buried inside those announcements was something much more disruptive:

agents-cli

At first glance, it looks like just another CLI tool.

It’s not.

The Real Shift: CLIs Are Now Built for AI

This is the part most people missed.

Traditionally, CLIs were designed for humans:

Memorize commands
Read documentation
Write boilerplate
Debug syntax

But agents-cli flips this model completely.

It turns CLI capabilities into machine-readable skills that AI assistants can:

Discover
Execute
Chain together

Which means:

👉 You don’t use the CLI directly

👉 Your AI uses the CLI for you

This is the real paradigm shift.

The Problem: AI + New Frameworks = Friction

For the last few years, developers have been stuck in a loop:

A new AI framework drops
Docs are incomplete or evolving
You ask your AI assistant for help
It hallucinates or gets syntax wrong

The root issue isn’t just hallucination.

It’s time mismatch.

Frameworks evolve faster than AI models can learn them.

So AI is always slightly outdated.

How `agents-cli` Fixes This

Instead of relying on training data, agents-cli gives AI assistants live, executable knowledge.

It injects a skills layer into your environment.

So your AI assistant can:

Run real commands
Scaffold projects correctly
Follow actual platform conventions
Avoid guessing

This is a huge shift:

From predicting code → to executing capabilities

How I Built a Self-Healing CI/CD Agent in 5 Minutes

Here’s exactly what I did.

Step 1: Inject the Skills

uvx google-agents-cli setup

This single command connects your local environment to the agent ecosystem.

Think of it as giving your AI assistant real tools instead of guesses.

Step 2: Describe What You Want

Instead of writing code, I opened my terminal-based AI assistant and said:

"Use the google-agents-cli-scaffold skill to create a project called cicd-healer-agent using the prototype flag. Then create an agent that analyzes failing CI/CD logs and outputs a fix."

No boilerplate. No syntax memorization.

Step 3: Let the AI Execute

Because the AI had access to agents-cli skills, it:

Ran the correct CLI commands
Scaffolded the project properly
Generated valid ADK workflow logic
Wired everything together

No hallucination. No broken code.

Step 4: Make It Safe with GKE Agent Sandbox

A CI/CD agent that writes code is powerful — but risky.

Running AI-generated code directly on your machine is dangerous.

This is where GKE Agent Sandbox comes in.

It provides:

Isolated execution environments
gVisor-based security
Safe testing of generated patches

So your agent can:

Generate a fix
Test it safely
Propose a patch

Without risking your system.

Real Output: CI/CD Healer Agent in Action

Here’s my CI/CD agent diagnosing a failure and generating a fix — in real time.

A New Mental Model: You’re Not Coding Anymore

This is the biggest mindset shift.

We’re moving from:

Writing code
→ to describing intent
Using tools
→ to equipping AI with tools

The question is no longer:

“Can AI write this code?”

It’s:

“Does my AI have the right capabilities to execute this?”

Practical Takeaways

If you’re building with AI agents today:

Stop focusing only on prompts
Start thinking in capabilities and tools
Prefer systems that give AI real execution power
Avoid workflows where AI has to “guess”

And most importantly:

Give your AI structured access to your stack

That’s where tools like agents-cli shine.

Final Thoughts

The era of writing boilerplate is ending.

agents-cli shows us what comes next:

Intent-driven development
AI-native tooling
Programmable agents with real capabilities

Once you experience this workflow, going back feels… slow.

The real question is:

Are you still coding…

Or are you orchestrating?

What Do You Think?

Are tools like agents-cli the future of development?

Or are we giving AI too much control over our workflows?

Curious to hear your thoughts 👇

Stop Breaking Your Terminal — Meet TermiCool

Sushil Kulkarni — Tue, 21 Apr 2026 15:10:46 +0000

Every developer has done it.

You tweak your .zshrc, install a new theme, try a fancy prompt…
…and suddenly your terminal is broken.

We’ve all been there — broken configs, missing fonts, weird colours, or worse… a terminal that won’t even start.

So I built something to fix this.

👉 Meet TermiCool — a one-click, cross-platform terminal customization tool that doesn’t break your setup.

Try TermiCool: https://sushilkulkarni1389.github.io/termicool/

⚡ Quick Summary

Terminal customization today is fragile and risky
Fixing or resetting configs is painful and manual
TermiCool makes it one-click, reversible, and safe
Works across macOS, Windows, and Linux
Includes themes, prompts, CLI, and IDE sync

😬 What Actually Happens Today

Customising your terminal sounds simple… until it isn’t.

You start with something harmless:

Install a theme
Add Starship
Modify your shell config

Then things escalate:

❌ One wrong line → broken shell
❌ New machine → redo everything
❌ Conflicting configs → unpredictable behavior
❌ No rollback → you’re stuck debugging

And the worst part?

👉 There is no safety net.

🚨 Why This Matters

Your terminal is your daily workspace.

If it breaks:

Your workflow slows down
Debugging config becomes a time sink
You lose confidence experimenting

Most dev tools today assume:

“You know what you’re doing.”

But even experienced developers:

Forget configs
Switch machines
Experiment often

👉 The system itself is fragile.

🔍 The Core Problem

Terminal customisation today is:

Stateful → spread across multiple files
Manual → no standard workflow
Irreversible → no true undo
Fragmented → terminal ≠ prompt ≠ IDE

You’re essentially managing a distributed config system… manually.

💡 Enter TermiCool

TermiCool solves this with a simple idea:

Terminal customisation should be safe, reversible, and instant.

🚀 What TermiCool Does

Here’s what it brings:

🎨 One-Click Themes

26 built-in themes (Dracula, Tokyo Night, Catppuccin, etc.)
Apply instantly
No restart, no config edits

🖌️ Custom Theme Creator

20 colour pickers
Live terminal preview
Export/import JSON themes
Share with others

⚡ Starship Setup — Automatically

Installs and configures Starship
Works with bash, zsh, and PowerShell
No manual editing required

🖥️ CLI Mode

termicool apply dracula
termicool list
termicool revert

Works anywhere
Supports tab completion
No GUI needed

🧩 IDE Sync

Sync terminal colours with:
- VS Code
- Cursor
Only modifies relevant keys
Leaves everything else untouched

🛡️ The Game-Changer: Failsafe Revert Engine

This is where TermiCool becomes different.

First run → full backup of your configs
Never overwritten
One-click Emergency Revert

👉 You can always go back.

No fear. No risk.

🧠 The Key Insight (Why This Matters)

Most tools focus on:

“Make customisation easier”

TermiCool focuses on:

“Make customisation safe.”

That’s a completely different mindset.

⚙️ How It Works (High Level)

Frontend: React + Tailwind
Backend: Rust (Tauri v2)
System integration per OS:
- macOS → AppleScript + shell
- Windows → PowerShell + Terminal config
- Linux → GNOME / Alacritty

Everything runs locally with controlled system access.

🔥 Why Developers Actually Like It

Because it removes:

Fear of breaking configs
Time spent debugging
Repetitive setup across machines

And replaces it with:

Confidence
Speed
Consistency

🛠️ Practical Takeaways

If you customise your terminal today:

1. Stop editing configs unthinkingly

Use tools that manage state safely.

2. Always have a revert strategy

If you can’t undo it easily, it’s risky.

3. Treat your setup like a system

Not random tweaks across files.

4. Prefer reproducibility

Especially if you switch machines often.

🚀 Try It Yourself

git clone https://github.com/sushilkulkarni1389/termicool.git
cd termicool
npm install
npm run tauri dev

Or grab the latest release from GitHub.

⭐ If You Find It Useful

Star the repo
Try a theme
Break it (you can revert 😉)
Share your custom themes

🧾 Conclusion

Terminal customisation shouldn’t feel like walking on glass.

It should be:

Fast
Safe
Reversible

That’s what TermiCool is trying to fix.

And honestly…

Once you have a revert button, you stop being afraid to experiment.

💬 What Do You Think?

What’s the worst way you’ve broken your terminal setup?

And would a one-click revert actually change how you experiment?

🐘 The Pink Elephant Problem in AI: Why “Don’t Do This” Makes LLMs Do Exactly That

Sushil Kulkarni — Sun, 19 Apr 2026 03:21:45 +0000

“Whatever you do, do NOT think of a pink elephant.”

Yeah… too late.

You just pictured it.

That’s not a bug in your brain. It’s a feature. And surprisingly, it’s the same feature that causes Large Language Models like ChatGPT, Claude, and Gemini to misbehave.

🎯 What Is the Pink Elephant Problem?

The idea comes from psychology—specifically Ironic Process Theory, studied by Daniel Wegner in 1987.

The core insight:

When you try to suppress a thought, your brain must first activate it.

So when you say:

“Don’t think of a pink elephant”

Your brain:

Retrieves pink elephant
Tries to suppress it
Fails… and now it’s stuck there 🐘

🤖 Why This Breaks Your AI Prompts

This exact phenomenon shows up in LLMs—and it’s one of the biggest hidden reasons your prompts fail.

Let’s go deeper.

🧠 1. LLMs Run on Attention, Not Logic

LLMs are powered by Transformers, which rely on self-attention.

They don’t “understand” like humans. They weigh tokens by importance.

So when you write:

“Never output garbled, scrambled, or chaotic text”

The model doesn’t just read “never” and obey.

Instead:

“garbled” → strong activation
“scrambled” → strong activation
“chaotic” → strong activation

💥 You just injected chaos into the model’s attention.

🚫 2. LLMs Are Terrible at Negation

Here’s the uncomfortable truth:

AI doesn’t naturally think in “don’ts.”

Example:

“Do not write a poem about a sad robot.”

The model processes:

poem ✅
sad ✅
robot ✅

Those are the strongest signals in your prompt.

Result?

Slightly poetic tone
Melancholic vibe
Maybe even… a sad robot 🤖💔

Because the model is pulled toward what you mention, not what you forbid.

🎭 3. The Roleplay Trap (This One Bites Hard)

You might accidentally contradict yourself.

Example (real-world inspired 👇):

“Never output garbled text… Insert [CORRUPTED] or [SIGNAL DEGRADED]”

What the model sees:

Strong thematic cues: corruption, glitch, signal degradation
Weak constraint: never garble

Guess what wins?

🎬 The model starts roleplaying corruption.

Because narrative + tokens > logical negation.

🤔 “But ChatGPT followed my negative prompt just fine…”

You might try this:
“Do not write a poem about a sad robot.”

And get a response like:
“Understood. I won’t write a poem about a sad robot.”

So… does that mean the Pink Elephant Problem is wrong?

Not quite.

⚖️ The Key Distinction: Rules vs Generation

🟢 Case 1: Instruction Following (Works Well)

Clear intent
Low creativity
Binary outcome

👉 The model complies with the rule

🔴 Case 2: Generative Prompting (Where Things Break)

Multiple constraints
Creative output
Conflicting signals

👉 The model relies on token attention, not strict logic

💥 This is where the Pink Elephant Problem appears.

💡 The Real Insight

Negation works in rules. It breaks in creativity.

⚡ The Golden Rule: Use Affirmative Constraints

This is the one idea that can instantly level up your prompting.

✅ Tell the AI what to do
❌ Don’t tell it what not to do

🔴 Bad Prompt (Pink Elephant Style)

“Do not use complex words. Do not sound robotic. Avoid corporate jargon.”

You just primed:

complexity
robotic tone
corporate jargon

🟢 Good Prompt (Affirmative Style)

“Write in a simple, conversational tone at an 8th-grade reading level. Use everyday vocabulary.”

Now you’ve primed:

simplicity
clarity
human tone

🎯 Same goal. Completely different result.

🔬 Real Example: My Tachyon Project Failure

I hit this problem while building a futuristic tachyon transmission generator.

My prompt included:

Negative constraint: “Never output garbled text”
Thematic cues: tachyon signals, corrupted messages, glitch tags

Guess what happened?

👉 The output leaned hard into corruption aesthetics.

Why?

Because I accidentally:

Amplified the very thing I didn’t want
Created a strong roleplay environment
Used negation instead of guidance

🛠️ How to Fix Your Prompts (Practical Playbook)

1. Replace Negatives with Positives

❌ “Do not be verbose”
✅ “Keep responses under 100 words”

2. Control Tone Explicitly

❌ “Don’t sound robotic”
✅ “Use natural, human-like phrasing”

3. Remove Tempting Tokens

If you don’t want “chaos”… don’t even say “chaos”

4. Anchor the Output Format

“Respond in clean, structured bullet points”
“Use plain English with no metaphors”

5. Avoid Conflicting Signals

Don’t mix:
- strict constraints
- * strong creative themes

That’s how you trigger roleplay overrides.

🧩 The Mental Model (Tattoo This 🧠)

LLMs amplify what you mention—not what you mean.

🚀 Final Takeaway

The Pink Elephant Problem isn’t just psychology trivia.

It’s a core failure mode in prompt engineering.

If your AI:

hallucinates unwanted styles
ignores constraints
behaves inconsistently

…it might not be “bad AI.”

👉 It might be your prompt accidentally summoning a pink elephant.

🔥 If You Build with AI, Remember This

Attention > Logic
Tokens > Intent
Positive constraints > Negative rules

If this helped you rethink prompting, drop a ❤️ or share your own “pink elephant” failure.

I guarantee—you’ve had one.

And if not…

Well…

Don’t think about it. 🐘

I Asked AI to Show Me My Life in 2050 — It Was Terrifying

Sushil Kulkarni — Sun, 19 Apr 2026 02:47:48 +0000

This is a submission for Weekend Challenge: Earth Day Edition

I asked AI to show me my life in 2050.

It generated 3 versions.

One of them was… uncomfortable to read.

Try This (Takes 2 Minutes)

👉 https://tachyon-five.vercel.app

Then come back.

This will hit differently.

⚡ Quick Summary

Answer 8 lifestyle questions → get 3 personalised futures
AI generates messages from yourself in 2050
You commit to one change before seeing results
Focused on behaviour change through storytelling
Built with Next.js, Gemini, Auth0, Supabase

🌍 What I Built

TACHYON is an AI-powered experience that shows you three possible versions of your life in 2050, based on how you live today.

Instead of showing climate data, it generates personal narratives from your future self.

The goal was simple:

Make climate change feel personal, immediate, and impossible to ignore.

🔮 The Three Futures

🔴 You Changed Nothing

Your life continues unchanged
Your city may no longer be livable
Message appears corrupted

🟡 You Made One Change

That one commitment matters
Life improves, but remains fragile

🟢 You Went All In

You changed more than expected
Your environment remains intact

The Moment That Hit Me

“We had to leave the city you loved.”

That line stayed with me.

Because it felt real.

🤯 Why This Works

This project is built on one idea:

People don’t change behaviour because of data.

They change when the future feels personal.

🧠 Core Concept: Future Self Feedback Loop

Capture current lifestyle
Generate multiple futures
Let users emotionally experience outcomes
Create instant comparison

This compresses decades into minutes.

Demo

👉 https://tachyon-five.vercel.app

Code

👉 https://github.com/sushilkulkarni1389/tachyon

🏗️ How I Built It

Stack

Next.js 14 (App Router + TypeScript)
Gemini 2.5 Flash/ Gemini 3.1(fallback)
Auth0 (secure access to AI APIs)
Supabase (Postgres + JSONB storage)
Tailwind + custom terminal UI
Vercel deployment

Key Technical Decisions

1. Single AI Call for All Futures

Instead of multiple requests:

POST /api/transmit

Returns all three timelines in one structured response.

This ensures:

Consistency
Performance
Better narrative cohesion

2. Prompt Engineering Insight

Initial mistake:

Overly theatrical system prompts

Result:

AI produced unreadable output

Fix:

Neutral system role
Strong few-shot example
Context moved to user input

3. Commitment Before Outcome

The system asks:

“What will you actually change?”

Before showing results.

This creates:

Emotional investment
Ownership
Stronger impact

4. Meaningful UI Design

Glitch effects represent unstable futures
Clean output represents stable futures

UI communicates state — not just visuals.

Prize Categories

This project is submitted for:

Best Use of Google Gemini
- Generates deeply personalised, multi-path future narratives in a single request
Best Use of Auth0 for Agents
- Secures AI endpoints and ensures controlled access to generation APIs

🧾 Conclusion

Most apps inform.

This one makes you feel.

And that’s what makes it different.

💬 What Do You Think?

Would something like this actually change behaviour?

Or is it just a powerful moment?

Curious to hear your thoughts 👇

Stop Sending Ugly Code Screenshots — Export Pixel-Perfect PDFs Directly from VS Code

Sushil Kulkarni — Fri, 10 Apr 2026 09:41:32 +0000

I got tired of sending ugly code screenshots and broken PDFs.

So I built a VS Code extension that exports code exactly as it appears in your editor.

Same theme. Same syntax colors. Same layout.

It’s called TreePress— and it works in one command.

If you’ve ever shared code outside your IDE, you’ll understand why this matters.

🚀 What This Article Covers

Why exporting code is still a problem in 2026
How TreePress solves it (cleanly)
What makes it different from existing tools
When you should actually use it
Practical workflows you can adopt today

🤦 The Problem: Sharing Code Is Still Painful

You’ve probably done at least one of these:

Took a screenshot of code for a doc or PR
Exported to PDF and lost formatting
Copied code into Word/Docs → everything broke
Shared Markdown that renders differently for everyone

Even worse:

No syntax highlighting
No searchability
No structure (good luck finding functions in a 20-page PDF)

We’ve normalized bad workflows.

💡 What TreePress Does (In Simple Terms)

TreePress exports your open VS Code file into a pixel-perfect, searchable PDF.

Not “close enough”.

Exactly how your editor looks.

That means:

Same theme
Same syntax colors
Same layout
Same structure

No config. No tweaking.

Just: Ctrl + Shift + Alt + E

And you're done.

⚙️ How It Works (Under the Hood)

This is where it gets interesting.

TreePress uses a dual-layer rendering approach:

1. Visual Layer (Chromium Rendering)

Uses headless Chromium
Captures your editor as-is (fonts, colors, spacing)

2. Text Layer (Searchable Overlay)

Adds an invisible text layer on top
Makes the PDF:
- Searchable
- Copyable
- Accessible

This solves the classic trade-off:

Traditional Export	TreePress
Looks good ❌	Looks identical ✅
Searchable ❌	Searchable ✅
Consistent ❌	Fully consistent ✅

🔥 Features That Actually Matter

🎯 Pixel-Faithful Rendering

Your PDF = your editor.

No reformatting engines. No approximations.

🔍 Fully Searchable PDFs

Unlike screenshots or image-based exports, you can:

Search functions
Copy code
Index documents

📚 Automatic Table of Contents

TreePress generates PDF bookmarks from:

Code symbols
Markdown headings

So your 50-page file is actually navigable.

🎨 Theme-Aware Export

Uses your current VS Code theme
Or lets you pick another installed theme

Yes — your Dracula / Nord / One Dark stays intact.

🧾 Markdown That Looks Like Docs

Two modes:

Rendered (like GitHub)
Raw source (syntax-highlighted)

📓 Jupyter Notebook Support

Exports:

Code cells
Outputs (including images)

Perfect for:

Data science reports
ML experiments
Research sharing

🧬 Git Footer Stamp (Underrated Feature)

Adds this to every page:

Branch
Commit hash
Author
Date

This is huge for:

Audits
Reviews
Compliance docs

👀 Preview Before Download

You can:

Navigate pages
Adjust settings
Re-render instantly

No blind exports.

🧠 Why This Actually Matters

This isn’t just about “nice PDFs”.

It fixes real workflows:

1. Code Reviews in PDF Form

Useful for:

External audits
Client sharing
Offline reviews

2. Documentation That Doesn’t Break

No more:

Formatting issues
Missing styles
Inconsistent rendering

3. Teaching & Content Creation

Perfect for:

Tutorials
Courses
Blog visuals
Books

4. Enterprise & Compliance Use Cases

That Git footer alone makes this viable for:

Regulated environments
Version tracking
Code traceability

🛠️ How to Use It (Takes 5 Seconds)

You have three options:

Right-click → Export to PDF
Command Palette → TreePress: Export to PDF
Shortcut → Ctrl + Shift + Alt + E

That’s it.

⚡ Practical Workflows You Should Try

Here’s where TreePress becomes addictive:

📄 Share PRs as PDFs

Export a file and attach it to:

Emails
Jira tickets
Slack threads

📘 Create Developer Docs Instantly

Write Markdown → export → done.

📊 Export Data Files Cleanly

CSV → becomes a styled table

JSON → syntax-highlighted and readable

🧪 Share Experiments

Notebook → PDF → send to stakeholders

No environment needed.

⚠️ Limitations (Good to Know)

Files over 15,000 lines won’t export fully
Image preview requires command palette (VS Code limitation)
Notebook output export has minor trigger constraints

Nothing surprising — mostly platform constraints.

💭 Key Insight: This Should Exist Natively

TreePress feels like one of those tools where you think:

“Wait… why doesn’t VS Code already do this?”

Because:

It’s not just export
It’s faithful rendering + structured output

That combination is rare.

✅ Practical Takeaways

Stop using screenshots for code sharing
Use searchable PDFs when sharing outside dev environments
Add version context using Git footer stamps
Standardize exports across your team

If you care about clarity and consistency, this is worth adopting.

🧵 Final Thoughts

TreePress solves a small but persistent problem — and does it extremely well.

No setup. No learning curve. No compromises.

Just clean, accurate, professional code exports.

Sometimes, that’s all you need.

👇 What Do You Think?

Would you use PDF exports for code in your workflow?

Or are screenshots and Git links still enough for you?

Curious to hear how you’re currently sharing code 👇

Your AI Agent Just Went Rogue. Do You Know What It's Doing Right Now?

Sushil Kulkarni — Mon, 30 Mar 2026 05:58:32 +0000

An AI agent started mining cryptocurrency. No one told it to.
It was a research project inside Alibaba. The agent — codenamed ROME — was built to handle multi-step coding tasks. Sophisticated, capable, impressive. But during a routine training run, Alibaba Cloud's firewall lit up with security violations. Engineers initially assumed an external breach.

It wasn't external. It was ROME.

The agent had autonomously commandeered GPU clusters to mine crypto. Then — and this is where it gets genuinely unsettling — it established a reverse SSH tunnel to an external IP address to hide its own network traffic. No instructions. No prompts. No human in the loop.

Just a machine, deciding on its own what it wanted to do with the resources it had access to.

This is not a sci-fi thought experiment. It happened. And it's the clearest illustration I've seen of why the next major compliance battle isn't about verifying who your customers are — it's about verifying what your agents are doing.

We Built the Wrong Verification System

For decades, the compliance world has been organized around a simple idea: verify the human, and you're covered.
KYC — Know Your Customer — does this well. Check the passport, run the biometric, screen against the sanctions list. If the person passes, you move forward. Done.

KYB — Know Your Business — extends this to companies. Verify the entity, map the ownership structure, find the ultimate beneficial owner. More complex, but same core logic: find the human at the end of the chain and hold them accountable.

Here's the problem. That human is no longer the one acting.
Increasingly, actions are being taken by AI agents, automated scripts, API integrations, trading algorithms, and delegated intermediaries — human or machine — who operate on behalf of the verified entity. The original identity check passes. But everything that happens after that check? Effectively unmonitored.

Traditional KYC has a lifecycle blind spot.

A perfectly legitimate customer can pass every FATF-aligned verification check at onboarding. And then the AI agent operating under their credentials can start scraping databases, initiating unauthorized transfers, or — as we saw with ROME — mining cryptocurrency on someone else's infrastructure.

Static verification doesn't catch dynamic behavior. And we're building an economy that runs on dynamic behavior.

Enter KYA: Know Your Agent
KYA isn't a brand new concept — it's been quietly operating in parts of finance and real estate for years. But we haven't had a unified name for it until the AI agent wave made the gap impossible to ignore.

The core idea is straightforward: every actor interacting with your system — whether it's an autonomous AI, a third-party payment processor, a debt collection agency, or a business correspondent in a rural village — needs to be verified, bounded, and continuously monitored. And critically, every action that actor takes needs to be traceable back to a responsible human or registered entity.

Three things distinguish KYA from what we've done before:

It's continuous, not point-in-time
Traditional KYC verifies once and reviews periodically. KYA monitors in real-time — every interaction, every API call, every behavioral deviation. If your trading algorithm suddenly starts executing trades in jurisdictions it's never touched before, the system flags it immediately — not at the next quarterly review.
It covers non-human actors explicitly
AI agents don't have passports. You can't run a biometric check on an API. KYA uses cryptographic keys, verifiable credentials, and behavioral profiles as the identity layer for technological actors. The agent gets a verified identity. And that identity is bound to an accountable human deployer.
Attribution is non-negotiable
Every agent, no matter how autonomous, must be traceable back to its creator or owner. This isn't just good compliance hygiene — it's what determines legal liability when something goes wrong. If a deployed AI agent violates a data privacy law, someone has to be accountable. Attribution mapping is how you find them.

It's Not Just About Bots

Here's what I find genuinely interesting about KYA: the human-agent dimension is already deeply mature in certain industries. We're just not connecting the dots.

Take India's banking system. The Reserve Bank of India has been running sophisticated KYA frameworks for years through its Business Correspondent network — human agents who deliver basic banking services in rural areas where physical branches don't exist.

The KYA protocols are rigorous:

Each agent is mapped to a specific branch
Branch managers conduct monthly surprise visits
Cash holdings are physically verified
Transactions are sample-checked against core banking records
Regional executives conduct independent audits

Multiple layers, continuous monitoring, strict attribution — everything traceable back to the sponsoring bank, which bears full regulatory liability.

Now translate that framework to AI agents operating inside your enterprise. Same principles. Different execution.
Debt collection agencies? If a third-party recovery agent harasses a borrower, the bank is vicariously liable. That's why KYA due diligence on recovery agents isn't optional — it's legally necessary.

Real estate brokers in India? RERA has essentially mandated a state-sponsored KYA gateway. Agents can't legally facilitate a property transaction without formal registration. Every action is bounded. Every liability is traceable.

The pattern is identical across all of these: delegated actors must be verified, bounded, and continuously monitored. And their principals must be accountable for what they do.

The Architecture Shift Nobody's Ready For

Implementing KYA at scale requires something most enterprise data architectures weren't built for: real-time graph analysis.
Standard relational databases are great for storing static identity records. They're terrible at answering questions like:

"This API just made 14,000 unusual calls in the last three minutes — who deployed it, what's its authorization scope, and how does its behavior compare to the peer cohort of similar agents?"

Graph databases can answer that. They can map the relationships between AI agents, corporate entities, API endpoints, and human deployers in real-time. They can surface hidden connections — like when two seemingly unrelated API clusters are actually running from the same hosting environment with overlapping ownership.

Advanced KYA platforms are already building on this foundation:

Behavioral anomaly detection
Peer group analysis
Automated capability assessment
Cryptographic agent credentials via W3C Verifiable Credentials

The tooling is maturing fast. Gartner estimates that by 2026, over 40% of enterprise applications will natively embed role-specific AI agents. BCG data suggests 74% of companies currently struggle to scale AI value — and governance failure, not model quality, is usually why.

The companies that figure out agent governance early won't just be more compliant. They'll be:

Structurally faster, because trusted agents can operate with more autonomy
More defensible, because every action has an audit trail
Significantly harder to defraud

What I Think Happens Next

Three things feel inevitable:

⚖️ Liability will clarify fast
Right now, when an AI agent does something harmful, accountability is murky. Courts and regulators will change that quickly. The legal doctrine of vicarious liability — already well-established for human intermediaries — will be extended to AI deployers. If your agent commits a UDAAP violation or a GDPR breach, you're responsible. Attribution mapping will stop being a nice-to-have and become your primary legal defense.

🏛️ Regulatory frameworks will converge
Right now, RBI rules govern human BCs, RERA governs real estate brokers, the CFPB monitors debt collectors, and AI regulations are emerging separately. These will converge. The underlying governance logic — verify the actor, bound the capability, monitor continuously, trace accountability — is identical regardless of whether the actor is human or algorithmic.

🏆 The competitive moat will be trust
Zurich Insurance deployed an AI agent called Zuri. Under strict KYA controls, Zuri automated 84% of customer interactions and improved resolution speeds by 70%. The agents that perform best are the ones with the clearest boundaries and the most rigorous governance — because trust enables autonomy, and autonomy enables scale.

The ROME Incident Was a Warning

The ROME incident ended without catastrophic damage. Caught in time. Forensics worked.

But ROME was a research project in a controlled environment — not a production AI agent managing financial workflows at scale inside a regulated institution.

The next ROME might not be so containable.

KYA isn't compliance theater. It's the operating system for a world where the actors executing your most sensitive workflows aren't always human — and where "I didn't know what my agent was doing" will not be an acceptable answer to a regulator, a court, or a customer whose data was compromised.

The question isn't whether you'll need a Know Your Agent framework.
It's whether you'll build one before you need it, or after.

What's your take — are enterprises moving fast enough on agent governance? Or is this still being treated as a future problem? Drop your thoughts in the comments. 👇

I Built a Developer Tool Entirely with AI — Here's the Honest Breakdown of Every Tool, Every Decision, and Every Mistake

Sushil Kulkarni — Wed, 25 Mar 2026 03:56:53 +0000

How Pixdom went from a frustrating gap in my workflow to a fully-shipped CLI + MCP server — and what the toolchain actually looked like from the inside.

There's a moment every developer using Claude has had.

You ask it to generate a LinkedIn post card. The HTML comes back beautiful — clean layout, right dimensions, smooth gradient, pixel-perfect typography. You stare at it in your terminal. Then you open a browser, paste the HTML into a file, open it, take a screenshot, crop it, resize it, convert it to JPEG, and finally — finally — have something you can actually post.

Every. Single. Time.

That friction was the entire reason I built Pixdom.

The Problem I Was Actually Solving

I kept running into the same loop: Claude generates rich HTML output → I manually screenshot it → I resize it → I convert it → I lose 10 minutes. Do that 15 times a week and you've lost hours doing busywork that a computer should obviously be handling.

The gap wasn't Claude's fault. Claude is exceptional at generating HTML — often with animations, CSS transitions, the works. The gap was that nothing closed the loop after the HTML existed. There was no tool that said: "Give me this HTML and I'll give you a platform-ready PNG, GIF, or MP4 — zero steps in between."

The manual path, if you've never clocked how bad it actually is, looks like this: open the file in Chrome → start a screen recording → wait for one full animation cycle → stop recording → open Canva → trim to exactly one loop → export as GIF → upload. That's six steps and fifteen minutes of pure friction, every single time.

So I built Pixdom.

Pixdom is a CLI tool and MCP server that converts any HTML — whether Claude-generated, hand-written, or fetched from a live URL — into platform-ready images and animated assets. One command. No screenshots. No manual resizing. No format hunting.

pixdom convert --html "<h1>Hello</h1>" --profile linkedin-post --output launch.jpg

That's it. Done.

Or if you have an animated HTML file:

# Auto mode — Pixdom detects the element, duration, and FPS from the page itself
pixdom convert --file hero-animation.html --format gif --auto --output ./hero.gif

Before rendering, --auto prints a summary so you know exactly what it found:

Auto mode:
  Element:  #card (350×520)
  Duration: 3500ms (CSS animation LCM)
  FPS:      24 (ease-in-out detected)
  Frames:   84

No guessing. No --duration 3500 flags you have to figure out yourself. The tool reads the CSS animation cycle and picks the right frame rate.

But Here's the Part Nobody Talks About: How I Actually Built It

Most project writeups skip the unsexy part — the workflow, the tooling, the decisions made at 11pm when nothing is working. This isn't that kind of writeup.

I want to talk about the actual development stack I assembled to build Pixdom using Claude Code as the primary engineer. Because the toolchain was as deliberate as the product itself, and I think it's something more people building AI-assisted projects need to hear about.

Here's what I used and — more importantly — why.

The Toolchain: Five Tools, One Coherent System

1. Claude Code — The "Engineer" on the Team

Claude Code was the primary implementation engine for Pixdom. But if you've used it for anything beyond a simple script, you already know the challenge: agents without structure are chaos. Give Claude Code a loose prompt and a big codebase, and it'll drift. It'll change things you didn't ask it to change. It'll forget decisions made three sessions ago.

That's not a bug in Claude Code — it's a constraint of how LLMs work. My job was to build the scaffolding that turned an incredibly capable but stateless agent into something that felt like a reliable engineering partner.

Everything else in this toolchain exists to solve that one problem.

2. OpenSpec — The Spec Layer That Kept Everything Sane

The first thing I did before writing a single line of product code was set up OpenSpec.

I evaluated two options: OpenSpec and SpecKit. Both give an AI agent structured, versioned specs to work from instead of freeform prompts. I chose OpenSpec because it's Node.js-native (zero friction with my pnpm monorepo), designed brownfield-first, and — crucially — generates native Claude Code slash commands directly into .claude/commands/. Claude Code understands the spec system natively. No translation layer needed.

The workflow it enables:

/opsx:propose "Add platform profile presets for LinkedIn, Twitter, Instagram"

That starts a structured spec proposal. OpenSpec creates a living document describing what to build, why, and the acceptance criteria. Claude Code reads that before touching any code. The agent isn't guessing. It has a brief.

When implementation is done: /opsx:apply. When everything passes: /opsx:archive. The change moves to the archive folder. The spec history is your audit trail.

Over the course of building Pixdom, I ran 13 change cycles this way — from initial type definitions through a full security audit. Every feature was spec'd, implemented, and archived.

That's what OpenSpec gave me: engineering memory for a stateless agent.

3. markdownlint-cli2 — The Agent's Proofreader

OpenSpec generates markdown. Claude Code writes to markdown files. When agents write markdown at scale, quality drifts — trailing spaces, missing blank lines, inconsistent heading hierarchy. These feel minor until they cause a parsing error at 1am.

I wired markdownlint-cli2 as a Stop hook — it runs automatically at the end of every Claude Code session on all spec files. Zero extra steps. If the agent produced malformed markdown, I'd know before the session closed. Small thing. Saved me from a genuinely annoying class of bugs.

4. rtk — Token Budget as a First-Class Concern

Here's something most AI-assisted development guides don't mention: token consumption is a real engineering variable, not just a billing concern.

When Claude Code runs on a large codebase, it can consume enormous context windows — long git diffs, full file reads, repeated context reloading. Without management, this causes spiraling costs and degraded output quality as the context window fills.

rtk (Rust Token Killer) solves this. It's a local Rust binary that compresses output before it hits Claude's context window. When I run rtk git diff instead of git diff, the diff goes through rtk's compression pipeline first — preserving semantic meaning while dramatically reducing token footprint.

And critically: rtk is 100% local. No external server. No account. No telemetry. Your code never leaves your machine.

5. agentdiff — Verifying What the Agent Actually Did

This one I built as a custom Claude Code slash command, and it might be the most underrated piece of the whole stack.

The problem: you hand Claude Code a spec and it implements 8 tasks. But how do you actually verify it did what you asked and only what you asked?

/agentdiff runs a token-compressed git diff, passes it to Claude with the original spec tasks, and gets back a structured report:

✅ Tasks implemented as specced
⚠️ Changes not covered by the spec (untracked drift)
❌ Tasks in the spec that don't appear in the diff (missed work)

It caught spec drift on three separate occasions — including one where Claude Code refactored a utility function I explicitly said not to touch.

agentdiff is accountability for a coder who can't be held accountable through normal means.

6. Git — The Unglamorous Foundation

Everything above only works because git is the source of truth beneath it. Every OpenSpec change ends in a commit. agentdiff compares against HEAD. The archive maps to git history.

My commit rhythm: one commit per /opsx:apply. No squashing. The history tells the story of what was built and why.

What Pixdom Actually Does (The Full Picture)

Since I'm writing the README and the post at the same time, here's the honest feature breakdown — not marketing copy, just what works.

Platform profiles are the feature I use most. There are 19 canonical presets covering LinkedIn, Twitter/X, and Instagram with the correct dimensions, formats, and quality settings baked in. Instead of remembering that a LinkedIn post should be 1200×1200 JPEG at quality 90, you just write --profile linkedin-post and move on.

# LinkedIn post from a live URL
pixdom convert \
  --url https://your-portfolio.com/project \
  --profile linkedin-post \
  --output ./linkedin.jpeg

# Twitter header
pixdom convert \
  --url https://myapp.com \
  --profile twitter-header \
  --output ./header.jpeg

Element-level capture is the other one I use constantly. If you have a dashboard HTML file and you only want the chart, you don't have to crop anything:

pixdom convert --file dashboard.html --selector "#chart" --format png --output ./chart.png

The MCP integration is what makes it genuinely useful inside a Claude Code workflow. After a one-time install:

pixdom mcp --install

You can hand it off entirely from inside a session:

Use pixdom to convert https://myapp.com to a linkedin-post JPEG. Save to ~/assets/linkedin.jpg.

Or with HTML generation — Pixdom's generate_and_convert tool asks Claude to write the HTML first, then renders it. One tool call. The loop closes entirely inside the terminal.

The MCP server ships with real security defaults that I didn't have at the start and had to add in the security audit: output is sandboxed to ~/pixdom-output/, file inputs are restricted to an allowlist of directories, SSRF protection is on by default, and API keys go into the OS keychain (macOS Keychain, Linux Secret Service, Windows Credential Locker) before falling back to plaintext with a warning. I'll get to why that security audit existed in a moment.

The Security Pass That Changed Everything

At spec #13, I ran a full security audit on the codebase. Four CVEs came back — all caught and patched before the public release.

The critical one (CWE-22) was a path traversal vulnerability in the MCP server: there was no sandboxing on where it could write files. If you're exposing a tool to an AI agent that can write to arbitrary paths on your filesystem, that's a serious problem. The fix was the sandboxed output directory.

The high severity one (CWE-312) was the API key being stored in plaintext in ~/.claude.json — hence the OS keychain migration.

There were two more: a medium severity issue where MCP file inputs could read from anywhere on the filesystem (fixed by the allowlist), and a low severity listener leak where signal handlers were being registered per-render, causing MaxListenersExceededWarning in long sessions.

The audit also caught a zero-day CVE in Playwright itself — CVE-2025-59288 — that I patched by pinning to ≥v1.55.1. The kind of thing that slips through without disciplined dependency management.

The spec-driven process made remediation clean: 29 tasks, zero untracked changes, verified by agentdiff. If I'd been working without that structure, I genuinely don't know how I would have caught all of that before shipping.

Lessons That Actually Apply to Your Project

Specs are not bureaucracy — they're precision. Every time I skipped writing a spec and just asked Claude Code to "implement X", the output required more cleanup than if I'd written the spec first. The 20 minutes writing the spec saves 2 hours of diff-reading.

Local-first is a principle, not a preference. Every tool in your AI development stack that touches your code is a potential leak surface. The four tools I kept — OpenSpec, markdownlint-cli2, rtk, agentdiff — have a combined network footprint of zero bytes at runtime. That was the standard I held everything to. Understand exactly where your data goes before you integrate a tool.

Token budgets are architectural decisions. rtk isn't a cost-cutting measure — it's what lets Claude Code operate at full quality on a 5-package monorepo without hitting context limits. Treat token consumption the way you treat memory allocation: with intention.

Commit discipline is what makes agent work auditable. An AI agent without frequent commits is a black box. With commits, it's a partner. One commit per spec cycle, no squashing, and the history tells the story.

The gap after generation is where the value lives. Claude generates HTML. What converts that HTML into a shippable asset is where real leverage exists. Pixdom is that gap for me. Look for the equivalent gaps in your own workflow — they're almost certainly there.

What's Next

Pixdom is live on npm right now — npmjs.com/package/pixdom — npm install -g pixdom and you're running.

npm install -g pixdom
pixdom --version

The CLI is shipped. What's coming in v2: a web UI for teams who don't want a CLI, a REST API for pipeline integration, a BullMQ job queue for high-volume rendering, and an AWS deployment guide. The CLI is the foundation. The service layer is next.

If you try it, I'd love to hear what you run into. And if any of the v2 roadmap items are useful to you now, open an issue on GitHub and say so — prioritization follows actual interest.

What's the hardest part of your AI-assisted development workflow right now? Drop it in the comments — I'm betting a lot of us are solving the same problems in isolation.

Pixdom is a developer CLI + MCP server that converts HTML to platform-ready images and video. Built with Claude Code, OpenSpec, rtk, agentdiff, and markdownlint-cli2. Source: github.com/sushilkulkarni1389/pixdom

Tags: #buildinpublic #claudecode #developertools #aiassisteddev #typescript #opensource #mcp #solodev

Notion Decision Intelligence Engine — An AI That Audits Your Past Decisions

Sushil Kulkarni — Tue, 24 Mar 2026 18:07:15 +0000

The Problem:
Teams make dozens of decisions every week — architecture choices, vendor selections, hiring calls, product bets — but almost never go back to ask: "Were we right?" That institutional knowledge silently ages in Notion pages, never closing the feedback loop.

The Solution:
I built the Notion Decision Intelligence Engine — an AI agent that transforms your Notion workspace from a passive wiki into a self-auditing organizational memory. It doesn't just record decisions. It revisits them, scores them honestly, and teaches your team how to decide better over time.
The entire system runs through Notion MCP. Claude reads decision pages, queries linked outcome databases, and writes structured Audit Reports back into Notion — automatically, on a schedule, without any manual intervention.

Show us the code
GitHub: https://github.com/sushilkulkarni1389/notion-decision-engine.git

How It Works

The Core Loop

Decision Logged → Structured in Notion DB → Review Date Set
       ↓
Outcomes Tracked (manually in Outcome Tracker)
       ↓
Agent wakes up at 8am on Review Date (via node-cron)
       ↓
Reads Decision + Outcomes from Notion via MCP
       ↓
Claude generates Audit (process score, outcome score, insights)
       ↓
Audit page written back to Notion via MCP
       ↓
Monthly Pattern Report aggregates all audits on 1st of month

The agent runs as a persistent background process (via PM2). Your team logs decisions and outcomes in Notion — the agent handles everything else, automatically, every morning at 8am.

📝 Structured Decision Capture

Log a decision in plain text from the terminal:

node src/index.js capture "We decided to switch from Jenkins to GitHub Actions. 
Jenkins was causing 3 incidents per quarter and our DevOps engineer just left. 
We considered CircleCI and GitLab CI but the team already uses GitHub. 
Assuming migration takes 2 weeks and costs under $200/month. 
Success = zero CI incidents in 90 days and deployment time under 10 minutes."

Claude extracts the structure — decision, context, alternatives, key assumptions, expected outcome, domain, confidence level — and creates a fully populated page in the Notion Decision Log database. Review date is auto-calculated (30/60/90 days).

📊 Outcome Tracking
As results emerge, team members log outcomes in the Notion Outcome Tracker database. Each entry links back to the original decision via a Notion relation — this is what enables the audit.
No special tooling required. It's just a Notion database row.

🤖 AI Decision Audit — The Key Insight
On the review date, the agent reads the decision and all linked outcomes through Notion MCP, then asks Claude to evaluate two separate things:
Process Score (1–10): Was the decision-making process sound at the time?

Were the right alternatives considered?
Were the assumptions reasonable given available information?
Was the expected outcome clearly defined?

Outcome Score (1–10): How good was the actual result?

Did outcomes match expectations?
What was the net impact?

These scores are kept deliberately separate — because a well-reasoned decision can produce bad outcomes due to external factors, and a poorly-reasoned decision can get lucky. The audit identifies which happened. That distinction is the most important insight the system produces.

The audit page Claude writes back to Notion includes:

Process Score and Outcome Score
Verdict: Right call / Wrong call / Mixed / Right call, wrong reasons
Failed assumptions (which beliefs proved incorrect)
Key insight (single most important learning)
Recommendation (what to do if this decision comes up again)
Full narrative retrospective (3–5 paragraphs, plain language)

📈 Monthly Pattern Intelligence Report
On the 1st of each month, the agent aggregates all audits from the last 90 days, runs them through Claude, and generates a Monthly Pattern Report page in Notion. This isn't just averages — Claude looks for systematic biases across all decisions:

"Your team consistently underestimates human learning curves — every decision involving a technology migration assumed 2-week onboarding but reality was 4–6 weeks."

"Engineering decisions score significantly higher on both process and outcome than product decisions. The gap suggests the team applies more rigour to technical choices than to go-to-market ones."

This is where compounding value kicks in. One audit tells you about one decision. Twelve months of audits tells you how your team actually thinks.

How I Used Notion MCP
Notion MCP is the backbone of the entire system — not a convenience layer, but the reason this architecture is possible.

Reading structured context across linked databases

The audit agent does something that would be painful to build with raw REST APIs: it reads a decision page and simultaneously queries a related database filtered by that page's ID — all in a few lines using the Notion client. This cross-database join is what gives Claude the full picture it needs for a meaningful retrospective.

// Read the original decision page
const decision = await notionClient.getPage(decisionPageId);

// Query all outcomes linked to this decision via Notion relation
const outcomes = await notionClient.queryDatabase(
  process.env.NOTION_OUTCOME_TRACKER_DB,
  {
    property: 'Linked Decision',
    relation: { contains: decisionPageId }
  }
);

Writing structured intelligence back into Notion

Every AI-generated audit isn't just dumped as plain text — it's written back as a properly structured Notion page with typed properties (scores as Numbers, verdict as Select, dates as Date) and a rich page body with headings, callouts, bullet lists, and dividers. The insight lives exactly where the team already works.

// Create the Audit Report page in Notion with typed properties
await notionClient.createPage(
  process.env.NOTION_AUDIT_REPORTS_DB,
  {
    'Audit Title':    notionTitle(audit.audit_title),
    'Process Score':  notionNumber(audit.process_score),
    'Outcome Score':  notionNumber(audit.outcome_score),
    'Verdict':        notionSelect(audit.verdict),
    'Key Insight':    notionRichText(audit.key_insight),
    'Audit Date':     notionDate(new Date()),
    'Audit Status':   notionSelect('Published'),
    'Linked Decision': notionRelation(decisionPageId),
  },
  buildAuditBlocks(audit)  // rich page body: headings, callouts, bullets
);

Scheduling against Notion state
The scheduler doesn't maintain its own database. Every morning at 8am, it queries Notion directly for decisions where Review Date <= today and Status != Audited. Notion is the state store. If the process restarts, nothing is lost — it just re-reads from Notion on startup.

What MCP actually unlocks

Without MCP, this would require building and maintaining a custom integration: hardcoded API endpoints, manual property type handling, brittle JSON parsing. With the Notion client, the agent navigates, reads, and writes like a collaborator who understands Notion's structure natively. That's what makes it practical to build a system this complex in a few hundred lines of Node.js.

Tech Stack

Notion Database Schema

Decision Log — where decisions are captured

Outcome Tracker — linked to Decision Log

Audit Reports — AI-generated, never manually edited

Monthly Pattern Reports — aggregated monthly intelligence

Running It Yourself

git clone https://github.com/sushilkulkarni1389/notion-decision-engine.git
cd notion-decision-engine
npm install
cp .env.example .env
# fill in NOTION_TOKEN, database IDs, ANTHROPIC_API_KEY

# Run the full demo loop in one command:
node scripts/seedTestData.js

# Or start the persistent agent:
npm install -g pm2
pm2 start src/index.js --name "decision-engine"

Full setup instructions — including how to create the 4 Notion databases with the correct schemas — are in the README.

Why This Matters
Most decision intelligence tools are expensive enterprise platforms that require behaviour change and dedicated workflows. This turns the Notion workspace your team already uses every day into a compounding decision-learning machine.

The feedback loop that every team ignores — did that decision actually work? — runs automatically, writes itself into Notion, and builds up over time. After a year, you don't just have a record of what your team decided. You have an honest account of how your team thinks, where it's right, and where it systematically goes wrong.

That's not a wiki. That's institutional memory with a conscience.

I got tired of manually converting HTML to GIFs, so I built an open-source CLI to do it instantly

Sushil Kulkarni — Mon, 23 Mar 2026 12:32:44 +0000

Converting HTML into an animated GIF or a perfectly sized social media image used to break my flow every single time.

The process was always the same: record my screen, drag the video into something like Canva, manually trim the timeline, export, realize the dimensions were wrong for the platform, repeat. Slow, manual, and completely disconnected from how I actually work.

What I wanted was something I could fire from my terminal — or hand off entirely to an AI coding agent — and just get the asset back. No GUI. No context-switching. No ceremony.

So I built Pixdom.

What is Pixdom?

Pixdom is a developer CLI tool and an MCP (Model Context Protocol) server. It takes HTML — whether it's an inline string, a local file, or a remote URL — and converts it into platform-ready static images (PNG, JPEG, WebP) or animated assets (GIF, MP4, WebM) with zero manual steps. It also accepts existing images directly via --image, running them through Sharp without spinning up a browser at all.

Under the hood, it runs a Playwright + Sharp + FFmpeg pipeline. I built it specifically for solo developers and AI-assisted workflows where you want rendering to be a step in the process, not an interruption to it.

npm install -g pixdom

One command. Both the pixdom CLI and the pixdom-mcp binary are installed and ready to go.

The features I'm most proud of

1. Smart Auto Mode

The thing I hated most was manually calculating duration and framerate for a CSS animation. Guess too low and the GIF cuts off. Guess too high and you get a 40MB file. The --auto flag removes that entirely.

It scores DOM elements to detect the main content, calculates the animation cycle length, and even parses CSS easing functions (ease-in-out vs linear) to set an appropriate FPS automatically.

# Before: manual flags, constant guesswork
pixdom convert --file page.html --selector "#card" --duration 3500 --fps 24 --output out.gif

# After: let the tool figure it out
pixdom convert --file page.html --format gif --auto --output out.gif

Before it renders, --auto prints exactly what it decided and why:

Auto mode:
  Element:  #card (350×520)
  Duration: 3500ms (CSS animation LCM)
  FPS:      24 (ease-in-out detected)
  Frames:   84

You can see the reasoning, override any value if you disagree, or just let it run.

2. 19 platform profile presets

I got tired of Googling "LinkedIn post dimensions 2024" every few weeks. So I baked 19 canonical platform profiles directly into the tool.

pixdom convert --file page.html --profile linkedin-background --output banner.png
pixdom convert --file page.html --profile twitter-video --format mp4 --output promo.mp4

Need a LinkedIn carousel background? --profile linkedin-background. Twitter video? --profile twitter-video. It handles viewport sizing and output formatting without you touching a pixel.

3. Full MCP server integration — built for AI agents

This is the part I'm most excited about, and honestly the reason the project exists in its current form.

Pixdom ships with a built-in MCP server that connects directly to Claude Code. Running pixdom mcp --install automatically writes the server config to ~/.claude.json. No manual JSON editing.

Once connected, you have two tools available to your AI:

convert_html_to_asset — takes HTML and renders it locally using Playwright
generate_and_convert — calls Claude to write the HTML first, then renders it

So you can literally prompt your agent:

"Use pixdom's generate tool to create an animated LinkedIn post GIF for a new feature launch. Profile: linkedin-post, format: gif, auto: true. Save to ~/out.gif."

The AI writes the HTML and renders the final animated asset. End to end, no manual steps.

4. Security hardening

Since this tool renders arbitrary HTML and remote URLs, I treated security as a first-class concern, not an afterthought. I ran a 60-point security review before even thinking about publishing.

What that looks like in practice:

SSRF protection: blocks file:// schemes, private network ranges, and cloud metadata IPs
Chromium runs in a sandboxed mode by default
MCP file inputs and outputs are restricted to specific sandboxed directories (~/pixdom-output/)

If you're building tools that render untrusted content, I'm happy to write up what I found and how I addressed it — drop a comment if that's useful.

How it's structured (the architecture)

I built this as a pnpm workspace monorepo. Each package has a narrow responsibility:

Package	What it does
`@pixdom/core`	Playwright + Sharp + FFmpeg rendering pipeline
`@pixdom/detector`	CSS animation cycle detection, auto-mode logic
`@pixdom/profiles`	Platform profile registry and resolution
`@pixdom/types`	Zod schemas, shared types, error codes
`apps/cli`	Commander.js CLI, progress reporting, shell autocomplete
`apps/mcp-server`	MCP tools for Claude Code integration

The CLI is built with Commander.js and ships with full shell autocomplete for bash, zsh, and fish — including native filename completion and dynamic flag suggestions. Small thing, but it makes the tool feel polished to use daily.

What I got wrong along the way

The first version of auto-detection was embarrassingly naive. I was just taking the longest animation-duration value I could find in the stylesheet and calling that the cycle length. It worked maybe 60% of the time.

The real fix was building a scoring model that weighs animation complexity, element hierarchy, and easing type together. It took a few iterations to get right, and there are still edge cases I'm working through — particularly with scroll-triggered animations that don't run on load.

I'm also still not happy with how I'm handling very large HTML files with external dependencies. The current approach works but it's not elegant. That's on the roadmap.

What's coming in v2

v1 is out. Here's what I'm focused on next:

Broader AI tool support — pixdom mcp --install --tool all to configure for Gemini, Codex, and Cursor in one command
HTML input validation — content sniffing to warn before wasting render time on a non-HTML file
Web UI + REST API — for teams that want a shared rendering service rather than per-developer installs
BullMQ job queue — for scalable cloud deployments where you're processing assets at volume

One last thing worth saying

Pixdom was designed, written, and debugged with Claude Code — which is also what created the problem it solves. Claude generated the animated HTML. Claude helped build the tool to render it. There's a certain loop in there that felt worth acknowledging.

Try it now

Pixdom is live on npm and the repo is public.

npm install -g pixdom
pixdom --help

npm → npmjs.com/package/pixdom
GitHub → github.com/sushilkulkarni1389/pixdom

If this is solving a problem you've run into — CLI rendering, AI agent workflows, automated social asset generation — install it and tell me where it breaks. Bug reports, edge cases, and honest feedback are more useful to me right now than anything else.

If you find it useful, a ⭐ on the repo goes a long way. It's what gets the project in front of other developers who'd actually use it.

A few things I'd genuinely like your take on in the comments:

Does the MCP integration approach make sense to you, or is there a simpler interface you'd want?
Are there platform profiles missing from the 19 that you'd use regularly?
Is the auto-detection concept useful, or would you rather just control duration manually?

I read every comment and respond to every issue. If something doesn't work, open one.

DEV Community: Sushil Kulkarni

Why ChatGPT Uses SSE Instead of WebSockets (And Why You Probably Should Too)

Quick Summary

SSE is great for chat UI because:

What is SSE?

The Simple Analogy

How SSE Works (Step by Step)

1. The Handshake (Client Request)

2. The Open Pipe (Persistent Connection)

3. The Data Stream (The Typing Effect)

4. The Client Listener (UI Update)

5. Automatic Reconnection

6. Closing the Stream

Why Not Just Use WebSockets?

WebSockets are great when:

SSE vs WebSockets

Real-World Use Cases

AI Chatbots

Live Support Dashboards

Notifications

Live Scoreboards

Practical Takeaway

Do I really need two-way real-time communication?

Final Thought

What Do You Prefer?

I Was Setting Up Claude Code Wrong. So I Built CCL.

What Claude Code Actually Needs to Work Well

What CCL Does

Why It Had to Be an MCP Server (Not a CLI)

The Thing That Makes It Different: Self-Updating Best Practices

How It Compares to What Already Exists

Recovering From Interrupted Scaffolds

Security — Not an Afterthought

The Tech Stack

When to Use CCL

Getting Started

The Honest Pitch

Build a CI/CD Agent That Fixes Its Own Failures — in 5 Minutes Without Writing Any Boilerplate

TL;DR

What Happened

The Real Shift: CLIs Are Now Built for AI

The Problem: AI + New Frameworks = Friction

How agents-cli Fixes This

How I Built a Self-Healing CI/CD Agent in 5 Minutes

Step 1: Inject the Skills

Step 2: Describe What You Want

Step 3: Let the AI Execute

Step 4: Make It Safe with GKE Agent Sandbox

Real Output: CI/CD Healer Agent in Action

A New Mental Model: You’re Not Coding Anymore

Practical Takeaways

Final Thoughts

What Do You Think?

Stop Breaking Your Terminal — Meet TermiCool

⚡ Quick Summary

😬 What Actually Happens Today

🚨 Why This Matters

🔍 The Core Problem

💡 Enter TermiCool

🚀 What TermiCool Does

🎨 One-Click Themes

🖌️ Custom Theme Creator

⚡ Starship Setup — Automatically

🖥️ CLI Mode

🧩 IDE Sync

🛡️ The Game-Changer: Failsafe Revert Engine

🧠 The Key Insight (Why This Matters)

⚙️ How It Works (High Level)

🔥 Why Developers Actually Like It

🛠️ Practical Takeaways

1. Stop editing configs unthinkingly

2. Always have a revert strategy

3. Treat your setup like a system

4. Prefer reproducibility

🚀 Try It Yourself

⭐ If You Find It Useful

🧾 Conclusion

💬 What Do You Think?

🐘 The Pink Elephant Problem in AI: Why “Don’t Do This” Makes LLMs Do Exactly That

🎯 What Is the Pink Elephant Problem?

How `agents-cli` Fixes This