DEV Community: kimuson

Introducing Claude Crew: Enhancing Claude Desktop's Coding Agent Capabilities

kimuson — Thu, 03 Apr 2025 09:14:13 +0000

I've developed a tool called "Claude Crew" that extends Claude Desktop's capabilities as an autonomous coding agent. I'd like to introduce this tool and share some insights gained during its development.

Repository:

https://github.com/d-kimuson/claude-crew

Claude Crew is designed with inspiration from OpenHands but specifically for Claude Desktop. It leverages Model Context Protocol (MCP) and custom instructions to maximize Claude Desktop's coding capabilities.

TL;DR

Created Claude Crew, an autonomous coding agent for Claude Desktop similar to OpenHands
Provides RAG functionality and project-optimized MCP to enhance Claude's performance

What is a Claude Desktop-Based Agent?

Recently, LLM-based coding tools have become widespread, with solutions like Cline, Cursor, Devin, and others being actively used by developers. You may have tried some of these or even incorporated them into your workflow.

Claude Desktop comes equipped with:

Custom instructions setting capabilities
A Model Context Protocol (MCP) client

By configuring MCP with file operations (through the official filesystem implementation) and third-party or self-built shell access, and setting custom instructions to enable agent behavior, Claude Desktop can function as a coding agent on its own.

While these existing mechanisms make it possible to create a coding agent based on Claude Desktop, basic MCP integration alone has limitations when it comes to understanding context in large projects and efficiently using tokens. Claude Crew provides a toolset to address these challenges.

Differences from Editor-Integrated Coding Assistants

AI coding assistants like Cline, Cursor, and Windsurf are designed for human collaboration. They follow an interactive workflow where humans review and help modify code in real-time while the agent is making edits.

In contrast, Claude Crew aims for a more autonomous workflow based on the concept of "create XXX" tasks, where AI completes tasks autonomously from start to finish.

In essence, Claude Crew resembles implementing OpenHands on Claude Desktop.

It's worth noting that higher autonomy isn't always better—collaborative and autonomous approaches have clear trade-offs:

Collaborative (Cline/Cursor)	Autonomous (Claude Crew)
Better at difficult or poorly articulated problems	Only handles well-defined, simpler tasks
Human judgment can redirect to solve harder problems	Removes human bottlenecks for parallel processing
Requires continuous feedback	Only needs final result verification
Requires engineering feedback	Works better with feedback from non-technical stakeholders

In practice, both approaches complement each other.

In my own workflow, once Claude Crew became usable, I would:

Delegate simpler feature implementations to Claude Crew in parallel
Focus my attention on more complex problems using Cursor

Problems Claude Crew Solves

While basic agent functionality can be achieved by simply connecting Claude Desktop with MCP, there were several challenges to overcome for practical use:

Context Understanding Limitations - Understanding related code in large projects is crucial but difficult
Token Restrictions - Claude Desktop offers unlimited usage with a subscription, but has relatively strict character limits, requiring efficient context window usage
Feature Gaps - Compared to editor-integrated tools like Cursor, Claude Desktop lacks feedback mechanisms for LLMs, which would require significant implementation work to match

Claude Crew addresses these challenges comprehensively:

Builds local RAG for your codebase to effectively supplement context understanding
Provides effective LLM feedback reflecting your development project information
- Automatic unit testing and static analysis when files are modified, with results fed back to minimize trial and error and produce correct code
Offers an all-in-one solution with features that enhance coding performance but would be difficult to set up individually:
- Memory banks, TypeScript Compiler API-based identifier implementation search, "think" tool for improved coding performance, etc.

How Claude Crew Works

Claude Crew provides both MCP for Claude Desktop integration and a CLI that comprehensively enhances Claude Desktop's functionality.

In addition to Claude Desktop, you'll need:

OpenAI API key for running local RAG (optional but recommended)
Docker for running PostgreSQL for RAG searches

