openhands-extensions 0.7.1__tar.gz → 0.8.0__tar.gz

openhands_extensions-0.8.0/.release-please-manifest.json

@@ -0,0 +1,3 @@
+{
+  ".": "0.8.0"
+}

{openhands_extensions-0.7.1 → openhands_extensions-0.8.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: openhands-extensions
-Version: 0.7.1
+Version: 0.8.0
 Summary: OpenHands extensions, plugins, and skills (Python bindings for the integration catalog)
 License-File: LICENSE
 Requires-Python: >=3.12

{openhands_extensions-0.7.1 → openhands_extensions-0.8.0}/README.md

@@ -87,7 +87,7 @@ The JS and Python versions are kept in lock-step by `release-please` and guarded
 ## Extensions Catalog
 
 <!-- BEGIN AUTO-GENERATED CATALOG -->
-This repository contains **2 marketplace(s)** with **60 extensions** (50 skills, 10 plugins).
+This repository contains **2 marketplace(s)** with **61 extensions** (51 skills, 10 plugins).
 
 ### large-codebase
 
@@ -106,7 +106,7 @@ OpenHands skills for interacting, improving, and refactoring large codebases
 
 Official skills and plugins for OpenHands — the open-source AI software engineer.
 
-**56 extensions** (48 skills, 8 plugins)
+**57 extensions** (49 skills, 8 plugins)
 
 | Name | Type | Description | Commands |
 |------|------|-------------|----------|
@@ -151,6 +151,7 @@ Official skills and plugins for OpenHands — the open-source AI software engine
 | openhands-automation | skill | Create and manage OpenHands automations - scheduled tasks that run in sandboxes. Use the prompt preset to create auto... | `/automation:create` |
 | openhands-sdk | skill | Reference skill for the OpenHands Software Agent SDK - build AI agents with custom tools, LLM configuration, conversa... | `/sdk` |
 | pdflatex | skill | Install and use pdflatex to compile LaTeX documents into PDFs on Linux. Use when generating academic papers, research... | — |
+| plain-english-content | skill | Write and edit clear, accessible prose in a plain English content style: active voice, front-loaded content, sentence... | — |
 | pr-review | plugin | Automated PR code review — analyzes diffs and posts inline review comments via the GitHub API. | — |
 | prd | skill | Generate a Product Requirements Document (PRD) for a new feature through an interactive clarifying-question workflow.... | `/prd` |
 | qa-changes | plugin | Validate pull request changes by actually running the code — setting up the environment, exercising changed behavior,... | — |

{openhands_extensions-0.7.1 → openhands_extensions-0.8.0}/integrations/catalog/linear.json

@@ -11,6 +11,34 @@
   "notes": "Popular among modern product engineering teams and already useful to this repo's users.",
   "popularityRank": 86,
   "connectionOptions": [
+    {
+      "id": "oauth",
+      "provider": "mcp",
+      "auth": {
+        "strategy": "oauth2",
+        "oauth": {
+          "authorizationUrl": "https://mcp.linear.app/authorize",
+          "tokenUrl": "https://mcp.linear.app/token",
+          "registrationUrl": "https://mcp.linear.app/register",
+          "scopes": [
+            "read",
+            "write"
+          ],
+          "pkce": true,
+          "clientAuthentication": "none",
+          "additionalAuthorizationParams": {
+            "resource": "https://mcp.linear.app/mcp"
+          },
+          "additionalTokenParams": {
+            "resource": "https://mcp.linear.app/mcp"
+          }
+        }
+      },
+      "transport": {
+        "kind": "shttp",
+        "url": "https://mcp.linear.app/mcp"
+      }
+    },
     {
       "id": "api-key",
       "provider": "mcp",
@@ -36,5 +64,5 @@
     "tasks",
     "tickets"
   ],
-  "installHint": "Authenticate with a Linear API key (Linear → Settings → Security & access) — sent as a Bearer token. Optional when the endpoint accepts your OAuth session."
+  "installHint": "Prefer the OAuth MCP connection for Linear. The MCP server supports OAuth 2.1 with dynamic client registration at mcp.linear.app; a bearer-token MCP option remains available for API-key or existing OAuth-token workflows."
 }

{openhands_extensions-0.7.1 → openhands_extensions-0.8.0}/marketplaces/openhands-extensions.json

@@ -728,6 +728,15 @@
         "cron",
         "automation"
       ]
