Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Developer platform tool stack evaluator

Evaluates and compares tooling options for internal developer platforms across six categories — source control, CI/CD, container orchestration, secrets management, observability, and service catalogs — producing a…

download .md

Purpose

Produce a defensible, weighted evaluation of internal developer platform tooling across six categories — turning a subjective vendor debate into a scored decision with clear tradeoffs, integration risk, and a sequenced adoption path. Solves the problem of platform teams making high-lock-in tooling choices without a consistent evaluation framework or leadership-ready justification.

When to Use

Invoke this skill when the user asks to:

  • Select or shortlist tooling for a new internal developer platform (IDP)
  • Compare specific vendors or open-source options within a category (e.g., Argo CD vs. Flux, Vault vs. cloud-native secrets)
  • Consolidate a sprawling tool stack down to a rationalized set
  • Justify a build-vs-buy or replace-vs-keep decision to a CTO or architecture review board
  • Assess integration risk before committing to a platform tool with high switching cost
  • Build a weighted scoring matrix to defend a tooling decision

Inputs Required

Before starting, collect:

  • Categories in scope: Which of the six categories to evaluate (source control, CI/CD, container orchestration, secrets management, observability, service catalogs), or all
  • Candidate tools: Named options per category to compare; if none given, the skill proposes a standard shortlist
  • Environment constraints: Cloud provider(s), on-prem/hybrid needs, Kubernetes vs. VM/serverless, existing tools that must stay
  • Team scale: Number of engineers, number of services/repos, platform team size
  • Priorities: Ranked drivers — cost, security/compliance, developer experience, operational burden, lock-in avoidance, scalability
  • Compliance requirements: SOC 2, FedRAMP, HIPAA, air-gapped, data residency, or none
  • Budget posture: Preference for open-source/self-hosted, managed SaaS, or mixed

If priorities are not ranked, default the weighting to Developer Experience 25%, Operational Burden 20%, Security/Compliance 20%, Cost 15%, Scalability 10%, Lock-in Avoidance 10%, and state the assumption.

Instructions

Step 1: Confirm Scope and Establish Scoring Weights

Lock the evaluation criteria before scoring anything.

  • Confirm the categories in scope and candidate tools per category.
  • Establish six weighted criteria totaling 100%: Developer Experience, Operational Burden (setup + ongoing maintenance), Security/Compliance, Cost (licensing + infrastructure + labor), Scalability, Lock-in Avoidance.
  • Adjust weights based on stated priorities (e.g., a FedRAMP requirement pushes Security/Compliance to 30%+).
  • Restate the final weights so the buyer can see how the scoring is calibrated to their context.

Step 2: Score Each Candidate Per Category (1–5 Scale)

For every candidate tool, score each of the six criteria on a 1–5 scale with a one-line justification per score. Anchor the scale:

  • 5 = clear category leader for this criterion in the buyer's context
  • 3 = adequate, no major concerns
  • 1 = significant gap or risk

Apply category-specific evaluation lenses:

Source Control

  • Branching/merge model support, monorepo scalability, code review workflow, CODEOWNERS/policy enforcement, ecosystem integrations, self-host vs. SaaS.

CI/CD

  • Pipeline-as-code maturity, build parallelism/caching, secrets injection model, GitOps support, runner cost model, extensibility/marketplace, deployment strategy support (canary/blue-green).

Container Orchestration

  • Managed vs. self-managed control plane, multi-cluster/multi-region, autoscaling maturity, upgrade/maintenance burden, ecosystem (operators, CNI, service mesh compatibility).

Secrets Management

  • Dynamic vs. static secrets, rotation automation, encryption/KMS integration, access audit trail, break-glass procedures, HA/DR posture, cost per secret/request.

Observability

  • Metrics/logs/traces coverage, cardinality cost model, OpenTelemetry compatibility, alerting/SLO tooling, retention economics, data egress/lock-in.

Service Catalogs / Internal Developer Portal

  • Software templates/scaffolding, catalog metadata model, plugin ecosystem, RBAC, TechDocs/discovery, self-service actions, maintenance overhead.

Step 3: Build the Weighted Scoring Matrix

For each category, produce a table:

  • Rows = candidate tools; columns = the six weighted criteria plus a Weighted Total (raw score × weight, summed, normalized to a 0–100 scale).
  • Compute the weighted total explicitly for each candidate.
  • Bold the leading score per category.

Step 4: Integration & Interoperability Risk Assessment

Evaluate how the recommended tools fit together, not just individually:

  • Integration seams: Does CI/CD inject secrets natively? Does the service catalog scaffold into source control and trigger pipelines? Does observability auto-instrument the orchestration layer?
  • Lock-in concentration: Flag if multiple categories consolidate into a single vendor (convenience vs. leverage risk).
  • Migration cost: For any tool replacing an incumbent, rate switching cost (Low/Medium/High) with the specific migration friction (data export, retraining, pipeline rewrites).

Step 5: Per-Category Recommendation

For each category, state the recommended tool with:

  • Winner and its weighted total
  • Why it wins in this specific context (2 sentences tied to the buyer's constraints, not generic marketing)
  • Runner-up and when to choose it instead (the condition under which the second choice becomes correct)
  • Watch-outs: the top risk of adopting the winner

Step 6: Phased Adoption Roadmap

Sequence adoption to minimize simultaneous disruption:

  • Phase 1 (foundation): The tools other categories depend on (typically source control + CI/CD).
  • Phase 2 (runtime + security): Orchestration and secrets management.
  • Phase 3 (visibility + self-service): Observability and service catalog.
  • For each phase: prerequisite, rough effort (S/M/L), and the "don't proceed until" gate.

Output Format

  • Structure: Weighting rationale → per-category scoring matrices → integration risk → per-category recommendations → phased roadmap
  • Length: 1,100–1,600 words
  • Format: Markdown tables for scoring matrices; structured bullets for recommendations and roadmap
  • Sections: Scoring Weights → Category Scoring Matrices (one per category in scope) → Integration & Lock-in Risk → Per-Category Recommendations → Phased Adoption Roadmap
  • Tone: Platform architect — analytical, tradeoff-honest, opinionated where the data supports it, never vendor-cheerleading

Quality Checklist

Before delivering output, verify:

  • [ ] The six scoring weights sum to exactly 100% and reflect the buyer's stated priorities
  • [ ] Every candidate has a score for all six criteria, each with a one-line justification
  • [ ] Weighted totals are computed and shown (not just raw scores)
  • [ ] Each in-scope category has a named winner, a runner-up condition, and a watch-out
  • [ ] Integration risk section names at least one specific lock-in or interoperability concern
  • [ ] The roadmap sequences foundation tools before dependent tools, with a gate per phase

Notes

  • Operational burden is the most systematically underweighted criterion — self-hosted "free" tools often lose on total cost once platform team labor is counted; make this cost visible.
  • When a single vendor wins multiple categories, flag it explicitly: consolidation lowers integration cost but raises negotiating and exit risk.
  • If the buyer names no candidates, propose a defensible 2–3 tool shortlist per category spanning managed SaaS, open-source self-hosted, and cloud-native options.
  • Avoid declaring a universal "best" tool — the winner is always relative to the confirmed constraints and weights.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills