work-on-issue
$
npx mdskill add huggingface/OpenEnv/work-on-issueStart focused work on a GitHub issue using TDD workflow.
SKILL.md
.github/skills/work-on-issueView on GitHub ↗
---
name: work-on-issue
description: Start work on a GitHub issue. Extracts requirements, creates worktree, sets up TDD workflow.
---
# /work-on-issue
Start focused work on a GitHub issue using TDD workflow.
## EXECUTE THESE STEPS NOW
When this skill is invoked, you MUST execute these steps immediately. Do NOT just describe what will happen - actually do it.
### Step 1: Parse Issue Number
Extract the issue number from `$ARGUMENTS`:
- Remove `#` prefix if present
- The issue number is: **$ARGUMENTS**
### Step 2: Spawn Issue Worker Agent
Use the Task tool to spawn the issue-worker agent:
```
Task tool:
subagent_type: issue-worker
prompt: "Read GitHub issue #<NUMBER> and extract:
1. Goal - what the user wants to achieve
2. Acceptance criteria - specific testable requirements
3. Edge cases and constraints
4. Suggested PR split if complex"
```
Wait for the agent to return requirements.
### Step 3: Create Worktree
After receiving requirements, run this command:
```bash
.claude/scripts/worktree-create.sh issue-<NUMBER>-<short-description>
```
Where `<short-description>` is 2-3 words from the goal (e.g., `add-mcp-tools`).
### Step 4: Activate TDD Enforcement
Activate TDD enforcement in the new worktree. This uses `tdd-state.sh`'s
direct-execution mode so it works in a single Bash call:
```bash
cd .worktrees/issue-<NUMBER>-<short-description> && bash .claude/hooks/tdd-state.sh activate <NUMBER>
```
This writes `.tdd-session.json` to the worktree root, which all hooks check.
Without this step, hooks would not block direct edits.
### Step 5: Create Todos
Use TodoWrite to create a todo for EACH acceptance criterion:
```
TodoWrite:
todos:
- content: "Test: <acceptance criterion 1>"
status: pending
activeForm: "Testing <criterion 1>"
- content: "Test: <acceptance criterion 2>"
status: pending
activeForm: "Testing <criterion 2>"
...
```
### Step 6: Begin TDD Cycle
Immediately invoke `/write-tests` for the first todo.
DO NOT stop and wait for user input. Start the TDD cycle now.
---
## When to Use
- Starting work on a GitHub issue
- You want TDD enforcement (opt-in via this skill)
- You want isolated work (no branch switching)
## When NOT to Use
- Quick exploration (just stay in main repo)
- Already in a worktree for this issue
- Issue doesn't exist in GitHub
## Workflow Overview
```
/work-on-issue #42
↓
Step 1: Parse "42" from arguments
↓
Step 2: Spawn issue-worker → get requirements
↓
Step 3: Create worktree issue-42-<name>
↓
Step 4: Activate TDD enforcement (.tdd-session.json)
↓
Step 5: Create todos from acceptance criteria
↓
Step 6: Invoke /write-tests → begin TDD cycle
```
## Important
This skill runs in the MAIN conversation context (not forked) because it needs to:
1. Spawn the issue-worker agent and receive its results
2. Run worktree-create.sh script
3. Create todos that persist in the conversation
4. Invoke /write-tests to continue the workflow
The issue-worker agent runs in a forked context and returns requirements.
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.
- 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.