Build the Tool You Are Missing: A Searchable Clip Bank for AI Manga and Anime

Every AI video workflow eventually produces the same problem. You generate clips faster than you can review them, the folder count climbs past forty, and one day you need "the shot where Hikari and Akari are laughing side by side" and you simply cannot find it. The footage exists. Finding it costs an afternoon of scrubbing.

The Japanese creator behind CreativeEdge CL+, who runs the AI drama COLORS and produces an anime and a manga from the same material simultaneously, hit this wall and responded in a way worth copying: instead of buying an asset manager or switching tools, they spent a few engineering hours building a small search system on top of the existing folder, with Codex doing the implementation. Their production notes from August document the whole build, and the interesting part is not the code. It is the discipline around it.

The 70/10/20 constraint

First, the context that shapes every decision. This is a one-person studio running a drama, an anime series, and a manga at the same time. The stated split of daily work: 70 percent creative, 10 percent engineering, 20 percent everything else.

That 10 percent matters. There is no room for a proper platform, a database, or a week of tooling work. The system has to start as a minimum viable version and grow slowly, in small verified steps, without ever endangering the footage it is meant to protect. That constraint produced most of the good decisions below.

The clips in question are generated video intended for manga panels, the same video-to-still technique this creator uses for editorial stills. Each clip is a candidate source of frames, organized into folders named after characters and their emotional ranges, for example "Hikari's joy-anger-sorrow-laughter, set A". The bank keeps growing, which is exactly why browsing it stopped scaling.

Rule one: the agent may not touch the source

Before any system existed, the first prompt to Codex was essentially a contract. Not a feature request, a list of prohibitions. One honest limitation up front: in this build the boundary is prompt-based only, the source folder carries no read-only mount, ACL, or sandbox policy. Prompt rules are soft enforcement, and anyone running the same pattern against footage that cannot be regenerated should add a hard boundary (a read-only mount or ACL on the source folder, or a Codex sandbox policy that denies writes there) before trusting an agent near it. With that understood, the contract:

• The source folder is original data. Do not modify, delete, move, or rename anything inside it.
• Do not create files or folders inside it.
• Do not copy the videos out as part of this indexing run. Keep separate, verified backups outside the source folder; the no-copy rule exists to keep the experiment contained, not to leave footage without a backup.
• Treat the source as read-only, always.
• Any test files go in the separate project folder only.
• Do not install anything (apps, Homebrew packages, Python libraries, ffmpeg) without reporting first.
• Do not request full-disk access.
• Do not analyze the whole library on the first run.

If you have ever let a coding agent loose on a directory of irreplaceable footage, you know why this list exists. Agents are eager. An agent told loosely to "index my videos" may well decide the best route involves re-encoding files in place or installing three dependencies it found online. The prohibitions turn the agent from a bull into a precision tool.

There is a second, quieter benefit. Constraints like these shrink the problem until the first step is nearly risk-free, which makes it easy to verify and easy to trust. That sets up the staging strategy.

Verify feasibility before building anything

The first task was not "build the search system". It was eight explicit checks, ending with: read one MP4 from the source folder, extract one low-resolution still from the middle of it, save that single test image into the project folder, and report back in Japanese what was confirmed, which method was used, and whether it succeeded.

No index, no thumbnails, no HTML, no database. One video, one frame.

This is the pattern engineering teams call a spike, run by a solo creator with an agent. The question is not "can we build it" but "can this machine, with only what is already installed, pull a frame out of an MP4 without touching the original". The answer turned out to be yes: the existing ffmpeg and ffprobe installs were enough, no new dependencies required.

If that check had failed, the entire plan would have changed before any code existed. That is the point of doing it first.

Contact sheets instead of thumbnail forests

With feasibility proven, the next stage was a pilot index over exactly one character folder, fifteen clips. For each video: read the duration with ffprobe, pull nine evenly spaced frames, and compose them into a single 3x3 contact sheet with timecodes printed on or under each frame. Alongside the sheets, one plain text file, index.tsv, recording the source folder, filename, full path, duration, and contact sheet path for every clip.

The design choice that deserves attention is the 3x3 sheet. The naive approach, one JPEG per extracted frame, produces a file explosion: fifteen clips times nine frames is 135 image files for a single folder. The sheet approach produces fifteen. Across the full library, which keeps growing, that difference compounds. The pilot index for the whole folder came out around 1.5 megabytes total, and the source folder remained untouched, verified at the end of the run.

Timecodes on each cell are what turn the sheet from a browsing aid into a search target. Once you know the right cell, you know the timestamp to extract from the original video.

There is a second role for the sheets that is easy to miss. Contact sheets mean an agent (or a vision model, or a tired human at midnight) can triage fifteen clips by looking at fifteen images instead of playing fifteen videos. The sheets do not eliminate decoding altogether: extracting the final stills later re-reads the selected source clips. What they eliminate is repeated full-video review during search. The heavy browsing pass happens once at index time; everything after that works on kilobytes until you decode exactly the clip you chose.

Searching in plain language

The final stage in the documented build is the payoff: natural language queries against the bank. Type something like "Hikari facing forward and laughing", and the system looks through the contact sheets, identifies which videos and timecodes plausibly match, then asks for "the top three written out", at which point the matching frames get extracted from the originals into a dedicated folder as manga-ready stills.

Two things make this work without any vision model in the loop at the indexing stage. First, the folder naming convention carries metadata: character names and emotional ranges live in the folder name, so a text search already narrows the space massively before anyone looks at pixels. Second, the contact sheet gives whatever does the looking a compact, complete view of each clip.

The naming convention is the part anyone can adopt today, with zero tooling. If your asset folders are named final_v2_new and stuff, no search system can help you. If they are named after character, emotion, and shot type, then even a plain desktop search becomes half a retrieval system.

The transferable version

You may not use Codex, and you may not make manga. The underlying recipe is tool-agnostic:

1. Name your asset folders after what is in them: character, emotion, scene, camera. The folder tree is your first database.
2. Keep generated material read-only once it is organized. Indexes and derived files live somewhere else.
3. Build a cheap visual index: contact sheets with timecodes, generated from your existing ffmpeg install, in a separate folder. A sheet per clip, not a file per frame.
4. Keep a plain text or TSV index mapping each sheet back to its source path and duration. Text files open in anything and diff cleanly.
5. Only then consider automating search, with an agent or a script, working exclusively against the index, never the source.

The shape of the ffmpeg invocation, for reference, is a select filter sampling the timeline at even intervals, frames scaled down, piped into a tile filter, one output image per clip. The exact sampling interval depends on clip length; the pilot pulled nine frames per video regardless of duration.

The deeper lesson from the original notes is an attitude, not a technique. The author frames AI as human capability extension rather than automation, and treats tooling as something you grow yourself, slowly, in the ten percent of the week you can spare. Most creators stop at whatever the tools give them and work around the gaps forever. This build is the counterexample: the gap was "I cannot find my own footage", and the fix was two hours and a strict contract, not a new subscription.

What this looks like inside Phosphene

The same logic applies to generation sessions. Every Phosphene dream stores its graph state, tags, and generated images together, which means your session history is already a partial index of your own work: name dreams after the character or scene they contain, and recall becomes a matter of opening the right dream instead of scrolling a gallery. Structure at capture time is what makes retrieval cheap later, whether the library is a folder of MP4s or a list of saved sessions.

For the wider strategy of producing drama, anime, and manga from one material base, see the video-first multi-format pipeline, and the modular production approach this same creator evolved from.