本文へ移動
cccskills
無料GitHub で公開

codexkit-vendor-comparison-matrix

Build structured vendor/tool evaluation matrices with weighted scoring, TCO analysis, and recommendation memos. Covers criteria definition, deal-breaker identification, and negotiation points. Use when selecting SaaS tools, evaluating technology vendors, or making build-vs-buy decisions.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md5.2 KB
  • agents/openai.yaml176 B

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Vendor Comparison Matrix

When to Use

  • When evaluating 2+ vendors or tools for a purchase decision
  • When building a business case for tool selection
  • When leadership requires a structured evaluation for procurement
  • When comparing build-vs-buy options

Procedure

Step 1 — Requirements Gathering

Categorize requirements:

CategoryRequirementPriority (Must/Should/Nice)
Functional[What it must do]Must
Integration[What it connects to]Should
Security[Compliance needs]Must
Performance[Speed, scale]Should
Support[SLA, response time]Nice

Identify deal-breakers — any Must requirement not met eliminates the vendor.

Step 2 — Weight Criteria

Assign weights that sum to 100:

CategoryWeightJustification
Functionality30Core use case
Integration20Must connect to existing stack
Security & Compliance20Regulated industry
Pricing / TCO15Budget constrained
Vendor viability10Long-term relationship
UX / Adoption5Ease of rollout

Step 3 — Score Vendors

Score each vendor 1–5 per criterion:

Criterion (Weight)Vendor AVendor BVendor C
Feature set (30)4 → 1205 → 1503 → 90
Integration (20)5 → 1003 → 604 → 80
Security (20)4 → 804 → 805 → 100
Pricing (15)3 → 452 → 305 → 75
Viability (10)5 → 504 → 402 → 20
UX (5)4 → 205 → 253 → 15
Weighted Total415385380

Step 4 — TCO Analysis

Calculate Total Cost of Ownership over 3 years:

Cost ComponentVendor AVendor BVendor C
License / subscription$X$Y$Z
Implementation / migration.........
Training & change management.........
Ongoing support / maintenance.........
Integration development.........
Opportunity cost of downtime.........
3-Year TCO$XX$YY$ZZ

Step 5 — Risk Assessment

VendorRiskLikelihoodImpactMitigation
AVendor acquisitionLowHighContractual exit clause
BPoor integrationMediumMediumPOC before commit

Step 6 — Recommendation Memo

Write a concise memo:

  1. Recommendation: Vendor A
  2. Rationale: Highest weighted score, best integration, acceptable TCO
  3. Trade-offs accepted: Higher price than C, less feature-rich than B
  4. Next steps: Negotiate contract, run POC, plan migration

Inputs

InputRequiredFormat
Vendors to evaluateYesList of options
RequirementsYesFunctional and non-functional
BudgetRecommendedAnnual or 3-year
Evaluation teamRecommendedWho scores and decides

Output

## Vendor Evaluation — [Category]

### Recommendation: Vendor A (Score: 415/500)

### Weighted Comparison
[Scoring matrix table]

### TCO (3-Year)
[Cost breakdown table]

### Risk Assessment
[Risk table per vendor]

### Negotiation Points
- Request 15% volume discount based on 3-year commitment
- Include SLA with penalties for >99.9% uptime
- Require data portability clause

Definition of Done

  • Requirements categorized with priorities
  • Weights assigned and justified
  • All vendors scored consistently
  • TCO calculated over 3+ years
  • Risks identified with mitigations
  • Clear recommendation with rationale

Quality Criteria

  • Data sources and assumptions are explicitly stated
  • Calculations are reproducible from provided inputs
  • Visualizations or tables have clear labels, units, and time ranges
  • Caveats and confidence levels are documented for estimates

Verification (4C)

CheckQuestion
CorrectnessAre formulas, aggregations, and statistical methods applied correctly?
CompletenessDoes the analysis cover all requested metrics and time ranges?
Context-fitAre the chosen metrics relevant to the business question being answered?
ConsequenceIf this data were used for a decision today, what blind spots remain?

Edge Cases

  • Missing or incomplete data — Document gaps and their potential impact on conclusions. Provide ranges instead of point estimates.
  • Outliers skewing results — Report with and without outliers. Document the decision to include or exclude.
  • Changing data definitions mid-period — Split analysis at the change boundary and note the schema difference.

Changelog

  • v1.0.0 — Initial release

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Design rigorous A/B test plans with hypothesis, sample size calculation, Minimum Detectable Effect (MDE), randomization strategy, and decision rules. Includes guardrail metrics and rollout playbook. Use when planning product experiments, conversion optimization, or data-driven feature decisions.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

Review REST and GraphQL API designs for consistency, usability, and best practices. Covers naming conventions, versioning strategy, error format, pagination, authentication patterns, and breaking change detection. Use when reviewing API specs, designing new APIs, or auditing existing endpoints.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

Write Architecture Decision Records (ADRs) following the Michael Nygard format. Captures context, options considered, decision rationale, and consequences. Use when making technology choices, framework selections, or any architectural decision that future developers need to understand.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

Assess organizational readiness for financial audits (internal or external). Map assertions to account balances, check evidence completeness, score readiness using a Red/Amber/Green framework, and generate a remediation timeline. Aligned with SOX, IFRS, and GAAP audit standards. Use before scheduled audits or when preparing for first-time compliance.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

Design safe recurring Codex automations with clear prompts, outputs, schedules, and gating rules.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

Refine Product Backlog Items to meet INVEST criteria. Write User Stories with Acceptance Criteria in Given/When/Then format, estimate with Story Points, and flag dependencies. Use before sprint planning when backlog items need grooming. Do not use to prioritize the backlog — that is the Product Owner's decision.

日本語の概要は準備中です。原文の説明を表示しています。

hoavdc/CodexKit252026年10月8日 更新

hoavdc のスキルをすべて見る

このスキルの問題を報告する