pre-submit-pr

$npx mdskill add huggingface/OpenEnv/pre-submit-pr

Validates code changes before submitting a pull request

  • Ensures code is ready for review with linting, tests, and alignment checks
  • Uses Git, Bash scripts, and repository files for validation
  • Compares changes against principles, invariants, and existing RFCs
  • Reports issues and confirms readiness for pull request submission

SKILL.md

.github/skills/pre-submit-prView on GitHub ↗
---
name: pre-submit-pr
description: Validate changes before submitting a pull request. Run comprehensive checks including lint, tests, alignment review, and RFC analysis. Use before creating a PR, when asked if code is ready for review, or before pushing for PR.
allowed-tools: Read, Grep, Glob, Bash
---

# Pre-Submit PR Check

Comprehensive validation before submitting a pull request. Run this before creating or updating a PR.

## Instructions

1. **Check branch freshness** (BLOCKING):
   - Run `git fetch origin main` to get latest main
   - Run `git rev-list --count HEAD..origin/main` to check commits behind
   - If > 0 commits behind, merge main before proceeding: `git merge origin/main`
   - This prevents "branch out of date" issues on GitHub

2. **Run all automated hooks**:
   - `bash .claude/hooks/lint.sh` - format check (includes ruff format + ruff check)
   - `bash .claude/hooks/test.sh` - run tests
   - `bash .claude/hooks/check-debug.sh` - find debug code

3. **Run alignment review**:
   - Read `.claude/docs/PRINCIPLES.md` and `.claude/docs/INVARIANTS.md`
   - Compare changes against principles and invariants
   - Identify Tier 1 (mechanical) and Tier 2 (alignment) issues

4. **RFC check**:
   - If changes touch `src/openenv/core/`, flag for RFC consideration
   - If any public API signatures change, RFC required
   - Check against existing RFCs in `rfcs/` for conflicts

5. **Documentation freshness check**:
   - Review `.claude/docs/REPO_WALKTHROUGH.md` against the current repo structure
   - If the PR adds new directories, moves files, or changes structure significantly:
     - Update REPO_WALKTHROUGH.md to reflect the changes
     - Include these updates in the PR
   - Check triggers: new directories in `src/`, `envs/`, `.claude/`, or `rfcs/`
   - Check if any public API signatures changed (function/class renames, new params):
     - Search for references in docs/, examples/, README.md, other .py docstrings
     - If stale references found, recommend running `/update-docs` before PR

6. **Summarize PR readiness**:
   - List all blocking issues
   - List all discussion points for reviewers
   - Provide overall verdict

7. **After push/PR creation**, run the post-push check:
   - `bash .claude/hooks/post-push-pr.sh`
   - Verifies: PR is open, no merge conflicts, branch freshness,
     PR description quality, CI check status

## Output Format

```
## Pre-Submit PR Report

### Branch Freshness
| Check | Status | Details |
|-------|--------|---------|
| Up to date with main | YES/NO | [X commits behind, merged if needed] |

### Automated Checks
| Check | Status | Details |
|-------|--------|---------|
| Lint | PASS/FAIL | [summary] |
| Tests | PASS/FAIL | [X passed, Y failed] |
| Debug code | CLEAN/FOUND | [details] |

### Alignment Review

#### Tier 1: Fixes Required (blocking)
- [ ] path/file.py:123 - [issue description]

#### Tier 2: Discussion Points (flag for reviewers)
[ALIGNMENT FLAGS or "None identified"]

### Invariant Check
[List any invariants at risk, or "All invariants maintained"]

### RFC Status
[NOT REQUIRED / RECOMMENDED / REQUIRED: reason]

### Documentation Freshness
[UP TO DATE / UPDATED: list of changes made to REPO_WALKTHROUGH.md]
[STALE DOCS: run /update-docs — list of stale references found]

### Verdict: READY FOR PR / ISSUES TO ADDRESS

### Summary for PR Description
[2-3 sentences summarizing changes for the PR description]
```

## Blocking Issues

The following issues block PR submission:
- Branch out of date with main (must merge first)
- Lint failures
- Test failures
- Debugger statements (breakpoint, pdb)
- Invariant violations
- RFC required but not written

## Non-Blocking (Flag for Reviewers)

These should be noted in PR but don't block:
- Alignment discussion points (Tier 2)
- RFC recommended (optional)
- TODOs in code
- Print statements (unless in core code)

More from huggingface/OpenEnv

SkillDescription
alignment-reviewReview code changes for bugs and alignment with OpenEnv principles and RFCs. Use when reviewing PRs, checking code before commit, or when asked to review changes. Implements two-tier review model.
deploy-hfDeploy an OpenEnv environment to Hugging Face Spaces. Use when asked to deploy, push to Hugging Face, or update a space.
generate-openenv-envGenerate OpenEnv environments from a concrete use case (for example, "generate an env for the library textarena"). Use when asked to design or implement a new environment under envs/ by researching a target library/API, selecting matching OpenEnv examples, asking key implementation questions, and building models/client/server/openenv.yaml. Do not use for model training or evaluation tasks.
hf-space-recoveryDiagnose and recover failing or stuck Hugging Face Space deployments for OpenEnv environments. Use when deploying envs from `envs/` to the Hub (`openenv` namespace with version suffixes), when Spaces are in `BUILDING`/`APP_STARTING`/`RUNTIME_ERROR`, or when release collections need to be reconciled after targeted redeploys.
implementMake tests pass. Invoke after /write-tests produces failing tests.
openenv-cliOpenEnv CLI (`openenv`) for scaffolding, validating, building, and pushing OpenEnv environments.
releaseRelease workflow for deploying OpenEnv environments to Hugging Face Spaces and keeping canonical references in sync.
rfc-checkDetermine if proposed changes require an RFC. Use when planning significant changes, before starting major work, or when asked whether an RFC is needed.
simplifyRefactor code after tests pass. The "Refactor" phase of Red-Green-Refactor.
sprintWork on a batch of GitHub issues in parallel using Agent Teams. Creates one worktree per issue with TDD enforcement, coordinates via a lead agent, then produces stacked PRs.