cce-rename

name	cce-rename
description	Rename a Chrome Extension Factory project — change the display name, slug, description, and (optionally) the parent folder in one pass. Updates wxt.config.ts, package.json, marketing/og.config.mjs, and per-entrypoint configs (welcome/screenshots/video), then lists prose files (README, CHANGELOG, etc.) that still mention the old name for manual follow-up. Idempotent; supports dry-run. Use when the user says things like "rename this extension", "change the extension name", "rebrand", "I renamed the project", or "/cce-rename".
triggers	["rename this extension","rename the extension","change the extension name","change the name","rebrand","I renamed the project","update the extension name everywhere","I want to call it something else","/cce-rename"]
invokes	["npx tsx scripts/rename.ts","npm run check:cws"]
writes	["wxt.config.ts","package.json","marketing/og.config.mjs","entrypoints/welcome/config.ts","screenshots/config.ts","video/config.ts"]

cce-rename skill

You are driving the cce-rename skill. Your single responsibility is to take the user from "I've decided on a new name for this extension" to "every config file reflects it, and I have a checklist of the prose files I still need to hand-edit."

You do NOT rewrite prose. You do NOT submit. You do NOT regenerate screenshots or video. You DO:

• Gather the new display name, slug, and (optionally) description from the user.
• Run scripts/rename.ts with --dry-run --json FIRST to show the user the plan.
• On user approval, re-run without --dry-run.
• Surface the prose-hit report so the user can update human-facing copy.
• Re-run npm run check:cws to confirm nothing broke.

Phase 0 — Locate the factory

A factory repo has BOTH:

• wxt.config.ts at the repo root
• scripts/rename.ts (i.e., a factory new enough to have this skill)

If either is missing, tell the user and stop. Don't clone or scaffold.

Phase 1 — Gather the new identity

Ask, in one message:

1. New display name — what shows in the Chrome Web Store, the Chrome toolbar, and the install prompt. Title Case. 4–45 chars.
2. New slug (optional) — kebab-case, used for package.json > name and the folder name. If the user omits it, the script auto-derives from the display name ("Webpage Summarizer" → webpage-summarizer).
3. New description (optional) — if the user wants to update manifest.description in the same pass. Otherwise leave alone.
4. Rename the parent folder on disk? — off by default. Ask explicitly. If yes, the script does mv $ROOT $PARENT/$NEW_SLUG at the end.

Phase 2 — Dry-run the plan

Run:

npx tsx scripts/rename.ts "<New Display Name>" \
  --slug <new-slug> \
  --description "<new description>" \
  --dry-run --json

Omit the flags the user didn't supply. Parse the envelope:

{
  "schemaVersion": 1,
  "kind": "rename",
  "dryRun": true,
  "oldName": "...",
  "newName": "...",
  "oldSlug": "...",
  "newSlug": "...",
  "edits": [{ "file": "...", "before": "...", "after": "..." }],
  "proseHits": [{ "file": "...", "line": 42, "text": "...", "match": "..." }],
  "warnings": []
}

Show the user:

• The file edits that will land.
• Count of prose hits, grouped by file.
• Any warnings (e.g., "nothing to change").

Ask: "Apply?"

Phase 3 — Apply

On yes, re-run without --dry-run and without --json (so the user gets human output):

npx tsx scripts/rename.ts "<New Display Name>" \
  --slug <new-slug> \
  --description "<new description>"

Add --rename-dir if the user opted into folder rename.

If the git working tree is dirty, the script bails with exit 1. Tell the user to commit or stash, or pass --force (only if they understand the risk).

Phase 4 — Prose follow-up

The script prints a per-file list of lines that still reference the old display name or slug. Walk the user through them file by file if they want; most are one-line README titles, CHANGELOG entries, or doc references. A few judgment calls to surface:

• CHANGELOG.md — historical entries should usually keep the old name (that's what was released). New entries use the new name.
• docs/ — references inside skills/scripts usually need updating.
• README.md — H1 title, intro paragraph, install instructions.

Phase 5 — Re-validate

Run:

npm run check:cws

Structural green means no regressions. If the user plans to ship immediately, also run npm run check:cws:ship — a rename usually doesn't break ship-readiness, but listing-ready-name now checks against the new name, so re-confirm.

Phase 6 — Remind about external surfaces

The script only touches files in the repo. Rename does NOT update:

• The Chrome Web Store listing (edit in CWS admin, or re-run /cws-content).
• Git remote / GitHub repo name (gh repo rename <new-slug> if they want).
• The OG card (marketing/og.config.mjs got updated, but re-render with the og-card skill to regenerate assets/og.png).
• Published npm package name, if any.
• Privacy-policy page URLs, if hard-coded anywhere outside wxt.config.ts.

List whichever apply to the user's extension, then stop.

Edge cases

• User invokes /cce-rename with no new name given. Ask for it; don't guess.
• Slug collides with sibling folder. Script prints a warning and skips the dir rename. File edits still apply.
• entrypoints/welcome/config.ts doesn't exist yet. Script skips it silently; user's profile doesn't use a welcome page.
• Repo isn't a git repo. Script skips the dirty-tree check. Proceed.
• User wants to undo. git checkout -- . reverts file edits. The dir rename is reversible with mv by hand (print the inverse command).

Done criteria

check:cws is green, git diff shows only the expected renames, and the user has acknowledged the prose follow-up list.