Purpose
Turn raw operational metrics into a decision-ready health scorecard — with defensible Red/Amber/Green ratings per dimension, an overall grade, and a ranked set of actions — so IT operations managers and engineering leads can quickly see which applications are healthy, which are at risk, and where to spend the next quarter's effort.
When to Use
Invoke this skill when the user asks to:
- Assess the health of an application or service for a periodic review
- Build a quarterly or monthly application health scorecard
- Rate applications RAG (Red/Amber/Green) across operational dimensions
- Compare an application's current state against prior periods or SLAs
- Decide whether to invest in, maintain, or retire an application
- Present operational health to stakeholders or leadership
Inputs Required
Before starting, collect:
- Application name and context: What the app does, criticality tier (mission-critical / important / low), and user base size
- Reporting period: The window the metrics cover (e.g., last 30 days, Q2)
- Availability metrics: Uptime %, SLA target, number/duration of outages
- Incident data: Incident count by severity, MTTR (mean time to recover), MTBF if available
- Delivery metrics: Deployment frequency, change failure rate, lead time for changes
- Technical debt indicators: Open critical bugs, dependency/version age, code coverage, known deprecated components
- User satisfaction: CSAT/NPS, support ticket volume/trend, or qualitative feedback
- Cost/security (optional): Monthly run cost, known open security findings, last pen test date
If a dimension's inputs are missing, rate it Amber – Insufficient Data, state exactly what's needed, and do not silently assume Green.
Instructions
Step 1: Establish Rating Thresholds
Before scoring, set the RAG bands. Use these defaults unless the user provides their own SLAs — and state which bands you used.
- Availability: Green ≥ 99.9% (or meets SLA) | Amber 99.0–99.9% | Red < 99.0% or SLA breached
- Reliability (incidents): Green = 0 Sev1/2 and MTTR under target | Amber = occasional incidents, MTTR near target | Red = recurring Sev1/2 or MTTR 2x+ target
- Delivery velocity: Green = frequent deploys, change failure rate < 15% | Amber = moderate cadence, CFR 15–30% | Red = rare deploys or CFR > 30%
- Recoverability (MTTR/MTBF): Green = MTTR under target and stable | Amber = trending up | Red = MTTR above target or worsening
- Technical debt: Green = few critical bugs, current dependencies | Amber = mounting debt or aging stack | Red = critical bugs unaddressed, deprecated/unsupported components
- Security posture: Green = no open critical/high findings, recent review | Amber = medium findings or overdue review | Red = open critical/high findings
- User satisfaction: Green = CSAT/NPS healthy, tickets flat/down | Amber = mixed signals or rising tickets | Red = declining satisfaction or ticket spike
- Operational cost: Green = efficient / stable | Amber = rising or unclear | Red = disproportionate to value
Step 2: Score Each of the 8 Dimensions
For every dimension produce:
- RAG rating (Red / Amber / Green)
- Evidence — the specific metric value(s) that drove the rating
- Interpretation — 1–2 sentences on what it means and any trend vs. prior period
- Confidence — High / Medium / Low based on data completeness
Weight dimensions by application criticality: for mission-critical apps, Availability, Reliability, and Recoverability carry the most weight; for internal/low-tier apps, Cost and Technical Debt weigh more heavily. Note the weighting applied.
Step 3: Calculate the Overall Health Grade
Roll the 8 dimensions into a single grade using a simple, transparent rule:
- Green (Healthy): No Red dimensions and no more than 2 Amber
- Amber (At Risk): Any single Red in a non-critical dimension, or 3+ Amber
- Red (Critical): Any Red in Availability, Reliability, or Security for a mission-critical app, or 2+ Red dimensions total
State the rule that produced the grade so the result is auditable.
Step 4: Identify the Top Risks
List the 3–5 findings most likely to cause business impact if unaddressed. Each risk: what it is, the dimension it lives in, and the likely consequence (outage risk, cost overrun, churn, security exposure).
Step 5: Build the Remediation Plan
Produce 5–8 recommended actions, ranked by impact-to-effort. For each action:
- Action: The specific fix (not "improve reliability" — name the change)
- Dimension it moves: Which RAG rating it improves
- Effort: Low / Medium / High
- Owner suggestion: Team or role best placed to execute
- Target: The measurable outcome that would flip the rating (e.g., "MTTR under 30 min")
Step 6: Set the Next Review Trigger
State when this app should be reviewed again (based on grade — Red = sooner) and which 2–3 metrics to watch as leading indicators before then.
Output Format
- Structure: Executive summary → RAG scorecard table (all 8 dimensions) → overall grade with reasoning → top risks → ranked remediation plan → next review trigger
- Length: 800–1,100 words
- Format: Scorecard table for the 8 dimensions; ranked list for remediation; short prose for summary and grade
- Sections: Application snapshot → Rating thresholds used → 8-dimension scorecard → Overall health grade → Top 3–5 risks → Remediation plan (ranked) → Next review trigger
- Tone: IT operations manager — analytical, evidence-first, decision-oriented; no hedging on ratings
Quality Checklist
Before delivering output, verify:
- [ ] All 8 dimensions are rated with an explicit RAG color (no dimension skipped)
- [ ] Every rating cites the specific metric value that produced it — not just the color
- [ ] Missing-data dimensions are marked Amber with the exact input needed, not assumed Green
- [ ] The overall grade states the rule that produced it and is consistent with the dimension ratings
- [ ] Every remediation action names a specific change, effort level, and measurable target
- [ ] The RAG thresholds used are stated so a reader could reproduce the scoring
Notes
- If the user provides prior-period metrics, always show trend direction — a Green rating that's declining is more urgent than a stable Amber
- Criticality tier changes everything: a Red on availability for a nightly batch job is not the same emergency as a Red on a customer-facing checkout service — weight accordingly
- Resist grade inflation. If the data supports Red, deliver Red — a scorecard that never shows problems is worthless for prioritization
- For portfolio reviews, run this skill per application and compare overall grades to rank investment vs. retirement candidates
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:
- Drag this file into a new chat, or copy and paste its contents
- 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