Understand toolkits

Your coding app gets better results when it only sees the tools that matter for the job in front of it. A toolkit is that set of tools: the skills, MCP servers, and settings you hand the Claude app, Claude Code CLI, the Codex app, or Codex CLI for one kind of work.

You keep several toolkits and pick one each time you start a session. You can build your own, or start from one someone else already put together.

Why smaller toolkits work better

It is tempting to install every skill and MCP server that looks useful. Each one has a cost:

• It takes up room. When a session starts, the coding app reads a short description of every skill and the full tool list of every MCP server. That text sits in the same context window as your code and your conversation.
• It gets in the way. With dozens of similar tools to choose from, the agent is more likely to reach for the wrong one, or to spend a turn working out which one to use.
• It adds setup. Many MCP servers need a key or a sign-in. Every one you don’t use is one less thing to set up on each computer.

How much this matters depends on the app and the task, but the habit is the same: give the agent what today’s work needs, and keep the rest in another toolkit.

What makes a good toolkit

A good toolkit is for one job you do again and again, such as reviewing a pull request or shipping a release. Write down the job’s steps, then give each step a tool.

Pick the kind of tool that fits the step. Use skills for procedures, agents for roles that run on their own, MCP servers for outside systems like GitHub or your database, rules for the standards your work follows, and commands for what you run yourself.

Start from a shared toolkit when one fits the job, then add your own tools for the steps it leaves out. Keep one tool per step so your agent never has to guess between two that do the same thing. The size of a toolkit follows its steps, not a number.

Example: one app, three kinds of sessions

Say you’re building Plantpal, an app that reminds people to water their plants, built with Expo and headed for the App Store. Over one week, your sessions look nothing alike:

One app, three kinds of sessions

Your appPlantpal

1. Monday

   Build the app

   This session’s toolkit

   Plantpal: build

   • ExpoMCP
   • Expo RouterSkill
   • SupabaseMCP

2. Wednesday

   Market it: landing page, store listing, launch posts

   This session’s toolkit

   Plantpal: marketing

   • CopywritingSkill
   • SEO fundamentalsSkill
   • FigmaMCP
   • Landing page auditSkill

3. Friday

   Get it into the App Store

   This session’s toolkit

   Plantpal: release

   • ExpoMCP
   • App Store submissionSkill
   • Store screenshotsSkill

SkillMCP server

Each session gets only the tools in its own toolkit.

Monday’s session never sees the copywriting tools, and Wednesday’s never sees the database. Each session starts with a short, relevant set of tools, so the agent spends its attention on your app.

Once Plantpal is in the App Store and most of your work is marketing, make Plantpal: marketing the project’s Default toolkit. Every session now opens with the marketing tools, and when a bug report comes in you pick Plantpal: build for that one launch.

Not sure which tools to pick? Start from what others use

You don’t need to know which of thousands of skills and MCP servers are any good. Other people have already found out, and Code Config shows you what they chose.

Use a toolkit someone else built

People who have a setup that works share it in Community toolkits, such as a toolkit for a Supabase app or an Astro marketing site. Sort by Popular to see the ones most people use.

Open one to see its tools and which coding apps it works with, then choose Use this toolkit:

• Follow updates if you want the improvements its author shares later. You’re told when there’s an update, and you choose when to take it.
• Save a copy if you want a fixed starting point to change however you like.

Either way it becomes one of your toolkits, ready to launch with: a setup someone else already worked out, without the trial and error.

Build from the most popular tools

When you’d rather build your own, start from the tools people already trust. In Tool Builder, sort Items by Most starred to see the most popular skills and MCP servers first. Under Sources, Most used in toolkits shows which repositories other Code Config users rely on most.

Pick a few that fit your project, add them to a toolkit, and you’re done. Stars come from GitHub and show popularity, not a quality check, so read a tool’s description and Before you add notes before you add it.

Share yours back

