# VSIX Ready > Check a VS Code extension against the first-party extension contract before you publish. Paste your VS Code extension's > package.json, its publish workflow and the previous version's manifest, and get the extension contract, registries, > auth, telemetry and versioning checked, then the go/no-go plan per job or the release-gate plan for this version. > Built on the SkillSafe skill @samber/ide-extension-offering, from samber/developer-platform-skills (MIT), by Samuel > Berthe. > Not affiliated with or endorsed by Microsoft, the Eclipse Foundation or JetBrains. > Scope: a developer platform's official editor integrations - whether to ship an IDE extension, for which job and which > editors, and running it: published to the VS Code Marketplace and Open VSX, trusted, in sync with the CLI, and retired > cleanly. Not internal or personal extensions, not writing extension or language-server code, not choosing extensions to > install. https://vsix-ready.skillsafe.ai/ ## What is free - Parsing: the package.json and the previous version's, each read with JSON.parse; a paste that does not parse is named by its line and column. Read: name, publisher, displayName, version, engines.vscode, main, browser, activationEvents, contributes (commands, configuration properties with their keys, types, descriptions and defaults, views, walkthroughs, authentication, jsonValidation, languages, debuggers, mcpServerDefinitionProviders), capabilities (untrustedWorkspaces, virtualWorkspaces), extensionKind, extensionDependencies, extensionPack, scripts, dependencies, devDependencies, repository, bugs, icon, keywords, pricing and preview. Nothing is run or installed. - The publish workflow (GitHub Actions or GitLab CI), scanned as text with fixed signal kinds: vsce_package, vsce_publish, ovsx_publish, id_token_write, secret_scan, tests, tests_insiders, tests_stable, verify_plugin, pat_env, vsce_login and literal_token; whether one packed file goes to both registries. A token written into the file is masked, never echoed. An optional JetBrains plugin.xml is read for its id, name, vendor, since-build and until-build. - The extension contract as checks, each with an id, its rule number and pass, fix, fail, note or n/a; a check that fails on one setting carries the setting as its subject: r1_direct_api and r1_cli_detect (rule 1, no business logic or hand-written API calls); r2_open_vsx and r2_same_file (rule 2, the same .vsix on both registries); r3_secret_setting (rule 3, no credential in a setting); r4_own_setting and r4_logger (rule 4, telemetry follows the host); r5_ext_id and r5_plugin_id (rule 5, a published ID never changes); r6_vsce_token, r6_ovsx_token, r6_id_token, r6_literal_token and r6_secret_scan (rule 6, short-lived or federated publishing credentials). Then a_activation, a_bundler, a_extension_kind, a_browser, a_untrusted, a_virtual, a_engines, a_walkthrough, a_auth_provider, a_json_schema, a_ext_deps and a_mcp_def (architecture); v_format, v_channel, v_prerelease_engine, v_increase, v_engine_raise and v_vsce_package (versioning); j_since_build and j_until_build (JetBrains); l_repository, l_icon and l_keywords (the listing); fleet and community. - The manifest diff, with the previous package.json pasted: every change is one of id_changed, command_removed, command_renamed (a removed command whose title reappears on a new ID), setting_removed, setting_type_changed, setting_default_changed, activation_added_star, engine_floor_raised, dependency_added, trust_widened, telemetry_dep_added or view_removed, identified by its kind and its subject (a setting by its key, never by a description two settings may share), each with what it does to users, the safe alternative (deprecate, never remove; narrow, never widen) and an action: keep, revert, deprecate or narrow. - The ladders, each naming the answer that moved it: the job ladder (json_schema, language_server, mcp_server, cli_command, thin_shell, shell_launch, rich_extension; go, go_later or no_go per job), the editor families (vscode, jetbrains, other_editors, visual_studio; default, promoted, starved, documented, separate or not_needed) and the auth ladder (authentication_provider, cli_login, secret_store_key or none). - The release gates, pass, fail or unknown from the files and the interview: same_vsix, secret_scan, host_tests, plugin_verifier, compat_matrix, telemetry_off and untrusted_test. The version facts: the current version, its kind from the minor's parity (odd for a pre-release, even for a release) and whether it is ok to publish as marked. - A consistency check: no settled verdict is contradicted by a failing check that argues about the same thing. - Exports: the checks (.csv), the diff (.csv), the compatibility matrix (.md, first row from your own fields or "unknown"), everything (.json), a fixed package.json ("*" leaves activationEvents only when other events remain, workspace trust becomes "limited" with a description when the extension runs the CLI, credential settings move out into a note - no command, ID, event or version is invented), a fixed publish workflow (package once, scan, publish that same file to both registries with federated credentials, print its hash - from your own names) and a deprecation notice from the skill's template. - Saved extensions keep a compact snapshot of the checks: reopening one, or pasting an extension of the same name, shows what changed since it was saved. - Every registry figure carries a dagger: an extension listed for 6+ months† and a domain registered 6+ months† for the verified-publisher badge, about 5 business days† of review, three platform majors† a year on JetBrains, global Azure DevOps PATs ending on 2026-12-01†, engines.vscode 1.63.0† or above for the pre-release channel, Node 22+† for vsce publish --oidc, a PNG icon of at least 128 px†, at most 30 keywords†, the JetBrains LSP API from 2023.2+† and in the free tier of unified PyCharm since 2025.1†. The app never knows a VS Code fork's Code-OSS base version and never guesses one. - † verify against the current registry documentation (VS Code Marketplace, Open VSX, JetBrains Marketplace) before quoting it. ## The metered lanes Two tasks on gpt-terra, metered per run, routed by `task`. Input string fields: `task` (plan or release), `context` (the interview answers), `manifest` (the package.json as read), `previous` (the previous package.json as read, or empty), `workflow` (the workflow's signal lines, or empty), `jetbrains` (the plugin.xml as read, or empty), `diff` (the page's diff rows, or empty), `carry` (release only: the plan's verdicts, auth rung and fixes), `facts` and an optional `retry_note`. - `plan` replies with `summary`, `verdicts` (`job`, `surface`, `verdict` go, go_later or no_go, `why`), `families` (`family`, `rung`, `why`), `auth` (`rung`, `why`), `fixes` (`check`, `subject`, `change`), `sequence` (`step`, `owner` a role, `when` a workflow step 1 to 9), `matrix` (`column`, `value`), `footnote` and `caveats`. - `release` replies with `summary`, `version` (`current`, `kind` release or pre_release, `ok`), `changes` (`kind`, `subject`, `consequence`, `action` keep, revert, deprecate or narrow), `gates` (`gate`, `status` pass, fail or unknown, `action`), `publish` (each step on its own line), `changelog` (each line on its own line), `footnote` and `caveats`. It needs the previous package.json. A reply stays on the page when the form changes after it ran, under an out-of-date banner, and its downloads and copies keep working; each plan fix and each release change copies on its own, and the plan's handoff carries its verdicts and fixes into the release lane. The page holds every reply to its own facts, matching rows by the same composite identity its facts use (a fix by check id and subject, a change by kind and subject): the plan keeps one verdict per selected job with the page's surface and verdict, the four families in the page's order and rungs, the auth rung, a fix for every failing check, a sequence owned by roles in workflow order and the page's matrix; the release keeps the version facts, one change per diff row with the page's action, one gate per page gate with its status, publish steps one per line for one packed file with federated credentials and the same hash, and a changelog one line per item that names a raised engines floor; both carry the dagger on every registry figure, the footnote, no URL, no backticks, no advice to remove or unpublish an extension, no credential in a setting and no implied endorsement. ## Links - API tutorial: https://vsix-ready.skillsafe.ai/api.html - Source skill: https://skillsafe.ai/skill/@samber/ide-extension-offering - Source repository: https://github.com/samber/developer-platform-skills