codebyplan 1.13.0 → 1.13.3

package/templates/skills/cbp-ship-configure/SKILL.md

@@ -1,7 +1,7 @@
 ---
 scope: org-shared
 name: cbp-ship-configure
-description: Configure shipment for one or more surfaces in the current repo — Vercel link, EAS project + eas.json scaffold, Apple credentials probe, npm publish auth check (including `codebyplan` asset-publish automation via release-please), Railway project link, Supabase access token verify; Supabase GitHub branching integration via /cbp-supabase-setup. Interactive step-by-step; never stores credentials in the repo.
+description: Configure shipment for one or more surfaces in the current repo — Vercel link, EAS project + eas.json scaffold, Apple credentials probe, npm publish auth check (including `codebyplan` asset-publish automation via the publish-on-main workflow), Railway project link, Supabase access token verify; Supabase GitHub branching integration via /cbp-supabase-setup. Interactive step-by-step; never stores credentials in the repo.
 argument-hint: [--surface=<id>]
 allowed-tools: Read, Write, Edit, Bash(which *), Bash(vercel *), Bash(eas *), Bash(npm *), Bash(railway *), Bash(jq *), Bash(mkdir *), Bash(cp *), Bash(echo *), Skill(cbp-supabase-setup)
 effort: xhigh
@@ -152,22 +152,23 @@ If multiple surfaces were configured, list each one's status. If any failed, lis
 
 Re-running on an already-configured surface re-runs the probe (CLI installed? logged in? token still valid?) and refreshes the `.codebyplan/shipment.json` block. It does NOT replace credentials — those stay where the CLI keeps them. This is the primary path for "I rotated my npm token, does shipment still work?" — re-run, the probe catches the bad token immediately.
 
-## Special case: opt-in to release-please
+## Special case: versioning mode (npm-package)
 
-`release-please` is one of three versioning modes (manual, release-please, changesets). Opt-in is part of npm-package configure:
+Picking a versioning mode is part of npm-package configure:
 
 ```
 Step N/M: Versioning mode
 A) Manual — bump package.json version yourself before /cbp-ship
-B) release-please — GH Action opens version-bump PRs based on conventional commits (recommended for npm packages)
-C) changesets — manual changeset entries; tooling aggregates into version PRs (recommended for monorepos with many published packages)
+B) in-branch-bump — `codebyplan ship` patch-bumps changed packages in the feat branch; merge to main auto-publishes via the publish-on-main workflow (recommended for codebyplan-CLI repos)
+C) release-please — GH Action opens version-bump PRs based on conventional commits
+D) changesets — manual changeset entries; tooling aggregates into version PRs (recommended for monorepos with many published packages)
 ```
 
-If B or C, the skill scaffolds the GitHub Actions workflow + config file (`templates/workflows/release-please.yml` or `.changeset/config.json`).
+If B, the skill scaffolds the publish-on-main workflow via `codebyplan scaffold-publish-workflow` (see the `codebyplan` asset-publish automation section below). If C or D, the skill scaffolds the GitHub Actions workflow + config file (`templates/workflows/release-please.yml` or `.changeset/config.json`). See [../ship/reference/versioning.md](../ship/reference/versioning.md) for the full mode comparison.
 
 ## Special case: `codebyplan` asset-publish automation
 
-The canonical-owner repo publishes the `codebyplan` npm package — the distribution mechanism for `scope: org-shared` skills/agents/hooks (via its `claude install|update|uninstall` subcommand group). Sibling repos consume it via `npx codebyplan claude update` (the merged CLI; package path `packages/codebyplan-package/`). This branch handles the once-per-repo setup so release-please can autopublish on merge to main. (CHK-132 consolidated the prior standalone `@codebyplan/claude` package into `codebyplan`; the legacy `@codebyplan/claude` package on npm stays un-deprecated at its last published version for backward-compat, but receives no further updates.)
+The canonical-owner repo publishes the `codebyplan` npm package — the distribution mechanism for `scope: org-shared` skills/agents/hooks (via its `claude install|update|uninstall` subcommand group). Sibling repos consume it via `npx codebyplan claude update` (the merged CLI; package path `packages/codebyplan-package/`). This branch handles the once-per-repo setup so the package autopublishes on merge to main via the publish-on-main workflow. (CHK-132 consolidated the prior standalone `@codebyplan/claude` package into `codebyplan`; the legacy `@codebyplan/claude` package on npm stays un-deprecated at its last published version for backward-compat, but receives no further updates.)
 
 When the user picks `--surface=npm-package` AND the detected package is `packages/codebyplan-package`, the walkthrough runs these extra probes / scaffolds in addition to the standard npm-package configurator (see [reference/npm-package.md](reference/npm-package.md)):
 
