DEV Community: Joe C

Who Is an AI Agent Actually For? A User-Type Field Guide

Joe C — Mon, 15 Jun 2026 18:17:33 +0000

"AI agent" is one of those terms that has earned the right to mean almost anything. Ask a grandmother using a voice assistant, a QA engineer writing test harnesses, and a software architect designing orchestration layers, you'll get three definitions that barely overlap. That's not a problem with the term. That's a feature of how the technology actually lands in the world.

Your relationship to an AI agent is shaped entirely by what you need it to do. And what you need it to do is shaped by where you sit. But what's interesting isn't just that these definitions differ it's how they differ. The gap between a non-technical user and a software architect isn't just vocabulary. It's a completely different mental model of what an agent is, what it owes you, and what goes wrong when it doesn't deliver. That gap has consequences: products get built for the wrong user, expectations get set in the boardroom that engineering can't meet, and users get handed tools they were never taught to distrust.

So let's walk the ladder, not purely by technical knowledge, but by proximity to the system itself: from the person who just wants the thing to work, all the way up to the person who has to decide whether to build it in the first place.

The Everyday User (Non-Technical)

For the non-technical everyday user, an AI agent is whatever the product told them it was. Maybe it's a chatbot on a website. Maybe it's the thing their nephew set up on their phone that "helps with emails." They don't think about models, tools, or memory. They think about whether it did the thing they asked, and whether they have to ask twice.

What this user actually wants is boring, in the best possible way: they want the thing to work the first time. Not "work if you phrase it right." Not "work after you read the docs." Work like a light switch. They have a task, they describe it in plain language, and the agent handles it. The entire surface area of their relationship with the technology is that moment of contact and what comes back.

Ask them what worries them about AI and you'll hear some version of: "I don't want it to do something I didn't ask it to do." Not model drift. Not agentic loops. Just: don't go rogue on me. That instinct is remarkably well-calibrated. It's the same concern sophisticated users have they've just learned the technical vocabulary for it.

The non-technical user's relationship with AI agents is built on trust extended without understanding. The next rung up is someone who has just enough understanding to extend that trust in stranger directions.

The Everyday User (Technical)

This person has a ChatGPT account and a custom system prompt they're quietly proud of. They've tinkered with Zapier automations, maybe wired up a Make.com workflow that posts to Slack when their RSS feed updates. They know what a token is. They've watched at least one YouTube video about prompt engineering and applied roughly half of it. They are, in short, dangerous in a specific way: capable enough to build something that almost works, not experienced enough to know what "almost" is hiding.

The things that bite this user aren't the things they worried about. They worried about the agent giving wrong answers. What actually gets them is the agent giving confidently structured wrong answers formatted beautifully, cited convincingly, wrong in ways that take a week to notice. Or the automation that ran perfectly for two months and then silently stopped because an API changed. They built the happy path. They forgot there were other paths.

Now move one rung up to someone who doesn't build anything, but who just decided the whole company is going to use agents starting Q3.

The CEO / Sales Person

This user doesn't think about how agents work. They think about what agents unlock: headcount reduction, faster cycle times, a story to tell investors. That's not cynicism; that's their job. The problem is that "what it unlocks" is only true if "how it works" is solved first. And they're usually not in the room when that part happens.

Their relationship with the agent ends at the handshake. Everyone downstream inherits what they promised. The engineering team gets a spec built from a demo. The QA team gets a product with no failure budget because the timeline was set before anyone knew what needed testing. The IT team gets a deployment requirement with no documentation. The promises compound as they travel down the ladder, and the people closest to the actual system are the last to find out what was sold.

Quality Assurance

Somewhere between the CEO's promises and the developer's implementation sits the person whose job is to ask: but what actually happens? Not in the demo. Not in the happy path. In the real conditions, with real users, with inputs nobody anticipated. QA is the organizational immune system. When agents are involved, that immune system is being asked to catch a new class of pathogen with the same old antibodies.

What QA wants from an AI agent is the same thing they've always wanted: reproducibility and a clear definition of "correct." They want to write a test case, run it, get a result, and know whether the thing passed or failed. Agents make all three of those things harder. The output isn't always reproducible. "Correct" is often subjective. And failure modes can be subtle enough that the test passes while the behavior is quietly wrong.

