agentleFS
MakiDevelopMakiDevelop/claude-skills/skills/vendor-eval/SKILL.md

vendor-eval

Skill3 starsChanged 8 months agoMITView on GitHub

Vendor proposal evaluation. Analyze technical architecture, pricing, and market benchmarks from a proposal PDF/Doc. Output evaluation report + comparison.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 10 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read a vendor proposal document and produce a comprehensive evaluation report with negotiation toolkit.

    line 17
  2. Distinctive:

    If missing the proposal file, ask user.

    line 42
  3. Distinctive:

    Confirm scope: if user specified (e.g., "OCR only"), focus only on that scope from here.

    line 67
  4. Distinctive:

    Use WebSearch to research:

    line 111
  5. Distinctive:

    If WebSearch is unavailable, note the gaps and suggest the user research them manually.

    line 116
  6. Distinctive:

    After collecting all data, synthesize into:

    line 120
  7. Distinctive:

    If user specified "exclude certain competitors":

    line 167
  8. Distinctive:

    Don't recommend that competitor as alternative

    line 169
  9. Distinctive:

    Don't cite their pricing in market comparisons

    line 170
  10. Distinctive:

    Use a sensitivity range for ROI.

    line 211

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/vendor-eval — Vendor Proposal Evaluation

Read a vendor proposal document and produce a comprehensive evaluation report with negotiation toolkit.

Output

  1. Markdown report — Full evaluation (tech analysis + pricing breakdown + risk matrix + negotiation strategy)
  2. Comparison table — Alternative solutions + PoC acceptance criteria + negotiation priorities

Not Applicable When

  • Vendor gave only a verbal quote, no written proposal → ask for written document first
  • Pure price comparison with no technical content → just use a spreadsheet
  • Involves confidential internal pricing strategy → handle offline

Input

From $ARGUMENTS or conversation:

FieldRequiredDescription
Proposal fileYesPDF path, or document URL
Evaluation scopeNoDefault: all. Can limit to e.g., "OCR module only"
Excluded competitorsNoe.g., "CompanyX is our competitor, don't mention in report"
Audience / purposeNoAffects report tone, e.g., "for exec negotiation" vs "internal tech review"
Industry contextNoClient's industry, size, IT maturity (helps judge solution fit)

If missing the proposal file, ask user.

Decision Model

Phase 0: Read Proposal (Pre-flight)

  1. Identify file type:
    • Local PDF → Read tool
    • URL → WebFetch to download then read
  2. Extract key info, build a proposal summary card:
## Proposal Summary Card
- Vendor name: {name or "not specified"}
- Client: {client name}
- Module count: {N}
- Modules and pricing: {list}
- First-year total: {amount}
- Usage limits and overage fees: {list}
- Reference customers: {list}
- Timeline: {N weeks}
- Security/compliance terms: {yes/no}
  1. Confirm scope: if user specified (e.g., "OCR only"), focus only on that scope from here.

Phase 1: Technical Architecture Analysis

Analyze each module:

Analysis ItemContent
Architecture assessmentReasonable / Over-engineered / Insufficient
Underlying tech inferenceWhich APIs / services / frameworks are likely used
Technical risksSingle points of failure, vendor lock-in, maintenance difficulty
NecessityIs this module essential for the client's pain point?
AlternativesAre there simpler or more mature alternatives?

Pay special attention to:

  • Dual/multi-engine designs → is it technically necessary or just marketing?
  • ERP/CRM integration → confirm scope boundaries and cost ownership
  • AI/ML claims → distinguish "uses API" vs "proprietary model"
  • Security terms → distinguish "cloud-native built-in" vs "vendor-developed"

Phase 2: Pricing Analysis

Conduct market benchmark comparison:

  1. Each module's pricing vs market rates (provide market range)
  2. Overage fees vs underlying API costs (calculate markup multiplier)
  3. ROI verification — deconstruct vendor-claimed benefits, provide realistic estimates
  4. Three-year TCO projection

ROI Deconstruction Framework:

ItemVendor ClaimsRealistic EstimateDiscrepancy Reason
Annual labor savings{vendor number}{adjusted number}{inflation point}
First-year ROI{vendor %}{adjusted %}{calculation gap}
Payback period{vendor months}{adjusted months}

