[parkerlandon-codaio]

Prepare the first local npm release as @superhuman/plugins-sdk, retaining version 1.18.4 and the existing changelog.

The change is limited to four files:

• package.json: set the npm name and public registry.
• .github/releases/first-publish.config.cjs: stage the current version through release-it for separate approval, without creating Git commits/tags/pushes or GitHub releases.
• documentation/samples/package.json and pnpm-lock.yaml: keep existing sample imports working through a local workspace alias after the package name changes.

Documentation content, examples, SDK/CLI code, generated files, changelog, Makefile, and CI workflows are unchanged.

Use an npm version supporting staged publication, such as npm 11.15.0 pinned in CI. From an updated, clean main checkout with the supported Node version and dependencies installed:

make build
npm login --registry=https://registry.npmjs.org
.pnpm_install/bin/pnpm exec release-it --config .github/releases/first-publish.config.cjs --dry-run
.pnpm_install/bin/pnpm exec release-it --config .github/releases/first-publish.config.cjs

The last command submits a stage; it does not make the package public. Release-it prints the stage approval command. Inspect the stage, then publish it separately with npm 2FA:

npm stage approve <stage-id>

For the feature branch, explicitly override the config's main-only check with --git.requireBranch=parkerlandon-superhuman-npm-publication. Authentication uses the local npm login; no separately minted automation token is needed. Nothing has been staged or published by this PR.

Validation: frozen pnpm install, full build, sample validation, and packed artifact inspection passed after merging main's 1.18.4 release. The staging change passed an isolated release-it fixture with network blocked: it runs npm stage publish, prints the approval command, never directly publishes or approves, preserves version/changelog/Git state, and retains authentication/branch checks. skip-version-check preserves the requested existing version.

Refs GOECOS-722. Internal source/export alignment remains separate coordination before publication.

[linear-code]

GOECOS-722 Verify and publish @superhuman/plugins-sdk on npm

Scope

Publish the SDK exported to superhuman/plugins-sdk as @superhuman/plugins-sdk. This is the npm publishing portion split from GOECOS-505 to track milestones independently.

Coordinate release ownership with Publish SDK out of FEWM.

First complete GOECOS-773 to identify the @superhuman npm scope owner and confirm the publishing-access path. This issue owns final artifact verification and initial publication. Publishing identity setup is split into GOECOS-894. Compatibility verification remains in GOECOS-714.

Acceptance criteria

• ☐ Verify package metadata for the published artifact. New-package publishing identity and release protection verification are tracked in GOECOS-894; CI workflow migration is tracked in GOECOS-893.
• ☐ Inspect npm artifact for expected JavaScript, declarations, and supported entry points.
• ☐ Existing SDK fixture installs the artifact, builds, and runs through supported CLI workflows after dependency/import changes alone, retaining newPack().
• ☐ Upload behavior and wire contracts remain unchanged; coordinate Studio/CLI verification with GOECOS-714.
• ☐ Publish initial release after verification and verify installation from npm.
• ☐ Document release ownership, how to pause publishing, and how to revert export configuration changes.

Requires successful export verification in GOECOS-505. Optional Connector aliases in GOECOS-506 are not a prerequisite. Old-package retirement is separate in GOECOS-723.

References

• Compatibility agreement

Related implementation PR

• superhumans-org/product#27296. Package-renaming work is shared with the export setup in GOECOS-505; this issue tracks verification and npm publication.

Review in Linear

[wiz-d3cfedd612]

Wiz Scan Summary

Scanner	Findings
Sensitive Data	-
Secrets	-
IaC Misconfigurations	-
Software Management Findings	-
Total	-

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try the Wiz Code extension for VS Code, JetBrains, or Visual Studio.