@openhands/extensions 0.1.0 → 0.2.0

package/plugins/onboarding/skills/agent-readiness-report/scripts/scan_workflows.sh

@@ -0,0 +1,127 @@
+#!/usr/bin/env bash
+# Scan for Workflows & Automation signals (Pillar 3)
+# Helps the agent find relevant files — not a substitute for judgment.
+
+REPO="${1:-.}"
+cd "$REPO" 2>/dev/null || { echo "Cannot access $REPO"; exit 1; }
+
+echo "=== Pillar 3: Workflows & Automation ==="
+echo ""
+
+echo "-- Issue templates --"
+if [ -d .github/ISSUE_TEMPLATE ]; then
+  echo ".github/ISSUE_TEMPLATE/:"
+  ls -1 .github/ISSUE_TEMPLATE/ 2>/dev/null | while read f; do echo "  $f"; done
+else
+  echo "  (not found)"
+fi
+
+echo ""
+echo "-- PR template --"
+find . -maxdepth 3 -iname 'pull_request_template*' 2>/dev/null | sort
+[ -f .github/pull_request_template.md ] || echo "  (not found)"
+
+echo ""
+echo "-- Dependency update automation --"
+for f in .github/dependabot.yml .github/dependabot.yaml renovate.json .renovaterc \
+         .renovaterc.json renovate.json5; do
+  [ -f "$f" ] && echo "./$f"
+done
+
+echo ""
+echo "-- Release automation --"
+if [ -d .github/workflows ]; then
+  grep -ril 'release\|publish\|deploy' .github/workflows/ 2>/dev/null | while read f; do
+    echo "  $(basename "$f")"
+  done
+fi
+for f in .releaserc .releaserc.json .releaserc.yml release-please-config.json \
+         .goreleaser.yml .goreleaser.yaml; do
+  [ -f "$f" ] && echo "./$f"
+done
+
+echo ""
+echo "-- Branch protection signals --"
+# Can't check GitHub settings from filesystem, but look for merge queue triggers
+if [ -d .github/workflows ]; then
+  grep -rl 'merge_group' .github/workflows/ 2>/dev/null | while read f; do
+    echo "  merge_group trigger in $(basename "$f")"
+  done
+fi
+
+echo ""
+echo "-- Merge automation --"
+find . -maxdepth 2 -name '.mergify.yml' -o -name 'mergify.yml' 2>/dev/null | sort
+if [ -d .github/workflows ]; then
+  grep -rl 'auto-merge\|automerge\|gh pr merge' .github/workflows/ 2>/dev/null | head -3
+fi
+
+echo ""
+echo "-- Task runner --"
+for f in Makefile GNUmakefile makefile Justfile justfile Taskfile.yml taskfile.yml \
+         Rakefile Earthfile; do
+  [ -f "$f" ] && echo "./$f"
+done
+if [ -f package.json ]; then
+  script_count=$(python3 -c "import json; d=json.load(open('package.json')); print(len(d.get('scripts',{})))" 2>/dev/null)
+  [ -n "$script_count" ] && echo "  package.json: $script_count scripts"
+fi
+
+echo ""
+echo "-- Structured change tracking --"
+[ -d .changeset ] && echo ".changeset/ ($(ls .changeset/*.md 2>/dev/null | wc -l | tr -d ' ') pending changesets)"
+find . -maxdepth 2 -name 'commitlint.config.*' -o -name '.commitlintrc*' 2>/dev/null | sort
+if [ -d .github/workflows ]; then
+  grep -rl 'conventional-commits\|commitlint\|semantic-pull-request' .github/workflows/ 2>/dev/null | head -3
+fi
+
+echo ""
+echo "-- CI concurrency control --"
+if [ -d .github/workflows ]; then
+  concurrency_count=$(grep -rl 'concurrency:' .github/workflows/ 2>/dev/null | wc -l | tr -d ' ')
+  cancel_count=$(grep -rl 'cancel-in-progress' .github/workflows/ 2>/dev/null | wc -l | tr -d ' ')
+  echo "  $concurrency_count workflows with concurrency groups, $cancel_count with cancel-in-progress"
+fi
+
+echo ""
+echo "-- Automated release notes --"
+for f in release-please-config.json .github/release.yml cliff.toml .cliff.toml; do
+  [ -f "$f" ] && echo "./$f"
+done
+if [ -d .github/workflows ]; then
+  grep -rl 'auto-changelog\|conventional-changelog\|git-cliff\|release-please' .github/workflows/ 2>/dev/null | head -3
+fi
+
+echo ""
+echo "-- Stale issue management --"
+if [ -d .github/workflows ]; then
+  grep -rl 'stale' .github/workflows/ 2>/dev/null | while read f; do
+    echo "  $(basename "$f")"
+  done
+fi
+[ -f .github/stale.yml ] && echo ".github/stale.yml"
+
+echo ""
+echo "-- Label automation --"
+find . -maxdepth 3 -name 'labeler.yml' -o -name '.github/labeler.yml' -o -name 'label-sync*' 2>/dev/null | sort
+
+echo ""
+echo "-- Multi-platform CI --"
+if [ -d .github/workflows ]; then
+  grep -rl 'matrix:' .github/workflows/ 2>/dev/null | while read f; do
+    os_line=$(grep -A5 'matrix:' "$f" | grep -i 'os:' | head -1)
+    [ -n "$os_line" ] && echo "  $(basename "$f"): $os_line"
+  done
+fi
+
+echo ""
+echo "-- Deployment automation --"
+if [ -d .github/workflows ]; then
+  grep -ril 'deploy' .github/workflows/ 2>/dev/null | while read f; do
+    echo "  $(basename "$f")"
+  done
+fi
+[ -f vercel.json ] && echo "./vercel.json"
+[ -f netlify.toml ] && echo "./netlify.toml"
+[ -f fly.toml ] && echo "./fly.toml"
+[ -f render.yaml ] && echo "./render.yaml"

