Companies have moved past the “should we use AI” conversations. Everyone has a workflow, a few go-to skills, a tool they’ve built or borrowed.
You’ve probably seen some version of this on your own team: two people, working separately, build the same tool for the same problem. Neither knows the other is doing it. Both are ok, both have different features and are custom to just the one user. It’s like having multiple cooks working on the same recipe, yes all have a little difference, but no one needs that much potato salad.
Getting real efficiency out of AI means treating it like any other process on your team. When everyone knows what everyone else is working on, and does their part well, less time gets spent solving problems that already have a solution. And your team’s handoffs get cleaner too so your stakeholders don’t waste time deciphering multiple different versions of the same item from different members of your team.
Fixing it takes someone coordinating what’s being built across the team, and being intentional about who’s working on what instead of letting it happen by accident.
Path One: Consolidation
If your team has already been experimenting, you likely have an army of AI tools built independently, and some redundancy. The easiest starting point is coordinating what already exists. Have your team run a quick show-and-tell of what they’ve built.
Once you can see the full picture, look for the overlaps. Assign someone to pull the strongest features from each version into one tool that works for the whole team, instead of everyone maintaining their own. Take the five separate kitchens and combine the best parts of each recipe into the one the whole team cooks from.
The payoff here is depth. Multiple people already worked out multiple ways to solve the same problem. The final tool benefits from all of it, instead of any one person’s first attempt.
Path Two: Division
This path requires coordinating before anything new gets built. Catalog what your team needs, then assign each build to one person or a small group. Only that person spends the time developing the tool. Everyone else applies it to their own workflow and helps refine it as they go. One kitchen perfects the dish, and the rest of the team just uses it.
The payoff here is coverage. Instead of one problem solved multiple times, you get multiple problems solved at once, each one improving as the team uses it.
Getting Started
Depth and coverage aren’t strict either/or. Blend them based on what the task needs, how urgent it is, how sensitive it is. Maybe a few people go deep on one thing while others divide up the rest. The exact mix matters less than making that choice on purpose instead of by accident.
AI is a part of business now. The conversation needs to grow to being deliberate about where and how it gets applied to actual roles.
Compare Two AI Builds — Prompt
Paste this into a new conversation when two people have each built a Claude Skill, Custom GPT, or similar tool meant to do the same job, and you want to decide what to keep, merge, or retire.
You’re going to help me compare two AI builds — Claude Skills, Custom GPTs, or similar — that were built by different people to accomplish the same goal, so I can decide what to keep, merge, or retire.
Before doing anything else, ask me for the following, and wait until you have all of it before proceeding:
- The shared goal both builds are meant to accomplish (one sentence).
- Build A — ask me to attach the file(s) for this build (e.g., its SKILL.md, an exported Custom GPT configuration, or a doc/screenshot of its instructions and settings), and tell you which platform it’s from (Claude Skill / Custom GPT / other).
- Build B — same: attached file(s) plus platform.
- The target platform for the merged version, if there is one (Claude Skill / Custom GPT / undecided).
Once you have all four, read the attached files fully and evaluate both builds across these dimensions. For each, name a winner (A / B / tie) and justify it in one or two sentences — make a call, don’t just describe both:
- Goal fit — does each actually solve the stated goal, or has it drifted into solving something adjacent?
- Activation/discoverability — how reliably does it trigger or get invoked on the right request, and how would a user know to reach for it?
- Instruction quality — are the steps/logic unambiguous and correctly ordered? Would two different runs produce consistent output?
- Guardrails — banned behaviors, tone/voice rules, compliance boundaries. Which set is tighter or catches more real failure modes?
- Knowledge/context inputs — quality, specificity, and currency of any reference material, examples, or files each relies on.
- Capability usage — for a GPT: are its enabled tools (actions, browsing, code interpreter) actually necessary and well-used, or bolted on? For a Skill: is it using the right level of structure (steps vs. bundled scripts/resources) for the job?
- Output spec — how clearly does it define what “done” looks like (format, length, structure)?
- Edge-case coverage — what does one handle that the other misses entirely?
- Maintainability — since someone other than the original builder may own this going forward, how easy would it be for a third person to read this and update it correctly?
- Redundancy — unnecessary steps, verbose instructions, or scope creep that adds no accuracy.
Then:
- Flag any direct CONTRADICTIONS between the two (e.g., A always does X, B never does X). List them — don’t silently resolve these, tell me I need to decide.
- If the two builds are on different platforms, flag anything that doesn’t survive the move to the target platform (e.g., a GPT Action with no Skill equivalent, or a Skill’s bundled script with no GPT equivalent) so nothing gets promised that can’t actually be built.
- Give a final recommendation: keep A, keep B, or merge. If merge, give a proposed outline for the single resulting version in the target platform’s structure, noting which section should come from which source.
- Call out anything either build does that’s genuinely novel and worth preserving even if that build loses overall.
