fix: sync manifests, unblock release-PR checks, add OpenAI submission docs - #21
Conversation
The two Claude Code manifests had diverged. `.claude-plugin/plugin.json` carried a stale description and lacked the `supply-chain-security` keyword; root `plugin.json` had no `userConfig` block at all, so anything reading it saw a plugin with no configurable options. Claude Code reads the `.claude-plugin/` copy, so the options worked in practice — but release-please stamps `$.version` into both, and the README, AGENTS.md, and CLAUDE.md all document both as the manifest. Both files are now identical: root's fuller description and keyword list, plus the `userConfig` block from `.claude-plugin/`. Adds tests/test_manifest_parity.sh to keep them that way — it asserts deep JSON equality and names the offending key on mismatch. Verified it fails on induced drift, not just passes on the synced state. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118eLJLbPbqYXiPc8R9AAiJ
docs/versioning.md already prescribed this fix; it was never wired up. A release PR opened by the default GITHUB_TOKEN has its checks created in `action_required` state — they sit unstarted until a maintainer approves them in the Actions tab. v0.4.1 was merged in exactly that state, so the release shipped before its tests had run. `token:` now resolves `secrets.RELEASE_PLEASE_TOKEN` and falls back to GITHUB_TOKEN when the secret is absent, so releases keep working (with the manual approval step) until the secret is created. Requires an owner action to take effect: create a fine-grained PAT with contents:write + pull-requests:write and set it as RELEASE_PLEASE_TOKEN. No further workflow edit needed once it exists. Also corrects versioning.md where it was wrong or stale: the release PR stamps `$.version` into all six manifests, not just one; and the runs are created-but-gated rather than never created at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118eLJLbPbqYXiPc8R9AAiJ
Paste-ready listing copy, the 5 positive / 3 negative test cases the portal requires, and the portal prerequisites (Apps Management: Write, verified developer identity). Resolves the "open question for the owner" left in marketplaces.md: the submission type is Skills only — hooks are not a submittable portal component, so a directory listing ships the skill and cannot enforce blocking. Links the two docs together. Flags one real gap: the portal requires privacy and terms URLs, and no PRIVACY.md/TERMS.md exists in the repo yet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118eLJLbPbqYXiPc8R9AAiJ
📝 WalkthroughWalkthroughThe changes add plugin configuration settings, validate parity between plugin manifests, configure release token fallback behavior, update versioning guidance, and document Skills-only OpenAI submission materials. ChangesManifest and Submission Updates
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (1)
tests/test_manifest_parity.sh (1)
28-33: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winAssert the new option schema, not only parity.
Deep equality detects drift, but both manifests can contain the same invalid
userConfig. Add assertions fordisable.type,disable.default,window_hours.type,window_hours.default,window_hours.min, andwindow_hours.maxfor both manifests.Proposed test addition
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 + +for manifest in "$A" "$B"; do + assert_eq "boolean" "$(jq -r '.userConfig.disable.type' "$manifest")" \ + "$manifest: disable.type" + assert_eq "false" "$(jq -r '.userConfig.disable.default' "$manifest")" \ + "$manifest: disable.default" + assert_eq "number" "$(jq -r '.userConfig.window_hours.type' "$manifest")" \ + "$manifest: window_hours.type" + assert_eq "24" "$(jq -r '.userConfig.window_hours.default' "$manifest")" \ + "$manifest: window_hours.default" + assert_eq "1" "$(jq -r '.userConfig.window_hours.min' "$manifest")" \ + "$manifest: window_hours.min" + assert_eq "168" "$(jq -r '.userConfig.window_hours.max' "$manifest")" \ + "$manifest: window_hours.max" +done🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/test_manifest_parity.sh` around lines 28 - 33, Extend the manifest assertions in tests/test_manifest_parity.sh beyond parity checks by validating the option schema in both manifests: assert disable.type and disable.default, plus window_hours.type, default, min, and max. Use the existing jq/assert_eq pattern and preserve the current drift checks for description, version, userConfig, and keywords.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release-please.yml:
- Around line 20-26: Update the RELEASE_PLEASE_TOKEN permission guidance in
.github/workflows/release-please.yml lines 20-26 and docs/versioning.md lines
109-112 to include issues:write alongside contents:write and
pull-requests:write, and ensure the setup and verification instructions
consistently require this permission; do not disable release-please labeling.
In `@docs/openai-submission.md`:
- Around line 3-4: Update the portal flow in the submission instructions to use
“Create plugin” → “Skills only” → the current Prompts and Testing steps, and add
paste-ready starter prompts to the document. Keep the existing submission
guidance while ensuring the prompts are directly usable in the portal.
- Around line 58-89: Update the Testing tab examples with concrete fixture
inputs and expected artifact/result shapes for all positive cases, including the
exact recorded entries and manifest changes. Replace every `vs-record`
invocation with the documented `/vs-record` command from the recording script.
For each negative case, state the specific enforced rejection reason, and remove
the hook-based `BLOCKED` outcome in favor of the skill-only verification
behavior.
- Around line 51-56: Define one tested, self-contained OpenAI Skills archive
containing skills/version-sentinel/ and its required scripts/, then update the
bundle references at docs/openai-submission.md:51-56,
docs/openai-submission.md:98-104, and docs/marketplaces.md:115-119 to
consistently name and describe that archive, including the required scripts
adjacency.
- Around line 23-36: Update the Skills-only listing in the tagline and long
description to use advisory wording: replace enforcement claims such as “forces”
and “must verify” with terms like “guides” and “instructs,” while preserving the
dependency checks, source-citation, and drift-audit capabilities described.
- Around line 40-45: Resolve the missing policy-page references in the
submission materials by adding and publishing dedicated PRIVACY.md and TERMS.md
pages, then update the Privacy URL and Terms URL entries to point to them. Keep
worldwide availability selected only once those public policy URLs are
available; otherwise make that selection conditional.
In `@docs/versioning.md`:
- Line 41: Update the TL;DR release-owned file list in docs/versioning.md to
state that release-please manages all six manifest version fields, matching the
manifests listed near the existing release configuration references. Remove the
outdated “all four” wording and clarify that contributors must not edit the
other five version fields manually.
---
Nitpick comments:
In `@tests/test_manifest_parity.sh`:
- Around line 28-33: Extend the manifest assertions in
tests/test_manifest_parity.sh beyond parity checks by validating the option
schema in both manifests: assert disable.type and disable.default, plus
window_hours.type, default, min, and max. Use the existing jq/assert_eq pattern
and preserve the current drift checks for description, version, userConfig, and
keywords.
🪄 Autofix
✅ Autofix completed
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 5552d0e4-239b-4666-b433-b1742463d09e
📒 Files selected for processing (7)
.claude-plugin/plugin.json.github/workflows/release-please.ymldocs/marketplaces.mddocs/openai-submission.mddocs/versioning.mdplugin.jsontests/test_manifest_parity.sh
| # A release PR opened by the default GITHUB_TOKEN lands its checks in | ||
| # `action_required`, so tests never run until someone approves them by | ||
| # hand. Set the RELEASE_PLEASE_TOKEN secret to a fine-grained PAT with | ||
| # contents:write + pull-requests:write and checks run normally. | ||
| # Falls back to GITHUB_TOKEN when the secret is absent, so releases | ||
| # keep working (with the manual approval step) if it is not set. | ||
| token: ${{ secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Tracked workflow and docs files:"
git ls-files ".github/workflows/release-please.yml" "docs/versioning.md"
echo
echo "Workflow excerpt:"
sed -n '1,80p' .github/workflows/release-please.yml 2>/dev/null || true
echo
echo "Versioning excerpt:"
sed -n '1,150p' docs/versioning.md 2>/dev/null || true
echo
echo "Release-please action / input references:"
rg -n "release-please|RELEASE_PLEASE_TOKEN|skip-labeling|issues|pull-requests|contents" .github/workflows/release-please.yml docs/versioning.mdRepository: 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 contents and pull-requests permissions are fundamental [1][2], the issues: write permission 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 includes issues: write in addition to contents: write and pull-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 the skip-labeling input to true [2][7][6]. with: skip-labeling: true * CLI usage: Pass the --skip-labeling flag [8][9]. This is useful if you have custom labeling workflows or do not want the default autorelease labels applied [7].
Citations:
- 1: https://github.com/google-github-actions/release-please-action
- 2: https://github.com/marketplace/actions/release-please-action
- 3: Fails to create label when action runs googleapis/release-please-action#1105
- 4: GITHUB_TOKEN requires
repository-projects: readto work properly googleapis/release-please-action#1072 - 5: Labels are not being correctly applied to PR using
GITHUB_TOKENgoogleapis/release-please-action#1074 - 6: https://github.com/googleapis/release-please-action
- 7: feat: support for skip-labeling parameter for GitHub action googleapis/release-please-action#1066
- 8: https://github.com/googleapis/release-please/blob/HEAD/docs/cli.md
- 9: https://github.com/googleapis/release-please/blob/a61fa929b42f04c6acdd6650328d3f90903b7dc5/docs/cli.md
Use one complete token-permission contract for release-please.
Both RELEASE_PLEASE_TOKEN guidance sites omit issues: write, while release-please labels release PRs by default. Add issues: write to the PAT setup instructions, or set skip-labeling: true and 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
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release-please.yml around lines 20 - 26, Update the
RELEASE_PLEASE_TOKEN permission guidance in .github/workflows/release-please.yml
lines 20-26 and docs/versioning.md lines 109-112 to include issues:write
alongside contents:write and pull-requests:write, and ensure the setup and
verification instructions consistently require this permission; do not disable
release-please labeling.
| 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. |
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:
OpenAI plugins skills-only submission flow Prompts tab Create plugin submission portal
💡 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:
- 1: https://developers.openai.com/apps-sdk/deploy/submission
- 2: https://developers.openai.com/plugins/deploy/app-review
- 3: https://help.openai.com/en/articles/20001256-plugins-in-chatgpt-and-codex
- 4: https://developers.openai.com/codex/plugins
- 5: https://developers.openai.com/plugins/concepts/plugins
- 6: https://developers.openai.com/plugins/build/plugins
- 7: https://developers.openai.com/apps-sdk/app-submission-guidelines
Update the portal flow and add starter prompts.
Line 4 says New plugin and skips the Prompts tabs/steps. Use the current Create plugin → Skills only → Prompts/Testing steps and add paste-ready starter prompts here.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/openai-submission.md` around lines 3 - 4, Update the portal flow in the
submission instructions to use “Create plugin” → “Skills only” → the current
Prompts and Testing steps, and add paste-ready starter prompts to the document.
Keep the existing submission guidance while ensuring the prompts are directly
usable in the portal.
| - **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. |
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:
developers.openai.com plugins deploy submission OpenAI Skills submit only workflow guide vs enforce language
💡 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:
- 1: https://www.openai.com/blog/chatgpt-plugins
- 2: https://community.openai.com/t/error-plugins-are-no-longer-supported/715523
- 3: https://www.zdnet.com/article/on-march-19-chatgpt-plugins-get-replaced-by-gpts-heres-why-and-what-it-means-to-you/
- 4: https://community.openai.com/t/are-custom-gpts-replacing-plugins/590048/2
- 5: https://developers.openai.com/plugins/deploy/app-review
- 6: https://developers.openai.com/plugins/deploy/submission-errors
- 7: https://developers.openai.com/plugins/quickstart
- 8: https://developers.openai.com/apps-sdk/deploy/submission
- 9: https://help.openai.com/en/articles/8554397-creating-and-editing-gpts
🌐 Web query:
OpenAI Codex plugins PreToolUse hooks skills submission review requirements
💡 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 @plugin-creator skill to scaffold the required directory structure and manifest [2][5]. Iteration is done locally before packaging for distribution [1][3]. 2. Distribution: Reusable skills, connectors, or bundled workflows are packaged into plugins [1]. Marketplace entries (typically a JSON catalog) turn these directories into installable units [3]. 3. Review Requirements: When submitting plugins for broader platform distribution, developers must adhere to specific submission flows that include MCP checks, test case requirements, and compliance with permissions and privacy policy standards [6]. PreToolUse Hooks The PreToolUse hook is a lifecycle event that allows developers to intercept tool calls—primarily Bash/shell commands—before they are executed by the agent [7][8]. - Functionality: When a plugin is enabled, it can bundle PreToolUse hooks [7][9]. These hooks run alongside user, project, and managed hooks [10][9]. - Governance and Trust: Plugin-bundled hooks are considered non-managed [7][9]. They are not automatically trusted upon installation [7][9]. Codex skips these hooks until the user explicitly reviews and trusts the specific hook definition via the /hooks interface in the CLI [7][11]. - Technical Limitations: As of current specifications, PreToolUse hooks primarily intercept the shell (Bash) tool [8]. While intended to provide governance, they operate with specific constraints—for example, they cannot rewrite tool inputs or interpose interactive human confirmation flows directly; they function mainly to permit or deny execution [8]. Key Development Resources - Plugin Manifest:.codex-plugin/plugin.json [2][9]. - Hook Configuration: Defaults to hooks/hooks.json or can be specified in the manifest [7][9]. - CLI Utilities: The Codex CLI is the primary interface for inspecting hooks, reviewing/trusting definitions, and managing plugin installations [7][6]. - Official Documentation: Detailed requirements for packaging and submission are available at developers.openai.com/codex/plugins and related build guides [2][6][9].
Citations:
- 1: https://developers.openai.com/codex/skills
- 2: https://developers.openai.com/codex/plugins/build
- 3: https://harnez.ai/posts/plugin-marketplace-architecture/
- 4: https://github.com/openai/codex/blob/31519549/codex-rs/core-plugins/src/manifest.rs
- 5: https://github.com/openai/codex/blob/main/codex-rs/skills/src/assets/samples/plugin-creator/SKILL.md
- 6: https://developers.openai.com/codex/plugins
- 7: https://developers.openai.com/codex/hooks
- 8: https://agenticcontrolplane.com/blog/codex-cli-hooks-reference
- 9: https://developers.openai.com/plugins/build/plugins
- 10: https://learn.chatgpt.com/docs/hooks.md
- 11: https://learn.chatgpt.com/docs/hooks
🌐 Web query:
site:docs.claude.com plugins submit skills hook enforcement skills only
💡 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:
- 1: https://docs.claude.com/id/release-notes/claude-apps
- 2: https://docs.claude.com/zh-TW/release-notes/claude-apps
- 3: https://docs.claude.com/fr/resources/claude-3-model-card.md
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
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/openai-submission.md` around lines 23 - 36, Update the Skills-only
listing in the tagline and long description to use advisory wording: replace
enforcement claims such as “forces” and “must verify” with terms like “guides”
and “instructs,” while preserving the dependency checks, source-citation, and
drift-audit capabilities described.
| - **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). |
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:
OpenAI plugins availability worldwide regions requirement privacy terms URLs openai.com plugins/deploy/submission
💡 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 ai-plugin.json manifest files—ceased functioning in April 2024 [1][2]. Current Availability and Status: - Legacy Plugins: These are no longer supported [1][2]. Conversations relying on them stopped working as of April 9, 2024 [1][2]. - Modern Alternatives: OpenAI has replaced the plugin functionality with more robust tools, primarily GPTs, GPT Actions, and native integrations (such as ChatGPT Search and Data Analysis) [1][4]. Developers and users are encouraged to migrate legacy plugin workflows to GPT Actions, which allow for similar API connectivity but operate within the updated GPT builder interface [5][6][7]. - Current "Plugins" terminology: In 2026, you may encounter references to "plugins" in the context of ChatGPT Work or Codex environments [8][9]. These are distinct from the deprecated legacy ChatGPT plugins. They function as a way to bundle skills, apps, and connectors for specific workflows within these professional environments [8][9]. Requirements and Privacy: - For the modern integrations available in ChatGPT Work or Codex, capabilities are managed through the plugin directory within those specific platforms [8][9]. - Privacy and terms for these integrations are handled on a per-app basis [8]. When using a connection or app, users are subject to the specific terms and privacy policies of the underlying third-party service [9]. - Access to these features is subject to your specific plan (e.g., ChatGPT Work), workspace settings, administrative controls, and regional availability [8][10]. Administrative controls allow workspace admins to manage installation and permissions [8]. If you are looking to deploy or manage modern capabilities, you should reference the official documentation for ChatGPT Work or Codex, rather than the legacy developer documentation for the original ChatGPT plugin beta [8][9].
Citations:
- 1: https://chatai.guide/features/chatgpt-plugins-legacy/
- 2: https://community.openai.com/t/error-plugins-are-no-longer-supported/715523
- 3: https://www.openai.com/blog/chatgpt-plugins
- 4: https://au.lifehacker.com/ai/10621/news/why-openai-replaced-chatgpt-plugins-with-gpts
- 5: https://community.openai.com/t/i-migrated-my-plugin-to-gpt-here-is-what-i-have-found-with-oauth-and-openapi/486664
- 6: https://community.openai.com/t/how-to-migrate-from-chatgpt-plugins-to-actions-solving-oauth-failures/480400/1
- 7: https://bestremotetools.com/migrate-chatgpt-plugins-to-custom-gpts-step-by-step-2026/
- 8: https://help.openai.com/en/articles/20001256-plugins-in-chatgpt-and-codex
- 9: https://developers.openai.com/codex/plugins
- 10: https://openai.com/index/codex-for-every-role-tool-workflow/
🌐 Web query:
developers.openai.com plugins deploy submission policy regional availability privacy terms URLs
💡 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:
- 1: https://chatai.guide/features/chatgpt-plugins-legacy/
- 2: https://www.getdrio.com/blog/chatgpt-plugins-vs-custom-gpts
- 3: https://developers.openai.com/plugins/deploy/submission
- 4: https://developers.openai.com/plugins/deploy/app-review
- 5: https://developers.openai.com/plugins
- 6: https://developers.openai.com/plugins/app-guidelines
- 7: https://developers.openai.com/plugins/deploy/submission-errors
- 8: https://help.openai.com/en/articles/20001256-plugins-in-chatgpt-and-codex
- 9: https://chatgpt.com/features/plugins/
Resolve policy URLs before publishing the submission materials.
Lines 40-45 acknowledge that PRIVACY.md and TERMS.md are missing. Lines 91-95 then recommend selecting worldwide availability. Since the submission requires public privacy and terms URLs and availability should match support/terms readiness, fix the missing policy pages first, or make worldwide availability conditional until they are published.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/openai-submission.md` around lines 40 - 45, Resolve the missing
policy-page references in the submission materials by adding and publishing
dedicated PRIVACY.md and TERMS.md pages, then update the Privacy URL and Terms
URL entries to point to them. Keep worldwide availability selected only once
those public policy URLs are available; otherwise make that selection
conditional.
| 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. |
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:
OpenAI Plugins Directory Submit plugins skill package assets referenced files self-contained bundle documentation
💡 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:
- 1: https://www.zdnet.com/article/on-march-19-chatgpt-plugins-get-replaced-by-gpts-heres-why-and-what-it-means-to-you/
- 2: https://au.lifehacker.com/ai/10621/news/why-openai-replaced-chatgpt-plugins-with-gpts
- 3: https://knowtechie.com/openai-chatgpt-plugins-gpts/
- 4: https://developers.openai.com/plugins/deploy/submission
- 5: https://developers.openai.com/plugins/quickstart
- 6: https://www.openai.com/blog/chatgpt-plugins
- 7: https://community.openai.com/t/error-plugins-are-no-longer-supported/715523
- 8: https://developers.openai.com/plugins/build/plugins
- 9: https://developers.openai.com/codex/plugins/build
- 10: https://github.com/openai/codex/blob/main/codex-rs/skills/src/assets/samples/plugin-creator/references/plugin-json-spec.md
- 11: https://developers.openai.com/plugins/deploy/app-review
- 12: https://developers.openai.com/plugins/app-guidelines
- 13: https://developers.openai.com/plugins/deploy/submission-errors
- 14: https://developers.openai.com/apps-sdk/deploy/submission
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 scripts/ as if they can remain outside the uploaded skill. Define the exact skill archive used for OpenAI testing, and update all bundle references in the OpenAI docs and marketplace summary to match it.
📍 Affects 2 files
docs/openai-submission.md#L51-L56(this comment)docs/openai-submission.md#L98-L104docs/marketplaces.md#L115-L119
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/openai-submission.md` around lines 51 - 56, Define one tested,
self-contained OpenAI Skills archive containing skills/version-sentinel/ and its
required scripts/, then update the bundle references at
docs/openai-submission.md:51-56, docs/openai-submission.md:98-104, and
docs/marketplaces.md:115-119 to consistently name and describe that archive,
including the required scripts adjacency.
| ## 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. |
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:
OpenAI plugins deployment submission testing tab expected result fixture data OpenAI Skills submission tests
💡 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:
- 1: https://www.openai.com/blog/chatgpt-plugins
- 2: https://community.openai.com/t/error-plugins-are-no-longer-supported/715523
- 3: https://au.lifehacker.com/ai/10621/news/why-openai-replaced-chatgpt-plugins-with-gpts
- 4: https://knowtechie.com/openai-chatgpt-plugins-gpts/
- 5: https://developers.openai.com/plugins/deploy/submission
- 6: https://developers.openai.com/plugins/deploy/submission-errors
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 BLOCKED case from the skills submission and replace it with the skill-only behavior if testing. Use the exact command shown by docs/openai-submission.md and scripts/vs-record.sh; currently line 62 uses vs-record ... while that script says use /vs-record ....
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/openai-submission.md` around lines 58 - 89, Update the Testing tab
examples with concrete fixture inputs and expected artifact/result shapes for
all positive cases, including the exact recorded entries and manifest changes.
Replace every `vs-record` invocation with the documented `/vs-record` command
from the recording script. For each negative case, state the specific enforced
rejection reason, and remove the hook-based `BLOCKED` outcome in favor of the
skill-only verification behavior.
Source: Coding guidelines
| - `version.txt` | ||
| - `.release-please-manifest.json` | ||
| - `.claude-plugin/plugin.json` `$.version` (via `release-please-config.json` `extra-files`) | ||
| - `$.version` in all six manifests (via `release-please-config.json` `extra-files`): `plugin.json`, `.claude-plugin/plugin.json`, `.claude-plugin/marketplace.json`, `kimi.plugin.json`, `gemini-extension.json`, `.codex-plugin/plugin.json` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Update the release-owned file list in the TL;DR.
Line 11 still says that release-please owns only .claude-plugin/plugin.json and “all four” release files. The new six-manifest contract in Lines 41 and 57-60 contradicts that statement. Update Line 11 so contributors do not edit the other five version fields manually.
Proposed documentation fix
-... or `.claude-plugin/plugin.json` `$.version` manually. release-please owns all four.
+... or any manifest `$.version` field manually. release-please owns those six version fields plus the other release files listed here.Also applies to: 57-60
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/versioning.md` at line 41, Update the TL;DR release-owned file list in
docs/versioning.md to state that release-please manages all six manifest version
fields, matching the manifests listed near the existing release configuration
references. Remove the outdated “all four” wording and clarify that contributors
must not edit the other five version fields manually.
Fixes Applied SuccessfullyFixed 3 file(s) based on 7 unresolved review comments. Files modified:
Commit: The changes have been pushed to the Time taken:
Lines 8–13 permissions:
contents: write
pull-requests: write
+ issues: write
jobs:
release-please:Lines 20–26 # A release PR opened by the default GITHUB_TOKEN lands its checks in
# `action_required`, so tests never run until someone approves them by
# hand. Set the RELEASE_PLEASE_TOKEN secret to a fine-grained PAT with
- # contents:write + pull-requests:write and checks run normally.
+ # contents:write + pull-requests:write + issues:write and checks run normally.
# Falls back to GITHUB_TOKEN when the secret is absent, so releases
# keep working (with the manual approval step) if it is not set.
token: ${{ secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }} |
Fixed 3 file(s) based on 7 unresolved review comments. Co-authored-by: CodeRabbit <noreply@coderabbit.ai>
1 participant
Clears the three follow-ups left open after #19 / #20.
1. Manifest drift (
fix:)plugin.jsonand.claude-plugin/plugin.jsonhad diverged three ways:plugin.json.claude-plugin/plugin.jsondescriptionsupply-chain-securitykeyworduserConfigClaude Code reads the
.claude-plugin/copy so the options worked in practice, but release-please stamps$.versioninto both, and README / AGENTS.md / CLAUDE.md all document both as "the" manifest — anything reading root saw a plugin with no configurable options.Both files are now byte-identical: root's fuller description and keyword list, plus
.claude-plugin/'suserConfig.tests/test_manifest_parity.shkeeps them that way — deep JSON equality plus per-key assertions so a regression names the offending field instead of dumping a whole diff. It runs insidetests/run.sh, so the existing 3-OStestjob covers it; no new CI job.I verified the guard actually fails rather than merely passing on the synced state:
2. Release-PR checks never ran (
ci:)docs/versioning.md:110already prescribed this fix — it just was never wired up.A release PR opened by the default
GITHUB_TOKENgets its checks created inaction_required: the runs exist but sit unstarted pending manual approval in the Actions tab. v0.4.1 was merged in exactly that state, so that release shipped before its tests ran (they were approved and passed afterwards).token:now resolves${{ secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }}, degrading to today's behavior when the secret is absent.Also corrected two stale claims in
versioning.md: the release PR stamps$.versioninto all six manifests (not one), and the gated runs are created-but-unstarted rather than never created.3. OpenAI submission docs (
docs:)Adds the previously-untracked
docs/openai-submission.md— listing copy, the 5 positive / 3 negative test cases the portal requires, and its prerequisites. Resolves the "open question for the owner" inmarketplaces.md: submission type is Skills only, since hooks aren't a submittable portal component, so a directory listing ships the skill and can't enforce blocking.Flags a real gap rather than papering over it: the portal requires privacy + terms URLs and no
PRIVACY.md/TERMS.mdexists yet.Verification
The
fix:commit means release-please will open a 0.4.2 PR — appropriate, since the.claude-plugin/description and keywords are user-visible in the marketplace listing.🤖 Generated with Claude Code
https://claude.ai/code/session_0118eLJLbPbqYXiPc8R9AAiJ
Summary by CodeRabbit
New Features
Documentation
Chores