TL;DR: Code is version-controlled because it’s explicit. Editing know-how isn’t—it’s tacit, locked in one editor’s hands. Our bet with YouViCo is that you can give tacit editing know-how the three properties that make Git safe—you can diff it, test it, and revert it—and once you do, a team’s editing craft becomes a shared, evolving asset instead of something that walks out the door when someone leaves. Here’s the design.
The Problem: Editing Craft Doesn’t Scale
A skilled editor carries hundreds of small decisions in their hands. How tight to cut dialogue. When to let a beat breathe. How they balance music under a voiceover. None of it is written down. It lives as intuition, and it leaves when the editor does.
Code doesn’t have this problem. It’s explicit—written out, diffable, reviewable, revertible. That’s the whole reason Git works. You can see what changed, test whether the change is good, and undo it if it isn’t.
So we asked a blunt question: what would it take to give editing know-how those same properties?
The Core Idea: A Skill
We call the unit a Skill: one editor’s know-how, captured as something an AI can call like a function. A Skill bundles a trigger (when it applies), preconditions, the action it performs, and examples that demonstrate the right result.
Skills get created two ways:
- From finished work. The system reads a completed project file and extracts the patterns the editor actually used.
- From recording. A capture feature records a workflow inside the plugin and converts it into a Skill—or updates an existing one.
Once created, a Skill is stored in the YouViCo workspace, GitHub-style. One person’s editing method becomes something the rest of the team can use, improve, and grow.
Three Properties That Make Auto-Update Safe
The reason you can’t just let an AI overwrite know-how automatically is trust. So the design rests on giving every Skill three Git-like properties.
Diffability
A Skill has structure—trigger, precondition, action, examples—so a proposed change is a readable diff, not an opaque blob. You can see exactly what the AI wants to change.
Testability
A changed Skill has to pass all of its own reference examples before it can merge. This is a regression gate: if an “improvement” breaks a known-good example, it doesn’t ship. It’s the same idea as a content-parity check in CI, applied to editing know-how.
Revertibility
Every change is a commit, so undoing it is a one-line revert. If an auto-merged change turns out wrong, you roll it back exactly the way you’d revert a bad code release.
Together, these turn automatic updates from “overwrite and hope” into “accumulate evidence and verify.”
Update by Evidence, Not by Overwrite
A single observation is a signal, not a fact. So the update policy is conservative on purpose.
- Evidence threshold. A new technique is added as a variant or example by default. Only after the same intent is observed consistently, several times, does the system propose changing the canonical Skill.
- Regression gate. A changed Skill must pass its reference examples to merge.
- Two-tier permission. A candidate Skill (personal) can auto-merge once it passes CI with enough confidence. A canonical Skill (shared with the org) requires human review—branch protection, essentially.
- Reversibility. Every change is a commit with a one-line revert.
The non-obvious part: Skills don’t always merge—sometimes they speciate. Two editors can do the same task differently and both be right. Forcing a merge would destroy information. Instead we keep both as variants and let the orchestrator pick based on context—fast cuts versus a calm vlog. A single Skill evolves into a bundle of “context → implementation” branches. That’s something code in Git doesn’t naturally do, and it’s a YouViCo-specific strength.
The Lifecycle Loop
Put together, the system runs as a loop:
- Capture — recording and finished project files.
- Extract — an AI proposes a structured Skill delta.
- Propose — the change opens as a Skill pull request automatically.
- Verify — examples replay through a regression gate.
- Merge — one-click, or auto-merge for confident candidates.
- Release — a version plus a history entry.
- Observe — telemetry on which Skills get accepted or overridden.
- Back to capture, with the new signals feeding the next round.
Why This Is Buildable, Not Just a Vision
The honest engineering view is that the hardest components already exist in our stack. A headless AI that auto-generates pull requests is running. A content CI gate that blocks merges already enforces invariants. A commit-log database tracks every release. A structured vocabulary of editing commands—razor, ripple, color adjustments, keyframes, reframing—is in use.
The genuinely new risk concentrates in two places, and we’re honest about both. Extraction quality—reliably turning tacit work into structured Skills—is a machine-learning problem, not an infrastructure one, which means we measure it through dogfooding. And replay judgment—the editing host can’t run headless, so we verify at the action-trace level and have to design what “equivalent result” means. Everything up to automatic merging reuses existing assets heavily.
Lessons So Far
Explicitness is the whole game. The moment know-how has structure, the rest of Git’s machinery—diff, test, revert—becomes available to it.
Append before you overwrite. Treating new techniques as variants by default, and only promoting to canonical on strong evidence, keeps a bad signal from corrupting a good Skill.
Don’t force a merge when you should speciate. Two correct approaches to the same task are information, not conflict. Preserve both and choose by context.
Reuse beats greenfield. The reason this is realistic is that most of the hard infrastructure was already built for other reasons. New ambition rode on existing rails.
What’s Next
The near-term focus is extraction quality and the replay harness—the two real unknowns. Longer term, the workspace becomes a team’s version-controlled library of editing craft, where one editor’s intuition is something the whole organization can build on.
Frequently Asked Questions
Is this the same as recording a macro or action?
No. A macro replays fixed steps. A Skill is structured know-how with triggers, preconditions, and examples that an AI selects and adapts by context—and that can be tested and reverted like code.
Does auto-update mean the AI changes my work without asking?
No. New techniques are added as variants by default, canonical changes to shared Skills require human review, and every change is a one-line revert. The design is evidence-accumulating, not overwrite-by-default.
Why not just merge everyone’s editing style into one Skill?
Because two editors can be right in different ways. Forcing a merge loses information. Variants let the orchestrator pick the right approach for the context.
Related Reading
- How We Built an AI Assistant That Lives Inside Premiere Pro — the panel this runs on
- What Is an AI Video Editing Assistant? — the concept, for non-engineers