Skip to content
cccskills
FreePublished on GitHub

change-grug

Try model or training changes in a copied Grug or Grugformer experiment, document the differences, and bring successful changes back into the base template while removing superseded experiment code and checking behavior.

OriginalShow the original description

Modify or upstream behavior in a named Grug/Grugformer experiment variant.

Run score Not tested

See how to install

Good for

  • Try changes to attention or masking
  • Experiment with optimizers or training loops
  • Bring successful changes into the base template
  • Archive experiment history and remove stale code

Files included (1)

  • SKILL.md3.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Skill: Changing Grug (Template-First)

Grug is intentionally template-first: the canonical edit surface lives in experiments/grug/base/, not in a shared levanter.grug trainer stack.

This skill covers two steps: trying a change in an experiment copy, and upstreaming it into the base template when it proves out.

Do not use this skill to run an existing variant, change launch-only configuration, or add a bounded operational diagnostic. Use the variant README and launcher controls for those tasks.

Source Of Truth

  • Canonical template: experiments/grug/base/ — model.py, train.py, launch.py.
  • Variants: experiments/grug/<variant>/ — copy from base and modify locally (e.g. MoE).
  • One-off speedruns: experiments/speedrun/... — useful for exploration, not canonical.
  • Reference branch for array-stacked grug variant wiring: https://github.com/marin-community/marin/tree/codex/array-stacked-grug-variant-pointer — useful for perf-focused experiments, especially improving compile times and reducing peak HBM.

Workflow

1) Pick one change bucket

Keep each pass scoped to one bucket:

  • attention/masking
  • block wiring/norm ordering
  • MLP/activation
  • loss kernel behavior
  • optimizer/training loop behavior

2) Experiment in a copy

  • Copy experiments/grug/base to a new variant directory.
  • Keep edits local and explicit (copy/paste over abstraction).
  • Avoid introducing reusable framework surface unless there's clear repeated use.

3) Record the experiment

Update docs/reports/grug-archive.md with: path, origin (base, moe, or another source variant), commit SHA (when known), purpose, status (active, superseded, deleted), and diff link (prefer the CI-posted PR comment link; fallback to local report path).

For PRs that add a new experiments/grug/<variant>/, CI posts a visual diff comment automatically — copy that link into the archive entry.

For a local fallback, generate the diff report manually and link the report in the archive entry:

uv run python scripts/ci/grug_dir_diff.py \
  experiments/grug/base \
  experiments/grug/<variant> \
  --out /tmp/grug-diff

4) Upstream to base if it wins

Port the successful change back into experiments/grug/base/model.py, train.py, and launch.py. Keep it grug-style:

  • plain JAX arrays and explicit sharding
  • Equinox modules with init + __call__
  • minimal config knobs
  • legibility first; if a block gets hard to read, introduce a small local helper instead of framework indirection
  • when HBM is tight, use docs/references/hbm-optimization.md before bespoke memory hacks
  • when compile time or peak HBM is the bottleneck, evaluate an array-stacked variant first (see reference branch above)

5) Delete stale paths

After upstreaming, delete superseded experiment code; keep only the archive trail in docs/reports/grug-archive.md.

6) Validate

./infra/pre-commit.py --all-files
uv run pytest tests/test_grug_variant_contracts.py

Add focused tests for any behavior changes.

This workflow is inspired by modded-nanogpt: iterate quickly in copy-paste experiments, then upstream only what stays simple and useful.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

ab-test-zephyr

FreeSummary

Compare Zephyr changes using the same prepared dataset and matching execution settings. Analyze Finelog metrics for each processing stage to distinguish CPU efficiency, elapsed time, and peak memory changes, then report improvements, regressions, or tradeoffs.

  • Compare Zephyr performance before and after a PR
  • Assess speed gains against additional CPU usage
  • Check peak memory and out-of-memory regressions
marin-community/marin4KUpdated Oct 23, 2026

add-dataset

FreeSummary

Register Hugging Face datasets for Marin by inspecting their structure without downloading the full dataset. Identify text fields, configurations, and data splits, then add a dataset module and validate the mapping with a sample.

  • Registering a Hugging Face dataset for Marin
  • Inspecting text fields without a full dataset download
  • Checking configurations and data splits
marin-community/marin4KUpdated Oct 23, 2026

add-grant

FreeSummary

Turn a specified GCP access request into a reviewable Pulumi change and pull request. Select the narrowest suitable role and encrypt personal email identities, covering resource permissions and Cloud Run viewer access through IAP, an access gateway.

  • Prepare a request for GCS bucket read access
  • Add a viewer to a Cloud Run service protected by IAP
  • Prepare service account impersonation permissions
marin-community/marin4KUpdated Oct 23, 2026

Add or update Pallas/Mosaic kernels, specialized computation routines for JAX. The skill covers reference implementations, output and gradient checks, public wrappers, fallback behavior, performance benchmarks, and hardware-specific tuning when requested.

  • Adding a Pallas kernel for a JAX computation
  • Checking outputs and gradients against a reference
  • Maintaining backend selection and fallback behavior
marin-community/marin4KUpdated Oct 23, 2026

Organize Marin experiment reports into a maintained index, or archive explicitly named older experiments using lasting tags and issue references. Existing conclusions and canonical links are preserved so experiment records remain traceable.

  • Organizing an index of experiment reports
  • Consolidating canonical report entries
  • Archiving named legacy experiments
marin-community/marin4KUpdated Oct 23, 2026

file-issue

FreeSummary

Turn a bug report, improvement request, or experiment into a structured GitHub issue. Check for duplicates, write reproduction steps or testable completion criteria, apply suitable labels, and verify the published title and body.

  • File a bug with clear reproduction steps
  • Create an improvement task with testable completion criteria
  • Track an experiment's hypothesis, status, and conclusions
marin-community/marin4KUpdated Oct 23, 2026

See all skills by marin-community

Report a problem with this skill