The CLI offers interactive setup that outputs structured configuration for your project:

$ cd /path/to/your-project
$ npx claude-crew@latest setup

This configuration is passed during MCP startup, allowing MCP to operate according to your project structure.

Configuration example:

{
  "mcpServers": {
    "claude-crew-claude-crew": {
      "command": "npx",
      "args": [
        "-y",
        "claude-crew@latest",
        "serve-mcp",
        "/path/to/.claude-crew/config.json"
      ]
    }
  }
}

Additionally, it creates:

.claude-crew/instruction.md
.claude-crew/memory-bank.md

Setting .claude-crew/instruction.md as Claude Project's custom instruction enables the coding agent functionality.

Running a Real Task

Let's use Claude Crew to add a feature to Claude Crew itself. In this case, we'll add a "keep branch up-to-date" feature.

Since there is no mechanism to keep the branch up-to-date, please implement one.

Allow setting git's default branch when configuring via CLI
During prepare, if there are no local changes and we're on the default branch, do git pull --rebase origin [default branch]
Update the README to reflect the changes
After verifying the functionality, commit with a message in English

Let's begin.

Once a task begins, the custom instruction invokes the "prepare" tool, which provides the LLM with:

Highly relevant source code
Relevant documentation
Memory bank contents
Project overview and tech stack information parsed from configuration and package.json

Using this context information, it explores for additional necessary information and performs coding tasks.

The claude-crew-write-file tool is used to update files, automatically:

Returning type-checking results
Returning ESLint results
Detecting and running relevant tests and returning results

We want the output to pass tests and linting, but running these as MCP would increase round-trip communications, so they're built into MCP for efficiency.

When implementation is complete, the custom instruction calls the claude-crew-check-all tool to verify everything works correctly and completes the task.

This process allows features to be implemented without human intervention.

Lessons and Challenges

Here are some lessons learned and remaining challenges:

MCP Inspector is Useful for Development

MCP Inspector is a valuable tool for debugging. It lets you test tools as if you were the LLM.

Capturing stdout is Essential for Stability

MCP uses standard input/output for communication, so using console.log can cause MCP client errors due to invalid messages.

I tried using a custom logger to avoid standard output during MCP usage, but some libraries inevitably needed it, so I overrode process.stdout:

// eslint-disable-next-line @typescript-eslint/unbound-method -- It's fine because we're just returning to a method with the same 'this'
const originalWrite = process.stdout.write
process.stdout.write = (content) => {
  myLogger.info(content.toString())
  return true
}
// Process that outputs to stdout
process.stdout.write = originalWrite

However, permanently overriding process.stdout.write would break MCP itself, so this approach must be used selectively. A cleaner solution would be preferable.

Long Tasks are Difficult with MCP

Initially, I wanted the "prepare" tool to handle database migrations and re-indexing changed code, but debugging with MCP Inspector revealed timeout issues.

As this article explains, MCP Inspector times out after 10 seconds, while Claude Desktop allows 60 seconds. The client has the final say.

Since the server can't request longer wait times for heavy tasks like "prepare," design must account for these constraints on long-running tasks.

MCP Optimization Achieves Many Goals

I've previously experimented with coding agents:
Vercel AI SDK Mastra AI Agent

While coding the agent lifecycle offers more flexibility, MCP and instructions can accomplish quite a lot on their own.

The main advantages I observed were:

RAG availability
Optimized feedback during file operations
Message compression for cost efficiency
Dynamic system prompt modification during tasks

The first two can be achieved with MCP and configuration (plus CLI tools), while the latter two require complete implementation, which comes with:

Usage-based billing concerns
Complex implementation challenges
- Despite assistance from LLMs, Vercel AI SDK, Mastra, etc., implementing chat UIs and dynamically modifying agent system prompts involves difficult state management

Starting with an MCP-first approach might be worthwhile.

Context Understanding Could Be More Efficient

In the task example, we hit character limits and had to request continuation. While some constraints are unavoidable, I'd like to minimize them.

