Name: workbench
Author: eigenwise

🧰 eigenwise-toolshed

A small, growing marketplace of Claude Code plugins by Eigenwise.

Sharp little tools for Claude Code, kept in one shed. 🛠️

Plugins

Plugin	What it does
workbench	The one user-scope install for workspace setup, Toolshed updates, health checks, retrospectives, and the freshness guard. Use `/init-workspace`, `/update-toolshed`, `/workbench-doctor`, and `/retro`.
codebase-mapper	Keeps a small, self-updating map of your codebase and loads it into every Claude session, so Claude already knows how your project is built when you start working.
live-rules	Inject your own rules into Claude's context the moment they apply: global rules on every prompt, file-type and directory rules right before an edit, keyword rules when your prompt matches. Edit a rule, it applies on the next prompt.
sidequest	A Trello-light quest log for Claude Code. Side issues you mention mid-task get captured as tickets on the spot, with pasted images attached, then managed on a live, self-hosted Kanban dashboard spanning every project you work in. Category-based routing picks a concrete model and reasoning effort per ticket, with category and global fallbacks.

More tools will move into the shed over time.

Install

/plugin marketplace add Eigenwise/eigenwise-toolshed
/plugin install workbench@eigenwise-toolshed --scope user
/plugin install codebase-mapper@eigenwise-toolshed
/plugin install live-rules@eigenwise-toolshed
/plugin install sidequest@eigenwise-toolshed

Then run /reload-plugins (or restart Claude Code) and you're set. It's a public marketplace, so there's no auth to deal with.

Quickest start: install workbench at user scope, reload, then in any project ask "set up a Claude workspace here". Workbench owns setup, updates, health, retrospectives, and the freshness guard.

Why workbench?

Workbench owns the workspace lifecycle in one user-scope install. It sets up project-side configuration, updates Toolshed plugins, checks local health, runs retrospectives, and covers freshness checks.

Why codebase-mapper?

On any non-trivial repo, a fresh Claude session starts blind. It greps for the architecture, hunts down the entry points, and re-learns your conventions before it can do anything useful, then starts from scratch again the next session. codebase-mapper does that work once and keeps it:

It writes a set of small, atomic Markdown docs under .claude/.codebase-info/ (architecture, modules, entry points, patterns, dependencies, and so on).
A bundled UserPromptSubmit hook re-injects the map on every prompt, so it stays in context deep into a long session and Claude keeps consulting and updating it as you work.
A companion skill refreshes only the docs your changes actually touch, so the map stays current.
It works on any language or stack, and on both new and existing projects.

Two skills run it: map-codebase builds the map and update-codebase-map refreshes it. The plugin README has the full details.

Why live-rules?

CLAUDE.md is a static, always-on brief. But a lot of guidance is conditional: a React rule only matters when you touch a .tsx file, a deploy checklist only matters when you deploy. Put it all in CLAUDE.md and it is either permanently in your context or quietly buried. live-rules fixes that: