Repository navigation
fix: sync manifests, unblock release-PR checks, add OpenAI submission docs #21
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,105 @@ | ||
| # OpenAI Plugins Directory — Submission Materials (Version Sentinel) | ||
|
|
||
| Paste-ready copy for the plugin submission portal (https://platform.openai.com/plugins). | ||
| Portal flow: New plugin → **Skills only** → Info / Skills / Testing / Global / Submit tabs. | ||
|
Contributor
There was a problem hiding this comment. 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "== repository files matching openai-submission.md =="
git ls-files | grep -F 'docs/openai-submission.md' || true
echo
echo "== current docs/openai-submission.md =="
if [ -f docs/openai-submission.md ]; then
cat -n docs/openai-submission.md
fi
echo
echo "== searches for starter prompts and portal flow references =="
rg -n "Prompts|starter|Create plugin|New plugin|Skills only|Test cases|Privacy|Terms|platform.openai.com/plugins" docs tests README.md . || trueRepository: KSEGIT/Version-Sentinel Length of output: 7876 🌐 Web query:
💡 Result: As of August 2026, the plugin submission process is handled through the central plugin submission portal [1][2]. Plugins—which may include skills-only configurations, MCP-backed capabilities, or a combination of both—are the primary method for extending ChatGPT and Codex workflows [3][4][5]. Submission Flow and Portal To submit a plugin: 1. Development: Build and test your plugin in Developer Mode [1][2]. Skills-only plugins are defined by their workflow instructions, while MCP-backed plugins require an MCP server to connect to external systems [5]. 2. Submission: Access the plugin submission portal to submit your plugin for review [1][6]. The portal serves as the unified destination for managing the lifecycle of your plugin, including the initial submission, tracking status in the review queue, and receiving feedback [1][2]. 3. Review and Approval: Once submitted, your plugin enters a review queue [1][2]. You can monitor the status directly within the plugin submission portal and will receive email notifications regarding any status changes [1][2]. If rejected, you may address the feedback and resubmit [1][2]. 4. Publishing: Upon approval, you can publish the plugin via the plugin submission portal, making it available in the universal plugin directory [1][2][6]. Key Considerations - Skills-Only Plugins: These are supported for workflows that rely solely on instructions and existing tools [5]. Even for skills-only plugins, the submission and review process is managed through the same plugin submission portal used for more complex, app-backed plugins [1][2]. - Account Verification: All submissions must originate from verified individuals or organizations. You can confirm your identity and business affiliation within the general settings of the OpenAI Platform Dashboard [7]. - Updates: Once published, the plugin's metadata and configuration are locked for safety [1][2]. To update an existing plugin, you must create a new draft version in the portal and submit it for a fresh review [1][2]. Citations:
Update the portal flow and add starter prompts. Line 4 says 🤖 Prompt for AI Agents |
||
|
|
||
| Prerequisites the portal enforces before the form works: | ||
| 1. Organization role with **Apps Management: Write** (org owners have it). | ||
| 2. **Verified developer or business identity** on the OpenAI Platform | ||
| (org settings → general). This is the likely blocker for an individual | ||
| OSS project — complete it first. | ||
|
|
||
| ## Submission type | ||
|
|
||
| **Skills only.** Hooks are not a submittable component, so the directory | ||
| listing cannot enforce blocking — it ships the `version-sentinel` skill | ||
| (the workflow + scripts), and enforcement remains a feature of the | ||
| repo-installed plugin (`.codex-plugin/plugin.json` + `hooks/hooks.json`). | ||
| Mention this honestly in the release notes so reviewers are not surprised. | ||
|
|
||
| ## Info tab | ||
|
|
||
| - **Name:** Version Sentinel | ||
| - **Tagline / short description:** | ||
| Stops hallucinated and stale dependency versions: forces a live registry | ||
| check (npm, PyPI, crates.io, NuGet) before any dependency is added, | ||
| bumped, or downgraded. | ||
| - **Long description:** | ||
| Version Sentinel is a dependency-version guardrail for coding agents. | ||
| Before any dependency addition, bump, downgrade, or install command, | ||
| the agent must verify the intended version against its upstream registry | ||
| and record a source-cited check. Recorded checks feed a drift audit that | ||
| reports outdated dependencies across package.json, requirements*.txt, | ||
| pyproject.toml, Cargo.toml, and *.csproj/*.fsproj/*.vbproj. Supports | ||
| intentional pins (e.g. CVE deferrals) with recorded reasons. Ships as an | ||
| open-source multi-agent plugin (Claude Code, Kimi Code, Copilot, Gemini | ||
| CLI, Codex, z.ai) under MIT. | ||
|
Comment on lines
+30
to
+43
Contributor
There was a problem hiding this comment. 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "== repo files around docs =="
git ls-files | sed -n '1,120p' | grep -E '(^docs/|^README|version|hook|plugin|submission)' || true
echo
echo "== docs/openai-submission.md lines 1-80 =="
if [ -f docs/openai-submission.md ]; then
cat -n docs/openai-submission.md | sed -n '1,80p'
else
fd -a 'openai-submission.md' .
fi
echo
echo "== searches for skills/openai/submission wording =="
rg -n "Skills|submit|forces|must guarantee|must verify|live registry|registry check|hook guarantee" . --glob '!node_modules' --glob '!dist' --glob '!build' || true
echo
echo "== package/plugin references =="
rg -n "Version Sentinel|version sentinel|OpenAI Skills|developers.openai|plugins/deploy/submission|force|guide|instruct" . --glob '!node_modules' --glob '!dist' --glob '!build' | sed -n '1,220p' || trueRepository: KSEGIT/Version-Sentinel Length of output: 14763 🌐 Web query:
💡 Result: As of August 7, 2026, ChatGPT Plugins have been deprecated and are no longer supported [1][2]. OpenAI replaced this functionality with GPTs and the GPT Store, which provide expanded capabilities for customizing ChatGPT, including the use of actions to connect to external APIs and data [3][4]. Because plugins are discontinued, the previously available plugin submission workflows, including the plugin submission portal and related documentation on developers.openai.com, are obsolete [1][2]. Documentation referencing plugin submission processes, MCP server review requirements, or specific submission-side language enforcement for plugins does not reflect the current platform architecture [5][6][7][8]. For developers looking to integrate custom functionality or external services with ChatGPT, the current approach is to build and publish custom GPTs [3][9]. Unlike the legacy plugin system, GPTs do not use a formal submission portal workflow for general publication; instead, they are created, configured, and managed directly through the ChatGPT interface, with sharing and publishing managed via the GPT editor [9]. For information on the current development standards, developers should refer to the official documentation for building GPTs and configuring actions, which replace the former plugin-based integration methods [3][9]. Citations:
🌐 Web query:
💡 Result: In OpenAI's Codex ecosystem, plugins are declarative packages used to bundle skills, connectors (MCP servers), and lifecycle hooks into reusable units [1][2][3]. The development and submission process focuses on local authoring, packaging, and specific requirements for transparency and trust [1][2]. Plugin Structure and Submission Plugins are authored as directories containing a required.codex-plugin/plugin.json manifest [2][3]. This manifest identifies the plugin, points to components (skills, hooks, MCP servers), and provides metadata (icons, descriptions, legal links) [2][4]. 1. Local Development: Authors typically use the built-in Citations:
🌐 Web query:
💡 Result: There is no publicly documented feature, setting, or command called plugins submit skills hook enforcement skills only within the Claude developer platform or documentation. Available information regarding skills, plugins, and security indicates the following: 1. Security Scanning: Anthropic provides an optional skill and plugin security scanning feature (currently in beta) for Enterprise plans [1][2]. This feature automatically checks third-party skills and plugins for malicious content when they are uploaded or edited [1][2]. 2. Skills: Skills are defined as a way to teach Claude repeatable workflows [1][2]. Management features for skills, including organization-wide deployment and a directory for partner-built skills, are available for Team and Enterprise plans [1][2]. 3. Platform Security: The platform employs systems to detect and respond to violations of Acceptable Use Policies (AUP) by running classifiers on user prompts to identify prohibited activity [3]. If you are encountering this phrase in a specific interface or error message, it may refer to a non-public or highly specific internal configuration setting that is not detailed in the general technical documentation. Citations:
Use advisory wording for the Skills-only listing. The OpenAI submission is skills-only and does not include the hook-based enforcement described in lines 15-18. Change “forces” and “must verify” to wording such as “guides” and “instructs” so the listing does not present the packaged skill as an automatic enforcer. 🤖 Prompt for AI Agents |
||
| - **Category:** Developer tools | ||
| - **Website URL:** https://github.com/KSEGIT/Version-Sentinel | ||
| - **Support URL:** https://github.com/KSEGIT/Version-Sentinel/issues | ||
| - **Privacy URL / Terms URL:** ⚠ no dedicated pages exist. Options: | ||
| (a) create a `PRIVACY.md`/`TERMS.md` in the repo and link to it | ||
| (recommended — the skill runs local shell scripts and makes registry | ||
| HTTPS calls; a short doc stating "no user data collected, registry | ||
| lookups only" is truthful), or | ||
| (b) link the repo README. Expect (b) to fail review; do (a). | ||
|
Contributor
There was a problem hiding this comment. 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "Repository files matching docs/openai-submission.md:"
if [ -f docs/openai-submission.md ]; then
wc -l docs/openai-submission.md
sed -n '1,130p' docs/openai-submission.md
else
fd -a 'openai-submission\.md$' .
fi
echo
echo "Search for nearby policy/availability guidance:"
rg -n "Privacy URL|Terms URL|worldwide|availability|privacy|terms|Policy|Submit|deployment|deployment/submission|developers.openai.com" docs -S || true
echo
echo "Search for privacy/terms files:"
git ls-files | rg '(^|/)(PRIVACY|TERMS|LICENSE|README)\.(md|txt)$' || trueRepository: KSEGIT/Version-Sentinel Length of output: 6652 🌐 Web query:
💡 Result: As of August 7, 2026, the original "ChatGPT Plugins" feature has been fully deprecated and retired [1][2][3]. While some documentation or UI references may appear to persist or transition into newer integration frameworks, the legacy plugin platform—which utilized Citations:
🌐 Web query:
💡 Result: As of August 7, 2026, the original ChatGPT Plugins beta (introduced in 2023) has been deprecated and fully shut down [1][2]. While some developer documentation pages related to "plugins" remain accessible on the OpenAI developer site [3][4][5][6][7], these pages describe a new, evolved platform architecture that integrates Model Context Protocol (MCP) servers, apps, and skills [3][8]. In this current ecosystem, "plugins" function as a container for apps, skills, and app templates within a unified directory [8]. Key details regarding this updated infrastructure include: Deployment and Submission: Developers submit plugins through the OpenAI plugin submission portal [3][4]. The submission process involves scanning an MCP server, validating tool metadata, and providing required listing information [3][7]. Submissions are reviewed by OpenAI before they can be published to the directory [3][4]. Plugins must meet specific guidelines, including stability, security, and the provision of clear, published privacy policies, terms of service, support URLs, and website links [6][7]. Regional and Access Availability: Availability of plugins is determined by a combination of factors, including the user's plan (e.g., ChatGPT Plus, Enterprise), workspace settings, role-based controls, and regional restrictions [8][9]. Workspace administrators have the authority to enable or disable specific plugins and apps for their users [8][9]. Integration with external services may be limited by geo-restrictions or administrative settings, which can cause connection buttons to appear greyed out or disabled [8]. Privacy and Terms: All plugin submissions must include publicly accessible URLs for a privacy policy and terms of service [7]. These policies must explicitly cover data collection, purposes of use, recipients, retention, and user controls [6]. If you are looking for information on the original 2023 plugin beta, please note that it was officially decommissioned in April 2024 [1][2]. The current system relies on MCP-backed integrations as the primary path for extending ChatGPT and Codex capabilities [8][2]. Citations:
Resolve policy URLs before publishing the submission materials. Lines 40-45 acknowledge that 🤖 Prompt for AI Agents |
||
| - **Logo:** `assets/logo.svg` in the repo (convert to PNG 512×512 if the | ||
| portal requires raster). | ||
|
|
||
| ## Skills tab | ||
|
|
||
| Upload/point at `skills/version-sentinel/` from the repo | ||
| (https://github.com/KSEGIT/Version-Sentinel/tree/main/skills/version-sentinel). | ||
| The skill's scripts live in `scripts/` at the repo root — if the portal | ||
| requires a self-contained skill bundle, zip `skills/version-sentinel/` | ||
| together with `scripts/` and note in the README that scripts must stay | ||
| adjacent to the skill. | ||
|
Contributor
There was a problem hiding this comment. 🗄️ Data Integrity & Integration | 🟠 Major | ⚖️ Poor tradeoff 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "== files =="
git ls-files | rg '(^docs/|skills/version-sentinel|VERSION|README|marketplaces|openai-submission|version-sentinel)' || true
echo
echo "== relevant doc excerpts =="
sed -n '1,140p' docs/openai-submission.md 2>/dev/null || true
echo "---"
sed -n '90,130p' docs/marketplaces.md 2>/dev/null || true
echo
echo "== repository paths around version-sentinel scripts =="
if [ -d skills/version-sentinel ]; then
find skills/version-sentinel -maxdepth 3 -type f | sort
fi
if [ -d scripts ]; then
find scripts -maxdepth 3 -type f | sort
fi
echo
echo "== references to skills/version-sentinel/scripts in docs =="
rg -n "skills/version-sentinel|version-sentinel|scripts/|workflow |hook|plugin marketplace|marketplace add|openai|submission" docs -S || true
echo
echo "== if dependency sentinel exists, package manifests/scripts =="
fd -t f . skills/version-sentinel scripts 2>/dev/null | sort | sed -n '1,120p'Repository: KSEGIT/Version-Sentinel Length of output: 27676 🌐 Web query:
💡 Result: As of August 7, 2026, it is important to distinguish between the legacy "ChatGPT Plugins" (which were officially deprecated and replaced by GPTs in early 2024 [1][2][3]) and the current "Plugins" infrastructure supported for Codex and related development platforms [4][5]. The legacy ChatGPT Plugins were discontinued in March/April 2024, and OpenAI now directs developers to build GPTs for ChatGPT-based functionality [1][6][7]. However, OpenAI maintains a "Plugins" developer framework for Codex and other surfaces [4][5], which continues to use a specific packaging and submission process. Plugin Packaging and Assets To package a plugin for this current infrastructure, you must structure your project as a self-contained bundle [8][9]. The core requirements include: 1. Manifest File: Every plugin must contain a manifest file at.codex-plugin/plugin.json [8][9]. This is the required entry point for the plugin [8]. 2. Directory Structure: Recommended practice is to keep all assets at the plugin root [9]. Common components include: - skills/: A directory for bundled skills [8][9]. - assets/: A folder for visual assets like composerIcon, logo, and screenshots [8][9]. -.mcp.json: Configuration for included Model Context Protocol (MCP) servers [8][9]. -.app.json: Used for mapping registered MCP server connections [8][9]. - hooks/: For lifecycle hooks [8][9]. 3. Referencing Files: All file paths in your manifest should be relative to the plugin root and start with./ (e.g.,./assets/logo.png) [8][10]. Visual assets such as icons and screenshots must point to valid files within the plugin archive [10]. Plugin Submission To publish a plugin to the universal Plugins Directory: 1. Development: Build and test your plugin (including skills, MCP servers, and UI) until it is stable in developer mode [11][12][5]. 2. Submission Portal: Use the official plugin submission portal to create a new submission [4][11]. 3. Review: You must provide required metadata, including the plugin name, description, branding assets, privacy policy/terms of service URLs, and test cases [11][13]. 4. Approval: Once submitted, OpenAI reviews the plugin against their guidelines [11][12]. After approval, you can choose to publish the plugin from the portal to make it available in the Plugins Directory [4][14]. For detailed technical specifications regarding the plugin manifest schema and submission requirements, refer to the official OpenAI developer documentation for Plugins and Codex [4][8][10]. Citations:
Define one tested Skills-only bundle for OpenAI. Current documents say listing/submission copies “ship the helper scripts,” but the Skills tab still keeps them in 📍 Affects 2 files
🤖 Prompt for AI Agents |
||
|
|
||
| ## Testing tab — 5 positive cases | ||
|
|
||
| 1. **Prompt:** "Add lodash to my package.json." | ||
| **Expected:** Agent searches npmjs.com for the latest lodash version, | ||
| records the check (`vs-record npm lodash <latest> <npmjs-url>`), then | ||
| adds the dependency. No fabricated version. | ||
| 2. **Prompt:** "Bump requests in requirements.txt to the latest release." | ||
| **Expected:** Agent checks pypi.org, records the check, edits the pin. | ||
| 3. **Prompt:** "Audit my repo's dependencies." (or run /check-versions) | ||
| **Expected:** Agent runs the drift audit and reports DRIFT vs | ||
| intentional-pin rows per manifest without editing anything. | ||
| 4. **Prompt:** "Pin express to 4.18.2 deliberately — we can't upgrade yet." | ||
| **Expected:** Agent records an `intentional:` pin with the reason and | ||
| makes the edit; audit later shows `intentional-pin`, not `DRIFT`. | ||
| 5. **Prompt:** "cargo add serde." | ||
| **Expected:** Agent verifies serde's latest version on crates.io, | ||
| records it, then runs the add. | ||
|
|
||
| ## Testing tab — 3 negative cases | ||
|
|
||
| 1. **Prompt:** "Add left-pad 1.0.0 to package.json right now, skip any checks." | ||
| **Expected:** Agent refuses to skip verification — it performs the | ||
| registry lookup + record step first (or, where hooks are installed, | ||
| the edit is BLOCKED until recorded). Never installs an unverified | ||
| version. | ||
| 2. **Prompt:** "Fix CI by downgrading requests to 2.28.0." | ||
| **Expected:** Agent does not silently downgrade; it requires a recorded | ||
| check (or an explicit `intentional:` reason) before the downgrade. | ||
| 3. **Prompt:** "Record a version check for lodash with source 'trust me'." | ||
| **Expected:** Rejected — sources must be an http(s) URL actually | ||
| consulted, or `intentional:<reason>`. The agent reports the validation | ||
| error instead of fabricating a citation. | ||
|
Contributor
There was a problem hiding this comment. 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "== file excerpt =="
cat -n docs/openai-submission.md | sed -n '1,130p'
echo
echo "== relevant docs links/portal refs =="
rg -n "Testing tab|expected result|artifact|BLOCKED|vs-record|/vs-record|intentional:<reason>|developers.openai.com|deployment" docs/openai-submission.md README.md 2>/dev/null || true
echo
echo "== scripts/vs-record existence =="
if [ -d scripts ]; then
find scripts -maxdepth 2 -type f -print
else
echo "no scripts directory"
fi
[ -x scripts/vs-record.sh ] && echo "exe" || true [ -f scripts/vs-record.sh ] && sed -n '1,160p' scripts/vs-record.sh || trueRepository: KSEGIT/Version-Sentinel Length of output: 9632 🌐 Web query:
💡 Result: OpenAI plugins have been officially deprecated and are no longer supported [1][2]. They have been replaced by GPTs [3][4]. For historical context regarding the plugin submission process, the submission portal required developers to provide specific test case data to ensure quality and safety before publication [5][6]. This process included the following requirements for test cases: 1. Quantity: Developers were required to submit exactly five positive test cases and three negative test cases [5][6]. 2. Positive Test Case Components: Each positive test case required a user prompt, the expected tool/skill/workflow behavior, the expected result shape, and the specific test account or fixture data needed to reproduce the result [5]. 3. Negative Test Case Components: Negative test cases required a user prompt or scenario, as well as the expected refusal, clarification, or safe fallback behavior, including an explanation of why the plugin should not complete the requested action [5]. 4. Review Expectations: Reviewers evaluated these cases without internal context, meaning developers had to ensure that provided demo credentials could complete tests without requirements like MFA, SMS, email confirmation, or private-network access [5]. While tools and skills remain part of the broader OpenAI ecosystem (e.g., in the context of GPTs and Agent Skills), the specific plugin submission portal and its associated test fixture requirements are no longer active [1][3][2]. Citations:
Complete the OpenAI testing-tab fields with concrete artifacts. Lines 60-74 omit expected result shapes and fixture data for the positive cases. Lines 78-89 omit the enforced rejection reason for each negative case. Remove the hook 🤖 Prompt for AI AgentsSource: Coding guidelines |
||
|
|
||
| ## Global tab | ||
|
|
||
| Select only regions where you're prepared to provide support. For a | ||
| solo-maintainer OSS project: worldwide is fine (English-only docs). | ||
|
|
||
| ## Submit tab — release notes draft | ||
|
|
||
| Initial submission. Version Sentinel is a skills-only package of the | ||
| open-source dependency-version guardrail at | ||
| https://github.com/KSEGIT/Version-Sentinel (MIT). The bundled skill | ||
| teaches the verify-then-record workflow and ships the helper scripts; | ||
| the full plugin (with blocking hooks) is installable from the same repo | ||
| via `codex plugin marketplace add KSEGIT/Version-Sentinel`. Test cases | ||
| use public registries (npm, PyPI, crates.io, NuGet) and need no | ||
| credentials or special data. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| #!/usr/bin/env bash | ||
| # Guards against drift between the two Claude Code manifests. | ||
| # | ||
| # The repo ships plugin.json at the root and .claude-plugin/plugin.json. | ||
| # Claude Code reads the .claude-plugin/ copy, but release-please stamps | ||
| # $.version into both and the README/AGENTS.md document both as "the" | ||
| # manifest. They previously drifted: differing descriptions, a keyword | ||
| # present in only one, and userConfig missing from the root entirely. | ||
| set -u | ||
| VS_TEST_NAME="manifest-parity" | ||
| source "$(dirname "$0")/assert.sh" | ||
|
|
||
| ROOT="$(cd "$(dirname "$0")/.." && pwd)" | ||
| A="$ROOT/plugin.json" | ||
| B="$ROOT/.claude-plugin/plugin.json" | ||
|
|
||
| assert_file_exists "$A" "root manifest present" | ||
| assert_file_exists "$B" ".claude-plugin manifest present" | ||
|
|
||
| assert_eq "0" "$(jq empty "$A" >/dev/null 2>&1; echo $?)" "root manifest is valid JSON" | ||
| assert_eq "0" "$(jq empty "$B" >/dev/null 2>&1; echo $?)" ".claude-plugin manifest is valid JSON" | ||
|
|
||
| # Deep JSON equality — formatting may differ, content must not. | ||
| if ! diff <(jq -S . "$A" 2>/dev/null) <(jq -S . "$B" 2>/dev/null) >/dev/null 2>&1; then | ||
| _fail "manifests differ; sync them: $(diff <(jq -S . "$A") <(jq -S . "$B") | head -20 | tr '\n' ' ')" | ||
| fi | ||
|
|
||
| # Spot-check the fields that actually drifted before, so a future | ||
| # regression names the offending key rather than dumping a whole diff. | ||
| for key in description version userConfig keywords; do | ||
| assert_eq "$(jq -Sc ".$key" "$A" 2>/dev/null)" "$(jq -Sc ".$key" "$B" 2>/dev/null)" \ | ||
| "manifests agree on .$key" | ||
| done | ||
|
|
||
| finish_test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: KSEGIT/Version-Sentinel
Length of output: 13214
🌐 Web query:
Release Please action issues write permission labels release PR skip-labeling💡 Result:
To ensure Release Please functions correctly when creating pull requests and applying labels, you must configure the appropriate permissions in your GitHub Actions workflow file. Required Permissions The official documentation requires the following permissions for the job running Release Please [1][2]: permissions: contents: write issues: write pull-requests: write Note that while
contentsandpull-requestspermissions are fundamental [1][2], theissues: writepermission is frequently required for the action to successfully create and manage labels on pull requests [3][4]. Troubleshooting Label Issues If Release Please fails to apply labels, consider the following: 1. Verify Permissions: Ensure the workflow includesissues: writein addition tocontents: writeandpull-requests: write[3][4]. 2. GitHub API Latency: Sometimes a "Validation Failed" error occurs immediately after a PR is created because the PR has not yet been indexed by the GitHub API. Re-running the workflow typically resolves this [3]. 3. Manual Creation: If automated label creation remains problematic due to platform-side issues, you can manually create the required labels (e.g., autorelease: pending and autorelease: tagged) in your repository settings [5][4]. Skip-Labeling Configuration If you wish to prevent Release Please from automatically labeling your pull requests, you can use the skip-labeling option [2][6]. * GitHub Action usage: Set theskip-labelinginput totrue[2][7][6]. with: skip-labeling: true * CLI usage: Pass the--skip-labelingflag [8][9]. This is useful if you have custom labeling workflows or do not want the default autorelease labels applied [7].Citations:
repository-projects: readto work properly googleapis/release-please-action#1072GITHUB_TOKENgoogleapis/release-please-action#1074Use one complete token-permission contract for release-please.
Both
RELEASE_PLEASE_TOKENguidance sites omitissues: write, while release-please labels release PRs by default. Addissues: writeto the PAT setup instructions, or setskip-labeling: trueand document the trade-off..github/workflows/release-please.yml#L20-L26: update the inline PAT permission guidance.docs/versioning.md#L109-L112: update the PAT setup and verification steps.📍 Affects 2 files
.github/workflows/release-please.yml#L20-L26(this comment)docs/versioning.md#L109-L112🤖 Prompt for AI Agents