To improve context understanding and for better cost-efficiency than letting the system autonomously seek context, I included:

RAG for codebase and source code
Simplified memory bank
- Unlike the original memory bank implementation with multiple files, Claude Crew uses a single file with reduced sections

In the example, the prompt and context consumed about 5,500 tokens. I'm considering optimizations like choosing between memory bank and RAG to reduce this overhead.

Conclusion

I've introduced Claude Crew, a tool I developed to enhance Claude Desktop's coding agent capabilities!

https://github.com/d-kimuson/claude-crew

I'm continuing development with the goal of creating a tool that allows you to delegate relatively simple tasks entirely to Claude Desktop within your subscription limits.

Please try it out! Contributions and stars are welcome and motivating!

Footnotes

Reference: https://www.anthropic.com/engineering/claude-think-tool
The embedding model costs approximately 10,000,000 tokens per dollar. Indexes are automatically kept up-to-date, but a content hash-based differential update logic is used to minimize updates.

Introduction to type-predicates-generator, which automatically generates type guards from TypeScript type definitions

kimuson — Tue, 23 Nov 2021 05:48:54 +0000

I've created a tool to automatically generate user-defined type guards (type predicate) and assertion functions from TypeScript type definitions. By automatically generating user-defined type guards, you can protect the types of your applications safely and easily without writing wrong implementation as type predicate.

https://github.com/d-kimuson/type-predicates-generator

type predicate and problems

If you use type annotations or as <type> for typing a value that comes from an external source such as API or JSON parsing, you won't be able to notice when you get an unexpected value.

type Task = {
  id: number
  titile: string
  description: string
}

const task: Task = JSON.parse('...') // Write annotations for functions that return any type
task /* :task */ // value is typed as Task even if the type is not match to the Task type

If the type is different from what it actually is, it is undesirable because it reduces the benefits of TypeScript, both in terms of application safety and development experience.

In such a case, you can use type predicate (v is <type>) to do type guarding using a user-defined function.

It allows you safe typing of untyped value.

// define type predicate
function isTask(value: unknown): value is Task {
  return (
    typeof value === 'object' &&
    value ! == null &&
    'id' in value &&
    typeof value.id === 'number' &&
    'title' in value &&
    typeof value.title === 'string' &&
    'description' in value &&
    typeof value.description === 'string'
  )
}

// using type predicate
if (isTask(task)) {
  // if isTask returns true, assume task is of type Task
  task /* :Task */ }
}

This is safer than using as or type annotations, but TypeScript does not take care of the correct implementation of this type predicate function.

In the extreme case, a messed up implementation such as const isTask = (v: unknown) v is Task => true will narrow down the type to Task without getting angry.

I don't think you ever write such an implementation, of course, but

A case where the implementation was correct at the time of writing, but the Task type is changed and isTask becomes an inappropriate implementation (adding a property)
A simple implementation error (as you can see in isTask, it is quite complicated to write object property checks properly, and there are also shared types, array child element checks, etc., so mistakes can be made)

In some cases, incorrect runtime checking functions may be introduced due to them.

Also, since it is difficult to write type predicates for each type, psychologically speaking, it is easy to compromise with type annotations or as without writing the type predicate itself.

Introduction to type-predicates-generator

The type-predicates-generator solves these problems by automatically generating a type predicate function from a type definition.

It can be installed from npm.

https://www.npmjs.com/package/type-predicates-generator

$ yarn add -D type-predicates-generator # or npm

The type predicate function will be generated automatically by passing the appropriate options to the type-predicates-generator command.

$ yarn run type-predicates-generator -f 'path/to/types/**/*.ts' -o '. /type-predicates.ts'

Then, automatically generates predicates functions from exported type declarations (type alias and interface) in files matching path/to/types/**/*.ts, and writes them to type-predicates.ts.

If you run type-predicates-generator on the Task type used in the above example, it will automatically generate the following