package/plugins/onboarding/skills/improve-agent-readiness/README.md

@@ -0,0 +1,19 @@
+# Improve Agent Readiness
+
+Take an agent readiness report and turn its gaps into concrete, repo-appropriate fixes.
+
+## Triggers
+
+This skill is activated by the following keywords:
+
+- `improve-agent-readiness`
+
+## Prerequisites
+
+An agent readiness report must already exist — either from running `agent-readiness-report` on the target repo or provided directly by the user. If no report exists, run the readiness report skill first.
+
+## What This Does
+
+1. **Reads the report** — identifies every missing feature across all five pillars
+2. **Proposes 5–10 high-impact fixes** — ranked by how directly each change helps an agent complete coding tasks, not by checklist coverage
+3. **Implements on request** — applies approved fixes with atomic commits, then updates the readiness report to reflect the new state

package/plugins/onboarding/skills/improve-agent-readiness/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: improve-agent-readiness
+description: Use an agent readiness report to identify and implement improvements that make a repository more agent-friendly. Proposes repo-appropriate fixes for each pillar, then implements them on request. Use after running a readiness report or when a user wants to improve their repo's AI-readiness.
+triggers:
+- improve-agent-readiness
+- agent onboarding
+---
+
+# Agent Onboarding
+
+Take a readiness report and turn its gaps into concrete, repo-appropriate fixes.
+
+## Prerequisites
+
+This skill expects an agent readiness report to already exist — either from
+running `agent-readiness-report` on this repo or provided by the user.  If no report
+exists, run the readiness report skill first.
+
+## How to run
+
+### Step 1: Read the report
+
+Identify every **✗** (missing) feature across all five pillars.
+
+### Step 2: Propose high-impact fixes
+
+Don't try to fix everything.  Pick the **5–10 changes that would help agents the
+most** across all pillars, ranked by impact.  Not every pillar needs to be
+represented — focus on what matters most for this repo.  The goal is to
+meaningfully improve the score, not to hit 74/74.
+
+**Ranking heuristic** — rank by how directly the change helps an agent complete a
+coding task in this repo:
+
+1. Things that unblock agents from working at all (AGENTS.md, build commands,
+   bootstrap scripts, dev environment setup)
+2. Things that give agents faster feedback on their work (pre-commit hooks, test
+   documentation, PR templates with checklists)
+3. Things that improve quality or process (CI caching, label automation, spell
+   checking, merge queues)
+4. Things that improve governance or compliance (SECURITY.md, CODEOWNERS,
+   actionlint, CodeQL)
+
+A single change that lets an agent build and test the project outranks a 2-for-1
+that addresses minor gaps.
+
+Proposals should fit **this specific repo**:
+
+- Look at the languages, frameworks, and tools already in use
+- Look at the project structure (monorepo vs single package, etc.)
+- Look at what's already partially in place (don't reinvent what exists)
+- Propose additions that match the repo's existing conventions and style
+
+For each proposal, include:
+- What to add or change
+- Where it goes (file path)
+- Which pillar(s) it improves
+- **Why it's high impact** — use the feature descriptions in
+  `references/criteria.md` to explain what goes wrong for agents without this
+  feature.  Don't just say "improves Agent Instructions" — say what the agent
+  can't do today and what it'll be able to do after the fix.
+
+### Step 3: Implement on request
+
+When the user approves fixes (all or a subset), implement them, then **update the
+readiness report** to reflect the new state.  Flip each addressed feature from ✗
+to ✓ and update the pillar counts and summary.  This ensures the next run of this
+skill won't re-propose fixes that have already been applied.
+
+Follow these rules:
+
+- **Don't generate boilerplate** — content should be specific to this repo
+- **Match existing style** — if the repo uses tabs, use tabs; if docs are in
+  RDoc, don't write Markdown
+- **Don't over-generate** — a concise, accurate AGENTS.md beats a long generic
+  one
+- **Commit atomically** — one commit per logical fix, not one giant commit
+
+## Pillar-specific guidance
+
+### Agent Instructions fixes
+
+The highest-impact fix is almost always an **agent instruction file** at the
+root.  A good one includes:
+
+- Build / test / lint commands (copy from CI config or Makefile, not invented)
+- Project structure overview (what's in each top-level directory)
+- Key conventions (naming, architecture patterns, things to avoid)
+- Where to find more documentation
+
+If the repo is a monorepo, also consider per-component instruction files that
+cover component-specific conventions.
+
+Other common fixes:
+- Add AI IDE configuration if the team uses Cursor, Copilot, or Claude Code
+- Create a contributing guide if one doesn't exist
+- Add `.env.example` if the project uses environment variables
+
+### Feedback Loops fixes
+
+Focus on what gives agents the fastest signal:
+
+- **Pre-commit hooks** are the single fastest feedback loop — configure them with
+  the linter and formatter the project already uses
+- **Test run documentation** in the agent instruction file — agents need to know
+  *exactly* which command runs which tests
+- If the project has no linter or formatter configured, propose one that matches
+  the language ecosystem (don't propose Prettier for a Go project)
+
+### Workflows & Automation fixes
+
+Focus on structure that helps agents understand the process:
+
+- **PR template** with a checklist — agents follow checklists well
+- **Issue templates** for bugs and features — gives agents structured input
+- **CI concurrency control** — prevents agent-triggered CI from piling up
+
+### Policy & Governance fixes
+
+Focus on boundaries the agent needs to know:
+
+- **CODEOWNERS** — agents should know who owns what before making changes
+- **Security policy** — agents need to know not to file public security issues
+- Agent-aware **.gitignore** entries — prevent agent config files from being
+  committed accidentally
+
+### Build & Dev Environment fixes
+
+Focus on reproducibility:
+
+- **Dependency lockfile** if one doesn't exist — agents can't work with
+  non-deterministic installs
+- **Tool version pinning** — prevents "works on my machine" failures
+- **Single-command setup** — document or script the full bootstrap
+
+## Output format
+
+Present proposals like this:
+
+```
+# Agent Onboarding Proposals: {repo name}
+
+Ranked by impact.  Implementing all of these would improve:
+Agent Instructions (+4), Feedback Loops (+2), Policy & Governance (+1)
+
+1. **Create AGENTS.md** — Agent Instructions
+   - Include build commands from Makefile, test commands from CI, project structure
+   - Path: `./AGENTS.md`
+   - Right now agents have no way to learn this repo's conventions, banned
+     patterns, or how to build/test — they'll guess and get it wrong.
+
+2. **Add pre-commit hooks** — Feedback Loops
+   - Configure with ruff (already in pyproject.toml) and mypy
+   - Path: `./.pre-commit-config.yaml`
+   - Agents currently don't find out about lint/type errors until CI runs.
+     Pre-commit hooks catch these in seconds instead of minutes.
+
+3. **Add .env.example** — Agent Instructions, Build & Dev Environment
+   - Document the 3 env vars referenced in docker-compose.yml
+   - Path: `./.env.example`
+   - Agents can't start the dev server without knowing which env vars to set.
+     They'll either skip setup or hallucinate values.
+
+...
+
+Ready to implement? Reply with "all" or specify which proposals to apply.
+```

package/plugins/onboarding/skills/setup-agents-md/README.md

@@ -0,0 +1,15 @@
+# Generate AGENTS.md
+
+Generate a high-quality, repo-specific AGENTS.md file that tells AI agents how to work effectively in a repository.
+
+## Triggers
+
+This skill is activated by the following keywords:
+
+- `setup-agents-md`
+
+## What This Does
+
+Reads the actual repository — Makefiles, CI configs, package.json scripts, linter configs, directory structure — and produces an AGENTS.md with real commands, real paths, and real conventions. Never generates generic boilerplate.
+
+Sections are included only when relevant: project overview, build/test/lint commands, project structure, coding standards, testing setup, and guardrails for things the agent must not do.

package/plugins/onboarding/skills/setup-agents-md/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: setup-agents-md
+description: Generate a high-quality, repo-specific AGENTS.md file that tells AI agents how to work effectively in a repository. Reads the actual repo to extract commands, structure, conventions, and guardrails — never generates generic boilerplate. Use when a user wants to create or improve their AGENTS.md, or after a readiness report identifies a missing agent instruction file.
+triggers:
+- setup-agents-md
+- agents-md
+---
+
+# Generate AGENTS.md
+
+Create a repo-specific AGENTS.md that gives AI agents the context they need to
+work effectively.  Every section should reference real commands, real paths, and
+real conventions from the repository — not generic advice.
+
+## Why this matters
+
+An AGENTS.md is the single highest-impact addition for agent readiness.  It
+directly addresses features across multiple pillars:
+
+- **Agent Instructions**: agent instruction file, README with build/run/test,
+  contributing guide, environment variable documentation
+- **Feedback Loops**: test run documentation — agents need exact commands
+- **Policy & Governance**: guardrails the agent must follow
+
+Without it, agents guess at build commands, miss project conventions, run the
+wrong test suite, and don't know what's dangerous.  The best AGENTS.md files
+share the same core pattern: real commands, clear structure, explicit boundaries.
+
+## How to run
+
+### Step 0: Check for an existing AGENTS.md
+
+Look for an existing `AGENTS.md` (or `.agents/AGENTS.md`) in the repo root.
+If one exists, **do not rewrite it from scratch**. Instead, read the repo
+(Step 1), compare what you find against what's already documented, and suggest
+specific additions or changes. Present the suggestions to the user and let them
+decide what to incorporate.
+
+If no file exists, proceed to create one.
+
+### Step 1: Read the repo
+
+Before writing anything, gather the actual information.  Check these sources:
+
+**Commands** (most important — agents need to know how to build, test, lint):
+- `Makefile` / `justfile` / `Taskfile.yml` — look for build/test/lint/format targets
+- `package.json` `scripts` — npm/yarn/pnpm run targets
+- `pyproject.toml` `[tool.prek]` / `[tool.pytest]` — Python tooling config
+- `.github/workflows/*.yml` — CI steps reveal the real commands
+- `Cargo.toml` — Rust build/test commands
+- `build.gradle` / `pom.xml` — Java/Kotlin build commands
+- `Rakefile` — Ruby task definitions
+- `docker-compose.yml` — service orchestration commands
+
+**Project structure**:
+- Top-level directory listing — what's in each major directory
+- Monorepo indicators: workspace configs, multiple package.json/Cargo.toml/pyproject.toml
+- Source vs test layout (where does code live, where do tests live)
+
+**Conventions**:
+- Existing linter/formatter configs (.eslintrc, .prettierrc, rustfmt.toml, .rubocop.yml, ruff.toml)
+- CONTRIBUTING.md — often contains coding standards
+- Existing README — architecture descriptions, setup instructions
+- `.editorconfig` — indentation/style basics
+
+**Guardrails**:
+- Database configs — identify destructive commands to warn about
+- CI enforcement — what must pass before merge
+- Secrets/env patterns — `.env.example`, vault configs
+- Branch protection or merge requirements
+
+### Step 2: Write the AGENTS.md
+
+Use this structure.  Every section is optional — include only what's relevant to
+this repo.  A 30-line file with real commands beats a 200-line file with generic
+advice.
+
+```markdown
+# AGENTS.md
+
+## Project overview
+
+One or two sentences: what this project is, what language/framework, and the
+high-level architecture (monorepo? client-server? library?).
+
+## Commands
+
+Organized by category.  Use the exact commands from the repo — copy from
+Makefile/CI/package.json, don't invent them.
+
+### Build
+### Test
+### Lint & format
+
+## Project structure
+
+What's in each top-level directory.  Focus on what an agent needs to navigate
+the codebase — not an exhaustive tree.
+
+## Coding standards
+
+Language-specific conventions that aren't captured by linter config.  Things
+like: naming patterns, import ordering preferences, test file location
+conventions, preferred patterns over anti-patterns.
+
+## Testing
+
+Where tests live, how they're organized, how to run a single test vs the full
+suite, any test database setup needed.
+
+## Guardrails
+
+Things the agent must NOT do.  Destructive commands, files that shouldn't be
+edited by hand, operations that require human approval.
+```
+
+### Key principles
+
+**Be specific, not generic.**  Don't write "run the linter before committing" —
+write `uv run ruff check --fix <file>`.  Don't write "follow the project's
+coding standards" — write "use `snake_case` for variables, no `assert` in
+production code."
+
+**Commands are king.**  If the agent only reads one section, it should be
+Commands.  Every command block should be copy-pasteable.
+
+**Link, don't repeat.**  If there's a detailed CONTRIBUTING.md or architecture
+doc, link to it rather than duplicating the content.  The AGENTS.md is an index
+and quick reference, not a manual.
+
+**Include dangerous operations.**  If `make db-reset` destroys the dev database,
+say so.  If `git push -f` to main is forbidden, say so.  Agents are literal —
+they need explicit guardrails.
+
+**Keep it maintainable.**  A short, accurate AGENTS.md is better than a long one
+that drifts out of date.  Reference CI configs and Makefiles by path so a human
+(or agent) can update the AGENTS.md when the underlying commands change.
+
+### What to leave out
+
+- Generic software engineering advice ("write clean code", "use meaningful names")
+- Process documentation that belongs in CONTRIBUTING.md
+- Full API documentation that belongs in doc comments or a docs site
+- Operational runbooks that belong in an ops directory
+
+### Monorepo considerations
+
+If the repo is a monorepo, the root AGENTS.md should cover repo-wide commands
+and conventions.  Consider sub-directory AGENTS.md files only for packages with
+substantially different commands or conventions, and link to them from the root.

package/plugins/onboarding/skills/setup-openhands/README.md

@@ -0,0 +1,20 @@
+# Set Up OpenHands
+
+Configure a repository for effective use with OpenHands in one pass.
+
+## Triggers
+
+This skill is activated by the following keywords:
+
+- `setup-openhands`
+- `set up openhands`
+- `configure openhands for this repo`
+
+## What This Does
+
+Walks through four steps to make a repo OpenHands-ready:
+
+1. **AGENTS.md** — generates a root-level agent instruction file with real commands and conventions from the repo
+2. **`.openhands/setup.sh`** — creates a bootstrap script that installs dependencies and sets up the environment at the start of every session
+3. **`.openhands/pre-commit.sh`** — creates a pre-commit script that mirrors CI checks so the agent gets fast feedback before pushing
+4. **PR review workflow** — adds a GitHub Actions workflow for automated code review on pull requests

package/plugins/onboarding/skills/setup-openhands/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: setup-openhands
+description: Set up a repository for effective use with OpenHands. Creates AGENTS.md, setup and pre-commit scripts, and a PR review workflow. Designed to run automatically with minimal user intervention. Use when a user wants to configure their repo for OpenHands.
+triggers:
+- setup-openhands
+- set up openhands
+- configure openhands for this repo
+---
+
+# Set Up OpenHands for a Repository
+
+Work through these steps in order.
+
+## Step 1: Create AGENTS.md
+
+Run `setup-agents-md` to generate a root-level `AGENTS.md` from the repo's actual
+CI workflows, build files, and documentation.
+
+## Step 2: Create `.openhands/setup.sh`
+
+Create `.openhands/setup.sh` — a bootstrap script that runs at the start of
+every OpenHands session. Read the repo's CI workflows, AGENTS.md, and build
+files to determine the correct commands. The script should:
+
+- Install dependencies (the project's actual install command)
+- Set required environment variables
+- Run any other bootstrap steps (e.g. copy `.env.example` to `.env`)
+
+Keep it idempotent and fast. Use the real commands from CI, not generic examples.
+
+**Docs**: https://docs.openhands.dev/openhands/usage/customization/repository#setup-script
+
+## Step 3: Create `.openhands/pre-commit.sh`
+
+Create `.openhands/pre-commit.sh` — runs before every commit OpenHands makes.
+Read the repo's CI workflows to find the lint and test commands, then mirror
+them in the script. Exit non-zero on failure so the agent gets immediate
+feedback instead of waiting for CI.
+
+The script should run the same checks CI runs — if CI runs `ruff check` and
+`pytest`, run those. If it runs `cargo clippy` and `cargo test`, run those.
+
+**Docs**: https://docs.openhands.dev/openhands/usage/customization/repository#pre-commit-script
+
+## Step 4: Set up PR review
+
+Run `setup-pr-review` to create the GitHub Actions workflow and walk the user
+through configuration.
+
+## Step 5: Verify
+
+Confirm all files exist and are correct:
+- `AGENTS.md` at repo root with real commands (not boilerplate)
+- `.openhands/setup.sh` with the project's actual install/bootstrap commands
+- `.openhands/pre-commit.sh` mirroring the CI lint/test checks
+- `.github/workflows/pr-review.yml` with valid YAML

package/plugins/onboarding/skills/setup-pr-review/README.md

@@ -0,0 +1,23 @@
+# Set Up PR Review
+
+Add automated AI code review to a GitHub repository.
+
+## Triggers
+
+This skill is activated by the following keywords:
+
+- `setup-pr-review`
+- `set up pr review`
+- `add code review workflow`
+- `openhands pr review`
+
+## What This Does
+
+Creates a `.github/workflows/pr-review.yml` file that triggers an OpenHands agent to review pull requests and post inline comments. Walks you through configuration options:
+
+- **Review style** — `roasted` (blunt, Torvalds-style) or `standard` (balanced)
+- **When to trigger** — on-demand (label or reviewer request) or automatic (every PR)
+- **Which model** — any litellm-supported model, with optional A/B testing
+- **Evidence requirement** — optionally require proof-of-work in PR descriptions
+
+You'll need to add an `LLM_API_KEY` secret to your repository settings — the skill tells you exactly where.

package/plugins/onboarding/skills/setup-pr-review/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: setup-pr-review
+description: Set up the OpenHands automated PR review workflow in a GitHub repository. Creates the workflow file and asks the user for configuration preferences. Use when a user wants AI code review on their pull requests.
+triggers:
+- setup-pr-review
+- set up pr review
+- add code review workflow
+- openhands pr review
+---
+
+# Set Up OpenHands PR Review
+
+Add the PR review workflow to a GitHub repository so an OpenHands agent can
+review pull requests and post inline comments.
+
+**Docs**: https://docs.all-hands.dev/sdk/guides/github-workflows/pr-review
+
+## Step 1: Create the workflow file
+
+Create `.github/workflows/pr-review.yml` in the target repo. Fetch the latest
+example from https://docs.all-hands.dev/sdk/guides/github-workflows/pr-review
+and use it as the starting template. The workflow calls the
+`OpenHands/extensions/plugins/pr-review` composite action directly.
+
+## Step 2: Configure the LLM
+
+Ask the user whether they are using the **OpenHands app** (app.all-hands.dev)
+or their **own LLM provider** (e.g. Anthropic, OpenAI directly).
+
+### OpenHands app (default)
+
+OpenHands app users already have access to an LLM API key through the
+OpenHands litellm proxy. Tell them:
+
+> Go to https://app.all-hands.dev → Account → API Keys → OpenHands LLM Key, and copy your key.
+> Then add it as a GitHub repository secret:
+> Settings → Secrets and variables → Actions → New repository secret.
+> Name it `LLM_API_KEY`.
+
+Set these inputs in the workflow `with:` block:
+- `llm-model: litellm_proxy/claude-sonnet-4-5-20250929`
+- `llm-base-url: https://llm-proxy.app.all-hands.dev`
+
+### Own LLM provider
+
+If the user has their own API key (e.g. from Anthropic or OpenAI), tell them
+to add it as a repository secret named `LLM_API_KEY` using the same path
+above. Leave `llm-base-url` unset and set `llm-model` to the provider-prefixed
+model name (e.g. `anthropic/claude-sonnet-4-5-20250929`).
+
+**You cannot create secrets — the user must do it manually.** Do not ask for
+the key value. Just tell them where to put it.
+
+## Step 3: Ask the user for preferences
+
+Present these options and apply any requested changes to the workflow file:
+
+**Review style** (default: `roasted`)
+- `roasted` — Linus Torvalds-style, blunt, focuses on data structures and
+  simplicity.
+- `standard` — balanced, covers style/readability/security.
+
+**When to trigger** (default: on-demand only)
+- On-demand: add `review-this` label or request `openhands-agent` as reviewer.
+- Automatic: review every new PR. Add `opened` and `ready_for_review` to
+  `on.pull_request.types` and matching conditions to the `if:` block.
+
+After applying these, ask the user if they want to explore additional options
+(model selection, evidence requirements, custom review skills, observability).
+If yes, walk them through it — use the docs as a reference:
+https://docs.all-hands.dev/sdk/guides/github-workflows/pr-review
+If not, you're done.

package/plugins/openhands/.plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "name": "openhands",
+  "version": "0.1.0",
+  "description": "Unified OpenHands plugin — bundles Cloud CLI, REST API, Automations, and Software Agent SDK skills into a single plugin.",
+  "author": {
+    "name": "OpenHands",
+    "email": "contact@all-hands.dev"
+  },
+  "homepage": "https://github.com/OpenHands/extensions",
+  "repository": "https://github.com/OpenHands/extensions",
+  "license": "MIT",
+  "keywords": ["openhands", "cloud", "api", "automation", "cli", "delegation", "sdk", "agent"]
+}