DEV Community: devjiro

I analyzed 40 OpenClaw use cases — 92.5% don't need OpenClaw

devjiro — Sat, 14 Mar 2026 15:02:38 +0000

Why I Built This

I was looking at the awesome-openclaw-usecases repo — 40 real-world use cases for OpenClaw. It looked like a goldmine of automation ideas.

But then I noticed something: almost none of them actually need OpenClaw. The "skills" are just API wrappers. The "memory system" is just file storage. The "sub-agents" are just parallel tasks. Every capability they depend on exists in any capable AI agent.

What I Found

Classification	Count	%
Agent-agnostic (works anywhere)	20	50%
Partial (swap one tool)	17	42.5%
OpenClaw-dependent	3	7.5%

Only 3 out of 40 use cases genuinely require OpenClaw. The rest? They work with Claude Code, Codex, Cursor, or any agent with shell access + LLM reasoning.

The Context Efficiency Problem

So I extracted the 37 agent-agnostic use cases. But dumping 37 guides into one skill file would burn ~30,000 tokens every invocation. That's wasteful.

Instead, I used an Index Skill Pattern:

SKILL.md is just a table of contents (~1,200 tokens)
Each use case lives in its own file under usecases/
Only the selected file gets loaded on demand (~800 tokens)
93% context savings vs monolithic

not-need-claw/
├── SKILL.md          # Index skill (~1,200 tokens)
└── usecases/         # 37 use cases (loaded on-demand)
    ├── second-brain.md
    ├── self-healing-home-server.md
    └── ... (35 more)

Try It

npx skills add devjiro76/not-need-claw

GitHub: devjiro76/not-need-claw

What's Next

Looking for community contributions — if you have agent-agnostic use cases that work across platforms, PRs welcome.

not-need-claw is open source. I'd love to hear your feedback!

I Built a Retro FPS That Turns Your Git Repo Into a Shooting Game

devjiro — Wed, 11 Mar 2026 16:09:35 +0000

What if your git history was a first-person shooter?

SHOT MY GIT turns any GitHub repo into a retro FPS game. Bug-fix commits become bosses. Your code commits become bullets. Shoot your way through 10 waves of bugs.

Try It Now

https://devjiro76.github.io/shot-my-git/

Paste any public GitHub repo URL and hit FIGHT.

How It Works

Enter a GitHub repo URL (e.g. facebook/react)
The app fetches commits via GitHub REST API
Bug-fix commits (fix, hotfix, patch...) spawn as bosses
Your feature/refactor commits become bullets
Shoot through 10 waves of increasingly tough bugs

Bosses Have Tiers

Tier	Trigger	Behavior
MINI	1-2 files changed	Straight line
NORMAL	3-5 files	Zigzag pattern
ELITE	6+ files or 100+ line changes	Circle strafing
MEGA	Merge commits, 10+ files	Charge attack + escorts

Bullets Show Real Code

Every bullet you fire displays actual content from your commits:

Function/class names extracted from diffs
Commit messages and SHAs
Insertion/deletion stats
Color-coded by commit type (feature=cyan, refactor=yellow, test=blue)

The Stack

Three.js with low-res render target for pixel art aesthetic
Canvas2D -> CanvasTexture for text sprite rendering
Vite + TypeScript for the build
GitHub REST API (no backend, fully static)
Deployed on GitHub Pages

Git Events as Environmental Effects

The game world reacts to your repo's git history:

Merge - Two text sprites collide and explode
Branch - Y-shaped fork appears in the sky
Tag - Golden version number drops from above
Matrix rain - Actual diff code rains in the background

For Private Repos


bash
npm run extract -- /path/to/your/repo
# generates git-data.json, drag & drop it into the game

Links

- Live: https://devjiro76.github.io/shot-my-git/
- Source: https://github.com/devjiro76/shot-my-git

---
This was a weekend experiment to make git history more visceral. Every developer has fought bugs — now you can literally shoot them.