// auto-generated predicate definitions
import type { Task } from "path/to/your-type-declare"

const isNumber = (value: unknown): value is number => typeof value === "number"
const isString = (value: unknown): value is string => typeof value === "string"
const isObject = (value: unknown): value is Record<string, unknown> =>
  typeof value === "object" && value ! == null && !Array.isArray(value)

export const isTask = (arg_0: unknown): arg_0 is Task =>
  isObject(arg_0) &&
  "id" in arg_0 &&
  isNumber(arg_0["id"]) &&
  "title" in arg_0 &&
  isString(arg_0["title"]) &&
  "description" in arg_0 &&
  isString(arg_0["description"])

Now we can use the auto-generated function to protect our application by using it when values come in from the outside!

 import { isTask } from 'path/to/type-predicates'.

 fetch("path/to/api").then(async (data) => {
- const json: Task = await data.json(); // dangerous typing that doesn't check if it's really of type Task.
+ const json /* :any */ = await data.json();
+ if (!isTask(json)) throw new Error('Oops'); // throw an exception if the check fails

   json /* :Task */ }
 })

Now you can safely and easily type values that come from the outside.

If you specify the -a option, assertion function can also be generated automatically. The assertion function is more appropriate for cases like the one above.

// which is additionally auto-generated by `-a` option
function assertIsTask(value: unkonwn): asserts value is Task {
  if (isTask(task)) throw new TypeError(`value must be Task but received ${value}`)
}

// Use
const json /* :any */ = await data.json();
assertIsTask(json) // If it fails, an exception is raised
json /* :Task */

Since it is auto-generated, there is no need to write a predicate, and the psychological hurdle is low.

It also supports watch mode (-w), so you can run watch during development and reflect changes as they happen.

See the repository for cli other options

https://github.com/d-kimuson/type-predicates-generator#cli-options

What can be checked and what can't

Basically, I've tried to support all data structures that can be received as JSON (so if you find any missing, please raise an issue).

https://github.com/d-kimuson/type-predicates-generator/issues

On the other hand

Functions/Methods
Promise
Data structures with circular references (such as obj1.recursive = obj2, obj2.recursive = obj1)
- When checking properties, they go to each other to check each other's properties, resulting in an infinite loop.

It is not possible to perform checks in them.

On the other hand, all type operations are supported.

Complex types such as Mapped Types, Conditional Types, etc. can be generated without any problems, as long as they eventually resolve to JSON serializable types or their intersection or union types

// From: Partial using Mapped Types
type PartialTask = Partial<Task>;

// Generated: generated from the last resolved type
export const isPartialTask = (arg_0: unknown): arg_0 is PartialTask =>
  isObject(arg_0) &&
  ((arg_1: unknown): boolean => isUnion([isUndefined, isNumber])(arg_1))(
    arg_0["id"]
  ) &&
  ((arg_1: unknown): boolean => isUnion([isUndefined, isString])(arg_1))(
    arg_0["title"]
  ) &&
  ((arg_1: unknown): boolean => isUnion([isUndefined, isString])(arg_1))(
    arg_0["description"]
  )

Use with openapi-generator

In the front-end, some tools such as openapi-generator, aspida, etc. are used to automatically generate response types.

It is also possible to include them directly in the type-predicates-generator generation, but since the type definitions tend to be huge and it takes a long time to generate them, you can re-export only the ones you use.

(However, it took more than 5 seconds even when I tried it with a 4000-line type definition generated by GraphQL Code Generator, which I use in my personal blog, so you may not have to worry about time to generate too much.)

For this use case, I include not only the type declarations but also the re-exported type definitions in the generation

export { Category } from ". /typescript-axios/api".

There is a concrete example in the repository example. Types re-exported by re-export.ts You can see that the function is generated in type-predicate.ts from the type definition re-exported by re-export.ts. From the type definition re-exported by type-predicate.ts, we can see that the function has been generated

