Improve Claude Code skill descriptions and naming consistency

[bosconi]

Summary

Audit and improve the Claude Code skills in .claude/skills/ to trigger more
reliably and avoid confusing overlaps.

Commit-by-commit breakdown

1. Rename skills to use consistent mz- prefix — adapter-guide, debug-ci,
   limits-test, parallel-workload, platform-checks, and query-tracing are
   renamed to match the convention already used by mz-benchmark, mz-commit,
   mz-profile, mz-run, mz-test, and mz-pr-review. Updates name frontmatter
   fields and the trace_tree.py path reference.

2. mz-pr-review: add missing name field and improve description — This skill
   was missing the name frontmatter field entirely, which could prevent correct
   identification. The description was too generic and missed casual triggers like
   "review my code" or "does this look ok".

3. mz-debug-ci: expand description with casual trigger phrases — The old one-line
   description only matched formal phrases. Users more often say "why is CI red" or
   "checks failing".

4. mz-test: add cross-references to specialized framework skills — Clarifies
   mz-test as the general testing guide and entry point for framework selection,
   pointing to mz-platform-checks, mz-parallel-workload, and mz-limits-test for deep
   framework-specific guidance.

5. mz-adapter-guide: add problem-oriented trigger phrases — The old description
   only triggered on file paths and crate names. Adding triggers like "how does the
   coordinator work" helps the skill activate when someone is asking questions, not
   just editing files.

6. mz-query-tracing: add problem-oriented trigger phrases — Reframed from
   mechanism-focused ("tracing, spans, Tempo") to problem-focused ("why is this query
   slow", "where is the time going").

7. mz-benchmark: clarify distinction from mz-parallel-workload — Explicitly notes
   this is about performance measurement frameworks, not the parallel-workload
   stress-testing framework.

8. mz-parallel-workload: clarify distinction from mz-benchmark — Mirror
   disambiguation: leads with "stress-testing for panics/errors" and points to
   mz-benchmark for performance measurement.

9. Update skills README — Rewritten with clearer descriptions, new mz- names,
   a dedicated "Specialized Test Frameworks" section, and a note that the README is
   human documentation only (not used for skill triggering).

10. Add skills section to CLAUDE.md — A brief nudge reminding Claude that
    project-specific mz-* skills exist and are worth consulting before starting a
    task. This is lightweight by design: the skill descriptions are already in context
    via SKILL.md frontmatter, so CLAUDE.md does not duplicate them.

11. mz-test: fix cross-references to use mz- prefixed skill names — The
    cross-references said platform-checks, parallel-workload, and limits-test
    without the mz- prefix, so they did not match the actual skill names.

12. mz-commit: remove "code review" trigger to avoid collision with mz-pr-review
    — Both skills listed "code review" as a trigger phrase, but mz-commit is for
    creating commits/PRs while mz-pr-review is for reviewing changes. Removed the
    ambiguous trigger from mz-commit and added a pointer to mz-pr-review.

What was deliberately not done

• No exhaustive skill listing in CLAUDE.md. Duplicating all 12 skill descriptions
  would waste context tokens and create a maintenance burden. The brief mention is
  sufficient to nudge the model to check the skill list it already has.

• No AGENTS.md file. AGENTS.md is a cross-tool convention (Gemini CLI, Codex,
  etc.) that Claude Code also reads. Since the team is using Claude Code and CLAUDE.md
  is already established, adding AGENTS.md now would be premature. If other AI tools
  are adopted later, a symlink AGENTS.md -> CLAUDE.md is the right move — the
  skills section would be harmless noise for tools that do not support skills.

Test plan

• Verify all 12 skills appear in the skill list at session start (all mz-* prefix)
• Spot-check triggering: "why is CI red" should suggest mz-debug-ci
• Spot-check triggering: "review my changes" should suggest mz-pr-review
• Spot-check triggering: "code review" should suggest mz-pr-review, not mz-commit
• Verify /mz-query-tracing works and references the correct trace_tree.py path

🤖 Generated with Claude Code

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).