When your toolkit works well, share it. A teammate gets your exact tools in one step, and someone building the same kind of app can start from yours. Community toolkits covers using and sharing.

Your starter toolkits

Every new account comes with two ready-made toolkits, and you can use either as it is or change it.

• Efficient Builder is your default. It is a small set of coding skills that works in any codebase: finding and diagnosing bugs, code review, safe refactoring, test-first development, checking the work before calling it done, and writing the pull request. It needs no key and no setup.
• Full Auto lets the agent carry the work from plan to done with fewer stops to ask your permission, and has Codex review each change. It needs Codex installed and signed in on your computer.

Ready-made toolkits for other kinds of work, such as web apps, marketing sites, iOS, Android, data research, and machine learning, are in Community toolkits. Community toolkits covers using one.

Not sure where to start? Launch with Efficient Builder, and pick a Community toolkit for a launch when the work calls for it. Make your own toolkits once you notice the same tools missing, or tools you never use getting in the way.

Give each project its own toolkit

Why: if you work on more than one project, picking a toolkit every launch gets old, and it’s easy to open the bakery website with your app-building tools by mistake.

How: set each project’s Default toolkit once. From then on, opening that project starts a session with its own tools. You can still pick a different toolkit for a single launch.

Each project opens with its own toolkit

• Project

  bakery-website

  Default toolkit

  Bakery site

  • CopywritingSkill
  • SEO fundamentalsSkill
  • FigmaMCP

• Project

  gym-booking-app

  Default toolkit

  Gym app

  • ExpoMCP
  • Expo RouterSkill
  • SupabaseMCP

SkillMCP server

Open either project and its own toolkit comes with it. No picking needed.

Share common tools with a base toolkit

Why: some tools belong in every toolkit, like GitHub and Context7. Without a base, you add them to each toolkit by hand, and when you change one, you have to change them all.

How: put those tools in one toolkit, such as Base. Then open each of your other toolkits and, on its Contents, choose Add toolkit and pick Base. Each toolkit stays small, and a change to Base reaches every toolkit that includes it. From a terminal, csc toolkit set --toolkit <toolkit> --include Base does the same.

Shared toolkit

Base

• GitHubMCP
• Context7MCP

• Backend

  includes Base

  • SupabaseMCP

• UI polish

  includes Base

  • shadcn/uiSkill
  • Chrome DevToolsMCP

• Release

  includes Base

  • Deploy to VercelSkill
  • Page speedSkill

Change Base once, and every toolkit that includes it gets the change.

Tip

Name toolkits after the work, not the tools: Checkout redesign tells you when to use it; Supabase + shadcn doesn’t.

How a launch picks a toolkit

You never have to pick. When you don’t, Code Config works down this list and uses the first one it finds:

1. The toolkit you chose for this launch.
2. The project’s Default toolkit.
3. Your workspace default, which starts out as Efficient Builder.

Toolkit selection order shows where to change each one.

When to split a toolkit

A toolkit has grown too big when you notice any of these:

• The agent uses a tool that has nothing to do with what you asked.
• You scroll past tools you haven’t used in weeks.
• Sessions ask you to set up keys for MCP servers you don’t need today.

Split it into two smaller toolkits, or remove what you don’t use. Removing a tool from a toolkit doesn’t delete it; you can add it back from Tool Builder whenever you need it.

What a toolkit contains

A toolkit is a saved list of tools. Each tool comes from a GitHub repository; Code Config keeps track of which tools you picked and writes them into your coding app’s own settings when you launch.

A toolkit can hold skills, agents, commands, rules, context files, output styles, workflows, MCP servers, hook bundles, and plugins, plus supported settings for Claude Code and Codex. Not every coding app can use every kind; check a tool’s Works with result and the coding-app guide.

Changes you make to a toolkit apply the next time you launch. An app that is already running keeps the tools it started with.

Next

Create and manage toolkits.