cawcut-ad-video
CawCut Ad Video
Create a complete product ad video through the 5-stage AD Video wizard: Product → Config → Idea → Storyboard → Video. Each stage maps to cawcut ad-video commands against the developer API. Full command flag tables live in references/api.md; stage semantics and the invalidation matrix live in references/stages.md; authoring a script edit lives in references/script-editing.md; error recovery lives in references/troubleshooting.md. Read them at <base_dir>/references/<file>.md using the base directory printed at the top of this skill body — do not find/grep for them.
Reply language. All live replies — prose, status updates, AskUserQuestion / AskQuestion questions and option labels — follow the user's language for that turn. This is judged from the user's actual chat message content for that turn — not from whether the Skill tool call itself carried an args parameter, which is an unrelated, optional pass-through field. This includes implicit triggers: if the skill was invoked because the user's message matched a trigger phrase (e.g. "广告视频", "商品广告", "make an ad for …") rather than the literal /cawcut-ad-video command, that trigger phrase is the user's chat message content for the turn — reply in its language from the very first response, including when asking for the missing product URL. Only default to English when the invocation carries no language signal at all (e.g. literally just /cawcut-ad-video alone with no other text); once the user adds a real request in another language, follow that language for the rest of the session. Keep CLI commands/flags, JSON keys, URLs, and raw error codes in their original form regardless of reply language, and never paste raw English CLI output as the user-facing answer — summarize it in reply_language.
Step 0 — Bootstrap
Choose the login mode by execution environment
Choose by where commands actually run. On the user's own computer, run cawcut auth login --browser --json; the CLI opens the browser and waits for approval. In a remote environment, VM, or container without access to the user's browser, run cawcut auth login --device-auth --json and send the user authorization_url to open and approve on their own computer. Both modes support JSON; needing structured output is not a reason to choose device authorization. Agent names, non-TTY shells, and localhost URLs alone do not establish where commands run. Use the known execution context and explicit mode flags to override CLI auto-detection.
For device login, then run cawcut auth login --complete --wait --timeout 60 --json. If your tool has a short execution timeout, use single --complete --json calls instead, following next_poll_after_seconds. After device login is interrupted or returns wait_timeout, resume the saved current request rather than creating a new link. Browser login uses the legacy loopback callback; if interrupted, restart cawcut auth login --browser --json instead of using --complete. status=pending is not authentication success. Only retry the original operation after status=authenticated. Denial/expiry ends this request; do not silently create an endless sequence of authorization links. Never ask for a password, token, or a code copied back from the web page.
Run bootstrap as a silent guardrail, not as a user-facing phase.