What this marketplace installs today, filtered to what is operational: a skill appears here once it is merged and runs to its stated purpose, not merely once its files are on main. Listing is not a claim about how far a skill has been validated — the State column answers that for each one, and says so plainly when the answer is “not much”. Anything not listed does not exist yet as a usable skill, however firmly it has been discussed. Work in flight lives in the tracking issue for its skill family; ideas nobody has committed to live in the tracker as low-priority enhancement issues.
Scaffolding is deliberately absent — and as of qe 0.6.0 it no longer ships at all: an unbuilt skill lives only as the plan in its family’s tracking issue, so installing the plugin never puts a menu entry in front of you that does nothing. (Through 0.5.0 the style skills shipped as stubs reporting “not yet operational”; that practice is retired.)
Everything ships in the single qe plugin (#43, qe 0.7.0); the families keep their own tracking issues.
| Family | Skills | State | Tracking |
|---|---|---|---|
| Author-facing — from drafting a lecture to merging its PR | /qe:copilot-review, /qe:workplan | /qe:copilot-review is operational, validated from an installed plugin on 2026-08-03: plugin-root path resolution, cross-repo mode, and running from outside a working tree. /qe:workplan (0.5.0, consolidating 0.4.0’s workplan-issue and workplan-update and adding a read verb — the work-plan issue’s whole lifecycle: create, read/validate/recommend, resume, update, close-and-succeed) is operational for the verbs that have run: update and resume on 2026-08-20 from an installed plugin, and this repo’s own work-plan issue #25 revised again on 2026-08-25 as the consolidated skill’s first update. create, read and close are merged procedures with no run yet, and its sibling /qe:workplan-project (0.3.0 as /qe:workplan, renamed 0.4.0; report bundle → tracking issue with sub-issues) has never been run against a real bundle, so neither is listed above. Note the name reuse: /qe:workplan meant the report-to-project skill for one morning in 0.3.0; from 0.5.0 it is the lifecycle skill. The style skills (check-style and six per-category siblings) shipped as scaffolding through 0.5.0 and were removed in 0.6.0; their plan lives in #3, and they return once the rule snapshot and deterministic preflight land. | #3 |
| Benchmark — evaluating accelerated lecture implementations | /qe:benchmark (until qe 0.7.0: /benchmark:review-acceleration) | Operational for workspace runs: rubric v2, a deterministic scoring engine, and two complete worked evaluations as regression baselines. | #4 |
| Audit — bulk, read-only repository audits | /qe:audit-issues (until qe 0.7.0: /audit:issues) | Run twice as a skill, against deliberately different repo types. Run 1 — a 230-item tracker on 2026-07-28, 22 minutes, seven plugin defects (record); both severity-1 defects fixed in audit 0.2.0 (#34). Run 2 — QuantEcon/meta, 317 items and 138 open, 2026-08-25, ~53 minutes including a deliberate kill (record) — settled the claim the program exists to check: the open pass resumed across a lost session at the issue predicted beforehand, appending only, with no re-walk, skip or duplicate; and read-only moved from asserted to measured, a before/after fingerprint of all 317 issues hashing identically. What two runs still do not cover: the closed pass writes once for the whole survey, so an interrupt there loses the phase and the resume rule cannot address grouped entries (#57); no run has been killed mid-write, so the truncation guard is unexercised; and the working-directory rule’s .audit/ fallback leaves a public checkout untracked-dirty (#61). Further runs and the claims table: #16. | #12, #16 |
Installation and setup are in QuantEcon Skills; what it is like to run one is in Using QuantEcon skills.
Principles¶
The point of the marketplace is to share institutional knowledge — the checks, rubrics and procedures that experienced maintainers already apply by hand — so the same work produces more consistent results wherever it is run, across roughly 245 non-archived repos. Everything below serves that.
Few, high-frequency skills over many niche ones, each validated against actual PR history. The 2026-07-21 analysis of ~630 merged PRs across the four main lecture repos is the evidence base: style was the largest recurring theme by a wide margin, which is why it is the flagship. A skill justified by breadth rather than frequency, as the audit family is, should say so.
Report first, fix on request. Skills produce a structured report and offer fixes; they never silently edit. Safe to run in CI, and authors stay in control.
Cited claims; computed scores. Every finding carries a citation — a rule ID plus
file:line, or a number plus its source. Skills whose output is a findings list need nothing more. Skills that aggregate judgements into a scored verdict use the evidence-file pattern from the benchmark skill: judgement recorded as cited answers, every score computed by a deterministic engine, never typed by hand (see Developing skills).Scaffolding is advice, not instruction. Report shapes, phase divisions, naming forms and directory conventions are described as what an existing skill does, not as contracts a new one has to satisfy. Three skill families is not enough to know which of them generalise, and a rule invented from one worked example mostly succeeds at forcing the next skill into the first one’s shape. A skill can be a single
SKILL.md. Where something genuinely must hold — read-only boundaries, cited claims, a stated coverage of what was and was not checked — say so plainly and give the reason; everything else can converge later, once there is something to generalise from.
Note what the last two have in common: the rules stated firmly are the ones that keep output checkable by someone who will not re-run it. That is the test worth applying before writing any new rule down.