القائمة
File a GitHub issue for a bug or improvement found this session.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.
Debug a code bug with a structured debug log that records hypotheses, changes, and results.
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 | file-issue |
| description | File a GitHub issue for a bug or improvement found this session. |
Create a GitHub issue in the current repository from bugs, regressions, or
improvements identified in the current conversation. gh defaults to the repo of
the current checkout; pass --repo <owner>/<name> only to target a different one.
Read first: AGENTS.md.
Pick the kind, then use the matching body structure below. There are no GitHub issue templates — these structures live here.
| Kind | When to use | Labels |
|---|---|---|
| bug | A bug or regression was found | bug, agent-generated |
| task | An improvement, refactor, or feature request | agent-generated + priority if known |
| experiment | An experiment needs tracking | experiment, agent-generated |
**Describe the bug**
<what is broken -- concrete symptoms, error messages>
**To Reproduce**
1. <step>
2. <step>
**Expected behavior**
<what should happen instead>
**Additional context**
<root cause analysis, file:line references, suggested fix if known>
## Description
<what needs to be done and why -- enough context for anyone on the team>
### Definition of Done
<specific, testable completion criteria>
## TL;DR
<One-paragraph current summary. Leave blank only when the work is just being kicked off.>
## Description
<Context someone outside the thread can understand.>
## Hypothesis or Goal
<What are you trying to learn, fix, or achieve?>
## Status
<Current state; update as evidence lands.>
## Links
* Logbook:
* Report:
* Important updates:
## Decision Log
## Conclusion
Extract from the conversation:
If it's ambiguous what to file, ask the user before proceeding.
Pick the kind (bug, task, or experiment). If unsure, ask the user.
Search for existing issues first:
gh issue list --state open --search "<keyword>"
If a match exists, tell the user and offer to comment on it instead.
Title: Short imperative sentence under 80 characters, optionally prefixed
with a scope tag (e.g. [eval] Fix gradient accumulation off-by-one).
Body: Use the section structure for the chosen kind (see above).
Rules for the body:
file:line links, not inline dumps.If the user explicitly asked to file an issue, skip the preview — file it and share the link. If the agent surfaced the issue (not explicitly requested), show the drafted title and body and wait for approval or edits.
Write the body to a uniquely named temp file, then pass it with --body-file.
Do not inline the body with shell substitution (--body "$(cat <<'EOF' ...)")
— multiline text can be corrupted by pasted output or escaping mistakes. Do not
reuse a fixed path like /tmp/issue-body.md; concurrent agent runs can
overwrite each other's drafts on shared hosts.
body_file="$(mktemp "${TMPDIR:-/tmp}/issue-body.XXXXXX.md")"
trap 'rm -f "$body_file"' EXIT
cat > "$body_file" <<'EOF'
<body>
EOF
gh issue create \
--title "<title>" \
--label "agent-generated" \
--body-file "$body_file"
Add kind-appropriate labels (bug, experiment). If a relevant label does not
exist, skip it rather than creating new labels. For task issues, add a priority
label (p1, p2, p3) if the user specifies one or severity is clear.
Before creating the issue, re-open the body file and verify it contains no unrelated shell output (pre-commit logs, pytest session headers, prompt transcripts). If it does, clean the draft before posting.
Print the issue URL.
Terse: every sentence conveys new information; no preamble or editorializing; no restating code a link covers; annotate code links, don't narrate them.
agent-generated label.