work-on-issue

$npx mdskill add huggingface/OpenEnv/work-on-issue

Starts focused work on GitHub issues using TDD workflow

  • Parses GitHub issue number from input arguments
  • Uses issue-worker agent to extract requirements and test criteria
  • Creates isolated worktree with tdd-state.sh for test-driven development
  • Returns structured JSON with worktree location and TDD session status

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

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.
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.