@@ -190,38 +191,17 @@ Confirms the logged-in account has read on the `@codebyplan` org scope. If 404 /
 - Either the user does not belong to the `@codebyplan` org → STOP, request invitation from org owner
 - Or the scope is unclaimed → user creates the org at https://www.npmjs.com/org/create (org name `codebyplan`, free public-packages tier)
 
-### Scaffold 1 — release-please workflow
+### Scaffold — publish-on-main workflow
 
-If `.github/workflows/release-please.yml` is absent:
+The package autopublishes via `.github/workflows/publish.yml` (the publish-on-main model — version-change detection on merge to main, no Release PR). Scaffold it with the CLI:
 
 ```bash
-mkdir -p .github/workflows
-cp "${CLAUDE_SKILL_DIR}/../ship/templates/workflow-release-please.yml" .github/workflows/release-please.yml
-# Then replace REPLACE_WITH_INTEGRATION_BRANCH with the production branch from .codebyplan/git.json branch_config.production (typically `main`)
+codebyplan scaffold-publish-workflow
 ```
 
-The mechanics + commit-prefix → bump-tier mapping live in [../ship/reference/release-please-overview.md](../ship/reference/release-please-overview.md).
+This writes `templates/github-workflows/publish.yml` into `.github/workflows/publish.yml` (idempotent — re-running on an identical file is a no-op; pass `--force` to overwrite a divergent one, `--dry-run` to preview). `.github/` is outside the `codebyplan claude install` target (which only writes under `.claude/`), so the publish workflow has its own scaffold command rather than riding `claude install`.
 
-### Scaffold 2 — release-please-config.json at repo root
-
-If `release-please-config.json` is absent:
-
-```bash
-cp "${CLAUDE_SKILL_DIR}/../ship/templates/release-please-config.json" release-please-config.json
-# Then replace REPLACE_WITH_PACKAGE_NAME with codebyplan
-# Confirm `packages."."` block is replaced with `packages."packages/codebyplan-package"`
-```
-
-### Scaffold 3 — .release-please-manifest.json at repo root
-
-If `.release-please-manifest.json` is absent:
-
-```bash
-VERSION=$(jq -r '.version' packages/codebyplan-package/package.json)
-echo "{\"packages/codebyplan-package\": \"${VERSION}\"}" > .release-please-manifest.json
-```
-
-(Bootstrap version reads from `packages/codebyplan-package/package.json` `version` field at scaffold time.)
+The workflow needs no per-bump editing: it reads `package.json` `version` at run time, compares it to `npm view`, and publishes only when the committed version is greater. `package.json` is the sole version-of-record — there is no `release-please-config.json` / `.release-please-manifest.json`. (Repos that prefer the conventional-commit Release-PR flow can still scaffold release-please from `../ship/templates/` instead — see [../ship/reference/release-please-overview.md](../ship/reference/release-please-overview.md).)
 
 ### Verify — publishConfig.access on the package
 
@@ -249,8 +229,8 @@ Required value: `public`. If `missing` or `restricted`, instruct the user to add
       "packages/codebyplan-package": {
         "package_name": "codebyplan",
         "bin_name": "codebyplan",
-        "versioning": "release-please",
-        "publish_mode": "release-please-on-merge-to-main",
+        "versioning": "in-branch-bump",
+        "publish_mode": "publish-on-main",
         "access": "public"
       }
     }
