OpenHands / OpenHands/extensions

docs(review): define extension-specific review checkpoints

Open
#609 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement ready-for-dev
Dominant language
Python
Stars
148
Forks
90
Avg merge
1d 17h
Merged PRs (30d)
36

Description

Problem

The repository-specific review guide covers ownership and two documentation policies but omits recurring extension risks: executable setup instructions, local/cloud runtime parity, untrusted trigger authorization, generated-source direction, and factual documentation claims.

The review corpus includes bad approvals for hallucinated install commands, incorrect runtime environment variables, unauthenticated comment triggers, and documentation that reversed the source/generated data flow.

Desired Behavior

The repository guide and AGENTS.md should describe concise, matching checkpoints that extension authors can satisfy before review.

Acceptance Criteria
  • Add stable checkpoints for executable instructions, trigger authorization, sources of truth, documentation, and dependencies.
  • Keep content PRs focused on one extension or one genuinely shared mechanism.
  • Add matching contributor guidance to AGENTS.md.
  • Suppress optional prose, tone, and refactor comments without a concrete failure.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the repository-specific review guide and reading AGENTS.md to compare their existing documentation policies. Add matching, concise checkpoints for executable instructions, authorization, sources of truth, documentation claims, dependencies, and focused content PRs; done means both documents contain the agreed guidance and the acceptance criteria are satisfied.

Written by the indexing model from the issue text.

Assessment

Domain
developer-experience, documentation
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.