Menú
Refresh facts on an existing certification JSON when an Issue or routine sweep flags that something changed.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Add a new security certification to the roadmap by writing data/certs/<vendor>/<slug>.json from official + third-party sources.
Add a new authoritative source agency to data/sources/agencies.json so that future cert evaluations can cite it.
Compute every cert's tier (foundational / associate / professional / expert / specialty) by simulating three independent reviewer personas, and gate the run on persona disagreement.
Curate cross-vendor "commonly taken before" recommendations based on community / industry reputation. Adds entries to prerequisites.recommended_certs[] tagged with source "community" and a one-sentence rationale. Distinct from infer-relationships (which only handles official ladders).
Propose prerequisite cert relationships across the entire roadmap from neutral AI analysis of cert facts. Both within-vendor ladders and cross-vendor industry-conventional flows are in scope.
Triage a GitHub Issue (add-cert / update-cert / add-source / evaluation) and dispatch to the right skill, ending with a draft PR or a clarifying comment.
| name | update-cert |
| description | Refresh facts on an existing certification JSON when an Issue or routine sweep flags that something changed. |
update-certification Issue arrives.make target) finds a cert with a stale
official.fetched_at.Locate the file under data/certs/<vendor>/<cert>.json.
Re-fetch the official URL with WebFetch. Compare against the JSON, diffing field-by-field:
name, abbr, vendor.urllogistics.cost_usd, duration_min, questions, languages,
renewal_years, ce_required, formatprerequisites.experience_years, recommended_certsSpecial attention to recommended_certs[]: this list powers the
roadmap UI's arrow overlay (prerequisite arrows from this cert, and
inverse-lookup successor arrows on the prereqs themselves). If the
vendor adds, removes, or renames a prerequisite, the arrows must follow
— update the list explicitly rather than leaving stale entries.
Refresh third_party_evaluations[]. For each existing entry, re-fetch
to confirm the URL still resolves and the level_hint still matches
the evaluator's current page. Add new entries when you find them.
Update official.fetched_at to today's date. Add note fields to
any factor whose evidence has shifted.
Do not rewrite scoring_factors casually. Only change a factor when
the underlying evidence has changed. Comment on the diff in the PR
description.
Track availability changes. If the vendor has paused, retired, or
announced a future launch, set the top-level availability field
(paused / retired / coming-soon) and a one-line availability_note
quoting the vendor's wording. Reset to available (or remove the field)
once delivery resumes. The roadmap UI surfaces availability as a card
badge and a banner in the detail panel.
Reset evaluation freshness. Set evaluation.computed_at = null and
evaluation.computed_tier = null so CI's check_evaluations_fresh.py
forces a re-run of evaluate-roadmap-3-personas.
Update manifest + validate (make manifest, make validate).
Open a PR with a description that lists each changed field and links the evidence.
evaluation.computed_tier = null and add a top-level field is not
appropriate (the schema does not allow extra fields). Instead: in the
PR description, propose moving the file to data/certs-retired/ (a
future schema addition) and ask the maintainer.name and abbr; keep the file path so URLs in
third-party documents still resolve, unless the vendor itself changed.