@openhands/extensions 0.0.1-alpha → 0.2.0

package/skills/jupyter/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: jupyter
+description: Read, modify, execute, and convert Jupyter notebooks programmatically. Use when working with .ipynb files for data science workflows, including editing cells, clearing outputs, or converting to other formats.
+triggers:
+- ipynb
+- jupyter
+---
+
+# Jupyter Notebook Guide
+
+Notebooks are JSON files. Cells are in `nb['cells']`, each has `source` (list of strings) and `cell_type` ('code', 'markdown', or 'raw').
+
+## Modifying Notebooks
+```python
+import json
+with open('notebook.ipynb') as f:
+    nb = json.load(f)
+# Modify nb['cells'][i]['source'], then:
+with open('notebook.ipynb', 'w') as f:
+    json.dump(nb, f, indent=1)
+```
+
+## Executing & Converting
+```bash
+jupyter nbconvert --to notebook --execute --inplace notebook.ipynb  # Execute in place
+jupyter nbconvert --to html notebook.ipynb      # Convert to HTML
+jupyter nbconvert --to script notebook.ipynb    # Convert to Python
+jupyter nbconvert --to markdown notebook.ipynb  # Convert to Markdown
+```
+
+## Finding Code
+```bash
+grep -n "search_term" notebook.ipynb
+```
+
+## Cell Structure
+```python
+# Code cell
+{"cell_type": "code", "execution_count": None, "metadata": {}, "outputs": [], "source": ["code\n"]}
+# Markdown cell
+{"cell_type": "markdown", "metadata": {}, "source": ["# Title\n"]}
+```
+
+## Clear Outputs
+```python
+for cell in nb['cells']:
+    if cell['cell_type'] == 'code':
+        cell['outputs'] = []
+        cell['execution_count'] = None
+```

package/skills/kubernetes/.plugin/plugin.json

@@ -0,0 +1,18 @@
+{
+  "name": "kubernetes",
+  "version": "1.0.0",
+  "description": "Set up and manage local Kubernetes clusters using KIND (Kubernetes IN Docker). Use when testing Kubernetes applications locally or developing cloud-native workloads.",
+  "author": {
+    "name": "OpenHands",
+    "email": "contact@all-hands.dev"
+  },
+  "homepage": "https://github.com/OpenHands/extensions",
+  "repository": "https://github.com/OpenHands/extensions",
+  "license": "MIT",
+  "keywords": [
+    "kubernetes",
+    "k8s",
+    "kind",
+    "cloud-native"
+  ]
+}

package/skills/kubernetes/README.md

@@ -0,0 +1,53 @@
+# Kubernetes
+
+Set up and manage local Kubernetes clusters using KIND (Kubernetes IN Docker). Use when testing Kubernetes applications locally or developing cloud-native workloads.
+
+## Triggers
+
+This skill is activated by the following keywords:
+
+- `kubernetes`
+- `k8s`
+- `kube`
+
+## Details
+
+# Kubernetes Local Development with KIND
+
+## KIND Installation and Setup
+
+KIND (Kubernetes IN Docker) is a tool for running local Kubernetes clusters using Docker containers as nodes. It's designed for testing Kubernetes applications locally.
+
+IMPORTANT: Before you proceed with installation, make sure you have docker installed locally.
+
+### Installation
+
+To install KIND on a Debian/Ubuntu system:
+
+```bash
+# Download KIND binary
+curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.22.0/kind-linux-amd64
+# Make it executable
+chmod +x ./kind
+# Move to a directory in your PATH
+sudo mv ./kind /usr/local/bin/
+```
+
+To install kubectl:
+
+```bash
+# Download kubectl
+curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
+# Make it executable
+chmod +x kubectl
+# Move to a directory in your PATH
+sudo mv ./kubectl /usr/local/bin/
+```
+
+### Creating a Cluster
+
+Create a basic KIND cluster:
+
+```bash
+kind create cluster
+```

