← All craftbooks

Master the Audiobook

Media: audio and videoevalv1.0.1released 2026-07-22workflow: build-loop

Assemble the finished chapters into a release: completeness swept against the manuscript first, the metadata manifest built and verified chapter by chapter, the master assembled through the project's media pipeline with a run log, and the listener-facing description written — the moment the folder of takes becomes a book. Locks the packaging rules FIRST (order, metadata fields, total duration), then the manifest, then the master, then the release copy. Use for mastering an audiobook, packaging the chapters, audiobook release prep, and 'all the chapters are rendered, now what'.

Steps

Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.

  1. Sweep for completenessproducerentry

    chapters on disk checked against the manuscript, rules locked

    Show working prompt
    Establish that the book is actually finished before packaging it. Step 1: read the manuscript's table of contents under manuscript/ and list every chapter the book should have. Step 2: sweep the rendered audio under audio/ — each chapter's audio file and its run log — and check the two lists against each other; a missing or failed chapter stops the run here, reported plainly, because a master with a hole in it is not a master. Step 3: lock the packaging rules — the manifest at master/manifest.json records every chapter with its audio file, duration, and play order; order follows the manuscript; durations come from the chapters' run logs, never estimated; and the master is assembled through the project's pipeline script via the run_script tool with a status-ok log. Step 4: write an acceptance-criteria checklist ('every manuscript chapter has rendered audio', 'manifest complete with file, duration, and order per chapter', 'no duplicate chapters', 'master assembled with a status-ok log', 'total duration equals the sum of the chapters', 'listener description written'). Call write_task_note with the chapter counts + checklist and write notes/scope.md.
  2. Build the manifestdata-analyst

    master/manifest.json: chapter, file, duration, order

    Show working prompt
    Build the metadata manifest the master run and every player will trust. Step 1: write master/manifest.json as a JSON array, one record per chapter — the chapter title as the manuscript names it, the audio file path exactly as it exists under audio/, the duration taken from that chapter's run log, and the play order as a number following the manuscript. Step 2: verify as you go — every file path must point at a file that exists, no chapter appears twice, and the orders run without gaps. Step 3: total the durations and note the book's full running time for the release copy. Call write_task_note with the record count and the total duration.
  3. Assemble the masterdeveloper

    the chapters concatenated into the master with its log

    Show working prompt
    Assemble the release master. Step 1: the mastering pipeline is a project script — call list_scripts to find it, then run it with run_script({ name: "<script name>" }); never run it with run_nodejs_script and never reimplement it. It reads master/manifest.json, verifies every referenced audio file exists, joins the chapters in manifest order into master/book.m4b, and writes its run log to master/assembly-log.json with a status field, the chapter count, and the total duration it computed. Step 2: if run_script reports an error, read the error text, fix what it names — usually a manifest path or order — and run it again; never write master/assembly-log.json yourself — the log is evidence the pipeline ran. Step 3: once it succeeds, read the log and confirm status ok, the chapter count matching the manifest, and the total duration matching the manifest's sum. Call write_task_note with the run outcome and the master's total duration.
  4. Write the release copycopywriter

    listener description and release notes for the finished book

    Show working prompt
    Write the words that travel with the book. Step 1: write the listener-facing description — what the book is about and who it is for, in the voice a listener browsing a store would actually read, without spoiling it. Step 2: add the release facts — the total running time from the master log, the chapter count, and the chapter list with per-chapter durations from the manifest. Step 3: add the release notes for the owner — what was assembled, anything flagged during the sweep, and the one-line confirmation that the master's numbers match the manifest. Write master/release-notes.md and call write_task_note with the path and the total running time.
  5. Evaluatereviewer

    Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.

    Show working prompt
    Open master/release-notes.md, master/manifest.json, and master/assembly-log.json and verify every criterion from notes/scope.md: every manuscript chapter appears in the manifest exactly once with file, duration, and order, the referenced audio files exist, the log reports status ok with a chapter count and total duration matching the manifest, the release copy states the total running time, and the listener description reads like store copy rather than an internal note. Write PASS/FAIL per criterion; on any failure, name the gap and loop back to package — or to manifest if the metadata is the problem.
    
    Then route — this is the whole point of the loop:
    
    - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`.
    - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "package" })` to loop back. The builder fixes exactly those gaps.
    
    Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.
  6. Finishdeveloper

    All acceptance criteria met. Stamp a short summary and report DONE.

    Show working prompt
    Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.

Triggers

Phrases that suggest this craftbook to a crew.

Source

View this craftbook on GitHub · MIT license