Docs/Skills and code/skill video-script-production

.claude/skills/video-script-production/references/handoff-template.md

Markdown51 lines2.5 KBSkill: video-script-production

Mentioned on: page 06, page 12

The hand-off message (Step S11)

The final message is the user's one view of the work. Keep it plain and concrete: the user has said they want honest statements of what is unproven, and they react to specifics (a quote, a number, a rule id). Avoid AI-speak ("Here's what matters", "no X, just Y"). Do not pad. Lead with the state, not the effort. Use the structure below; drop a section only if it is empty.

<One or two sentences: the script/version is written and passes N rules (score), the damage test passes M checks, and what is NOT done. Say once that the linter only checks the declared structure.>

## The script
<File, length, beats, thesis in one line, and what it now covers. If the user asked for something specific, say how it is met, with the line from the script.>

## What you asked for
<One short block per request: what was done, and the evidence (rule id, a quoted line, a measured number).>

## Pipeline changes
<Only what changed in the skills: new rules, new tools, new references. Name the files.>

## Things you should know
- Corrections to earlier versions (a fact, a number, a claim) and where the error came from.
- Assumptions made (for example "first 60 mins" read as seconds).
- Sources that could not be verified ([V-search], [CHECK]).
- Tensions between a lesson and our own data (the winners do not do this).
- Length, and the cleanest cuts.

## Decisions for you
- Title (when the evidence is weaker than the packaging), with alternates.
- Naming a private person.
- Reader pass (needs subagents), if not done.
- Commit / push (nothing is committed unless asked).

<Paths of the files.>

The hand-off file, HANDOFF-vN.md

check.js reads three lines from it, so keep them at the start of a line:

Read-aloud pass: done (<date>; what was found)
Reader pass: done | skipped: <reason> | pending
Unproven: <one sentence on the same line: what the linter does not prove, what was not tested, which thresholds are design budgets>

Below them: Decisions for the user, Open items before filming (every [CHECK] and [V-search] row, plus the persona's "I" claims), and What changed from the previous version.

Before sending

1. check.js printed BAR MET, or you have said exactly which gate is open and why.
2. Every number in the message is one you just read from a tool output, not from memory.
3. session-log.js has written the research record; learnings.md and tools.md are updated; the memory notes are current.
4. Nothing committed or pushed unless the user asked.

# The hand-off message (Step S11)

The final message is the user's one view of the work. Keep it plain and concrete: the user has said they want honest statements of what is unproven, and they react to specifics (a quote, a number, a rule id). Avoid AI-speak ("Here's what matters", "no X, just Y"). Do not pad. Lead with the state, not the effort. Use the structure below; drop a section only if it is empty.

```
<One or two sentences: the script/version is written and passes N rules (score), the damage test passes M checks, and what is NOT done. Say once that the linter only checks the declared structure.>

## The script
<File, length, beats, thesis in one line, and what it now covers. If the user asked for something specific, say how it is met, with the line from the script.>

## What you asked for
<One short block per request: what was done, and the evidence (rule id, a quoted line, a measured number).>

## Pipeline changes
<Only what changed in the skills: new rules, new tools, new references. Name the files.>

## Things you should know
- Corrections to earlier versions (a fact, a number, a claim) and where the error came from.
- Assumptions made (for example "first 60 mins" read as seconds).
- Sources that could not be verified ([V-search], [CHECK]).
- Tensions between a lesson and our own data (the winners do not do this).
- Length, and the cleanest cuts.

## Decisions for you
- Title (when the evidence is weaker than the packaging), with alternates.
- Naming a private person.
- Reader pass (needs subagents), if not done.
- Commit / push (nothing is committed unless asked).

<Paths of the files.>
```

## The hand-off file, `HANDOFF-vN.md`

`check.js` reads three lines from it, so keep them at the start of a line:

```
Read-aloud pass: done (<date>; what was found)
Reader pass: done | skipped: <reason> | pending
Unproven: <one sentence on the same line: what the linter does not prove, what was not tested, which thresholds are design budgets>
```

Below them: Decisions for the user, Open items before filming (every [CHECK] and [V-search] row, plus the persona's "I" claims), and What changed from the previous version.

## Before sending

1. `check.js` printed `BAR MET`, or you have said exactly which gate is open and why.
2. Every number in the message is one you just read from a tool output, not from memory.
3. `session-log.js` has written the research record; `learnings.md` and `tools.md` are updated; the memory notes are current.
4. Nothing committed or pushed unless the user asked.

Shown as it is in the repository at build time (2026-11-03); the home directory appears as <home>. If this page and the file differ, the file is right. Back to the catalogue.