QA often knows the most about what the agent actually does in practice, they've run it against more cases than anyone. And they're frequently the least consulted when decisions get made about what it should do. The gap between what QA observes and what leadership hears about is one of the more consistent patterns in AI deployments that go wrong.

Basic IT Personnel

IT didn't design the agent. IT didn't choose the model. IT didn't set the expectations. IT got a ticket that says "deploy this" and another ticket three weeks later that says "it's down, fix it." Their relationship with AI agents is almost entirely inherited they're responsible for something they had no hand in building, running on infrastructure they may not control, with failure modes nobody bothered to document.

What IT needs is documentation that doesn't exist, runbooks that were never written, and a clear answer to the question: when this breaks, what do I restart? With traditional software, that question usually has a tractable answer. With an AI agent, the answer might be "nothing the model just had a bad day" or "the upstream API rate-limited us" or "a prompt injection in user input sent the whole thing sideways." IT can handle outages. They're less equipped to handle stochastic degradation.

The Database Administrator

The DBA's first question about any AI agent is the same question they ask about everything: where's the data? With agents, that question turns out to be surprisingly hard to answer. There's the relational database they already manage. There might be a vector store they've never heard of before. There's probably a context window holding things that won't survive a restart. And somewhere upstream, a model was trained on data that nobody in the organization can fully account for.

What gets handed to the DBA, sometimes explicitly, often by default, is a set of problems the traditional DBA role was never designed for. Who owns the embeddings when the source document changes? How stale is the retrieval index, and does anyone know? If the agent cited a policy that was updated last quarter, is that a data bug or a model bug? These aren't database questions exactly. But they live in the data layer, so they land on the DBA's desk. The DBA is frequently the person who discovers that the agent's "knowledge" and the organization's actual state have quietly diverged and the last person who gets credit for catching it.

The DBA can manage the data that feeds an agent. What they usually can't do is change how the agent uses it. That's the full-stack developer's territory the person who wired the whole thing together and is now the single point of contact for every problem nobody else can solve.

The Full-Stack Developer

The full-stack developer working on agents has had to become something they weren't trained to be: part engineer, part prompt author, part evaluator, part data curator. The skills that make someone good at building deterministic systems rigor, precision, clear specifications are necessary but not sufficient here. They also need tolerance for ambiguity, comfort with probabilistic reasoning, and the discipline to test things that can't be unit tested. It's a different kind of engineering, and most people doing it figured it out by breaking things.

The things that are hardest about this job aren't the things that were hard before. Writing the code is fine. Wiring up the API call is fine. The hard part is debugging a system that has no stack trace for the interesting failures. Traditional debugging has a loop: reproduce the bug, isolate the cause, fix the code, verify the fix. Agents break every step. The bug may not reproduce. The cause may be in a model weight nobody can inspect. The "fix" might be a prompt change that helps in one case and hurts in three others. And verification means running the system against enough cases to feel confident which is not the same as being confident. The full-stack developer working on agents is making architectural decisions every day because those decisions have to get made, and nobody else is positioned to make them.

The Software Architect

The software architect looks at an AI agent and sees a system with boundaries, contracts, failure modes, and dependencies. Where the CEO sees a capability and the developer sees a codebase, the architect sees a graph: which components talk to which, what guarantees they make to each other, where the blast radius is if something fails. That systems-thinking lens is exactly what's needed here. It's also frequently absent until after the first major production incident.

The architect's decisions ripple through every other user on this list. A good agent scope decision means IT has something they can actually restart. A good observability decision means QA has something they can actually test. A good trust boundary decision means the non-technical user doesn't accidentally authorize something they didn't understand. The architect rarely meets most of the people their decisions affect. That's the job.

Walk back down the ladder for a moment. The grandmother who doesn't want it to go rogue. The tinkerer who built the happy path. The CEO who made a promise. The QA engineer who can't write a deterministic test. The IT person who can't restart a bad day. The DBA who can't find the data. The developer who became an evaluator. The architect who has to make decisions that stick. They are all users of the same technology. They all need something from it. Almost none of them are talking to each other about what that is what the agent is supposed to do, what counts as correct, who owns what when it fails. That gap, not the technology, is the problem worth solving.

I Watched a Streamer Suffer Through Tournament Admin and Spent A Month Fixing It

Joe C — Sat, 13 Jun 2026 20:51:53 +0000