Common inflation patterns:

  • "Saves N hours of labor" ≠ direct salary savings (efficiency gain ≠ headcount reduction)
  • Vendor automation percentages require a workload definition, baseline, exception rate and measured human-review effort; do not substitute an invented industry average.
  • ROI counts only benefits, ignores hidden costs (training, process change, exception handling)

Phase 3: Market Intelligence

Use WebSearch to research:

  • Vendor background: funding, team size, key clients, technical credibility
  • Reference customer verification: do these companies publicly cite this vendor?
  • Alternative vendors: at least 3-4 alternatives with pricing and features

If WebSearch is unavailable, note the gaps and suggest the user research them manually.

Phase 4: Integrated Analysis

After collecting all data, synthesize into:

  1. Risk Matrix (Critical / High / Medium)
  2. Alternative Solutions Comparison (at least 3 options)
  3. Negotiation Strategy (priority order + talking points)
  4. Recommended Path (suggested decision path with fallback)

Risk Classification:

LevelCriteria
CriticalCould cause project failure, must resolve before signing
HighWill increase cost or risk by 30%+, should constrain in contract
MediumMonitor, have a backup plan

Phase 5: Output

5a: Evaluation Report (Markdown)

Structure:

Title: {Client} {Module Type} Evaluation Report
Executive Summary (one-line conclusion + recommended action)
Chapter 1: Proposal Summary (factual, no judgment)
Chapter 2: Technical Architecture Analysis
Chapter 3: Pricing Analysis
Chapter 4: Market Intelligence & Vendor Verification
Chapter 5: Risk Matrix
Chapter 6: Alternative Solutions Comparison
Chapter 7: Financial Model (adjusted ROI + 3-year TCO)
Chapter 8: Negotiation Strategy
Appendix (methodology, data sources, disclaimers)

5b: Comparison & Negotiation Sheet (Markdown tables)

Table 1: Solution Comparison | Comparison Item | Option A | Option B | Option C | Recommendation | Notes |

Table 2: PoC Acceptance Criteria | Acceptance Item | Pass Criteria | Test Method | Notes |

Table 3: Negotiation Priorities | Priority | Negotiation Item | Target | Talking Point / Rationale |

Competitor Exclusion Handling

If user specified "exclude certain competitors":

  1. Don't recommend that competitor as alternative
  2. Don't cite their pricing in market comparisons
  3. Scan full report to remove all mentions
  4. Note the exclusion in the report's methodology section

Quality Gates

  • Proposal summary card is complete
  • Every module has "assessment + risk + alternative"
  • ROI is deconstructed, not copied from vendor
  • Overage fees have underlying cost and markup calculated
  • Reference customers verified (public case study exists? yes/no)
  • Risk matrix has Critical / High / Medium classification
  • At least 3 alternatives with first-year cost estimates
  • Negotiation strategy has priority order + specific talking points
  • Report contains no excluded competitor names

Heuristics

Common Red Flags

  • Reference customers lack public case studies → mark unverified and request references or a PoC; absence of public evidence is not proof of a false claim.
  • Dual/multi-engine architecture → request measured accuracy, availability, latency and cost evidence for the additional engine.
  • Overage fee markup >10x underlying cost → vendor's real profit pool, must negotiate
  • First-year ROI claims → verify benefits, denominator, time horizon and all costs; a high percentage alone does not prove inflation.
  • "Proprietary AI" → request architecture, ownership and model evidence; headcount alone cannot establish whether a model is proprietary.
  • Security terms are just buzzword lists → probably cloud-native built-in, not vendor-developed
  • ERP integration "included in quote" → confirm which ERPs, how many, cost ownership

Negotiation Principles

  1. PoC before pricing — for vendors with unproven track record, PoC is the strongest weapon
  2. Negotiate per module — module-by-module beats whole-package discount
  3. Overage fees matter more than annual fees — 10% off annual saves thousands; wrong overage structure costs tens of thousands long-term
  4. IP ownership matters more than price — can't take anything with you when you leave = permanent lock-in
  5. Show alternatives — naming specific alternative vendors shows you have options

Evidence boundaries

Separate vendor statements, independently verified facts, scenario assumptions and hypotheses. Link primary pricing sources with currency, date and billing units. Never guess underlying services, margins or competitor prices as facts. Use a sensitivity range for ROI; no fabricated market average. Do not upload a confidential proposal to another service or delegate its contents externally without user authorization. Unavailable evidence remains explicitly unverified.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.