القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/open-thoughts/OpenThoughts-Agent --skill file-issueيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
Preserve + publish a finished RL (SkyRL/GRPO) training checkpoint after the job terminates (completed at max_steps OR early-stopped/scancelled) on an HPC cluster (Jupiter/Leonardo/Perlmutter). Covers: cancel pending retries, pick the BEST checkpoint by trailing-5 EMA of reward across the full restart chain, flatten weights to repo root, secret-scan, `hf upload` to laion/<job>-<step>-<size>, Supabase DB register (--training-type RL + cross-user FK safety pre-check), upload training traces to penfever/<job>, parse metrics, and clean up. Use when an RL run needs its model uploaded + registered, or when asked to "run the RL cleanup checklist". Distinct from SFT cleanup (that's a different flow).
Post-run cleanup for a datagen (trace-generation) job on Iris/CoreWeave or an HPC cluster (Jupiter/Leonardo/Perlmutter): get the generated traces onto HF (penfever org) and free temporary disk. There is NO model checkpoint — the artifact is the trace dataset. Covers the TIMEOUT-strands-traces gotcha (uploads silently never run), the ONE-level trace_jobs nesting (vs RL's double-nest), the real-vs-failed sanity check (avg_turns ≈ 1.0 = dead run, don't upload), the otagent-env uploader, the non-empty HF verify, and safe disk cleanup (one-off task dirs vs shared canonical tasks; leave Daytona snapshots). Use when a datagen/trace job finishes (COMPLETED or TIMEOUT) and its traces need uploading + verifying, or when consolidating a chunked datagen run. Distinct from RL/SFT cleanup (those publish a model checkpoint).
Format HPC job-status reports as box-drawing tables, bucketed by job type (RL · SFT · Datagen · Eval · Catch-all), with the right metric columns, signal thresholds, and red-flags per bucket. Use whenever reporting active/recently-terminated job status — during a cron sweep, an ad-hoc "how are my jobs doing", or a single-job progress update. Covers which metrics are mandatory (entropy + collapse signals for RL, not just step/reward/grad), where to pull live status (SFT .out vs trainer_log.jsonl), the RL collapse-warning rule, and which log lines are benign noise vs real faults. Cluster-agnostic — resolve paths, active clusters, and credentials from .agents/ops at execution time.
استنادا إلى تصنيف SOC المهني
| 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.
Before drafting, read:
.agents/skills/writing-style/SKILL.md.agents/skills/writing-style/issues.md.agents/skills/writing-style/ai-writing-donts.mdPick 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 |
<what is broken and its impact -- concrete symptoms or error messages>
Reproduce:
1. <step>
2. <step>
Expected: <what should happen instead>
<optional: concise evidence or confirmed root cause>
<what needs to be done and why -- enough context for anyone on the team>
Done when:
<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: At most 80 characters, optionally prefixed with a scope tag. State a
factual symptom for a bug (e.g. [training] Gradient accumulation drops the last microbatch) and an imperative outcome for a task (e.g. [training] Handle partial accumulation steps). Do not add bug:, task:, or another type
prefix.
Body: Use the section structure for the chosen kind (see above).
Rules for the body:
file:line links, not inline dumps.Description section.Done when criteria.Apply the writing-style final compression pass to the exact title and body that will be sent to GitHub. For a bug or task, verify the title is at most 80 characters. Every remaining sentence must add a symptom, impact, reproduction step, observation, expected behavior, or completion criterion.
This review is required even when the user explicitly asked to file the issue. It is an author self-check, not a request for approval.
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
issue_url="$(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.
After creating the issue, fetch its published text with
gh issue view "$issue_url" --json title,body and correct any text added or
altered by the publishing tool.
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.