How is it implemented?

The Compiler API extracts the type information from the Glob-specified file and generates it automatically.

I'll leave the details of the Compiler API to another article.

search Node for the matched file and pick up the declaration node of type alias and interface. 2.
recursively pick up the types from the declaration nodes using TypeChecker, and 3. writes the exported type information as Exportable Type Information, which is defined independently.
generate code based on the exported type information

This is how it works

https://github.com/d-kimuson/type-predicates-generator/blob/main/src/compiler-api/compiler-api-handler.ts

https://github.com/d-kimuson/type-predicates-generator/blob/main/src/generate/generate-type-predicates.ts

Conclusion

So, that's my introduction to type-predicates-generator!
It's still a work in progress, but it's an easy tool for improving type safety, so I hope you'll give it a try!
PR and issues are welcome!

VSCode Extension to expand hard-to-read type definitions in TypeScript

kimuson — Fri, 28 May 2021 15:59:23 +0000

I've created a VSCode extension that makes complex types easier to read, and I'll show you how to use it!

Motivation

When I'm writing TypeScript, it sometimes hard-to-read complex types for me, so I often need to bind them to variables and use completion to find properties. I was wondering if there was something I could do to see the expanded types.

I found out about TypeScript's CompilerAPI, so I thought it would be a good idea to extract the type and pass it to the VSCode Tree View, so I made it.

What I made

An extension that can expand TypeScript type definitions

You can install from ts-type-expand - Visual Studio Marketplace.

Like this, You can expand and check the hard-to-read types on VSCode as many times as you need.

If you hover over a variable, you will see the type information, but it sometimes hard to read like XXX & YYY & ZZZ and you won't know what the final type is. This extension is useful in such cases.

As for the supported types, CompilerAPI does the type resolution for you, so if TypeScript supports it, you should be able to expand all of them.

As for valid nodes can be selected is shown in repository, so please see it. but, you should be able to get types from most of the nodes you intuitively think you can get.

How to

CompilerAPI retrieves the type information of the selected node on VSCode and passes it to the Tree View.

After learning the basic usage by referring to the official material, I created an extension to retrieve the type information.

It was quite difficult because the necessary types for receiving Union types were not provided (the actual types existed, but there were no type definitions, so I had to find the properties by hand and use them), and the documentation was not very complete, so I did not know how to get the types I wanted.

Tree View API

The extracted types are expanded in VSCode's TreeView.

This API is quite simple, so I was able to create it without too much trouble.

However, the situation where we want to expand a type is

Properties
Candidates for Union type
Candidates for Enum
Function expansion (arguments and return value)

So when I tried to use it, I could understand that it could be expanded, but I couldn't understand why it could be expanded.

Eventually.

In this way, I have added information about what can be expanded (Properties, Union or Function).

Summary

In this post, I introduced ts-type-expand, an extension that can help you when you are reading hard to read types such as auto-generated types from GraphQL schemas or when the types provided by the library are difficult to understand.

Please try it out!

DEV Community: kimuson

Introducing Claude Crew: Enhancing Claude Desktop's Coding Agent Capabilities

TL;DR

What is a Claude Desktop-Based Agent?

Differences from Editor-Integrated Coding Assistants

Problems Claude Crew Solves

How Claude Crew Works

Running a Real Task

Lessons and Challenges

MCP Inspector is Useful for Development

Capturing stdout is Essential for Stability

Long Tasks are Difficult with MCP

MCP Optimization Achieves Many Goals

Context Understanding Could Be More Efficient

Conclusion

Footnotes

Introduction to type-predicates-generator, which automatically generates type guards from TypeScript type definitions

type predicate and problems

Introduction to type-predicates-generator

What can be checked and what can't

Use with openapi-generator

How is it implemented?

Other solutions

Conclusion

VSCode Extension to expand hard-to-read type definitions in TypeScript

Motivation

What I made

How to

Tree View API

Summary