Menu
Autonomous research loop for Citum migration fidelity gaps and converter-focused Rust fixes.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | migrate-research |
| description | Autonomous research loop for Citum migration fidelity gaps and converter-focused Rust fixes. |
Use this skill when multiple styles share a migration failure pattern or when a rich
input pass needs classification before changing citum_migrate.
Read first:
docs/policies/STYLE_WORKFLOW_DECISION_RULES.mddocs/guides/STYLE_WORKFLOW_EXECUTION.mddocs/specs/MIGRATE_RESEARCH_RICH_INPUTS.mddocs/guides/AGENT_SKILLS.mddocs/guides/JJ_AI_CHANGE_STACK.md when .jj is present and the research
pass needs an isolated local changemigration-artifact, style-defect, processor-defect,
or intentional divergence. For type- or field-population-shaped clusters,
run the conversion-layer pre-flight from the shared decision rules
(docs/policies/STYLE_WORKFLOW_DECISION_RULES.md) before classifying.profile + config-wrapper targets.journal + structural-wrapper as a valid endpoint; do not force thin-wrapper reduction.type-variants in a profile,
stop and reroute or escalate instead of breaking the profile contract.Report the chosen cluster, semantic class, implementation form, selected parent if any, classification, before/after evidence, exact change made if any, and whether the pass should continue, stop, or escalate.
When you reach a dead end not covered by the operating rules — a cluster pattern that doesn't fit the four classifications, a stop condition missing from the guides, or a migration artifact the evidence ladder doesn't anticipate — record the insight as a concrete bullet here and include the file update in the same commit or PR. Future research passes start with a richer surface.
node scripts/report-migrate-sqi.js --corpus random --seed 20260610 and pick
the cluster by reach from its fidelity headline + failure taxonomy, not from
the curated lab corpus alone. The random baseline and current cluster table
live in docs/architecture/audits/2026-06-10_MIGRATE_RANDOM_SAMPLE_BASELINE.md.type-variants
op matching no component) is always migration-artifact with an emit-time
validation fix in citum-migrate plus a regression test — the converter must
never emit YAML the processor rejects. No evidence ladder needed.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.
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