I was watching Studyy - one of my favorite Call of Duty players - run a community tournament on his Twitch stream. And somewhere between watching him alt-tab to update a Challonge bracket, then switch to his Google Form to check signups, then jump back to Discord to announce draft picks, then back to Challonge because he forgot to update something - a very specific thought crossed my mind:

I am a software developer. I could fix this. Why has no one fixed this?

The second question answered itself pretty quickly. The first one haunted me for the next few weeks.

Here's the thing - this wasn't starting from zero. I'd already helped build the system Studyy was using. Google Forms for signups. Challonge for the bracket. A workflow that worked, as long as "worked" meant one person manually copying data between two tabs like a very determined secretary.

Then the tournament evolved. Wheel spins. Degen format additions. Randomized chaos that the community loved and the admin pipeline absolutely did not. What had been a two-tab shuffle became a six-alarm coordination problem for a single person running it live on stream.

Challonge exists. Google Forms exists. Between them, you can run a tournament. What neither of them does is talk to each other, run a draft, spin a wheel, or remember that you already updated that bracket entry three minutes ago. The glue holding it together was a human being, and that human being was clearly suffering.

So I did what any reasonable developer does when they identify a solvable problem: I opened a new project folder, picked a tech stack, and dramatically underestimated how long this would take.

The requirements sounded simple in the way that all requirements sound simple before you build them. One dashboard. Signups flow in from Google Forms. Admin runs a draft - snake, random, or manual, depending on how chaotic the community is feeling. Finalized teams push to Challonge. Bracket fills itself. Nobody copies a player name by hand ever again. One button to start the tournament and trigger updates across every connected service.

Write it down like that and it looks like an afternoon project. Reader, it was not an afternoon project.

The first wall was Challonge. Their v1 API is versioned in a way that suggests it was designed by someone who had heard of REST but had strong opinions about it. Getting OAuth working meant building a local callback server, catching the token mid-redirect, encrypting it with Electron's safeStorage API, and storing it on disk in a way that Windows would protect with DPAPI. For a bracket app. For a CoD streamer. I was in it now.

Google was its own adventure. OAuth2 with a desktop app means no browser redirect to localhost that Google trusts by default, a service account you have to provision, and a Forms API that is powerful, documented, and somehow still confusing at 11pm. Both integrations eventually worked. Neither of them worked the first time, or the second time, or - honestly - the time after that.

Then the snake draft board populated for the first time. Twenty-four players. Teams assigned. Pick order locked. A timer ticking down in the corner. Admin can search players, drag picks, reset the timer, and when it's done - one push sends the whole thing to Challonge.

That was the moment. That was when it stopped being a project and started being a tool.

Here's what running a tournament with The Colosseum actually looks like:

Admin opens the app. Setup tab: tournament name, game, date, signup deadline, team size, draft style. Hit save - the Google Form updates automatically with those details. Link goes out to the community. Signups come in. Deadline hits.

Draft tab populates with every player who signed up. Pick your draft mode - snake if you want structure, random if the community is chaotic, manual if you want full control. Timer starts. Admin picks a player per team, round by round, with a reset button ready for when someone goes AFK mid-draft. Search bar filters the player list live so you're not squinting at 24 names trying to find the one you want.

Draft locked. One push. Challonge bracket fills with the team names, the date, the stream link. Brackets tab opens so the admin can update match results without leaving the app.

Start tournament. Done.

No alt-tabbing. No copy-paste. No midnight Discord pings asking why the bracket has the wrong team name.

The GitHub release went up. The installer built. The .exe works on Windows 10 and later. The app is called The Colosseum because it was called "Tourney App" for months and that name is soulless and gladiators do not compete in the Competition Venue.

The app works. Anyone can run a tournament without bouncing between four tabs. The community gets their degen wheel spins and their snake draft chaos and their bracket updating in real time. And I learned something that sounds obvious but apparently needed several iterations of OAuth headaches and late-night API docs to actually land:

When you see a problem you know how to solve, the only thing standing between you and solving it is deciding that you're going to actually solve it.

There's no reason not to do what you know you can do.
Be the change we wish to see, or something like that.

Link to the GitHub Release: GreenSide's Collosseum App

Solitice (Game Jam 2026)

Joe C — Fri, 12 Jun 2026 02:03:10 +0000

What I Built
I built Solitice, a relaxing, Solstice-themed 2D pixel art sidescroller. My intended goal was to capture the atmospheric and calming essence of the solstice season within a lightweight, accessible web game.

