High-throughput migration waves converting priority parent CSL 1.0 styles to Citum with repeatable before/after metrics and migration-engine gap recommendations. Fidelity is the hard gate.
Standardized QA gate for style work. Verifies fidelity, SQI drift, formatting defects, and regression surface. Produces approve/reject verdict with numbered findings.
Iterative LLM hand-tuning loop for embedded-core styles. Drives a style to 100% fidelity and clean SQI. Both are hard gates. Seeded from migrate evidence, not from the converter output as a terminal deliverable.
Autonomous research loop for Citum migration fidelity gaps and converter-focused Rust fixes.
Single human-facing command for all Citum style work. Use whenever someone asks to fix, improve, convert, create, or tune a citation style. Routes to upgrade, migrate, create, or tune. Always use this rather than calling internal skills directly.
Public entrypoint for Citum style work. Activate on: 'upgrade', 'migrate', 'create', 'tune', any style authoring request, or any request to fix/improve/convert a Citum or CSL citation style. Route to the shared workflow docs and internal roles.
Repo-owned test soundness auditor and navigator for citum-core. Reasons from a spec (not the implementation) to classify each test as good, suspicious, broken, or redundant; simultaneously reviews the spec for ambiguity, contradiction, and silence, halting to prompt the user when a spec defect blocks an honest verdict. Records state in the living ledger docs/architecture/TEST_SOUNDNESS_STATUS.md — never ephemeral JSON. Trigger on: "/test-soundness-review", "review my tests against the spec", "audit test soundness", "are my tests vacuous", "find broken tests", "find redundant tests", "are these tests just for the sake of it", "test quality review", "review the spec while you're at it", "what's the state of our test quality", "what test audits are outstanding", "what's next for test soundness". Also trigger proactively after a disambiguation, sorting, algorithm, or engine feature is implemented when the user asks "do the tests actually cover the spec?". Takes up to two arguments: /test-soundness-review [spec-pa
Domain knowledge for test coverage in citum-core. Use this skill whenever you're implementing a feature, fixing a bug, writing tests, or claiming something is "tested" in citum-core. Trigger on any task involving: adding fixture data, writing Rust tests, running the oracle, validating style behavior, or checking whether a code path is exercised. This skill tells you what reference shapes are required to test each behavior, and provides a pre/post checklist so nothing slips through.