Evaluate a new tool before it joins the stack — the problem-first framing (tools answer needs, not demos), the trial designed with success criteria upfront, the stack-fit check (integration, overlap, the tool-sprawl tax), and the security/data review sized to the stakes. Use when asked should we buy this tool, evaluate this software for the team, we have three tools that do this already, or run a proper trial before committing. Produces the need statement, the trial design with pre-set criteria, the stack-fit audit, and the adopt/decline verdict with its reasoning.
Start a fresh conversation. Replace the highlighted placeholders.
Use tool-procurement-eval to evaluate [candidate tool and vendor] for [problem, current stack, and data it would touch], with [trial participants], and deliver a need statement, stack-fit audit, pre-defined trial criteria, security gate, and adopt-or-decline recommendation without purchasing or starting a trial.
Required inputs
[candidate tool and vendor]
[problem, current stack, and data it would touch]
[trial participants]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: tool-procurement-evaldescription: "Evaluate a new tool before it joins the stack — the problem-first framing (tools answer needs, not demos), the trial designed with success criteria upfront, the stack-fit check (integration, overlap, the tool-sprawl tax), and the security/data review sized to the stakes. Use when asked should we buy this tool, evaluate this software for the team, we have three tools that do this already, or run a proper trial before committing. Produces the need statement, the trial design with pre-set criteria, the stack-fit audit, and the adopt/decline verdict with its reasoning."
Tool Procurement Eval Skill
Tools enter stacks backwards: someone sees a demo, gets excited, and the "evaluation" becomes a justification ritual (vendor-comparison-matrix fights this at the compare stage; this skill fights it at the door). The forward order: the need stated first (which problem, whose, costing what — purchase-justification arithmetic), the stack-fit check before the trial (does something we own already do this? — the overlap audit that kills half of tool requests honestly), the trial designed with success criteria written before day one (or the trial's warm feelings decide), and the security/data review sized to what the tool touches — because the fun tool that ingests customer data is a compliance decision wearing a productivity costume.
What This Skill Produces
The need statement — the problem, its owner, its cost, and the requirements it implies (must vs. nice — pre-demo)
The stack-fit audit — the overlap check against owned tools, the integration reality, and the sprawl tax named
The trial design — duration, participants, the pre-written success criteria, and the decision date
The verdict — adopt (with owner and rollout) / decline (with the reason logged) — plus the security-review gate where data warrants
Required Inputs
Ask for these if not provided:
The problem, not the tool — what's broken/slow/manual today, for whom, costing what; "I saw this cool tool" gets reverse-engineered into its implied need, which sometimes evaporates on contact
The current stack — what's owned that's adjacent (the overlap audit needs the inventory — contract-renewal-tracker's list is the source); most orgs own 30% more capability than they use
What the tool would touch — customer data? Credentials? Just public content? The security review's depth follows (skill-vetting blast-radius thinking, applied to SaaS)
The trial population — who'd actually test it (the enthusiast and a skeptic — enthusiast-only trials always pass)
Framework: The Eval Rules
Need before tool: the statement — problem, owner, frequency, cost of the status quo — written before any vendor contact; requirements derive from it (must-haves gate, nice-to-haves score). Tools without a need statement are solutions shopping for problems on your budget.
The overlap audit runs early and honestly: does an owned tool cover 80% of the need? (The honest answer kills the request — cheaply and correctly.) Half-used owned tools get their config/training gap named instead ("we own this in Notion; nobody set it up") — the sprawl tax (another login, another admin, another renewal row, another data silo) is a real cost the shiny demo never quotes.
Trials have pre-written criteria and a skeptic: "success = the team's weekly report time drops below 2 hours, and 4 of 6 pilots choose to keep it" — written before day one (survey-design-basics pre-commitment), tested with the enthusiast and the skeptic (the enthusiast finds the ceiling; the skeptic finds the floor), timeboxed with a decision date. Trials without criteria are extended demos that always end in purchase.
The security gate scales to the data: public-content tools get the light pass (vendor's security page, the data-processing basics); anything touching customer data, credentials, or internal documents gets the real review (where's the data stored, who can access, the deletion story, the tos-decoder read of their terms) — before the trial pipes real data in, not after. "It's just a trial" is how customer data ends up in un-reviewed vendors.
The verdict gets logged either way: adopt → owner named, rollout planned, the renewal row created at signature ([the intake rule]) · decline → the reason in the decision-log ("evaluated [tool] July 2026 — declined: 80% covered by owned stack") — because the same tool returns with a new champion every eighteen months, and the log converts the rematch into a lookup.