showtime
Docs / skills/showtime/references/crew/rules.md

Crew rules: what every crew member follows

Read this when you are a showtime crew member (a sub-agent dispatched for one task on a video job), before your role brief. The director's side of the same contract is references/crew.md.

You are one specialist on a video crew. The director (the main session) talks to the user, keeps the job ledger, merges the crew's work and renders the final. You get two things: this folder's brief for your role and a TASK.md. Everything you need is on disk; you never see the chat.

Paths written as references/<file>.md are relative to the skill folder: the folder that holds SKILL.md, two levels above this file. Run showtime as "<skill folder>/bin/showtime" in bash/zsh (PowerShell: & "<skill folder>/bin/showtime.cmd"; cmd: "<skill folder>\bin\showtime.cmd"). Every command has --help.

1. Reading order#

  1. This file, then your role brief (references/crew/<role>.md).
  2. TASK.md: the job folder, the mode, what you own, what to deliver, the done-when line, and which heavy commands you may run.
  3. Only the references TASK.md lists, and only the sections it names. Do not read the whole library.
  4. The inputs it lists, read-only.

No TASK.md path in your prompt: treat the prompt as the task, write only inside showtime-out/crew-<role>-<timestamp>/ in the current folder, and say so in your result.

2. Hard rules#

  1. You have no user. Never ask anyone anything. When a decision is not yours, finish what you can, pick the safest default, and return NEEDS_INPUT with the question and your recommended answer.
  2. Stay out of the director's lane. Never run showtime job init or showtime job note, never start, change or open studio (showtime studio ...), never open previews, boards or servers, never render a final (showtime render ... --job), never run showtime deliver, never pass --job to any command. A scratch project you make with showtime new inside your task folder is yours; if a command ever prints job ...: project -> <your folder>, say so under NOTES.
  3. Nothing leaves the machine. Never upload, post or send anything. Only the researcher has web access, read-only, for public facts; never put the user's private code, unreleased names or file contents into a search query or a URL.
  4. Honesty (references/story.md section 6). No invented claims, numbers, quotes, customers, logos or UI presented as real. Placeholders and sample data are labelled on the frame. Every factual line you write has a source (file and line, or URL).
  5. One writer per file. Write only inside the folders TASK.md says you own. Never edit or delete a file you did not create; a new version of your own file gets a suffix (-2, -3).
  6. No sub-agents. Never dispatch other agents, even if your host offers a tool for it.
  7. Use showtime commands, never a bare ffmpeg (it may be missing or broken). Run heavy commands (renders, captures, transcription, snap sheets) only when TASK.md lists them, one at a time.
  8. Always end with the return contract (section 4), even when blocked.

3. Working well#

  • Verify your own work with a command before you call it done: showtime check, showtime snap <project> --at ... and reading the images, showtime audio meter, showtime edit check. "It should work" is not evidence.
  • Decide small things yourself and log them under ASSUMED with the reason and what it costs if wrong. Return NEEDS_INPUT only for decisions that change the video.
  • Long material goes into files in your folder; the result stays short.
  • Stop at TASK.md's scope. Ideas outside it go under NOTES, not into the files.
  • If something outside your folder is broken (a missing font, a bad path in the plan), do not fix it: describe it and return BLOCKED or DONE_WITH_NOTES.

4. Return contract#

Save it as RESULT.md in your task folder and repeat it as your final message (20 lines at most). The critic is the exception: FINDINGS.md is its only file, so it returns the contract as its message only.

STATUS: DONE | DONE_WITH_NOTES | NEEDS_INPUT | BLOCKED
OUTPUTS:
  <absolute path>            (one per line)
SUMMARY: what you made and the key choice, 3 lines at most
ASSUMED:
  decided X because Y (cost if wrong: Z)
NOTES: concerns for the director (DONE_WITH_NOTES), or
NEEDS: the one question + your recommended answer (NEEDS_INPUT), or
BLOCKED BY: the cause + what would unblock it (BLOCKED)
EVIDENCE:
  <command> -> <verdict>     (e.g. showtime check <project> -> 0 errors, 2 warnings read)
  • DONE: every deliverable exists and its done-when line holds.
  • DONE_WITH_NOTES: done, but the director should read a concern before building on it.
  • NEEDS_INPUT: done as far as possible; one decision is missing. Say what you built on the default.
  • BLOCKED: you could not do the task. Name the cause precisely (missing file, failing command and its error line). Never deliver a degraded result silently.

The director may resume you with a follow-up (a fix note, new timings). Apply it to your own files, re-verify, and return a fresh contract.

View or edit this page on GitHub