package/skills/kubernetes/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: kubernetes
+description: Set up and manage local Kubernetes clusters using KIND (Kubernetes IN Docker). Use when testing Kubernetes applications locally or developing cloud-native workloads.
+triggers:
+- kubernetes
+- k8s
+- kube
+---
+
+# Kubernetes Local Development with KIND
+
+## KIND Installation and Setup
+
+KIND (Kubernetes IN Docker) is a tool for running local Kubernetes clusters using Docker containers as nodes. It's designed for testing Kubernetes applications locally.
+
+IMPORTANT: Before you proceed with installation, make sure you have docker installed locally.
+
+### Installation
+
+To install KIND on a Debian/Ubuntu system:
+
+```bash
+# Download KIND binary
+curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.22.0/kind-linux-amd64
+# Make it executable
+chmod +x ./kind
+# Move to a directory in your PATH
+sudo mv ./kind /usr/local/bin/
+```
+
+To install kubectl:
+
+```bash
+# Download kubectl
+curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
+# Make it executable
+chmod +x kubectl
+# Move to a directory in your PATH
+sudo mv ./kubectl /usr/local/bin/
+```
+
+### Creating a Cluster
+
+Create a basic KIND cluster:
+
+```bash
+kind create cluster
+```

package/skills/learn-from-code-review/.plugin/plugin.json

@@ -0,0 +1,19 @@
+{
+  "name": "learn-from-code-review",
+  "version": "1.0.0",
+  "description": "Distill code review feedback from GitHub PRs into reusable skills and guidelines. Use when users ask to learn from code reviews, extract review patterns, or generate coding standards from historica...",
+  "author": {
+    "name": "OpenHands",
+    "email": "contact@all-hands.dev"
+  },
+  "homepage": "https://github.com/OpenHands/extensions",
+  "repository": "https://github.com/OpenHands/extensions",
+  "license": "MIT",
+  "keywords": [
+    "code-review",
+    "learning",
+    "skills",
+    "guidelines",
+    "pr-feedback"
+  ]
+}

package/skills/learn-from-code-review/README.md

@@ -0,0 +1,64 @@
+# Learn from Code Review
+
+Distill code review feedback from GitHub pull requests into reusable skills and repository guidelines.
+
+## What It Does
+
+This skill analyzes PR review comments from a repository and extracts recurring patterns of feedback. These patterns are then transformed into:
+
+- **Repository-specific skills** (`.openhands/skills/`) for domain-specific patterns
+- **AGENTS.md updates** for general coding conventions and best practices
+
+## When to Use
+
+- "Learn from our code reviews"
+- "Distill PR feedback into guidelines"
+- "What patterns do reviewers keep pointing out?"
+- "Generate coding standards from review history"
+- Running `/learn-from-reviews`
+
+## Requirements
+
+- `GITHUB_TOKEN` environment variable
+- GitHub CLI (`gh`) available
+
+## Example
+
+```
+User: Learn from our code reviews over the past month
+
+Agent: I'll analyze recent PR review comments and distill them into actionable guidelines.
+
+[Analyzes 25 merged PRs with 150 review comments]
+[Filters out bot comments and low-signal responses]
+[Identifies 4 recurring patterns]
+
+Found the following patterns from code review feedback:
+
+1. Error Handling (12 comments)
+   - Always include context when logging errors
+   - Use structured error responses in APIs
+
+2. Testing (8 comments)
+   - Add edge case tests for validation logic
+   - Mock external services consistently
+
+3. Database Queries (6 comments)
+   - Use parameterized queries exclusively
+   - Add appropriate indexes for new queries
+
+I'll create a draft PR with:
+- New skill: `.openhands/skills/error-handling/SKILL.md`
+- Updates to `AGENTS.md` with testing and database guidelines
+```
+
+## Output
+
+The skill generates a draft PR containing proposed changes based on the analysis. Human review is expected before merging.
+
+## Related Skills
+
+- `github-pr-review` - Post structured code reviews
+- `code-review` - Perform code reviews
+- `skill-creator` - Create new skills manually
+- `agent-memory` - Persist repository knowledge

