spec-led-certification

A Claude Code plugin that picks a professional certification the way you would run a procurement: write the specification first, then go to market.

Choosing a certification is normally market-led — I work in this field, here is what's on offer, this one looks well-regarded, I'll sit that. The exam's blueprint becomes your specification by default, and the criteria you would have written are recovered afterwards as reasons for a choice already made. The tell is that the answer is usually the most famous option.

This inverts the order. It interviews you first, derives a weighted scorecard from your answers alone, freezes it before anything is looked up, and only then surveys the market and scores what it finds against it.

Three ways in

The stages are the same every time; the situation you arrive in is not. Each gets its own entry point rather than a branch inside one skill.

Entry point	When	Costs
start-search	First run, or a new subject	~an hour, nearly all of it intake
rerun-search	Intake on file — has the market moved?	Minutes plus a fresh sweep
update-profile	Something about you changed	A couple of minutes

rerun-search archives the previous run to runs/<date>/ — scorecard, data and conclusion together — and its report leads with what changed: whether the earlier recommendation still holds, which scores moved and why, what entered or left. That comparison is the payoff for having written the profile down.

update-profile deliberately stops short of researching. It re-interviews only what changed and marks the scorecard stale, so the next run rebuilds it. A two-minute correction should not drag an hour of research behind it, and a market sweep should not quietly reopen questions about you that nobody asked to reconsider.

/cert-search reads the state on disk and routes to the right one.

The stages

Skill	Question
create-workspace	Where does this search live? Private GitHub repo from the template, cloned
scaffold-workspace	Same, but a plain local directory with no remote
define-spec	What field, and which capability areas specifically?
benchmark-me	Where are you now — read off repos, site, CV, not self-report
learning-preferences	How do you take information in, and what has failed before?
define-objectives	What is the credential for, who has to believe it, what are your standing positions, by when, and what would make it not worth doing at all?
define-budget	Money and hours, captured separately because they fail separately
build-scorecard	Weighted anchored criteria and hard filters — then freeze
research-market	Survey, filter on eligibility, price the whole route, score with sources
recommend	The answer, why the runner-up lost, where to invest, what would change it

Install

/plugin marketplace add danielrosehill/Claude-Code-Plugins
/plugin install spec-led-certification@danielrosehill

Optional: Typst for the PDF. Everything else works without it — the markdown stands on its own.

Use

/cert-search                                  # read the state and route
/cert-search "agentic AI development"         # first run, subject given
/cert-search --rerun                          # re-sweep the market, keep the profile
/cert-search --update                         # change what's stored about you
/cert-search --repo                           # force a private GitHub repo workspace
/cert-search --local --in certification       # local folder instead, in a subdirectory
/cert-search --lean                           # don't bundle the skills into the workspace

Or invoke a skill directly — "where do I stand on this", "build me a scorecard for this", "what certifications are out there for X", "why did you rank that second", "has anything changed since last time", "I've got more study time now".

What makes it different from asking an assistant for a list

The freeze. No credential is named, searched for, or considered until the scorecard says frozen: true. Three things enforce it: every criterion carries a source column naming the line in your profile it came from, the scorecard is committed before research runs, and the research subagent never sees the intake conversation — so there is no anchor available to bend toward.

Hard requirements exclude, they don't score down. A requirement that can be outweighed is not a requirement. Eligibility gates and non-negotiables filter candidates out entirely, and the excluded ones appear in the report with the filter they failed — so "why not that one?" isn't re-asked on every run.

Every claim carries its source tier. V vendor-confirmed, S secondary, I inferred, printed next to the score. Certification research has a specific bias in its material: the bodies that certify often gate their blueprints, and the sites that are not gated are mostly selling preparation. A recommendation resting on inferred scores has to say so.

Every number in the report is computed from the data. The Typst template reads the CSVs at compile time and works out the totals, the ranking and the comparison table itself; the writing step produces prose only. A report whose narrative can drift from its arithmetic is untrustworthy in exactly the respect that matters.

Where the state lives

In your working directory, as markdown and CSV — never in an agent's memory store.

profile/      spec, benchmark, learning preferences, objectives, budget
scorecard/    criteria.csv, filters.csv, methodology.md
research/     candidates.csv, scores.csv, candidates/*.md, sources.md
report/       narrative.yaml, meta.yaml, report.typ, build.sh
runs/<date>/  archived previous runs — scorecard, data and conclusion together
pdf/          the built report

By default create-workspace makes that directory a private GitHub repo from the template, so the search survives the machine and its git history shows when the scorecard was frozen relative to when the research ran. Your own defaults for that — owner, visibility, where clones land, naming — live in ~/.claude-plugins/spec-led-certification/config.yaml, outside both this plugin and the template, so they are never committed to a public repo and survive /plugin update.

Two reasons this is on disk at all, and the second matters more. You can read, correct, date and diff a profile that lives in a file. And you may run the next pass with a different assistant entirely — the directory goes with you, an agent's memory does not. By default the scaffold also drops copies of the skills into the workspace, so it stays runnable without this plugin installed.

Every profile file carries captured and review_after, and they decay at different rates: what you know is stale in a quarter, how you learn is much the same in five years. A re-run six months later re-asks the one file that expired and confirms the other four.

Relationship to the template repo

The canonical source is Spec-Led-Certification, a GitHub template repository. Clone it and the workflow runs standalone, with no plugin and no Claude Code — the skills are plain markdown procedures.

This plugin is a packaging of it, for people who would rather install once and run the workflow in any directory than clone a repo per search. The twelve skills, the three subagents and the workspace template are vendored from there verbatim:

./scripts/sync-from-template.sh --check     # report drift
./scripts/sync-from-template.sh             # refresh from upstream

Only commands/, skills/scaffold-workspace/ and .claude-plugin/ are owned here. Changes to any stage skill go upstream first, then come back through the sync — the template repo is the source, this is the generated target.

The worked example lives upstream too, in examples/worked-run/: a complete scored run with deliberately fictional credentials, whose most instructive case is the best-known credential in the set finishing last — not because it is weak, but because that spec weighted recognition at 0.05.

Architecture

This plugin follows Plugin–Workspace–Vault and is that pattern's worked example: a public plugin, a private workspace instantiated per search from a public template repo, and a vault at ~/.claude-plugins/spec-led-certification/ for your own defaults. Three parts, three lifecycles — the plugin is replaced on update, the workspace is yours and permanent, the vault survives both and is committed nowhere.

Licence

MIT