Players can experience a tranquil platforming journey that ties directly into the challenge theme by celebrating the longest (or shortest!) day of the year through its environment, pacing, and visual aesthetics.

You can play the web build (HTML5) over on my itch.io page here: https://jchildree.itch.io/solitice-game-jam-26

Video Demo

Code

jchildree / Solatice-Gam-Jam-26

Solstice Game Jam '26

A game developed for the Solstice Game Jam 26, built using the Godot Engine.

📁 Project Structure

addons/silent_wolf/: Integration for SilentWolf, providing backend services (likely used for leaderboards, player authentication, or cloud data).
assets/: Art, audio, models, and other static resources used in the game.
docs/: Project documentation, design notes, and planning materials.
scenes/: Godot scene files (.tscn), containing the game's levels, UI layouts, and object prefabs.
scripts/: Core game logic written primarily in GDScript.
tools/: Utility scripts (Python, JavaScript, Shell, etc.) utilized for development, asset pipelines, or build/deployment workflows.
project.godot: The main configuration file for the Godot engine.
CLAUDE.md / CONTEXT.md: Project context and instructions for AI development assistants.

🛠️ Technology Stack

Game Engine: Godot
Primary Language: GDScript
Backend Services: SilentWolf
Auxiliary Tooling: JavaScript, Python, and Shell for automation and repository maintenance.

🚀 Getting

…

View on GitHub

How I Built It
I chose to build "Solitice" using the Godot engine. Godot's node-based system is incredible for 2D platformers and it allowed me to quickly iterate on the game's relaxing physics and movement mechanics. I focused heavily on cultivating a calming aesthetic using 2D pixel art.

One of the most interesting aspects of my technical approach was utilizing AI-assisted coding to help build out some of the game's systems. This allowed me to spend more time finding the right artwork and improving the atmospheric feel of the game to ensure it perfectly matched the Solstice theme.

To bring the project over the finish line, I leaned heavily on Google AI to handle the writing and presentation. I used Google's AI tools to brainstorm and generate the in-game descriptions, helping to flesh out the game's theme and tone without getting bogged down in writer's block. Furthermore, I used Google AI to help draft and structure this very Dev.to submission article! Using AI as a writing assistant allowed me to focus the bulk of my jam time on actual development and polish.

Prize Category
Best Google AI Usage
I am submitting this project for Best Google AI Usage. I utilized Google AI as a core part of my publishing and world-building workflow. Specifically, I used it to generate the game's descriptions and text, as well as to write and format this Dev.to submission article. It served as an invaluable writing assistant that helped me communicate my project's vision clearly for the game jam.

Captain Caveman Claude

Joe C — Fri, 29 May 2026 15:38:43 +0000

Claude-ITect-Skill Update: Regenerating Your Claude Code Setup (Club Optional)

"People assume that configuration is a strict progression of cause to effect, but actually, from a non-linear, non-subjective viewpoint, it's more like a big ball of wibbly-wobbly... skilly-willy... stuff."
— a Time Lord, probably, if Time Lords shipped install scripts

There is a particular flavor of pain known only to people who run Claude Code seriously: the slow, soul-eroding ritual of configuring fifty-one little things by hand. You wire one hook. You forget the second. You discover the third only exists in a Discord message from four months ago. Somewhere, a yak grows another inch of fur specifically so you can shave it.

Claude-ITect-Skill exists to make that ritual unnecessary. It is a one-command starter pack that drops a curated arsenal of skills, agents, and session hooks into any project's .claude/ directory, and then, with the smug confidence of someone who has clearly been burned before, tells you to run /audit to make sure it actually worked. The author calls people like himself "Claude-ITects™," which the industry refuses to call us, and honestly, after using this, the industry should reconsider.

This is the update, the regeneration, if you will. Same face-of-the-project, new internals. Let's open the TARDIS doors and see how much bigger it is on the inside.

The pitch, in one breath

Install it. It deposits a .claude/ folder containing 54 skills, 4 agent definitions, and 6 hook files into your project, patches your settings.json to wire up the session hooks, and gets out of your way. The README's entire onboarding flow is two words long: run audit. That restraint is the first sign you're dealing with someone who has actually used the thing he built rather than someone who just wanted a README with a lot of headers.