package/skills/learn-from-code-review/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: learn-from-code-review
+description: Distill code review feedback from GitHub PRs into reusable skills and guidelines. This skill should be used when users ask to "learn from code reviews", "distill PR feedback", "improve coding standards", "extract learnings from reviews", or want to generate skills/guidelines from historical review comments.
+triggers:
+- /learn-from-reviews
+- learn from code review
+- distill reviews
+---
+
+# Learn from Code Review
+
+Analyze code review comments from GitHub pull requests and distill them into reusable skills or repository guidelines that improve future code quality.
+
+## Overview
+
+Code review feedback contains valuable institutional knowledge that often gets buried across hundreds of PRs. This skill extracts meaningful patterns from review comments and transforms them into:
+
+1. **Repository-specific skills** - Placed in `.openhands/skills/` for domain-specific patterns
+2. **AGENTS.md guidelines** - Overall repository conventions and best practices
+
+## Prerequisites
+
+- `GITHUB_TOKEN` environment variable must be set
+- GitHub CLI (`gh`) should be available
+
+## Workflow
+
+### Step 1: Identify Target Repository
+
+Determine the repository to analyze:
+
+```bash
+# Get current repo info
+gh repo view --json nameWithOwner -q '.nameWithOwner'
+```
+
+If not in a repository, ask the user which repository to analyze.
+
+### Step 2: Fetch Review Comments
+
+Retrieve PR review comments from the repository:
+
+```bash
+# Fetch merged PRs from the last 30 days (adjustable)
+gh pr list --repo {owner}/{repo} \
+  --state merged \
+  --limit 50 \
+  --json number,title,mergedAt
+
+# For each PR, fetch review comments
+gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
+  --jq '.[] | {body: .body, path: .path, user: .user.login, created_at: .created_at}'
+
+# Also fetch review-level comments (not tied to specific lines)
+gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews \
+  --jq '.[] | select(.body != "") | {body: .body, user: .user.login, state: .state}'
+```
+
+### Step 3: Filter and Categorize Comments
+
+Apply noise filtering to keep only meaningful feedback:
+
+**Exclude:**
+- Bot comments (dependabot, copilot, github-actions, etc.)
+- Low-signal responses ("LGTM", "+1", "looks good", "thanks", "nice")
+- Comments shorter than 30 characters
+- Auto-generated comments (CI status, coverage reports)
+
+**Categorize remaining comments by:**
+- Security concerns
+- Performance patterns
+- Code style/conventions
+- Architecture/design patterns
+- Error handling
+- Testing requirements
+- Documentation standards
+
+### Step 4: Distill Patterns
+
+For each category with sufficient examples (3+ similar comments), identify:
+
+1. **The recurring issue** - What mistake or oversight keeps appearing
+2. **The desired pattern** - What reviewers consistently ask for
+3. **Example context** - Concrete before/after code snippets when available
+
+### Step 5: Generate Output
+
+If clear, actionable patterns emerge, generate focused skill files. If no clear patterns emerge, report this to the user—it's fine to produce no output when the codebase already has strong conventions or when review comments don't cluster into recurring themes.
+
+When creating skills, place them in `.openhands/skills/{domain-name}/SKILL.md`:
+
+```yaml
+---
+name: database-queries
+description: Database query patterns and best practices for this repository.
+---
+
+# Database Query Guidelines
+
+### Always Use Parameterized Queries
+[Pattern description with examples]
+
+### Connection Pool Management
+[Pattern description with examples]
+```
+
+Prefer skills over AGENTS.md updates, since AGENTS.md typically already contains general coding guidelines.
+
+### Step 6: Create Draft PR (if applicable)
+
+Use the `create_pr` tool to open a draft PR with the proposed changes. The PR description should include:
+- Number of PRs analyzed
+- Number of comments processed
+- Categories of patterns found
+- List of proposed changes (new skills and/or AGENTS.md updates)
+
+## Example Output
+
+### Sample Skill: API Error Handling
+
+```yaml
+---
+name: api-error-handling
+description: API error handling patterns for this repository.
+---
+
+# API Error Handling
+
+## Always Return Structured Errors
+
+❌ Avoid:
+```python
+return {"error": str(e)}
+```
+
+✅ Prefer:
+```python
+return {
+    "error": {
+        "code": "VALIDATION_ERROR",
+        "message": "Invalid input",
+        "details": {"field": "email", "reason": "Invalid format"}
+    }
+}
+```
+
+## Log Before Returning Errors
+
+```python
+logger.error(f"API error in {endpoint}: {e}", exc_info=True)
+return error_response(e)
+```
+```
+
+## Defaults
+
+This workflow analyzes PRs from the past 30 days by default.
+
+## Best Practices
+
+1. **Run periodically** - Schedule monthly or quarterly to capture evolving patterns
+2. **Review before merging** - Generated content is a draft; human review is essential
+3. **Iterate** - Refine patterns based on team feedback
+4. **Avoid duplication** - Check existing AGENTS.md and skills before adding
+5. **Cite sources** - Reference PR numbers when documenting patterns
+
+## Error Handling
+
+Handle these common edge cases gracefully:
+
+- **Repository has few PRs**: If fewer than 10 merged PRs exist in the timeframe, inform the user that there may not be enough data to identify patterns. Proceed with analysis but note the limited sample size.
+- **No patterns emerge**: When comments don't cluster into recurring themes (common for well-established codebases), report this to the user and suggest either expanding the time range or that the codebase may already have strong conventions.
+- **Token lacks repository access**: If the GitHub API returns 403/404, explain that the token may not have access to the repository and suggest checking token permissions.
+- **`gh` CLI unavailable**: Fall back to direct GitHub API calls using `curl` with `$GITHUB_TOKEN`, or inform the user that `gh` needs to be installed.
+
+## Limitations
+
+- Only analyzes accessible repositories (requires appropriate permissions)
+- Cannot capture verbal feedback from pair programming or meetings
+- Patterns may reflect individual reviewer preferences vs. team consensus
+- Historical comments may reference outdated code patterns
+
+## Additional Resources
+
+For posting structured code reviews, see the `github-pr-review` skill.
+For creating new skills, see the `skill-creator` skill.

