wandb-reporting

Publishes W&B runs, reports, and artifacts for experiment results too dense for GitHub comments.

3.2k|266|Updated Mar 22, 2024
One-click install
npx skills add https://github.com/marin-community/marin --skill wandb-reporting
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: wandb-reporting
Source: https://github.com/marin-community/marin/tree/main/.agents/skills/wandb-reporting
Command: npx skills add https://github.com/marin-community/marin --skill wandb-reporting

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Dense scalar series, plots, and large comparison tables from ML experiments overwhelm GitHub issues and logbooks, making results hard to review and reproduce. This Skill defines when and how to publish experiment data to Weights & Biases while keeping GitHub as the narrative layer.

Core Features & Use Cases

  • Project Scoping Policy: Chooses the correct W&B project based on the type of work, defaulting to the marin project for pretraining runs and requiring shared projects for run-to-run comparisons.
  • Run Naming and Metadata Conventions: Aligns W&B run names with experiment IDs used in logbooks and issue comments, and groups related sweeps under stable group names.
  • Reporting and Verification Checklist: Links W&B runs and reports from coordinating issues, verifies row counts and aggregation logic before publishing claims, and keeps artifacts under 10MB.
  • Use Case: After finishing a pretraining sweep, publish the runs to the marin W&B project, link the comparison chart from the tracking issue, and summarize only the decision-relevant numbers in GitHub.

Quick Start

Publish my latest pretraining sweep runs to the marin W&B project and link the comparison report from the tracking issue.

Frequently Asked Questions about wandb-reporting

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
When should I publish experiment results to W&B instead of GitHub?

Publish to W&B when results include scalar series, plots, large comparison tables, or raw artifacts too dense for issue comments or logbooks. Keep GitHub as the narrative layer with decision-relevant summaries, and link W&B for the dense data.

How do I choose the right W&B project for my experiment runs?

Choose the project based on the type signature of the work. Default to the marin project for pretraining runs, but create a new project for materially different work like kernel development or a new RL variant. Decide early since runs cannot be reliably moved across projects.

How should I name W&B runs for experiment tracking?

Use the same experiment or task ID in W&B run names, logbook entries, and issue comments so results map back to their context. Group related sweeps under a stable group name for easier comparison.

What are the limits for W&B artifacts in this workflow?

Artifacts should stay under 10MB. Larger artifacts belong in the experiment directory with a link from W&B. Prefer artifacts for raw CSV or JSON outputs that feed published tables.

What should I verify before publishing claims from W&B data?

Verify expected row counts, key uniqueness, and any de-duplication or aggregation logic before publishing. Confirm that claims in GitHub match the final W&B values and that the primary comparison table is linked from the issue.