Try it with your own repo and let me know your kill count.

I Built a Pixel Art Village Where AI Characters Have Real Emotions

devjiro — Thu, 05 Mar 2026 19:02:16 +0000

Last weekend I fell into a rabbit hole: what if game characters didn't just have scripted reactions, but actually felt things?

Not "if health < 20 then scared" kind of feelings. Something more like: a brooding introvert who slowly warms up to someone who keeps being kind, but snaps hard when betrayed. A resilient gym coach who barely flinches at insults. A shy librarian who experiences the deepest joy from simple affection.

So I built Persona World -- a pixel art village where 12 AI characters live, wander, interact, and develop real emotional states.

What It Looks Like

Each character walks around the village, and when they meet, they autonomously decide what to do -- based on their personality. You can see their current emotion floating above their head.

Click on any character to inspect their inner world: their VAD (Valence-Arousal-Dominance) emotional state, personality traits, and how they feel about every other character.

How Emotions Work

Each character has a HEXACO personality profile -- six dimensions that shape how they respond to everything:

Openness -- creative vs. conventional
Conscientiousness -- disciplined vs. spontaneous
Extraversion -- outgoing vs. reserved
Agreeableness -- cooperative vs. competitive
Neuroticism -- sensitive vs. calm
Honesty-Humility -- sincere vs. pragmatic

When an interaction happens (praise, tease, betray, etc.), an emotion engine computes the character's response using a 9-dimensional cognitive appraisal model. The result isn't a simple label -- it's a continuous emotional state in VAD space that shifts based on personality, current mood, and history.

For example, "Nyx" -- an introverted, sensitive poet (N=0.85, E=0.15) -- reacts to betrayal with the most intense emotional response in the entire village. Meanwhile "Rex" -- a resilient extraverted coach (E=0.95, N=0.25) -- barely registers the same event.

The Interesting Part

What surprised me was watching the emergent dynamics:

