Skill Health
- Repo stars 430
- Author updated Live
- Author repo aeon
- Domain
- Security · meta
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 94 / 100 · audit passed
- Author / version / license
- @aaronjmars · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
---
name: Skill Health
description: Audit skill metrics, file/resolve issues in memory/issues/, and notify on state change only <!--…
category: security
runtime: no special runtime
---
# Skill Health output preview
## PART A: Task fit
- Use case: Audit skill metrics, file/resolve issues in memory/issues/, and notify on state change only <!-- autoresearch: variation C — more robust: memory/issues integration per CLAUDE.md health-skill contract, state-change-gated notifications, graceful missing-data; folds in B's TL;DR+action-directives+top-5 and A's skill-runs fallback --> makes outbound network c….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Purpose / Data sources / Steps” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Audit skill metrics, file/resolve issues in memory/issues/, and notify on state change only <!-- autoresearch: variation C — more robust: memory/issues integration per CLAUDE.md health-skill contract, state-change-gated notifications, graceful missing-data; folds in B's TL;DR+action-directives+top-5 and A's skill-runs fallback --> makes outbound network c…”.
- **02** When the source has headings, the agent prioritizes “Purpose / Data sources / Steps” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; may access external network resources; usually needs no extra API key.
## Running Rules
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Purpose / Data sources / Steps”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: Skill Health
description: Audit skill metrics, file/resolve issues in memory/issues/, and notify on state change only <!--…
category: security
source: aaronjmars/aeon
---
# Skill Health
## When to use
- Audit skill metrics, file/resolve issues in memory/issues/, and notify on state change only <!-- autoresearch: variati…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Purpose / Data sources / Steps” and keep inference separate from source facts.
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "Skill Health" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Purpose / Data sources / Steps
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | may access external network resources
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} ${var} — Skill name to check. If empty, checks all scheduled skills.
If ${var} is set, only check that specific skill.
Purpose
Audit skill quality metrics, detect API degradation, file issues for new failures and resolve them when skills recover, and notify only when fleet health state actually changes.
Data sources
memory/cron-state.json— Per-skill quality metrics (as before).memory/skill-health/*.json— Per-skill quality analysis (Haiku post-run).memory/skill-health/last-report.json— Last run's classification snapshot (this skill writes it). Used to dedup notifications and detect flapping.aeon.yml— Enabled skills and schedules.memory/issues/INDEX.mdandmemory/issues/ISS-*.md— Open issues tracker. Check before filing, update on recovery../scripts/skill-runs --hours 168 --failures --json— Fallback source for failures that never wrote to cron-state (sandbox blocks, etc.). Run once, parse JSON.memory/logs/YYYY-MM-DD.md(last 3 days) — Grep forSKILL_*_ERRORorEMPTYsignatures keyed to skills missing from skill-health/*.json.
Steps
1. Gather state
- Parse
aeon.yml→ list of enabled skills with schedules. If${var}set, filter to just that skill. - Load
memory/cron-state.json(if missing or unparseable, treat as empty — first run, not failure). - Load every
memory/skill-health/*.json(exceptlast-report.json). - Load
memory/skill-health/last-report.jsonif present →prev_report. If missing,prev_report = {}. - Run
./scripts/skill-runs --hours 168 --failures --json 2>/dev/null || echo '{}'→ extract any skill with failures in the last 7d that isn't in cron-state (sandbox-blocked state writes). - Parse
memory/issues/INDEX.md→ extract open issues withdetected_by: skill-healthand their affected skills. If missing, treat as empty.
2. Classify each enabled skill
For each enabled skill, assign one status using the first matching rule:
| Status | Trigger |
|---|---|
| CRITICAL | consecutive_failures >= 3 OR (status==failed AND days_since_last_success >= 3) |
| DEGRADED | success_rate < 0.6 OR (latest skill-health/*.json avg_score < 2.5 over ≥3 runs) |
| FLAPPING | 3+ status transitions (success↔failed) in last 7 days per cron-state history or skill-runs output |
| WARNING | success_rate < 0.8 OR consecutive_failures >= 1 |
| HEALTHY | success_rate >= 0.8 AND consecutive_failures == 0 AND (no skill-health data OR avg_score >= 3) |
| NO DATA | no entry in cron-state AND never seen in skill-runs |
Compute severity score for sorting: consecutive_failures × (1 + days_since_last_success/7). Ties broken by days_since_last_success desc.
For each CRITICAL/DEGRADED/FLAPPING skill, record:
last_error(from cron-state or nearest log signature)api_hostif the error clearly names one (e.g.api.coingecko.com,api.github.com)suggested_action— one of:FIX CONFIG(missing secret, bad arg),WAIT-API(rate limit, 5xx, timeout on third-party host),INVESTIGATE(unrecognised error),DISPATCH-SKILL(NO DATA but scheduled — scheduler gap)
3. Detect systemic patterns
Group non-HEALTHY skills by shared api_host OR shared last_error signature. If ≥2 skills share one:
- Emit a single
SYSTEMIC:callout (e.g.SYSTEMIC: 3 skills failing on api.coingecko.com (rate_limit)). - Do not duplicate the same error across per-skill rows — reference the systemic line.
4. Reconcile with memory/issues/
Precondition guard: only perform issue filing/resolution if memory/issues/INDEX.md already exists. If it is missing, the operator has not opted into the issue-tracker contract yet — log SKILL_HEALTH_ISSUE_TRACKER_MISSING to memory/logs/${today}.md, skip this entire step (and the reconciliation side of step 5), and continue with classification + notification only. Do not auto-create INDEX.md.
For each CRITICAL or FLAPPING skill, check if an open issue already exists with this skill in affected_skills AND a matching root_cause signature:
- Open issue exists, same root cause → do nothing (no new file, no notification for this skill).
- Open issue exists, different root cause → append a note to the existing ISS file's body:
Update YYYY-MM-DD: new signature: <error>. Do not file a new issue. - No open issue → file a new one (see below).
For each skill now HEALTHY whose name appears in any open issue's affected_skills:
- Remove it from that issue's
affected_skills. If the list becomes empty, setstatus: resolved, setresolved_at: <now ISO>, and move the row from Open to Resolved in INDEX.md.
Filing a new issue:
- Find next ID: scan
memory/issues/ISS-*.md, take maxNNN, add 1. Format as zero-padded 3 digits (ISS-042). - Write
memory/issues/ISS-NNN.mdwith YAML frontmatter:--- id: ISS-NNN title: <skill> <concise failure> status: open severity: critical | high | medium | low # critical=CRITICAL status, high=FLAPPING, medium=DEGRADED category: rate-limit | timeout | missing-secret | config | api-change | sandbox-limitation | unknown detected_by: skill-health detected_at: <ISO timestamp> affected_skills: [<skill>, ...] # may grow later root_cause: <error signature, 1 line> fix_pr: null --- ## What happened <2-3 line summary> ## Signal - consecutive_failures: N - days_since_last_success: N - last_error: "<error>" - related skills: <list or "none"> - Append a row to
memory/issues/INDEX.mdunder Open:| ISS-NNN | title | severity | category | YYYY-MM-DD | skill-a, skill-b |.
All issue writes must be atomic per file — never partial updates mid-run.
5. Decide whether to notify
Build a stable signature from the current classification: sorted list of CRITICAL+FLAPPING+DEGRADED skill names + SYSTEMIC callouts. SHA-256 it → current_hash.
- If
current_hash == prev_report.hashANDnow - prev_report.last_notified_at < 24h→ do not notify. State unchanged. - Otherwise → notify (there's new signal or the daily reminder cadence elapsed).
Always write memory/skill-health/last-report.json:
{
"hash": "<current_hash>",
"last_notified_at": "<ISO if notified this run, else previous value>",
"last_run_at": "<ISO now>",
"classification": { "critical": [...], "degraded": [...], "flapping": [...], "warning": [...], "healthy_count": N, "no_data": [...] }
}
6. Format the report
Top line: HEALTH: OK | HEALTH: WARNING(W) | HEALTH: DEGRADED(D) | HEALTH: CRITICAL(C) — most severe wins.
Body (notify-channel format, max 1 message):
*Skill Health — ${today}*
HEALTH: CRITICAL(2) [systemic: api.coingecko.com rate_limit — 3 skills]
🔴 CRITICAL
- token-movers — 5 fails, 3d down — WAIT-API (rate_limit) → ISS-042
- defi-monitor — 4 fails, 2d down — WAIT-API (rate_limit) → ISS-042
🟡 DEGRADED / FLAPPING
- digest — 52% success (14d), avg quality 2.1 — INVESTIGATE → ISS-043
⚪ NO DATA (2): skill-x, skill-y — DISPATCH-SKILL
🟢 HEALTHY: 34
Open issues: 2 · Resolved this run: 1 (rss-digest)
Rules for formatting:
- Cap per-section rows at 5; collapse the rest as
+N more — see memory/issues/INDEX.md. - Omit HEALTHY list (count only). Omit any empty section.
- Always end with
Open issues: X · Resolved this run: Y. - If NO CRITICAL/DEGRADED/FLAPPING and no new/resolved issues → body is just
HEALTH: OK — N skills healthy.
7. Notify and log
- If the gate in step 5 said notify →
./notify "<report body>". Updatelast_notified_atin last-report.json to now. - If gate said skip → do not call
./notify. Log to memory/logs/${today}.md:### skill-health - SKILL_HEALTH_NOOP — state unchanged since <prev_run_at>, hash=<short>
On notify, log to memory/logs/${today}.md:
### skill-health
- HEALTH: <OK|WARNING|DEGRADED|CRITICAL>
- filed: [ISS-NNN, ...]
- resolved: [ISS-NNN, ...]
- open: N
- systemic: <pattern or none>
If all skills healthy, the body-only shortcut from step 6 still fires (once per 24h, per gate) so the operator gets confirmation the audit actually ran — but suppress if last-report.json shows a notify <24h ago with the same OK hash.
Sandbox note
The sandbox may block outbound curl. This skill does not fetch URLs directly — all data is local or via gh / ./scripts/skill-runs (which uses gh api). No curl fallback needed. If ./scripts/skill-runs fails, log SKILL_HEALTH_PARTIAL — skill-runs unavailable and continue with cron-state only.
Constraints
- Never file two open issues for the same
(skill, root_cause)pair — always check INDEX.md first. - Never edit a Resolved issue. If a previously-resolved issue re-fires, file a new ISS with a pointer (
related: ISS-NNN) in the body. - Do not notify on pure HEALTHY runs more than once per 24h.
- If
${var}is set (single-skill mode), skip INDEX.md updates only if the single skill is HEALTHY — otherwise file/resolve as normal. - Never touch
memory/issues/INDEX.mdResolved section except to move rows into it; never delete rows.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review