codebyplan 1.13.0 → 1.13.4

package/templates/skills/cbp-setup-eslint/reference/vitest.md

@@ -1,62 +1,42 @@
-# vitest — Vitest test-file rules
+# vitest — Vitest test files (official @vitest/eslint-plugin setup)
 
-For apps that test with Vitest (CBP web + CLI + most repos). Layers a **test-scoped** override
-on top of [base](base.md). Maps to the CBP **`testing`** DB preset
-(`tech_match.requires: ["Vitest"]`).
+> **Official source**: https://github.com/vitest-dev/eslint-plugin-vitest (verified 2026-05-31). This
+> is the plugin's official flat-config example verbatim.
 
-> **Verified 2026-05-31.** The package was **renamed** to the scoped
-> **`@vitest/eslint-plugin`** (the old `eslint-plugin-vitest` is the deprecated name). Its
-> flat-config key is plain **`configs.recommended`** — there is **no `flat/` prefix**.
+> The package was renamed from `eslint-plugin-vitest` to the scoped **`@vitest/eslint-plugin`**.
 
-## Packages
-
-| Package | Latest | Purpose |
-| ------- | ------ | ------- |
-| `@vitest/eslint-plugin` | `1.6.18` | Vitest rules (scoped pkg) |
+## Install
 
 ```bash
-pnpm add -D @vitest/eslint-plugin
+npm install @vitest/eslint-plugin --save-dev
 ```
 
-## Flat config
+## eslint.config.mjs (official example)
 
 ```js
-// eslint.config.mjs
+import { defineConfig } from "eslint/config";
 import vitest from "@vitest/eslint-plugin";
 
-export default [
-  {
-    files: ["**/*.{test,spec}.{ts,tsx,js,jsx}"],
-    plugins: { vitest },
-    rules: {
-      ...vitest.configs.recommended.rules,
-      // tests are I/O-heavy + mock-heavy — relax type-safety on test files:
-      "@typescript-eslint/no-explicit-any": "off",
-      "@typescript-eslint/no-unsafe-assignment": "off",
-      "@typescript-eslint/no-unsafe-member-access": "off",
-      "@typescript-eslint/no-unsafe-call": "off",
-      "@typescript-eslint/no-unsafe-argument": "off",
-      "@typescript-eslint/no-unsafe-return": "off",
-    },
-    settings: { vitest: { typecheck: true } }, // only if using Vitest type-testing
+export default defineConfig({
+  files: ["tests/**"], // or any other pattern
+  plugins: {
+    vitest,
+  },
+  rules: {
+    ...vitest.configs.recommended.rules,
+    "vitest/max-nested-describe": ["error", { max: 3 }],
   },
-];
+});
 ```
 
-## Gotchas
-
-- The key is **`vitest.configs.recommended`** (plain) — NOT `configs['flat/recommended']`.
-  Other plugins use the bracketed `flat/` form; Vitest does not.
-- When you spread only `.rules`, register `plugins: { vitest }` yourself. Alternatively spread
-  the whole `...vitest.configs.recommended` (carries the plugin registration).
-- The `no-unsafe-*` / `no-explicit-any` opt-outs are CBP convention — production code keeps
-  them at `error`; test surfaces relax them because mocks produce `any`-typed values.
-
-## CBP preset divergence
+## Notes (from the official docs)
 
-The CBP `testing` preset matches this (the six `no-unsafe-*`/`no-explicit-any` opt-outs,
-`@vitest/eslint-plugin: ^1.0.0`). No divergence.
+- The config key is **`vitest.configs.recommended`** — there is **no `flat/` prefix** (unlike most
+  other test plugins). Variants: `configs.recommended` and `configs.all`.
+- Register `plugins: { vitest }` yourself when spreading only `.rules`.
+- Scope to your test files via `files`. Vitest type-testing uses a separate `typecheck: true` setting.
+- The README still shows legacy `.eslintrc` JSON for ESLint ≤ v8.57.0 alongside flat config.
 
-## Official docs
+## Source
 
-- @vitest/eslint-plugin: https://github.com/vitest-dev/eslint-plugin-vitest
+- https://github.com/vitest-dev/eslint-plugin-vitest

package/templates/skills/cbp-ship/reference/versioning.md

@@ -2,11 +2,12 @@
 
 How `/cbp-ship` decides which version a surface ships at.
 
-## Three modes (per surface, configured per-package)
+## Four modes (per surface, configured per-package)
 
 | Mode | Trigger | Best for |
 |---|---|---|
 | `manual` | User bumps `package.json` / `tauri.conf.json` / `app.json` version themselves before checkpoint shipment | Apps with infrequent releases; small teams |
+| `in-branch-bump` | `codebyplan ship` detects changed workspace packages via `git diff <base>...HEAD`, patch-bumps each one, and commits a `chore(release): bump versions` commit on the feat branch BEFORE push + PR creation — so the bump rides the same feat→main PR | npm/CLI packages in a pnpm monorepo using the codebyplan CLI; never-missed patch bumps |
 | `release-please` | GH Actions opens version-bump PRs based on conventional commit messages on the watched branch; merge the PR before shipment | npm packages with frequent releases; multi-contributor repos |
 | `changesets` | Devs add `.changeset/*.md` entries in feature branches; an aggregator PR collects them | Monorepos with many independent packages |
 
@@ -16,7 +17,7 @@ Mode is set per-surface in `.codebyplan/shipment.json`:
 {
   "surfaces": {
     "npm-package": {
-      "packages/codebyplan-package": { "versioning": "release-please" }
+      "packages/codebyplan-package": { "versioning": "in-branch-bump" }
     },
     "tauri-desktop": { "versioning": "manual" },
     "expo-mobile": { "versioning": "auto-build-number" }
@@ -59,6 +60,32 @@ Conventional Commits are the trigger:
 
 The release-please workflow lives at `.github/workflows/release-please.yml` (scaffolded by `/cbp-ship-configure`).
 
+> **Retired in this repo.** CodeByPlan itself no longer uses release-please — its `release-please.yml`, `release-please-config.json`, and `.release-please-manifest.json` were removed in favour of the **publish-on-main model** (see in-branch-bump conventions below). `package.json` `version` is the sole version-of-record. The release-please workflow + config templates remain available under `templates/skills/cbp-ship/templates/` for consuming repos that prefer the conventional-commit Release-PR flow.
+
+## in-branch-bump conventions
+
+`codebyplan ship` (the CLI behind `/cbp-ship-main` and `/cbp-checkpoint-end`) runs the bump engine as part of shipping — no separate release PR, no conventional-commit parsing:
+
+1. **When** — after the main-sync merge (`/cbp-merge-main`) and the clean-tree check, BEFORE `git push` + PR creation. The bump therefore rides the same feat→main PR.
+2. **What changed** — `git diff <base>...HEAD` (base from `.codebyplan/git.json`, preferring `origin/<base>`) maps changed files to their owning workspace packages via the `pnpm-workspace.yaml` globs.
+3. **Bump** — every changed package/app is patch-bumped (`x.y.z → x.y.(z+1)`) in its version file (`package.json`, `src-tauri/tauri.conf.json`, Expo `app.json`), and a CHANGELOG entry is prepended where a `CHANGELOG.md` already exists.
+4. **Commit** — the bumped files are committed as `chore(release): bump versions` on the feat branch.
+5. **Idempotent** — a package whose working-tree version already exceeds its base version is skipped, so re-running ship never double-bumps.
+
+`codebyplan ship` is a non-interactive pipeline (bump → push → PR → checks → merge), so there is no confirm-before-merge prompt. To preview the planned bumps WITHOUT committing, run `codebyplan ship --dry-run` (or `codebyplan bump --dry-run`); opt a single real ship out of bumping with `codebyplan ship --no-bump`. The bumps committed on the feat branch are reported in the ship summary (and in `--json` as `bumps[]`). On merge to the production branch, version-change detection publishes each surface whose committed version now exceeds its published version (retiring the release-please Release-PR trigger).
+
+### publish-on-main model
+
+The bump is only half the loop — publishing is the other half. On every push to the production branch, `.github/workflows/publish.yml` closes it:
+
+1. **check-version** — reads the committed `package.json` `version` and compares it to the live `npm view <pkg> version`. Publish proceeds only when the committed version is strictly greater (semver-aware, via `sort -V`); an unchanged or lower version is a no-op. A never-published package is treated as publishable (first release).
+2. **publish** — builds and runs `npm publish --access public` via OIDC Trusted Publishing (no `NPM_TOKEN`; requires npm ≥ 11.5.1). `workflow_dispatch` keeps a manual recovery path (always publishes the current version) plus a `dry_run` input that prints the decision without publishing.
+3. **tag + release** — only after a successful publish, creates the `v{version}` git tag + a GitHub release (idempotent — skipped if the tag already exists, so no orphan tags on a failed publish).
+
+There is **no separate Release PR** — the version committed in the feat branch is the version that ships, so `package.json` is the sole version-of-record. The desktop surface keeps its own `release-desktop.yml` (tauri version vs `desktop-v{version}` tag), which the in-branch `tauri.conf.json` bump feeds automatically.
+
+Other repos inherit this workflow via `codebyplan scaffold-publish-workflow`, which writes `templates/github-workflows/publish.yml` into their `.github/workflows/`. (`.github/` is outside the `codebyplan claude install` target — which only writes under `.claude/` — so the publish workflow has its own scaffold command.)
+
 ## changesets conventions
 
 A changeset is a markdown file describing the change:
@@ -98,7 +125,7 @@ When multiple surfaces ship together, bumps may need to coordinate:
 
 ## What NOT to do
 
-- Don't manually edit `package.json` version inside `/cbp-ship` — versioning happens before shipment, not during
+- Don't hand-edit `package.json` version mid-shipment in `manual` / `release-please` / `changesets` modes — versioning happens before shipment, not during. (`in-branch-bump` inverts this: `codebyplan ship` bumps + commits automatically, after the main-sync merge and before PR creation, so the bump rides the single feat→main PR.)
 - Don't auto-bump in `manual` mode without confirmation — the user owns the bump
 - Don't squash changeset commits — release-please / changesets need each conventional commit visible
 - Don't tag a Tauri release before the version commit is on PRODUCTION branch — the tag locks the shipped version
@@ -107,6 +134,7 @@ When multiple surfaces ship together, bumps may need to coordinate:
 
 | Question | If yes |
 |---|---|
+| Is this an npm/CLI package in a pnpm monorepo shipped via the codebyplan CLI? | in-branch-bump |
 | Is this an npm package with multiple authors? | release-please |
 | Is this a monorepo with 3+ published packages? | changesets |
 | Is this a single app with infrequent releases? | manual |

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]].

