DEV Community: Barış Yerlikaya

You just joined a project. Crewforth 3.2.0 draws you its map.

Barış Yerlikaya — Thu, 22 Oct 2026 12:41:02 +0000

You just joined a new project. Nothing looks familiar. There are folders called core, common and shared, three package.json files, and a docker-compose.yml that mentions a queue nobody has told you about.

The usual move today is to ask an AI agent to explore the repository. That works, more or less. It is also slow, it costs tokens every time, and when it tells you "the billing service talks to Stripe", you cannot tell whether it read that or guessed it.

Crewforth 3.2.0 adds Crew Map, which answers four questions about a project:

What each part does
What it's built with
Who talks to whom
Where something is wrong

It does this without running anything. It reads the files.

What Crewforth is

Crewforth is an open-source (MIT) kit for Claude Code. It adds 14 specialist agents, 40 skills, 13 /crew-… commands, and hooks that enforce the rules that matter: a destructive command is refused, a commit waits for your approval, a leaked key never reaches history. Crew Map is one part of it.

npx crewforth init

Step 1: a scan that cites its sources

The first part is a scanner. It uses no model. It reads manifests and source for Node and TypeScript, Python, Go, .NET, Java and Kotlin, and writes one file, .crewforth/crew-map.json, with:

the modules,
the external resources they touch (databases, caches, queues, outside APIs),
the endpoints each module provides and the ones it calls.

Every module, every line between modules and every finding carries the file:line it was read from. If the map says module A calls module B, you can open the exact line.

Two details matter in practice:

It is deterministic. The same tree gives the same bytes. Run it with --check in CI and the build fails when the map is out of date.
It does not copy secrets. A configuration value is read only to name its kind (a Postgres URL, a Redis host), not stored.

Step 2: the model describes, but only what was read

A list of modules is not yet understanding. So /crew-map runs the scanner and then asks the model to describe what it found:

at most two sentences per module on what it is for,
a short overview of the project,
a layer for each module: ui, api, service, data, infra, tool or library,
the domain it serves (billing, auth, search...),
a tour of up to eight stops that a newcomer reads in order.

Each of these must cite lines the scan itself read. crew-map.sh --validate refuses a description that cites anything else or nothing, a layer not on the list, a domain written as a sentence, a tour stop that points at no module or visits one twice, and any scanner field changed by hand. When you scan again, descriptions that still hold are kept and the rest are dropped.

Module READMEs are read too. On a real project, four of ten modules had nothing else to describe them by.

This is the part I care about most: the model writes prose, but it cannot invent structure. A connection the model proposes is drawn differently from one a file proves.

Step 3: look at it in Studio

Studio is Crewforth's local panel (npx crewforth studio). Its Map view (press p) reads crew-map.json and scans nothing itself.

Modules sit in their layers, from UI down to Infrastructure. Each card names the module, its domain, up to three things it is built with and the outside services it calls.
Lines are solid where a file proves them, dotted where inferred, and marked where the model proposed them.
Search dims everything it does not match.
The tour steps through the map at the bottom of the pane.
The inspector shows a module's entry point, its folders and their file counts. Any file:line can be copied, and a finding can be copied as a task for the crew.
Compare with matches another project's calls against this one's endpoints, which helps when a frontend and a backend live in separate repos.

crew-planner, the agent that turns an unclear request into tasks, reads the map when it works on an unfamiliar project, so it starts from the same picture you do.

Where something is wrong

The scanner has ten gap rules. Five are proven by the lines they cite. The other five are conclusions from absence, such as an endpoint that nothing calls. Absence is easy to get wrong, so those five are hidden and only counted until their false-positive rate is measured. You can ask to see them.

Also in 3.2.0

Watch your crew from your phone. Studio can make a read-only viewer link, shown as a QR code. A phone on the same Wi-Fi opens the panel without ssh or a tunnel. Transcripts are hidden unless you tick them, a link lasts eight hours, and you can revoke it.
A new agent that writes your docs. crew-docs-agent owns READMEs, guides, release notes and store listings. Legal and privacy texts run on the critical tier and are audited by crew-privacy-agent.
A guard that tells you what it stopped. When the shell gate stops git reset --hard, git clean -f, git push --force or rm -r, one line says what it would have discarded, overwritten or deleted.

The full list is in the CHANGELOG.

Limits

Supported stacks are Node/TypeScript, Python, Go, .NET, Java and Kotlin. Others are not mapped yet.
Connections come from what the files show: imports, project references, HTTP calls. Wiring decided at runtime is missed.
The scan is free. The descriptions run in your Claude Code session and cost tokens like any other work.

Try it

npx crewforth init      # or: npx crewforth adopt, for an existing repo

Then, in Claude Code:

/crew-map

and open the Map with npx crewforth studio.