The install story is genuinely good. PowerShell for Windows, bash for macOS/Linux, sensible --force and --skip-hooks flags, and a thoughtful -ProjectPath option so you can aim it at a project other than your current directory. The -ExecutionPolicy Bypass note even reassures nervous Windows users that nothing permanent is happening to their system. It's the kind of small kindness that separates a tool someone made for themselves from a tool someone made for other people too.

What's under the hood

The 54 skills are organized into sensible tribes, which is where Captain Caveman would put down his club and nod approvingly. (Captain Caaaaaveman! Sorry. It happens.)

Superpowers — the workflow orchestration layer. This is the cleverest part of the whole pack and the part that most people will underestimate. Fourteen skills that auto-trigger at key moments rather than waiting to be summoned. brainstorming fires before implementation. systematic-debugging runs a real hypothesis loop. verification-before-completion is the digital equivalent of a Weeping Angel standing behind you whispering "don't declare it done yet." These aren't tools you reach for; they're behavioral guardrails that shape the agent before it does anything dumb. Borrowed and adapted from the excellent superpowers project, they're the connective tissue of the pack.

Engineering. Ten skills covering the unglamorous, load-bearing parts of real work: diagnose (reproduce → minimise → hypothesise → fix → regression-test, a loop with actual discipline), to-prd and to-issues for turning a conversation into shippable GitHub work, improve-codebase-architecture, zoom-out for when you've been heads-down so long you've forgotten whether the approach was ever correct. This is the section that earns the "architect" in Claude-ITect.

Caveman — token compression. Here is the headline act, and the source of every pun in this review. The caveman family cuts token usage by roughly 75% while keeping full technical accuracy, communicating in a deliberately compressed register with modes named lite, full, ultra, and the gloriously over-the-top wenyan-*. There's caveman-commit for compressed commit messages, caveman-review for terse PR comments, and caveman-stats to show you the real token savings from your session log. Unga bunga, big save. This is the feature that justifies the whole bundle existing, because token efficiency isn't a nice-to-have at scale, it's the difference between a session that finishes and a session that runs out of context two steps from the finish line.

The CaveCrew agents. Four subagents, three of them genuinely well-scoped:

CaveCrew Builder: surgical 1–2 file edits, and it hard refuses anything touching three or more files. A tool that knows what it's bad at is worth ten that don't.
CaveCrew Investigator: read-only code locator that returns a file:line table and, crucially, offers no fix suggestions. It finds; it does not editorialize.
CaveCrew Reviewer: one finding per line, severity-tagged, no praise. The most caveman thing in the entire repo and possibly the most useful.
Geometry Solver: the odd one out, a Custom Project-specific math agent doing Newell normals, MVC, and GJK/EPA collision work. More on this in a moment.

The rest: utilities (adr, audit, tools, phase, setup-pre-commit), productivity (grill-me, the relentless interview skill that stress-tests your plans until they cry), and a small writing suite (edit-article, writing-beats, writing-shape). Plus thefuck, which diagnoses your last failed shell command and proposes the correct one — and, refreshingly, never executes destructive corrections silently. It confirms first. Even the joke tool has manners.

The bits worth admiring

Three design decisions stand out as evidence of real taste rather than just enthusiasm.

First, audit-first onboarding. Most skill packs assume installation equals success. This one ships duplicate skills on purpose so the /audit skill has something to react to, verifying that the pack nests cleanly inside whatever skills your repo already has. That's a tool designed to survive contact with a messy real-world project, not a pristine demo repo.

Second, agents that refuse. The Builder's hard cap on file count and the Reviewer's no-praise rule are constraints, and constraints are where quality lives. A sonic screwdriver that did literally everything would be a worse plot device; the good ones have rules.

Third, readable-code discipline runs underneath everything. The karpathy skill operates as an internal reasoning layer, and the broader architecture leans on three-law readable-code rules and ADR-backed decisions. The pack doesn't just generate code — it generates code it can stand behind later.

A few easy wins for the next update.

The best part about reviewing something built in public is that the rough edges aren't flaws, they're the next update, just sitting there waiting to be claimed. Here are a few friendly ones, offered in the spirit of "Because I ran out of time, and couldn't ship them myself."

The em-dash easter egg. v1 shipped a check-encoding.js hook that cheerfully blocked any file write containing em-dashes or smart quotes. If you want the cosmic balance restored, it's a perfect first task to hand to /audit. (Or not. Some of us think the dashes earned their place.)

Let the personal bits raise their hand. The Geometry Solver agent and the Project Specific pieces are deeply specific to the author's own engine, and the README is refreshingly upfront that the NgonENGINE commands stay opt-in. That honesty is exactly right. The natural next step is letting the install flow ask which flavor of Claude-ITect you are, so the bespoke bits show up only for the people who'll cheer to see them. The author already wants this thing custom to whoever's using it, which is the whole reason it has a soul in the first place.

None of these are knocks. Every great TARDIS starts as a battered blue box that somebody loved enough to keep flying.

The verdict

Claude-ITect-Skill is what happens when someone who actually does the work gets tired of doing the setup for the work; and then, instead of grumbling about it forever, fixes it once, properly, and hands the fix to everyone else for free. That generosity is the throughline. The caveman compression layer alone is worth the install. The superpowers orchestration is the quiet genius humming underneath. The CaveCrew agents demonstrate the rarest virtue in any tool, knowing what to refuse. And the whole pack carries a readable-code, ADR-backed discipline that means it generates work it can still stand behind a month later.

It's an arsenal assembled by one practitioner with real taste and then opened up to the rest of us, inside jokes and all. If you run Claude Code and you've ever felt that yak-shaving despair, that slow drip of one more thing to configure; clone it, run the install, and (say it with me) run /audit. You'll be set up in the time it takes to make coffee.

Then go build something wonderful. The clubs are optional. The token savings are not. Captain Caaaaaveman would be proud.

Written against the live repository: 54 skills, 4 agents, 6 hooks. Numbers subject to regeneration without notice.

jchildree / Claud-itect-Skill

An awesome curated skill pack for Claude Code. Installs 54 skills, 4 agent definitions, caveman session hooks into any project in one command, and thefuck fixes any mistakes that occur....when you need it.

Claude-ITect-Skill

Are you a Claude Architect or as the industry refuses to call us: Claude-ITects™ Good. You're in the right place.

Welcome to Claude-ITect-Skill The "I don't want to configure 54 things manually" starter pack for Claude Code. Powered by Captain Caveman energy -- one club, infinite tools, zero yak-shaving.

What you get (whether you deserve it or not):

🧠 54 curated skills
🤖 4 agent definitions
🪓 Caveman session hooks (one command, no thinking required)
🔧 thefuck integration for when your terminal betrays you.

But don't get distracted by the features.

The real sorcery happens during setup when everything just… works.

No funny dances. No ritual sacrifices.

Install it. Try it. Judge me harshly afterward.

After installation start with these skills:

/onboard <- run first
/audit <- run next

Prerequisites

Claude Code -- claude.ai/code
Node.js (LTS) -- nodejs.org -- required for caveman hooks

Install

Windows

Open PowerShell (search…

View on GitHub

Claude-ITect-Skills

Joe C — Thu, 21 May 2026 16:16:27 +0000

I've been trying to make a personalized skill pack (but it's all timey-whimey) and would love to hear from everyone's feedback. This skill pack customizes itself to you, and the project. After you install, then run the /audit command, it executes a series of commands in the background (and foreground). This skill then updates itself and your other skills to align with your actual project goals and ensure you have what you need. There are other personality features as well but let's not give it all away here....spoilers!

jchildree / Claud-itect-Skill

An awesome curated skill pack for Claude Code. Installs 54 skills, 4 agent definitions, caveman session hooks into any project in one command, and thefuck fixes any mistakes that occur....when you need it.

Claude-ITect-Skill

Are you a Claude Architect or as the industry refuses to call us: Claude-ITects™ Good. You're in the right place.

Welcome to Claude-ITect-Skill The "I don't want to configure 54 things manually" starter pack for Claude Code. Powered by Captain Caveman energy -- one club, infinite tools, zero yak-shaving.

What you get (whether you deserve it or not):

🧠 54 curated skills
🤖 4 agent definitions
🪓 Caveman session hooks (one command, no thinking required)
🔧 thefuck integration for when your terminal betrays you.

But don't get distracted by the features.

The real sorcery happens during setup when everything just… works.

No funny dances. No ritual sacrifices.

Install it. Try it. Judge me harshly afterward.

After installation start with these skills:

/onboard <- run first
/audit <- run next

Prerequisites

Claude Code -- claude.ai/code
Node.js (LTS) -- nodejs.org -- required for caveman hooks

Install

Windows

Open PowerShell (search…

View on GitHub