+    },
+    {
+      "name": "plain-english-content",
+      "source": "./skills/plain-english-content",
+      "description": "Write and edit clear, accessible prose in a plain English content style: active voice, front-loaded content, sentence case, and accessible formatting.",
+      "category": "productivity",
+      "keywords": [
+        "plain-english"
+      ]
     }
   ]
 }

{openhands_extensions-0.7.1 → openhands_extensions-0.8.0}/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openhands/extensions",
-  "version": "0.7.1",
+  "version": "0.8.0",
   "description": "Public OpenHands extension catalogs for skills, plugins, integrations, and automation templates.",
   "license": "MIT",
   "type": "module",

{openhands_extensions-0.7.1 → openhands_extensions-0.8.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "openhands-extensions"
-version = "0.7.1"
+version = "0.8.0"
 description = "OpenHands extensions, plugins, and skills (Python bindings for the integration catalog)"
 requires-python = ">=3.12"
 

{openhands_extensions-0.7.1 → openhands_extensions-0.8.0}/python/openhands_extensions/_version.py

@@ -17,7 +17,7 @@ from importlib.metadata import PackageNotFoundError, version
 #: Fallback used only when the package is not installed (no dist metadata).
 #: Kept in lock-step with pyproject.toml/package.json by the version test.
 # x-release-please-update-version
-_FALLBACK_VERSION = "0.7.1"
+_FALLBACK_VERSION = "0.8.0"
 
 try:
     __version__: str = version("openhands-extensions")

{openhands_extensions-0.7.1 → openhands_extensions-0.8.0}/skills/index.js

@@ -363,6 +363,15 @@ export const SKILLS_CATALOG = [
     ],
     "content": "PdfLatex is a tool that converts Latex sources into PDF. This is specifically very important for researchers, as they use it to publish their findings. It could be installed very easily using Linux terminal, though this seems an annoying task on Windows. Installation commands are given below.\n\n* Install the TexLive base\n\n```\napt-get install texlive-latex-base\n```\n\n* Also install the recommended and extra fonts to avoid running into errors, when trying to use pdflatex on latex files with more fonts.\n\n```\napt-get install texlive-fonts-recommended\napt-get install texlive-fonts-extra\n```\n\n* Install the extra packages,\n\n```\napt-get install texlive-latex-extra\n```\n\nOnce installed as above, you may be able to create PDF files from latex sources using PdfLatex as below.\n```\npdflatex latex_source_name.tex\n```\n\nRef: http://kkpradeeban.blogspot.com/2014/04/installing-latexpdflatex-on-ubuntu.html"
   },
