mariadb-qa

In a /tmp copy of a /test/<ver> source tree, iterate a candidate MariaDB fix quickly - edit the source, build a light patched binary (a single build_mdpsms_*.sh variant, default dbg), run the test, and capture the change as fix.diff via git diff. This is the /tmp fix-iteration workspace; the source copy and the patched binary both stay in /tmp (ephemeral). Use when testing or iterating a candidate fix, or when a fix.diff artifact is needed. For a durable production build in /test use qa-build; to run an existing /test build standalone in /tmp use claude-basedir-fix-copy-setup.

Copy a built MariaDB basedir from /test to /tmp and re-run ~/st to rebake path-baked helpers (start, anc, cl, test, kill, wipe, mtra, init_empty_port.sh, gencerts.sh), giving Claude its own standalone server for Claude Code based tests, evaluations, bug reproduction, and fix verification - without touching the canonical /test basedir. Drive the copy only via its standard baked helpers (~/st then ./anc / ./cl / ./test / ./mtr[a] / ./kill), never a hand-rolled mariadbd. This skill copies, it does not build. A plain MTR run does NOT need this - drop the .test/.result under a new name into /test/<basedir>/mariadb-test/main and run ./mtr in place.

How to get authoritative information about Claude Code itself (the CLI, headless/print mode, SDK, settings, hooks, slash commands, MCP) and how to run it non-interactively from cron. Two sources of truth - the internal claude-code-guide agent and the online docs at code.claude.com/docs - plus a verified headless quick-reference. Use when a task needs Claude Code feature details, when automating Claude Code from a script/cron, or before answering any "can Claude Code ..." question (do not answer those from memory).

Send a plain-text email from this box via direct-to-MX SMTP (no local MTA, no credentials). Resolves the recipient domain's MX and delivers straight to the receiving mail server over STARTTLS, with a valid Message-ID and Date so Google/RFC-5322 filters accept it. Default sender is claude@<hostname>. Use when asked to email someone from this machine, send a test/notification message, or mail a short report. Not for inbox-grade authenticated mail (use the Superhuman Mail MCP tool for that).

Draft a short, clear Jira comment for a MariaDB ticket using Jira wiki markup. Use for assignee Q&A, patch-coverage verification, dup-merge clarification, follow-up questions, and similar tester-to-dev exchanges that go into jira.mariadb.org and are paste-ready.

Turn a reduced pquery trial under /data/<workdir>/<trial> into a filed public MariaDB bug. Pick the most-reduced testcase, hand-reduce it further and prettify with ~/tcp against the version where it reproduces, dedup-check EARLY against jira.mariadb.org (and present a decision menu if a duplicate is found), generate the bug report via ~/b (and ~/bs / ~/br as warranted), splice any SAN stacks/Setup/matrix into the body, build and verify an MTR testcase (CLI/MTR compatible note, or dual CLI+MTR blocks), derive Affects+Fix versions / components / labels / priority, write a paste-ready overview to log_jira_ticket.txt for approval, file the MDEV ticket via ~/jira, then register it (eb testcase + kb/kba UniqueIDs) and clean matching workdirs (ca). Public generic crash / assert / UB / ASAN bugs only.

Sweep the reducer/bug-family screens that `/test/loop_screens` cycles (`.s<N>`, and `.ge<N>`/`.pr<N>`/`newbug` siblings) and end the ones that are done, leaving only screens still actively reducing a reproduced issue. For each ended screen, reap that trial's leftover reducer/subreducer/pquery/mariadbd processes and remove its `/dev/shm/<epoch>` workdir. Decision rule keys off the reducer's `ATLEASTONCE` bracket: `[]` (never reproduced) -> end; `[*]` (reproduced) + finished -> end; `[*]` + still reducing -> leave. Use for the routine "loop_screens-like cleanup" of stuck/finished reducer screens.

Craft and verify a MariaDB MTR (.test) testcase from a CLI/pquery testcase - engine guards (InnoDB/partition/RocksDB/Spider), Mroonga/replication setup, default-engine differences, --error coverage, server options, reverse-gating, and run-in-place verification. Use any time a crash/assert/SAN repro must run under mariadb-test-run.pl, including when building the MTR block of a bug report.

Build MariaDB server basedirs from a /test source tree in place, using the ba / bas / bam / bat aliases (opt+dbg, UBASAN opt+dbg, MSAN opt+dbg, TSAN opt+dbg) or a single build_mdpsms_*.sh variant. Output basedirs and tarballs land in /test alongside the source. Two uses - (1) a plain re-build of a released version tree (e.g. /test/13.1), and (2) a feature or ticket tree (/test/MDEV-... or /test/MENT-...) whose outputs get the MDEV-<n>_ / MENT-<n>_ prefix. Tarballs move to /data/TARS. This skill never touches /tmp - to run a built basedir standalone in /tmp without touching the original, copy it there with claude-basedir-fix-copy-setup (that skill copies, it does not build).

End-to-end verification of a candidate fix for a MariaDB bug. Five-step loop - draft fix.diff, build the fix binary, copy basedirs to /tmp, run the bug's MTR test against each affected version, log PASS/FAIL in versions_affected.txt, then cleanup. Use when a fix needs full verification across all affected versions.