rfc-check
$
npx mdskill add huggingface/OpenEnv/rfc-checkDetermine if proposed changes require an RFC (Request for Comments).
SKILL.md
.github/skills/rfc-checkView on GitHub ↗
--- name: rfc-check description: Determine if proposed changes require an RFC. Use when planning significant changes, before starting major work, or when asked whether an RFC is needed. allowed-tools: Read, Grep, Glob --- # RFC Check Determine if proposed changes require an RFC (Request for Comments). ## Instructions 1. **Identify changed files** using `git diff --name-only` or provided context 2. **Apply RFC criteria**: **RFC Required**: - New APIs in `src/openenv/core/` - Breaking changes to existing APIs - New abstractions or design patterns - Changes affecting the two-interface model (WebSocket/MCP separation) - Major architectural decisions **RFC Not Required**: - Bug fixes - Documentation updates - Minor refactoring (no API changes) - New example environments (unless introducing new patterns) - Dependency updates - Test additions 3. **Check against existing RFCs** in `rfcs/` for conflicts or dependencies ## Analysis Steps 1. List all files being changed 2. Identify any files in `src/openenv/core/` 3. Check for public API signature changes 4. Look for new abstractions or patterns 5. Review existing RFCs for related decisions ## Output Format ``` ## RFC Analysis ### Files Changed - [list of files] ### Core Files Touched - [any files in src/openenv/core/, or "None"] ### API Changes - [any signature changes to public APIs, or "None"] ### New Patterns/Abstractions - [any new patterns introduced, or "None"] ### Verdict: NOT REQUIRED / RECOMMENDED / REQUIRED ### Reasoning [Explanation of decision based on criteria above] ### If RFC Needed - Suggested title: "RFC NNN: [title]" - Related RFCs: [list any related existing RFCs] - Key decisions to document: [list] ``` ## RFC Template Reference If an RFC is needed, use the template in `rfcs/README.md`: ```markdown # RFC NNN: Title **Status**: Draft **Created**: YYYY-MM-DD **Authors**: @username ## Summary [1-2 paragraph overview] ## Motivation [Problem Statement + Goals] ## Design [Architecture Overview, Core Abstractions, Key Design Decisions] ## Examples [Code samples demonstrating usage] ```
More from huggingface/OpenEnv
- 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.
- pre-submit-prValidate 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.
- releaseRelease workflow for deploying OpenEnv environments to Hugging Face Spaces and keeping canonical references in sync.
- 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.