+  {
+    "name": "plain-english-content",
+    "description": "This skill should be used when the user asks to \"write in plain English\", \"make this easier to read\", \"rewrite guidance\", \"improve report clarity\", or produce accessible public-facing prose. It applies plain English content design principles: active voice, front-loaded content, sentence case, and no bold or italics for emphasis.",
+    "triggers": [
+      "plain English"
+    ],
+    "content": "Open content up so anyone can understand it the first time they read it, without losing substance, nuance or precision. Aim to open up, not dumb down. Apply the GOV.UK style guide approach: plain English, user needs first, active voice, front-loaded structure and accessible formatting.\n\nUse this skill for reports, research write-ups, guidance, documentation, summaries, and public-facing prose where clarity and accessibility matter. When writing a report, default to this style. When briefing a research agent, pass this skill so the report follows the same style.\n\n## Content design principles\n\n- Start from the user need. Write what the reader needs to know to do or decide something, not what the writer wants to say.\n- Front-load everything. Put the most important point first in the document, each section, each paragraph and each sentence. Use the inverted pyramid: conclusion first, then detail, then background.\n- Keep one idea per sentence and one topic per paragraph. Split sentences that contain more than one idea.\n- Be specific and concrete. Give the number, name and date. Cut vague abstractions like \"a range of\", \"going forward\" and \"in terms of\".\n- Cut everything that does not add meaning. Shorter is clearer. Remove duplication.\n\n## Plain English\n\n- Open content up, do not dumb it down. Keep the substance, nuance and precision. Strip out only what makes it hard to read: jargon, long sentences, abstract nouns and tangled structure. Make the content clear enough for a non-specialist and precise enough for an expert.\n- Use the active voice. Say who does what. Write \"We reviewed the data\", not \"The data was reviewed\".\n- Keep sentences short: about 15 to 20 words, and rarely more than 25. Keep paragraphs short.\n- Use everyday words. Replace jargon and formal wording with plain alternatives:\n  - use, not utilise or leverage\n  - help, not facilitate or empower\n  - work with, not collaborate, liaise or engage with\n  - make or provide, not deliver\n  - about, not in relation to or with regard to\n  - so, not in order to\n  - start, not commence\n  - end, not terminate\n  - buy, not purchase\n  - enough, not sufficient\n  - solve, fix or deal with, not tackle or combat\n  - effect on, not impact on\n- Do not use impact as a verb.\n- Avoid metaphors and cliches: drive, unlock, deep dive, robust, key, ring-fence, hub, portal, landscape, ecosystem and going forward.\n- Address the reader as \"you\". Write about the organisation as \"we\". Use \"they\", \"them\" and \"their\" rather than gendered pronouns. Write \"disabled people\", not \"the disabled\".\n- Use contractions for a warmer tone when appropriate, such as \"we'll\" and \"you'll\". Avoid negative contractions: write \"cannot\", not \"can't\". Avoid \"should've\", \"could've\" and \"would've\".\n\n## Formatting\n\n- Do not use bold or italics for emphasis. Plain words and good structure carry the meaning. Use bold only for a literal interface element in an instruction, for example: select Save. Use single quotation marks for the titles of schemes or documents, not italics.\n- Use sentence case everywhere: headings, titles and table headers. Capitalise only proper nouns.\n- Front-load headings, keep them under about 65 characters, and make them unique and descriptive. Do not use a full stop, dash, slash or question mark in headings. Use headings to help readers skim.\n- Introduce bullet lists with a lead-in line that ends in a colon. Start each bullet lowercase. Keep each bullet to one idea. Do not put \"and\" or \"or\" after each bullet. Do not use semicolons. Do not use a full stop after the last bullet unless the bullet is a full sentence.\n- Use a numbered list only for steps readers must follow in order. Write steps as full sentences that end with a full stop. Do not use a lead-in colon.\n- Use descriptive link text that says where the link goes and front-loads the key words. Never write \"click here\" or \"read more\". Make link text understandable out of context.\n- Do not use Latin abbreviations. Write \"for example\" not \"eg\", \"that is\" not \"ie\", and \"and so on\" or \"such as\" not \"etc\". Latin abbreviations confuse some readers and screen readers.\n- Write \"and\", not \"&\", except in a registered name or logo.\n- Write \"one\", but use numerals from 2 upwards. Use the % symbol with numerals, such as 50%. Use £ with no decimals unless there are pence: £75, £75.50. Spell out millions and billions, such as £5 million. Write ranges with \"to\", not a hyphen: 10 to 20, Monday to Friday.\n- Write dates as \"4 June 2026\" with no comma or ordinal suffix. Use \"to\" for ranges, such as \"4 to 8 June\". Write times as \"10am to 11.30am\". Use \"midday\" and \"midnight\".\n- Do not use FAQs when the content can meet the user need directly. Do not use exclamation marks. Do not use all caps for emphasis.\n\n## Before finishing: self-check\n\n- Is the single most important thing first?\n- Could a non-expert understand every sentence on first read?\n- Is every sentence active, short and focused on one idea?\n- Have all bold or italic emphasis, jargon, Latin abbreviations and marketing language been removed?\n- Is everything in sentence case, with descriptive headings and links?\n- Can any more words be cut without losing meaning? If yes, cut them.\n\n## Scope note\n\nThe no-bold and formatting rules apply to produced prose, such as reports, guidance and summaries. Keep the conventions of code, data tables and direct quotations. Markdown headings and lists are acceptable because they provide structure, not emphasis.\n\n## Source\n\nImported and adapted from the public gist at https://gist.github.com/fofr/505e225f9bf5e839d30c12ba6bfa0be2.",
+    "license": "MIT"
+  },
   {
     "name": "prd",
     "description": "\"Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD.\"",

openhands_extensions-0.8.0/skills/plain-english-content/.claude-plugin/plugin.json

@@ -0,0 +1,15 @@
+{
+  "name": "plain-english-content",
+  "version": "1.0.0",
+  "description": "Write and edit clear, accessible prose in a plain English content style: active voice, front-loaded content, sentence case, and accessible formatting.",
+  "author": {
+    "name": "OpenHands",
+    "email": "contact@all-hands.dev"
+  },
+  "homepage": "https://github.com/OpenHands/extensions",
+  "repository": "https://github.com/OpenHands/extensions",
+  "license": "MIT",
+  "keywords": [
+    "plain-english"
+  ]
+}

openhands_extensions-0.8.0/skills/plain-english-content/README.md

@@ -0,0 +1,12 @@
+# Plain English content skill
+
+This skill helps OpenHands write and edit clear, accessible prose in a plain English content style.
+It focuses on active voice, front-loaded structure, sentence case, accessible formatting, and public-facing guidance conventions.
+
+Use it for:
+
+- rewriting reports, research summaries and guidance in plain English
+- checking public-facing documentation for clarity and accessibility issues
+- briefing another agent to produce clear, accessible prose
+
+The skill was imported and adapted from this public gist: <https://gist.github.com/fofr/505e225f9bf5e839d30c12ba6bfa0be2>.

openhands_extensions-0.8.0/skills/plain-english-content/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: plain-english-content
+description: >
+  This skill should be used when the user asks to "write in plain English",
+  "make this easier to read", "rewrite guidance", "improve report clarity",
+  or produce accessible public-facing prose. It applies plain English content
+  design principles: active voice, front-loaded content, sentence case, and no
+  bold or italics for emphasis.
+license: MIT
+triggers:
+  - plain English
+---
+
+Open content up so anyone can understand it the first time they read it, without losing substance, nuance or precision. Aim to open up, not dumb down. Apply the GOV.UK style guide approach: plain English, user needs first, active voice, front-loaded structure and accessible formatting.
+
+Use this skill for reports, research write-ups, guidance, documentation, summaries, and public-facing prose where clarity and accessibility matter. When writing a report, default to this style. When briefing a research agent, pass this skill so the report follows the same style.
+
+## Content design principles
+
+- Start from the user need. Write what the reader needs to know to do or decide something, not what the writer wants to say.
+- Front-load everything. Put the most important point first in the document, each section, each paragraph and each sentence. Use the inverted pyramid: conclusion first, then detail, then background.
+- Keep one idea per sentence and one topic per paragraph. Split sentences that contain more than one idea.
+- Be specific and concrete. Give the number, name and date. Cut vague abstractions like "a range of", "going forward" and "in terms of".
+- Cut everything that does not add meaning. Shorter is clearer. Remove duplication.
+
+## Plain English
+
+- Open content up, do not dumb it down. Keep the substance, nuance and precision. Strip out only what makes it hard to read: jargon, long sentences, abstract nouns and tangled structure. Make the content clear enough for a non-specialist and precise enough for an expert.
+- Use the active voice. Say who does what. Write "We reviewed the data", not "The data was reviewed".
+- Keep sentences short: about 15 to 20 words, and rarely more than 25. Keep paragraphs short.
+- Use everyday words. Replace jargon and formal wording with plain alternatives:
+  - use, not utilise or leverage
+  - help, not facilitate or empower
+  - work with, not collaborate, liaise or engage with
+  - make or provide, not deliver
+  - about, not in relation to or with regard to
+  - so, not in order to
+  - start, not commence
+  - end, not terminate
+  - buy, not purchase
+  - enough, not sufficient
+  - solve, fix or deal with, not tackle or combat
+  - effect on, not impact on
+- Do not use impact as a verb.
+- Avoid metaphors and cliches: drive, unlock, deep dive, robust, key, ring-fence, hub, portal, landscape, ecosystem and going forward.
+- Address the reader as "you". Write about the organisation as "we". Use "they", "them" and "their" rather than gendered pronouns. Write "disabled people", not "the disabled".
+- Use contractions for a warmer tone when appropriate, such as "we'll" and "you'll". Avoid negative contractions: write "cannot", not "can't". Avoid "should've", "could've" and "would've".
+
+## Formatting
+
+- Do not use bold or italics for emphasis. Plain words and good structure carry the meaning. Use bold only for a literal interface element in an instruction, for example: select Save. Use single quotation marks for the titles of schemes or documents, not italics.
+- Use sentence case everywhere: headings, titles and table headers. Capitalise only proper nouns.
+- Front-load headings, keep them under about 65 characters, and make them unique and descriptive. Do not use a full stop, dash, slash or question mark in headings. Use headings to help readers skim.
+- Introduce bullet lists with a lead-in line that ends in a colon. Start each bullet lowercase. Keep each bullet to one idea. Do not put "and" or "or" after each bullet. Do not use semicolons. Do not use a full stop after the last bullet unless the bullet is a full sentence.
+- Use a numbered list only for steps readers must follow in order. Write steps as full sentences that end with a full stop. Do not use a lead-in colon.
+- Use descriptive link text that says where the link goes and front-loads the key words. Never write "click here" or "read more". Make link text understandable out of context.
+- Do not use Latin abbreviations. Write "for example" not "eg", "that is" not "ie", and "and so on" or "such as" not "etc". Latin abbreviations confuse some readers and screen readers.
+- Write "and", not "&", except in a registered name or logo.
+- Write "one", but use numerals from 2 upwards. Use the % symbol with numerals, such as 50%. Use £ with no decimals unless there are pence: £75, £75.50. Spell out millions and billions, such as £5 million. Write ranges with "to", not a hyphen: 10 to 20, Monday to Friday.
+- Write dates as "4 June 2026" with no comma or ordinal suffix. Use "to" for ranges, such as "4 to 8 June". Write times as "10am to 11.30am". Use "midday" and "midnight".
+- Do not use FAQs when the content can meet the user need directly. Do not use exclamation marks. Do not use all caps for emphasis.
+
+## Before finishing: self-check
+
+- Is the single most important thing first?
+- Could a non-expert understand every sentence on first read?
+- Is every sentence active, short and focused on one idea?
+- Have all bold or italic emphasis, jargon, Latin abbreviations and marketing language been removed?
+- Is everything in sentence case, with descriptive headings and links?
+- Can any more words be cut without losing meaning? If yes, cut them.
+
+## Scope note
+
+The no-bold and formatting rules apply to produced prose, such as reports, guidance and summaries. Keep the conventions of code, data tables and direct quotations. Markdown headings and lists are acceptable because they provide structure, not emphasis.
+
+## Source
+
+Imported and adapted from the public gist at https://gist.github.com/fofr/505e225f9bf5e839d30c12ba6bfa0be2.

openhands_extensions-0.7.1/.release-please-manifest.json

@@ -1,3 +0,0 @@
-{
-  ".": "0.7.1"
-}

{openhands_extensions-0.7.1 → openhands_extensions-0.8.0}/integrations/catalog/notion.json

@@ -10,6 +10,22 @@
   "docsUrl": "https://developers.notion.com/docs/mcp",
   "popularityRank": 82,
   "connectionOptions": [
+    {
+      "id": "oauth",
+      "provider": "http",
+      "auth": {
+        "strategy": "oauth2",
+        "oauth": {
+          "authorizationUrl": "https://api.notion.com/v1/oauth/authorize",
+          "tokenUrl": "https://api.notion.com/v1/oauth/token",
+          "scopes": []
+        }
+      },
+      "http": {
+        "apiBaseUrl": "https://api.notion.com",
+        "openApiUrl": "https://developers.notion.com/openapi.json"
+      }
+    },
     {
       "id": "api",
       "provider": "mcp",
@@ -36,22 +52,6 @@
       "auth": {
         "strategy": "api_key"
       }
-    },
-    {
-      "id": "oauth",
-      "provider": "http",
-      "auth": {
-        "strategy": "oauth2",
-        "oauth": {
-          "authorizationUrl": "https://api.notion.com/v1/oauth/authorize",
-          "tokenUrl": "https://api.notion.com/v1/oauth/token",
-          "scopes": []
-        }
-      },
-      "http": {
-        "apiBaseUrl": "https://api.notion.com",
-        "openApiUrl": "https://developers.notion.com/openapi.json"
-      }
     }
   ],
   "iconBg": "#FFFFFF",