# Improve-videoclaw prompt

A reusable, Fable-5-tuned prompt for driving a comprehensive, high-leverage improvement
pass over the whole `videoclaw-v3` codebase. Authored with the `prompting-fable-5` skill
(give-the-reason, scope-guard tuned for improvement-not-churn, parallel-subagent fan-out,
progress-grounding, a plan-gate checkpoint, fresh-context self-verification, no
echo-your-reasoning).

For a **read-only review** (findings report, no changes), use the counterpart
`docs/CODEBASE_REVIEW_PROMPT.md` — its verified findings feed this prompt's plan gate.

## How to run

- Set effort to **xhigh** — this is hardest-range, end-to-end work.
- Default shape is **discover → plan-gate → implement end-to-end**: it pauses once for
  you to approve the ranked plan, then runs. For audit-only, replace the checkpoint
  paragraph with a hard stop after the findings.

## Prompt

```text
You're working on videoclaw-v3 (the `vclaw` CLI; npm package `videoclaw`) — a
TypeScript/Node 20, strict-NodeNext-ESM, multi-provider video pipeline CLI targeting
Veo (Flow/UseAPI/Omni), Seedance, Runway, and Dreamina. It's a solo-creator tool used
to ship real client video work end-to-end: init → brief → storyboard → assets → review →
publish, with an on-disk per-project folder as the source of truth and machine-readable
JSON at every stage. I want you to make this codebase genuinely kick ass: more robust,
more coherent, faster to work in, and harder to break — without changing what it does or
relitigating its architecture decisions.

Read first, then decide. Read CLAUDE.md, MERGE_PLAN.md, docs/ARCHITECTURE.md, the ADRs in
docs/adr/, and the memory index at
~/.claude/projects/-Users-davendrapatel-Documents-GitHub-videoclaw-v3/memory/MEMORY.md.
These encode load-bearing decisions (no silent fallback across provider routes; on-disk
project as source of truth; Seedance identity via Asset Library; director-mode approval
gate; the review-state ladder; position-sensitive import.meta.url path math in handlers).
Treat them as constraints, not suggestions — don't undo them.

Then survey the whole project for the highest-leverage improvements. Use parallel
subagents to explore independent areas concurrently (the CLI dispatch + handlers, the
src/video/* domain modules, the provider transports/adapters, the schemas, the test
suite, the docs, the smokes/guardrails) and keep working while they run; intervene if one
goes off track. Look for: correctness bugs and silent-failure paths, missing or weak test
coverage on critical seams (execution runtime, chain-from-prev, reference-budget
preflight, the review-state ladder), schema/writer drift, inconsistent error handling,
brittle path math, dead or duplicated code, gaps between docs and behavior, and developer-
experience friction. Rank what you find by impact-over-effort and tell me the ranking
before you start changing anything.

This is an improvement task, but improvement is not churn. Make changes that raise
correctness, robustness, test coverage, or clarity. Don't refactor for taste, don't
introduce abstractions for hypothetical future needs, don't add error handling for cases
that can't happen, and don't reformat files you aren't otherwise touching. Match the
surrounding code's conventions exactly (kebab-case filenames, .js import extensions,
2-space indent, machine-readable JSON output, node:test with assert/strict). When you add
or change a CLI command or artifact, follow the full registration checklist in CLAUDE.md
(handler + dispatch + schema + cli-schema COMMANDS + count assertion + test + README +
docs/CLI_REFERENCE.md).

Checkpoint before you commit to a direction: present your ranked findings and a short
plan, and pause for me there — that's a real scope decision only I should make. After I
approve the plan, proceed end-to-end without pausing for reversible steps. Only stop again
for genuinely destructive or irreversible actions or a true change of scope.

Hold a hard quality bar and verify against it. Build with `npm run build`; run `npm test`;
run the relevant smokes and `npm run check:release-readiness-lite` as your pre-flight
before declaring any batch of changes done. Verify your work with fresh-context verifier
subagents against the specification and the existing tests — separate verification from
the change, don't self-approve in the same pass. Every improvement ships with a test that
would have caught the problem.

Before reporting progress, audit each claim against an actual tool result from this
session: if tests fail, show the output; if a check was skipped, say so; state only what
you can point to evidence for. Don't claim a smoke passed unless you ran it.

When you finish, lead with the outcome — what's measurably better and how you proved it —
then the supporting detail. Write the summary for someone who didn't watch you work: plain
sentences, each file or command its own clause, no working shorthand.
```