@@ -258,7 +238,7 @@ Required value: `public`. If `missing` or `restricted`, instruct the user to add
 }
 ```
 
-After this branch completes, every merge to main with `feat:` / `fix:` / `feat!:` Conventional Commits will trigger release-please to open a version-bump PR. When the maintainer merges that PR, release-please tags the release and `npm publish` runs from the workflow (auth via `NODE_AUTH_TOKEN` GH secret or OIDC trusted publishing — see [../ship/reference/npm-publish-oidc-trusted.md](../ship/reference/npm-publish-oidc-trusted.md)). Siblings then pick up the new asset content via `npx codebyplan claude update`.
+After this branch completes, the publish loop is fully automatic: `codebyplan ship` patch-bumps the package in the feat branch (rides the single feat→main PR), and on merge to main `publish.yml` detects the committed version exceeds the npm-published version and runs `npm publish` via OIDC trusted publishing (see [../ship/reference/npm-publish-oidc-trusted.md](../ship/reference/npm-publish-oidc-trusted.md)), then tags `v{version}` + cuts a GitHub release. No separate Release PR. Siblings then pick up the new asset content via `npx codebyplan claude update`.
 
 ## Special case: Apple credentials for TestFlight
 

package/templates/skills/cbp-ship-configure/reference/npm-package.md

@@ -2,7 +2,7 @@
 
 Walkthrough for first-time npm publish setup.
 
-> **Special case** — when the package being configured is `packages/codebyplan-package` (i.e., the `codebyplan` npm package that ships `scope: org-shared` skills/agents/hooks via its `claude` asset subcommand group), the parent SKILL.md "Special case: `codebyplan` asset-publish automation" section runs additional probes (npm whoami, npm publish auth) and scaffolds (`release-please-config.json`, `.release-please-manifest.json` at repo root) on top of the generic walkthrough below. See SKILL.md for the full extra flow. (CHK-132 consolidated the prior `@codebyplan/claude` package into `codebyplan`.)
+> **Special case** — when the package being configured is `packages/codebyplan-package` (i.e., the `codebyplan` npm package that ships `scope: org-shared` skills/agents/hooks via its `claude` asset subcommand group), the parent SKILL.md "Special case: `codebyplan` asset-publish automation" section runs additional probes (npm whoami, npm publish auth) and scaffolds the publish-on-main workflow (`.github/workflows/publish.yml` via `codebyplan scaffold-publish-workflow`) on top of the generic walkthrough below. See SKILL.md for the full extra flow. (CHK-132 consolidated the prior `@codebyplan/claude` package into `codebyplan`.)
 
 ## Prerequisites
 
@@ -85,11 +85,20 @@ Surface any errors/warnings; offer to fix obvious ones (missing `files`, wrong `
 
 ```
 A) Manual — bump package.json version yourself before each release
-B) release-please — GH Action opens version-bump PRs based on conventional commits (recommended)
-C) changesets — manual changeset entries; aggregator PR (recommended for monorepos)
+B) in-branch-bump — `codebyplan ship` patch-bumps changed packages in the feat branch; merge to main auto-publishes via the publish-on-main workflow (recommended for codebyplan-CLI repos)
+C) release-please — GH Action opens version-bump PRs based on conventional commits
+D) changesets — manual changeset entries; aggregator PR (recommended for monorepos)
 ```
 
-If B, scaffold:
+If B, scaffold the publish-on-main workflow (idempotent; `--force` overwrites, `--dry-run` previews):
+
+```bash
+codebyplan scaffold-publish-workflow
+```
+
+`package.json` is the sole version-of-record — no `release-please-config.json` / `.release-please-manifest.json`. See [../../ship/reference/versioning.md](../../ship/reference/versioning.md) for the full model.
+
+If C, scaffold:
 
 ```bash
 cp ${CLAUDE_PLUGIN_ROOT}/skills/ship/templates/workflow-release-please.yml .github/workflows/release-please.yml
@@ -97,7 +106,7 @@ cp ${CLAUDE_PLUGIN_ROOT}/skills/ship/templates/release-please-config.json releas
 echo '{".":"<current version>"}' > .release-please-manifest.json
 ```
 
-If C:
+If D:
 
 ```bash
 cd "$REPO_ROOT"
@@ -134,7 +143,7 @@ The workflow uses `permissions: id-token: write` and runs `npm publish --provena
       "configured_at": "<now>",
       "packages/codebyplan-package": {
         "package_name": "codebyplan",
-        "versioning": "release-please",
+        "versioning": "in-branch-bump",
         "publish_mode": "oidc",
         "access": "public"
       }

package/templates/skills/cbp-ship-main/SKILL.md

@@ -48,10 +48,14 @@ codebyplan ship --body-file /tmp/cbp-ship-main-body.md --json${DRY_RUN:+ --dry-r
 
 Pass `--dry-run` through if the skill was invoked with a dry-run arg.
 
+`codebyplan ship` patch-bumps every changed workspace package and commits `chore(release): bump versions` on the feat branch BEFORE creating the PR, so the bump rides this same feat→main PR (see `cbp-ship/reference/versioning.md`, `in-branch-bump` mode). Pass `--no-bump` to skip for a single ship.
+
 ### Step 4: Report
 
 Parse JSON from Step 3. Report `pr_url`, `merge_commit`, `branch_deleted`. If `checks_failed: true`, surface `checks_failure_reason` and stop.
 
+If `bumps[]` is present with any non-skipped entry, surface a **Version bumps** line per package — `<name>: <currentVersion> → <nextVersion>` — so the user sees what this PR will publish on merge.
+
 If `branch_deleted === true`, run a conditional Supabase preview-branch teardown for the feat branch that was just merged:
 
 > Lifecycle contract: see [[supabase-branch-lifecycle]].