Q02 · EXTENSION COST · WORKFLOW 001

What does tool sprawl cost project continuity?

Ask whether a model, skill, MCP server, or plugin changes the result—or mainly adds setup, permission, switching, and breakage.

Question · first editionLast checked · 2026-08-15

Current decision

Current choice

Keep each extension in one state: primary, time-boxed trial, or remove. No observable result, no place in the main workflow.

Open the reasoning

The more flexible a tool becomes, the more deliberately its role boundaries must be maintained. Otherwise every new project, client, or upgrade reopens installation, permission, compatibility, and usage questions.

Q02 / DECISION MAPTRIGGER → STATES → ONE ACTION

This is not an installation inventory. It shows the order for deciding what stays; primary, trial, and removal conditions still need real-project evidence.

THREE STATES

Three real options

The choice is not simply installed or uninstalled.

Open the comparison boundary

A clear state and review date keep “might be useful later” from occupying the primary path forever.

01Primary pathOpen conditions

Best when: It is repeatedly used in recent real projects, with known failure modes and replacement cost.
Cost to carry: Permission, compatibility, and output quality still need review as the tool changes.
Switch when: Two consecutive projects do not use it, or a simpler built-in path produces the same result.

02Time-boxed trialOpen conditions

Best when: It addresses a named gap and can be compared safely with demo material.
Cost to carry: Success, time limit, and cleanup need to be written before the trial.
Switch when: The time limit passes without an outcome change, or permission and maintenance exceed the limit.

03Remove or archiveOpen conditions

Best when: Its role is duplicated, rarely used, poorly sourced, or too permissive.
Cost to carry: Occasional convenience may disappear, so keep only what is needed to reinstall.
Switch when: A new real task appears and existing paths cannot complete it at an acceptable cost.

MY CURRENT PRACTICE

Why this choice

Keep the primary workflow small. Let the trial area be broad only within a boundary.

Open experience and reasoning

I once treated model switching, plugin count, and skill coverage as flexibility. They do expand capability, but use traces do not establish that every extension improved project delivery.

Now I ask whether an extension changed a real outcome and whether, days later, I still know why it is there. The primary path keeps only frequent, explainable capability with known failure modes.

What can be confirmedOpen record

Real traces of multi-tool and extension use exist. The public page does not expose installed versions, permissions, or the internal toolchain.

What remains unknownOpen record

Net time saved, conflict frequency, and long-term maintenance cost have not yet been systematically recorded.

THE NEXT TIME YOU ADD AN EXTENSION

What to do next

Give it a seven-day trial, not a permanent place.

Nothing needs to be removed immediately. Start with the capability no one can clearly explain.

01
List the models, skills, MCP servers, and plugins actually enabled in the primary tool.
02
For each one, name the last real use and the outcome it changed.
03
Move anything without recent use or outcome evidence into a seven-day trial.
04
If no real task needs it during that period, keep reinstall notes and remove it.

Continue or stop

Once the extension load is visible, project recovery cost can be measured.

The next question separates opening an old session from recovering the correct project context.

Continue to Q03 · Project re-entry