If it helps you find your way around a codebase, a star on GitHub is the simplest way to tell me, and it helps other people find the project. If the map gets your project wrong, please open an issue with what it missed. That is the feedback I need most.

Crewforth 3.0: giving Claude Code a crew, and gates that don't forget

Barış Yerlikaya — Mon, 28 Sep 2026 09:27:59 +0000

I've been using Claude Code every day for months, at work and on side projects. It's the best coding assistant I've used. It also has two habits that kept costing me time:

It's one assistant doing every job at once. The same context plans the feature, writes the migration, reviews its own diff and writes the commit message. Nothing stops it from skipping the planning, and nobody else looks at the diff.
Rules are suggestions. I can write "never force-push" and "ask before committing" in CLAUDE.md, and most of the time it listens. Under pressure, in a long session or in auto mode, it sometimes doesn't.

Crewforth is what I built to fix both. Version 3.0 shipped this week. It used to be called Claude Starter Kit.

A crew instead of one assistant

Crewforth adds four kinds of things to Claude Code, all standard Claude Code features:

12 subagents, each owning one domain: crew-planner, crew-backend-expert, crew-database-expert, crew-frontend-expert, crew-devops-expert, crew-security-expert, crew-privacy-agent, crew-performance-expert, crew-test-expert, crew-review-agent, crew-commit-agent and crew-session-manager.
39 skills that hold the method: how to plan a change, how to review a migration, how to write a runbook, and so on.
10 commands you start with /crew-…: /crew-plan, /crew-review, /crew-ship, /crew-handoff, /crew-doctor and a few more.
Hooks that enforce the rules that matter (more on these below).

The work follows five stages:

Understand. An unclear request goes to crew-planner first. It scopes the change and writes acceptance criteria before any code exists.
Produce. The owner builds it: server work to crew-backend-expert, schema changes to crew-database-expert. A routing hook names the owner beside your request, so you can see who picked it up.
Audit. Security, privacy and performance audits run in parallel on the diff.
Close. crew-review-agent reviews the exact diff with a plan, a severity and a category for every finding. Only critical and high findings block. Then crew-commit-agent proposes the commit and waits for your approval.
Hand off. Before the context window fills up, a handover note is written. The next session reads it and picks up where you stopped.

It's stack-agnostic. Earlier versions had a .NET-specific path; 3.0 dropped it. The stack is detected from your repository or recorded once in CLAUDE.md, and the same agents work on Go, TypeScript, Python or C#.

Gates, not reminders

This is the part I care about most. A rule in a prompt is a request. A hook is code that runs outside the model, on every tool call, whatever the model decided.

Crewforth turns a small set of rules into hooks:

A destructive shell command (git push --force, git reset --hard, a recursive rm -rf, git commit --no-verify) is refused before it runs.
A commit waits for your explicit approval, with the review on record.
The staged diff is scanned for secrets before it can reach history.
Turning the gates off (git config core.hooksPath …) is itself refused.

They hold in every permission mode, auto mode included, because the model never gets a vote.

Measured, including what didn't hold

It's easy to write "makes Claude safer" in a README. I wanted numbers, so every claim runs the same prompt with and without Crewforth, in a throwaway workspace, and grades what is left on disk. The rule for publishing a claim is written down before the run.

The first run of the main experiment looked great: without Crewforth, 6 of 10 sessions left a world-writable file under pressure; with it, 0 of 10. Then I rewrote parts of the prompts for 3.0 and ran it again under the same rule. Without Crewforth it was 4 of 10 this time, below the threshold I had set. So the claim came off the README.

Both runs are on the evals page, next to the experiments where Crewforth made no difference at all. I would rather show you that than a single flattering number.

Try it

New project:

npx crewforth init

Existing repository:

npx crewforth adopt

adopt puts everything on a separate branch, staged and uncommitted. main is never touched, and you review the diff before anything lands.

As a Claude Code plugin:

/plugin marketplace add crewforth/crewforth
/plugin install crewforth@crewforth

Then run /crew-doctor inside Claude Code to check the setup.

Two more things:

npx crewforth studio opens a local panel that draws every delegation live: who runs, who waits, who failed.
The installer speaks English and Turkish. A Turkish install answers in Turkish, even after a bare command.

One note on context: Claude Code gives the skill list a slice of the context window. On a 1M-token model it fits by default. On a 200k model, /crew-doctor shows you the one setting that makes room and what it costs per turn, so you can decide.

If you used Claude Starter Kit

Nothing to do. The old package forwards to the new one, so your next update moves the project to 3.0 and renames the components. Your own files and your own lines in CLAUDE.md are left alone.

What's next

3.0.1 is already collecting small fixes. After that I want an eval that measures whether Claude picks the right skill from its description alone, because that's the part of the system I can currently only reason about, not measure.

If you try it, I'd like to hear where the gates get in your way. That's the feedback I can't produce myself.

Site: crewforth.com
Code: github.com/crewforth/crewforth (MIT)