菜单
Restart cctop for local development and testing. Use when the user asks to restart, relaunch, run, or prepare the cctop app locally; ensures the current cctop-hook is installed before the menubar app is relaunched and verified.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when designing, scripting, or storyboarding a short demo, launch, explainer, or marketing video (especially for a developer tool, app, or SaaS), OR when auditing, critiquing, or improving an existing video's narrative, hook, pacing, or storyboard. Runs a verified 6-stage process — positioning, message spine, beat sheet, script, storyboard, review — embedding StoryBrand, Before-After-Bridge / PAS / AIDA, the Pixar Story Spine, and the But/Therefore rule. Invoke whenever the work is about the STORY of a video rather than its rendering, including phrasings like "storyboard this", "what's the hook", "make the video more compelling", "the video falls flat", "script a launch video", or "audit this video". After an approved render, hand off publishing to video-assets so MP4 and AVIF release assets stay in sync. Do not use this skill for the encoding/rendering pipeline itself.
Use when publishing, replacing, auditing, or linking cctop promo/demo video assets through GitHub Releases, especially the non-latest media-assets release. Trigger for requests like "upload the launch video", "add another video asset", "replace the README demo video", "where should this video live", "update media-assets", or "generate the README AVIF preview". Covers stable asset names, release selection, AVIF preview generation, README/site links, and avoiding v* product-release tags. Do not use for video narrative/storyboard work; use video-storyboard for that.
Use when cutting a cctop release - "cut a release", "release vX.Y.Z", "bump the version and tag", "ship a new version". Drives version bump, CI, tag push, release pipeline monitoring, and verification, with hard approval gates before anything becomes public.
Use when debugging SwiftUI issues in this macOS app — views not updating, layout problems, unnecessary re-renders, state ownership bugs, Preview crashes, or NSHostingView/NSPanel quirks. Covers both general SwiftUI debugging and macOS-specific patterns.
Use when cctop-hook command fails or is not found. Guides user to install the cctop menubar app.
Use when smoke-testing cctop end to end — verifying a real coding-agent session is tracked and shows in the panel. Trigger on "smoke test sessions", "verify session tracking", "test the hook pipeline", "check cctop picks up a claude/codex/opencode/pi session", or "run the e2e test", even without the word "skill". Creates a real CLI agent session in a terminal, confirms cctop tracks it, opens the panel programmatically, and captures screenshot proof.
| name | cctop-restart |
| description | Restart cctop for local development and testing. Use when the user asks to restart, relaunch, run, or prepare the cctop app locally; ensures the current cctop-hook is installed before the menubar app is relaunched and verified. |
When the user asks to restart or relaunch cctop during development, treat it as an end-to-end client refresh:
./script/build_and_run.sh --verify from the repo root when available.make restart.~/.cctop/bin/cctop-hook reports or contains the current Config.hookVersion.CctopMenubar process path points at the current worktree/debug app.Do not use make run or open ...CctopMenubar.app alone for restart requests; those can leave shims using a stale installed hook.
After cctop investigation, validation, delegated PR work, or any workflow that launches or kills the dev app, leave the verified debug app running for the developer unless the user explicitly asks to stop it or a concrete blocker prevents a safe relaunch. Report the running app path and installed hook version. Do not stop the app at the end merely to keep the process table tidy; the developer uses the app while reviewing the work.
For delegated task closeout after merge, make restart/app state part of the handoff: confirm the developer-facing app is running when relevant, then archive or park the driver thread. Only remove the driver worktree after confirming no app, build, test, or agent process is still running from it.