Menu
Refresh facts on an existing certification JSON when an Issue or routine sweep flags that something changed.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.