package/templates/hooks/cbp-notify.sh

@@ -1,68 +0,0 @@
-#!/bin/bash
-# @hook: Notification
-# Hook: Notification for all matchers
-# Purpose: Send desktop notifications with project context. Cross-platform graceful-degrade —
-#          silent no-op when terminal-notifier is missing (Linux/Windows/macOS without Homebrew);
-#          VS Code click-to-focus action only on macOS hosts with `code` on PATH.
-# Exit 0 = always (notification hooks must never block Claude)
-#
-# Known: notification_type is not sent in JSON input (anthropics/claude-code#11964)
-# Input fields: session_id, cwd, hook_event_name, message
-
-set +e
-
-# Graceful skip on hosts without terminal-notifier (Linux, Windows, macOS w/o Homebrew)
-command -v terminal-notifier >/dev/null 2>&1 || exit 0
-
-# Read JSON input from stdin
-INPUT=$(cat)
-
-# Parse notification fields
-eval "$(echo "$INPUT" | jq -r '
-  @sh "MESSAGE=\(.message // "")",
-  @sh "CWD=\(.cwd // "")"
-' 2>/dev/null)"
-
-# Detect project name
-if [ -n "$CLAUDE_PROJECT_DIR" ]; then
-  PROJECT_DIR="$CLAUDE_PROJECT_DIR"
-elif [ -n "$CWD" ]; then
-  PROJECT_DIR="$CWD"
-else
-  PROJECT_DIR="unknown"
-fi
-PROJECT_NAME=$(basename "$PROJECT_DIR")
-
-TITLE="[$PROJECT_NAME] Claude Code"
-BODY="${MESSAGE:-Claude Code notification}"
-
-# VS Code focus click action — only on macOS with `code` available
-CLICK_ACTION=""
-if [[ "$OSTYPE" == darwin* ]] && command -v code >/dev/null 2>&1; then
-  # Quote path for re-parse by terminal-notifier -execute (POSIX sh)
-  SAFE_DIR=$(printf '%q' "$PROJECT_DIR")
-  CLICK_ACTION="code -r $SAFE_DIR && sleep 0.3 && osascript -e 'tell application \"System Events\" to keystroke \"\`\" using control down'"
-fi
-
-# Send notification via terminal-notifier in background (non-blocking).
-# Omit -execute argument entirely when CLICK_ACTION is empty (avoid passing empty string).
-if [ -n "$CLICK_ACTION" ]; then
-  terminal-notifier \
-    -title "$TITLE" \
-    -message "$BODY" \
-    -sound "Glass" \
-    -group "claude-${PROJECT_NAME}" \
-    -execute "$CLICK_ACTION" \
-    -sender "com.microsoft.VSCode" \
-    > /dev/null 2>&1 &
-else
-  terminal-notifier \
-    -title "$TITLE" \
-    -message "$BODY" \
-    -sound "Glass" \
-    -group "claude-${PROJECT_NAME}" \
-    -sender "com.microsoft.VSCode" \
-    > /dev/null 2>&1 &
-fi
-
-exit 0