---
name: fix-art-issues
description: >
  Fix a GitHub issue on OpenPipe/ART and open a PR.
  Use when the user asks to fix, solve, or work on an ART issue,
  or references a GitHub issue URL containing "OpenPipe/ART".
  Triggers: "fix ART issue", "solve this issue" with an OpenPipe/ART URL,
  "work on ART #N".
---

# Fix ART Issue

Fix a GitHub issue on `OpenPipe/ART` and open a PR.

- **Repo**: `OpenPipe/ART`
- **Base branch**: `main`

Assumes the workspace is already set up with the correct branch checked out and `.env` in place (handled by the system-level `fix-art-workspace` skill).

## Workflow

### 1. Read the Issue
```
gh issue view <number> --repo OpenPipe/ART --json title,body,labels,assignees,comments
```

### 2. Explore, Plan, Implement
- Use the Explore agent to understand relevant code before making changes.
- Plan clearly, implement with minimal focused changes. No over-engineering.

### 3. Commit and Push
- Commit with a message that includes `Closes #<issue-number>`.
- Push the feature branch. If HTTPS push fails due to SAML SSO, set SSH remote: `git remote set-url origin git@github.com:OpenPipe/ART.git`

### 4. Open a Draft PR
- `gh pr create --base main --draft`.
- PR body: `## Summary`, `Closes #<number>`, `## Changes`, `## Test plan`.

### 5. Testing
- **No test artifacts in the final PR**: debug prints, test scripts, and temporary changes must NOT be committed.
- Update the PR's test plan section with detailed results.
- When testing passes, mark the PR as ready: `gh pr ready`.

## Reference

Read `CONTRIBUTING.md` at the repo root for guidance on code quality checks (prek), CI cache refresh, and the release process.

## Dependency Management Tips

- **Pin versions strictly** (`==`) for critical deps like `transformers`, `trl`, `unsloth`, `unsloth-zoo`, `vllm` to avoid surprise breakage from new releases.
- **Don't loosen pins without reason**: if a dep was `==X.Y.Z`, keep it pinned unless there's a specific reason to change. Don't use `>=` just because it seems more flexible.
- **`uv run` fails on macOS** for backend deps (apex/torch need CUDA). This is expected — use `uvx ruff` for linting locally, test on GPU cluster.

## Deploying a GPU Cluster

Name the SkyPilot cluster after the branch name without the `fix/` prefix, replacing `/` with `-` (SkyPilot doesn't allow slashes). For example, if the branch is `fix/short-description`:
```
uv run sky launch -c short-description skypilot-config.yaml -y
```

To connect: `ssh short-description`

To tear down when done: `uv run sky down short-description`

## GPU Cluster Testing Tips

- **Kill stale GPU processes** before re-running tests: `nvidia-smi --query-compute-apps=pid --format=csv,noheader | xargs -r kill -9`. Previous failed runs leave processes holding GPU memory.
- **Set `gpu_memory_utilization`** in test scripts (e.g. `0.7`) — the default `0.9` is too high when Unsloth's training model is also loaded on the same GPU.
- **Redirect test output to a log file**: `nohup python test.py > /tmp/output.log 2>&1 &` then `tail -f /tmp/output.log`. SSH background tasks lose output when connection drops.
- **Git on cluster**: SSH keys may not be configured. Use HTTPS with token: `git remote set-url origin https://${GITHUB_TOKEN}@github.com/OpenPipe/ART.git`
- **Tear down clusters** when done: `sky down <cluster-name> -y`

$ARGUMENTS