release: v0.0.18 (project create guides instead of inventing a name)

[tonychang04]

Bumps to v0.0.18 to ship #50.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GMbAe5K1RfwaAcge5inX7P

---

Summary by cubic

Release v0.0.18 to ship the new project creation guides from #50. This replaces the auto-generated project name flow with a guided setup.

^{Written for commit cdbf358. Summary will update on new commits.}

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[jwfing]

Review — release: v0.0.18

Summary: Mechanical single-line version bump (0.0.17 → 0.0.18) in package.json to ship the #50 project-create fix; verified to match the established release convention and to actually contain the change it claims.

Requirements context

No /docs/superpowers/ or docs/specs/ directory exists in this repo — assessing against the PR description and repo release convention alone (no spec/plan document to consult, which is expected for a release-tag PR). I verified intent against the surrounding release history rather than a spec.

Findings

Critical — (none)

Suggestion — (none)

Information

• Functionality: The bump is monotonic and correct (package.json:3, 0.0.17 → 0.0.18). The shipped change #50 (fix(project create): guide to name it instead of inventing a junk-named project, commit 3a79323) is present as the direct parent of the release commit cdbf358, so the release genuinely ships what the body claims.
• Software engineering: Diff is identical in shape to the two preceding releases — v0.0.17 (01887c8) and v0.0.16 (caf94ee) — each a package.json +1/-1 bump only. No tests are warranted (no behavior change). No CHANGELOG exists in the repo, so nothing to keep in sync.
• Software engineering (no action): The package-lock.json root version field remains 0.0.0. This is not introduced by this PR — it was already 0.0.0 on the base (3a79323:package-lock.json) and across all prior releases, so it is a pre-existing repo convention (the lockfile does not track the published version). Flagging only for awareness; no change needed here.
• Security: No security-relevant changes — no code, no new/changed dependencies, no secrets, no auth surface touched.
• Performance: No performance-relevant changes — no runtime code paths modified.

Verdict

approved (informational; posted as a COMMENT — the GitHub green-check approval remains a separate human action). Zero Critical findings. Scope is tight and matches the release convention exactly.

[jwfing]

LGTM - approved.

[jwfing]

Review: release v0.0.18

Summary: A one-line release bump (package.json 0.0.17 → 0.0.18) to ship #50; the change is minimal, correct, and consistent with the repo's release conventions.

Requirements context

No matching spec/plan found — docs/specs/ is empty and there is no docs/superpowers/ directory. Assessed against the PR description, the version-release skill, and the repo's release automation. Note the feature being shipped (#50, "guide to name it instead of inventing a junk-named project") is already merged to main at the PR's base commit 3a79323; its code was reviewed on its own PR. This PR's scope is purely the version bump, which is exactly what a release PR should contain.

Findings

Critical — (none)

Suggestion — (none)

Information

• Software engineering / functionality: Version progression is a correct sequential patch bump. The prior release was v0.0.17 (#49, commit 01887c8) and the diff moves the single version field to 0.0.18 (package.json:3) — no stray edits. The head branch adds only the release commit on top of a base that already contains #50, so the diff is exactly scoped.
• Release consistency: Verified npm ci resolves cleanly against the existing package-lock.json (122 packages, no sync error), so the version bump does not break the CI test job (.github/workflows/ci.yml:17) or the publish-npm job (release.yml:119). Version stays aligned across all three release outputs: the published npm package reads version from package.json (0.0.18), and the binary version is injected from the tag name ${GITHUB_REF_NAME#v} (release.yml:40,47) — tag v0.0.18 → npm 0.0.18 → binary 0.0.18.
• Release readiness (informational, for the tagger): Tag v0.0.18 does not yet exist on the remote, so the idempotency check for the subsequent tag/release step is clear. Per the version-release skill, the tag must be pushed against main after this merges — pushing v* triggers the binary build + GitHub release + npm publish (release.yml), which are irreversible external side-effects.
• Pre-existing (not introduced here, no action needed): package-lock.json keeps its root version at 0.0.0 and name as insta-cli while package.json name is insta. This is the established pattern across every prior release (v0.0.13–v0.0.17) and npm ci is unaffected — flagging only so it isn't mistaken for a regression in this diff.

Security

No security-relevant changes — the diff touches only a version string; no new inputs, dependencies, secrets, or auth paths.

Performance

No performance-relevant changes.

Verdict

approved — no Critical findings. The version bump is correct, minimal, and CI-safe. (This is the bot's assessment; explicit GitHub approval remains a separate human action.)