Personality shapes everything. The same action produces wildly different results depending on who receives it. "Affection" makes Nyx feel genuine joy (she rarely gets positive attention) but barely moves Miko (who's already emotionally stable).

Relationships accumulate. Characters track how others have treated them. Over time, a character who receives mostly positive actions from someone will start preferring positive actions back. Negative spirals happen too.

Mood is slow, emotion is fast. A single insult doesn't ruin a character's day. But sustained negativity gradually shifts their baseline mood, which colors all future reactions.

Tech Stack

Frontend: React 19 + Canvas 2D + TypeScript
Emotion Engine: molroo SDK -- handles personality modeling, cognitive appraisal, and VAD emotion computation
Rendering: Pixel art sprites on HTML Canvas
Hosting: Cloudflare Pages

The emotion engine does the heavy lifting. Each interact() call sends an action with a 9-dimensional appraisal vector, and returns the character's new emotional state -- including discrete emotion labels, VAD values, mood shifts, and even somatic responses (physical sensations like "chest tightness" or "warm glow").

Try It / Build Your Own

Live demo: persona-world.pages.dev

Source code: github.com/devjiro76/persona-world

The whole thing is open source. You can swap out the 12 characters with your own (just edit src/data/personas.ts), change their personalities, or add new interaction types.

To run it yourself, you just need an API key:

git clone https://github.com/devjiro76/persona-world.git
cd persona-world
npm install
cp .env.example .env  # add your API key
npm run dev

The app auto-creates a world and seeds all 12 characters on first run.

I'm curious -- has anyone else experimented with continuous emotion models in games or simulations? Most AI character systems I've seen use discrete states or simple sentiment. The VAD approach feels more natural but I'm still finding edge cases (surprise is nearly impossible to trigger, and "challenge" produces numbness instead of determination).

Would love to hear thoughts or ideas.

I Built a Literary Analysis Dashboard with AI — Here's What I Learned

devjiro — Mon, 02 Mar 2026 10:18:09 +0000

What if you could upload a novel and get a full editorial-grade analysis — character maps, engagement curves, structural weaknesses — in minutes?

I built Story Miner to do exactly that. It's a web app that combines deterministic text analysis with LLM-powered narrative intelligence to give writers and editors deep insight into their stories.

Here's a walkthrough of what it does and how it's built.

The Verdict — Strengths & Weaknesses at a Glance

The first thing you see is a high-level report: what works, what doesn't, and actionable takeaways for the author.

This is generated by feeding episode-level summaries through an LLM pipeline that identifies narrative patterns, then synthesizes them into a structured report.

Engagement Map — Where Readers Stay (and Where They Leave)

This tab maps narrative structure (Setup → Development → Crisis → Climax → Resolution) alongside an engagement timeline that tracks sentiment, dialogue ratio, and pacing across every episode.

The engagement scores use a hybrid approach: deterministic metrics (sentence length variance, dialogue density, vocabulary richness) combined with LLM-assessed emotional intensity. This gives a much more reliable signal than either approach alone.

Character Craft — Relationship Graphs & Emotion Analysis

Every character gets profiled: role classification (protagonist/supporting/antagonist), emotion distribution, co-appearance frequency, and an interactive relationship graph.

The relationship graph uses force-directed layout to show character clustering — you can immediately see which characters form tight groups and which are isolated.

4-Language Support — Instant Switching

The entire analysis can be viewed in Korean, English, Japanese, and Chinese. Switch languages from the header and all analysis content re-renders in the selected language.

This isn't just UI translation — the LLM analysis results are stored per-language, so the narrative insights themselves are generated natively in each language.

Tech Stack

Layer	Tech
Frontend	Next.js 16, Tailwind CSS, shadcn/ui, Recharts
Backend	FastAPI, SQLite
AI	Claude (narrative analysis), deterministic NLP pipeline
Hosting	Cloudflare Workers (web), Railway (API)
Build	OpenNext for Cloudflare, Turbopack

The Hybrid Analysis Pipeline

The key architectural decision was splitting analysis into two phases:

Deterministic phase — keyword extraction (TF-IDF), character counting, co-occurrence matrices, topic modeling, sentiment scoring, style profiling. Fast, reproducible, and cheap.
LLM phase — episode-by-episode narrative analysis, overall structure detection, character relationship inference, and the final editorial report. Expensive but insightful.

The deterministic data feeds into the LLM prompts as context, grounding the AI analysis in measurable textual features. This prevents hallucination about pacing ("the middle section drags") when the engagement metrics actually show it's fine.

Per-Language Result Storage

Analysis results are stored with language-qualified keys (report:en, report:ja, etc.) in SQLite. The API tries the requested language first, then falls back to the default. This means you can analyze once and view in multiple languages without re-running the pipeline.

Try It

novelcat.io — The demo includes a pre-analyzed sample (The Godfather screenplay) with all 4 languages ready. No signup required.

The whole project is still in early stages (v0.1.0), but I'd love feedback on the analysis quality and what features would be most useful for writers.

Built with Claude Code in a weekend sprint. The AI wrote most of the code, I steered the product decisions.

We Pushed Claude to Generate as Much Documentation as Possible — And It Backfired

devjiro — Sun, 22 Feb 2026 11:27:44 +0000

When we first started integrating Claude into our development workflow, the idea seemed brilliant: let the LLM handle all the documentation. Write a function? Generate docs. Refactor a module? Generate docs. Rename a variable? Generate docs.

We pushed hard. We prompted aggressively. And Claude delivered — more than we ever expected.

The Documentation Avalanche

Within a few months, our repository had accumulated an astonishing volume of documentation files. README files for every directory. Inline comments for every function. Architecture decision records. API references. Onboarding guides. Glossaries. Runbooks. Postmortems for incidents that had long since been forgotten.

At first, it felt productive. It looked like a mature, well-maintained codebase.

But something was wrong.

No human could actually read all of it. And — this is the part that stings — neither could the LLM. When we asked Claude to help with a refactor, the context window filled up just loading the documentation layer. The docs had become noise, crowding out the actual signal: the source code.

The Source Moved On. The Docs Didn't.

The real problem wasn't the volume. It was the drift.

Our codebase kept evolving — new features, architectural pivots, dependency upgrades, renamed services. But the documentation? It stayed frozen at whatever moment Claude had generated it. There was no automated mechanism to detect that a doc was now stale. There was no diff that told us "this README no longer matches the module it describes."

So we ended up with a documentation graveyard — hundreds of files that were technically present but practically misleading. Worse than no documentation at all, because they created false confidence.

The Refactoring Trap

The consequences showed up most painfully during refactoring cycles.

When a developer opened a module they hadn't touched in six months, they'd find three or four documentation files associated with it: one from the original implementation, one from a partial refactor, one that seemed like a summary of the other two. Each file had slightly different descriptions of how the system worked. Each contradicted the others in subtle ways.

Which one was current? No one knew.

So developers did what developers do under uncertainty: they ignored all of them and went straight to the code. The documentation was not just useless at this point — it was actively slowing people down by creating doubt and requiring manual cross-referencing.

And then the same bugs came back. The same architectural mistakes. Because the lessons learned from the last refactor were buried in an outdated doc that nobody trusted anymore.

What We Should Have Done

We treated documentation like output, not like a living artifact.

The mistake wasn't using Claude to write docs. Claude is genuinely excellent at drafting clear, structured documentation from code context. The mistake was treating every generated doc as "done" — then moving on without any strategy for keeping it synchronized with the source.

Documentation needs ownership. It needs a lifecycle. If you can't commit to updating a doc when the code changes, you'd be better off with a short, manually-written doc that's actually accurate, than ten AI-generated docs that are confidently wrong.

A few principles we've adopted since then:

One source of truth per module. One doc file, linked directly in the code, with a clear owner.
Docs are part of the PR. If you change behavior, you update the doc. No exceptions.
Regularly audit and delete. An outdated doc should be treated like dead code — remove it.
Use Claude to draft, not to decide scope. The LLM can write the words, but humans should decide what needs to be documented and at what granularity.

The Real Lesson

LLMs are remarkably good at generating documentation. That's precisely the danger.

The ease of generation creates an illusion of completeness. You can produce a thousand words of polished, coherent documentation in seconds. It feels like you've done the work. But documentation that isn't maintained is a liability, not an asset.

We confused volume with value. And for a while, our codebase paid the price — in confusion, in duplicated effort, and in bugs that kept resurfacing because no one could find the lesson that had already been learned and written down, buried somewhere in a file that no one trusted anymore.

DEV Community: devjiro

I analyzed 40 OpenClaw use cases — 92.5% don't need OpenClaw

Why I Built This

What I Found

The Context Efficiency Problem

Categories

Try It

What's Next

I Built a Retro FPS That Turns Your Git Repo Into a Shooting Game

Try It Now

How It Works

Bosses Have Tiers

Bullets Show Real Code

The Stack

Git Events as Environmental Effects

For Private Repos

I Built a Pixel Art Village Where AI Characters Have Real Emotions

What It Looks Like

How Emotions Work

The Interesting Part

Tech Stack

Try It / Build Your Own

I Built a Literary Analysis Dashboard with AI — Here's What I Learned

The Verdict — Strengths & Weaknesses at a Glance

Engagement Map — Where Readers Stay (and Where They Leave)

Character Craft — Relationship Graphs & Emotion Analysis

4-Language Support — Instant Switching

Tech Stack

The Hybrid Analysis Pipeline

Per-Language Result Storage

Try It

We Pushed Claude to Generate as Much Documentation as Possible — And It Backfired

The Documentation Avalanche

The Source Moved On. The Docs Didn't.

The Refactoring Trap

What We Should Have Done

The Real Lesson