AI news · Tools

Claude Code Setup tested:
a good checklist, not setup automation.

DE Auf Deutsch lesen

September 17, 2026 · Reading time approx. 7 min

Anthropic ships a plugin that reads a codebase and suggests matching hooks, skills, MCP servers, and subagents. I tried it on two very different projects: SkillDiff, a TypeScript monorepo with a CLI, a Fastify backend, and a React frontend, and PlantWiz, a Vue PWA with MySQL, Keycloak, Stripe, Sentry, and Playwright. The value is in the first map of the territory. The plugin does not do the setup work for you.

Transparency note: Tested was claude-code-setup from the official Anthropic marketplace, version 1.0.0. By its own description, the skill is read-only. It is not meant to change project files. This assessment is based on the installed skill instructions and the two real repository configurations.

What the plugin actually does

The idea is sound: instead of recommending every Claude Code extension across the board, the skill looks for frameworks, test tools, databases, existing MCP configurations, and CI. From that it builds one or two suggestions per category. Its categories are MCP servers, skills, hooks, subagents, and plugins. The result is a report, not a generator for configuration files.

That's an important boundary. Anyone reading "setup" and expecting a finished .claude/settings.json to land in the project afterward gets something different: a priority list that still needs a review against the actual project.

Test 1: SkillDiff

SkillDiff separates a contract layer, a CLI, a backend, and a frontend. There's TypeScript, Vitest, GitHub Actions, and an already deliberately small .claude/settings.json: two hooks track SkillDiff's own workflow. Conventions are documented at length in CLAUDE.md, and specialized builder, reviewer, and tester agents already live in the repository.

Hits

Context7 for up-to-date library docs fits Fastify, Zod, React, and Vite. A pr-check workflow is also sensible, provided it respects package dependencies: build the schema first, then check the affected package. That matches the existing CI.

Too generic

An automatic type check or full test run after every edit would be miscalibrated here. Four packages and file dependencies make the hook slow and noisy. A suggestion should also recognize the existing telemetry hooks and not silently replace them.

For SkillDiff, what's left is a short list: Context7, a deliberately narrow /test-affected command, and possibly protection for actual secret files. This project doesn't need another generalist agent; its three roles already exist.

Test 2: PlantWiz

PlantWiz gives the skill more signal: Vue 3, Vite, and Pinia on the frontend; Express and MySQL on the backend; Keycloak, Stripe, and Sentry; its own Playwright suite; Docker Compose; already-configured GitHub and MySQL MCP servers. This is exactly the kind of project where a configuration advisor can be useful.

Hits

Playwright makes sense, since end-to-end tests already exist. A security reviewer would have a concrete brief: check authentication, garden roles, Stripe webhooks, and secret handling. An API documentation workflow fits the Express routes and the existing API.md.

What needs checking first

GitHub and MySQL MCP already exist. Recommending them again would just be duplication. A database MCP also must not default to write access. For this project, another server for Sentry is conceivable, but only once error analysis is actually meant to run through Claude regularly.

PlantWiz also has hooks that remind about keeping API.md and DATABASE.md in sync after changes to routes or the SQL dump. That's precisely targeted. A plugin should treat such rules as an existing decision, not a gap.

The test had a real limit

The headless Claude Code invocation didn't produce the final report for PlantWiz. This installation of Claude hasn't marked the repository as trusted yet. Claude therefore ignores local permissions and ends the run with a pointer to the trust dialog. That's not a weakness of the recommendation skill, but a relevant part of using it in practice: its analysis runs inside Claude Code's security and trust rules.

Important side finding: A trust decision should never be made just so an analysis skill can run. Hooks and MCP servers can trigger commands or access later on. So their permissions belong in the review, even when the recommendation skill itself only reads.

Assessment

CriterionVerdictWhy
Starting pointgoodThe categories cover the usual levers and force a short priority list.
Context fidelitymediumFrameworks and test tools are recognized well. Automation that already exists needs a second, human check.
SecuritymediumThe skill itself is read-only; effective suggestions like database MCP or hooks can still end up with far-reaching rights later.
Implementation valuegood, if someone curatesThe report saves research time. Selection, permissions, and maintenance stay project work.

My assessment: 7 out of 10 as a first walkthrough of a new repository. For small projects, you can act on most suggestions directly. For grown projects, the skill works more as a conversation starter with the existing configuration. That's not nothing, but it's something different from automatic setup.

How I'd work with it

  1. Generate the report and cap every category at two suggestions at most.
  2. Lay it next to the existing .claude and .mcp.json files.
  3. Only adopt automation whose run frequency, runtime, and permissions are clear.
  4. Review hooks and MCP servers like any normal code change, not as a convenience setting.

That's exactly where the plugin is strongest: it turns "what can Claude Code even do?" into a manageable list. Responsibility for the configuration stays with the team.

Setting up Claude Code for your team?

I help development teams choose skills, MCP servers, and hooks, and check permissions and maintenance overhead along the way.

Robin.Steltmann@googlemail.com