package/skills/learn-from-code-review/commands/learn-from-reviews.md

@@ -0,0 +1,8 @@
+---
+# auto-generated by sync_extensions.py
+description: Distill code review feedback from GitHub PRs into reusable skills and guidelines. This skill should be used when users ask to "learn from code reviews", "distill PR feedback", "improve coding standards", "extract learnings from reviews", or want to generate skills/guidelines from historical review comments.
+---
+
+Read and follow the complete instructions in the SKILL.md file located in this skill's directory.
+
+$ARGUMENTS

package/skills/linear/.plugin/plugin.json

@@ -0,0 +1,19 @@
+{
+  "name": "linear",
+  "version": "1.0.0",
+  "description": "Interact with Linear project management - query issues, update status, create tickets using the Linear GraphQL API.",
+  "author": {
+    "name": "OpenHands",
+    "email": "contact@all-hands.dev"
+  },
+  "homepage": "https://github.com/OpenHands/extensions",
+  "repository": "https://github.com/OpenHands/extensions",
+  "license": "MIT",
+  "keywords": [
+    "linear",
+    "ticket",
+    "issue",
+    "project-management",
+    "graphql"
+  ]
+}

package/skills/linear/README.md

@@ -0,0 +1,58 @@
+# Linear
+
+Interact with Linear project management - query issues, update status, create tickets, and manage workflows using the Linear GraphQL API. Use when working with Linear tickets, sprints, or project tracking.
+
+## Triggers
+
+This skill is activated by the following keywords:
+
+- `linear`
+- `ticket`
+- `issue tracking`
+
+## Details
+
+You need access to an environment variable, `LINEAR_API_KEY`, which allows you to interact with the Linear API.
+
+<IMPORTANT>
+You can use `curl` with the `LINEAR_API_KEY` to interact with Linear's GraphQL API.
+ALWAYS use the Linear API for operations instead of a web browser.
+Before performing any Linear operations, verify the API key is available by checking the environment variable.
+</IMPORTANT>
+
+## Features
+
+- **Query Issues**: Get assigned issues, filter by priority, search by identifier
+- **Update State**: Change issue status with workflow state lookup
+- **Comments**: Add comments to issues
+- **Create Issues**: Create new tickets with proper team assignment
+- **Reference**: Priority levels, state types, API documentation links
+
+## Important Concepts
+
+### Linear Identifiers
+
+Linear uses two types of identifiers for issues:
+
+- **Human-readable identifier** (e.g., `ALL-1234`): Displayed to users, used in search queries
+- **UUID** (e.g., `a1b2c3d4-e5f6-7890-abcd-ef1234567890`): Required for all mutations
+
+**Important workflow**: When updating issues:
+1. Search using the human-readable identifier
+2. Extract the UUID from the query result
+3. Use the UUID in mutation operations
+
+### Priority Levels
+
+| Priority | Label | Description |
+|----------|-------|-------------|
+| 1 | Urgent | Work on immediately |
+| 2 | High | Work on first |
+| 3 | Medium | Normal priority |
+| 4 | Low | When time permits |
+| 0 | None | Backlog |
+
+## Documentation
+
+- [Linear API Documentation](https://developers.linear.app/docs/graphql/working-with-the-graphql-api)
+- [GraphQL Schema Reference](https://studio.apollographql.com/public/Linear-API/variant/current/schema/reference)