Menu
Debug a code bug with a structured debug log that records hypotheses, changes, and results.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Build + push the gpu-rl Docker image (`ghcr.io/open-thoughts/openthoughts-agent:gpu-rl`) — the RL runtime for CoreWeave H100 (torch 2.11.0+cu128 + the from-source vLLM fork + flash-attn 2.8.3 + skyrl-train/torchtitan EP) — IN the CoreWeave `cw-us-east-02a` cluster, AS AN IRIS JOB USING KANIKO. Self-contained to THIS repo (MarinSkyRL): the RL env is `uv sync --frozen` against `skyrl-train/{pyproject.toml,uv.lock}` (the lock is the single source of truth — no constraint file). Covers WHY kaniko not buildkit (the cluster denies CAP_SYS_ADMIN/bind-mounts + runs gVisor), the crane-export-over-ubuntu recipe, the load-bearing resource/flag settings (512GB node, per-instruction layers not `--single-snapshot`, `--cache`, ghcr GitHub-PAT creds), the Dockerfile gotchas baked into the build (uv `--index-strategy unsafe-best-match`, `python -m pip wheel`, torchtitan+tyro via the `ep` extra), the build-asserts-as-validation, capturing the digest + bumping `DEFAULT_RL_DOCKER_IMAGE`, monitoring the build job, and WHEN a rebu
Lint, run the pre-PR checks, commit, push, and author or update the branch's pull request in the required plain-text format. Use when committing, pushing, or creating/updating a PR.
File a GitHub issue for a bug or improvement found this session.
Write or revise tests with an emphasis on behavior, regression coverage, pytest style, and avoiding "slop tests." Use when adding tests, fixing failing tests, reviewing test quality, or deciding what test would catch a bug.
Marin house writing style. Use when drafting or revising Marin-authored prose.
| name | debug |
| description | Debug a code bug with a structured debug log that records hypotheses, changes, and results. |
Systematic debugging for code-level bugs. Keep a structured debug log so each hypothesis, the change that tests it, and its result are recorded — this keeps a long investigation from looping and makes the reasoning reviewable.
For infrastructure or operational faults, first read any operations runbook the repo provides and follow its matching section; the guardrails there (what you may and may not touch on shared infrastructure) take precedence.
Maintain a debug log at docs/debug-log-<task-name>.md:
# Debugging log for <task>
<goal>
## Initial status
<initial status, as reported or observed>
## <Hypothesis N>
The suspected source of the bug, or a change needed to isolate it.
## Changes to make
Which files you are altering and how.
## Results
Test results and any new hypotheses. Repeat the Hypothesis/Results cycle as needed.
## Future work
- [ ] Cleanups observed along the way
Work one hypothesis at a time: state it, make the smallest change that confirms
or refutes it, record the result, then move on. When the fix lands, capture a
regression test (see the write-tests skill) so the bug cannot return silently.