Package Claude plugin with CLI

[raghubetina]

Summary

• assemble the canonical Skill and exact reviewed CLI into one deterministic Claude plugin npm package
• expose firstdraft through Claude Code plugin-root Bash PATH and map sensitive plugin configuration safely
• add compatibility, CI, protected publication, and public-install release gates
• record the isolated npm-source qualification and rejected transitive-dependency design

Verification

• npm audit: clean
• repository suite: 48 tests pass
• deterministic package check with real CLI: Node 22.0.0 and 24.18.0
• Claude Code 2.1.222 strict plugin validation: pass
• Skill quick validation: pass
• isolated npm-source install: pass with vendored CLI
• fresh Claude Bash invocation: firstdraft --version returned 0.1.0-alpha.2

Dependency

• merge Declare CLI release compatibility cli#20 first

No public npm package is published by merging this PR. Publication remains tag-triggered and approval-gated.

[raghubetina]

Post-merge retrospective on the founding packaging PR: canonical Skill plus exact reviewed CLI assembled
into one deterministic npm package, firstdraft exposed through the plugin-root Bash PATH, and the
compatibility, CI, protected-publication, and public-install release gates all born here. Two things read
differently with six weeks of hindsight. The deterministic assembly (same inputs, same packed digest) is
what every later promotion record leans on when it cites a tarball SHA-256; that property was a choice made
here, not an accident. And the "map sensitive plugin configuration safely" ambition met reality in #27/#28:
the userConfig bridge to a PATH executable turned out not to be a delivered capability, and the honest
resolution was deletion plus an open issue. The gates outlived the bridge, which is the right components
surviving.

[raghubetina]

This is the PR where a Skill and a CLI became one installable thing, and its durable lesson is
determinism as a release property.

The package assembles two inputs: the canonical Skill text and one exact, already-reviewed CLI revision. The
assembly is deterministic: build it twice from the same inputs and the packed tarball hashes identical.
Boring, until you notice that every release record downstream (promotions, install observations, failure
evidence) identifies packages by SHA-256. That entire evidence style is only possible because the build has
no timestamps, no network fetches at pack time, no "latest" resolution, nothing that varies. If your build
embeds a build date, you have opted out of content-addressable release records forever.

Bundling the CLI inside the plugin (rather than having the plugin install it) is the same instinct applied
to composition: the plugin version pins its exact CLI bytes, so "plugin 0.1.x" names one complete, testable
behavior rather than a combination that depends on what the user's machine fetched that day. The cost is
bigger packages and lockstep releases; the benefit is that qualification of a version means something.

And the gates established here (compatibility declared, CI on the exact head, protected publication
requiring approval, a public-install check after promotion) are the skeleton every later release PR in this
repo fills in. Infrastructure PRs are judged by what they make routine; this one made honest releases the
path of least resistance.