Claude Code Studied Nate Herk and Nick Saraev. Now It Edits My Videos.

There are two people on YouTube whose videos I like the look of: Nate Herk and Nick Saraev. Both build with AI, both edit with AI, and both publish how they do it.

I did not want to learn video editing. I wanted my raw recordings to come out edited like theirs, but my way.

So I gave the job to Claude Code. It studied their videos, measured how they edit, compared that with what my own pipeline did, and built the editor. It now cuts my long form and my shorts. And because the method worked, I turned it into a skill that does the same for any capability, not only video.

This is that skill, and how to build your own.

What Claude learned from two YouTubers

It took three versions, and the scores tell the story.

Version 1, 5 September. Claude researched their channels and built my first editor: silence and filler cuts, captions, animated overlays. I rated it 7. My note: it “did reach the goal” but “didn’t exactly bring back what I wanted”. The goal described the deliverable. It never described what good looked like.

Version 2, 26 September. This time Claude started from a reference: one of Nate’s tutorials, where Claude edits his videos with real B-roll. It transcribed it, measured its pacing (about 3 cuts a minute, a median shot of 3.73 seconds), compared it with what version 1 did, and turned every gap into a criterion on the visible result. Real B-roll, split screens, sound effects. 20 of 20 criteria proven, 0.76 USD spent of a 30 USD cap. I rated it 10. I wrote that whole run up as making Claude Code watch tutorials for me.

Version 3, 4 October. Now it measured. Six videos, three from each of them, the first three minutes of each, read from captions and contact sheets at one frame per second:

• Nate runs about 29.6 floating cards a minute over the speaker in his opens, with a range of 25.8 to 32.6.
• Each card sits at about 0.30 of the frame width, flanking the face, never on it.
• Each one stays about 2.2 seconds.
• The mix is roughly 45% media cards, 40% label chips, 15% keyword text.
• Nick puts zero cards over his face. He switches layouts instead.

Every one of those numbers became a target the pipeline checks itself against.

Nate Herk3 videos, first 3 minutesfloating cards over the speaker

Nick Saraev3 videos, first 3 minuteslayouts, nothing over the face

captions + 1 frame per second

29.6cards a minute in the open

0.30of the frame wide

2.2 son screen each

0cards over Nick's face

My editorversion 3's density, version 2's transitions, B-roll and split screens"Not a copy of Nate's kit."

Then I did the part no research can do. I watched versions 1, 2 and 3 side by side and decided. Version 2’s transitions, B-roll and split screens were better. Version 3’s density of things on screen was better. So my editor does both: mostly floating cards, with version 2’s moves as punctuation.

That is not Nate’s edit and it is not Nick’s. The skill file says it in so many words: “Not a copy of Nate’s kit.” What it took from his public kit is one rule: a card keeps the speaker visible and never covers the face.

Why the input before the goal decides the score

Same model, same operator, 7 then 10. The difference was what went in before the goal started: a reference to compare against, and criteria written on what I would see instead of on whether the machinery ran.

I had seen the same pattern outside video. On 11 August I ran a goal to mine my Claude Code history into course lessons, the AI Bible run, and rated it 2: “Very, very bad… probably because I didn’t do the due diligence before starting the goal.” The question prompts failed four times and the run went ahead on defaults. Claude invented the premise in its first reply. All 20 of its criteria tested process, none tested whether it answered my question.

On 25 September an audit of OrcStrator, the tool I use to run several Claude Code sessions at once, scored 10. It asked four questions with a recommended option each, fixed money at zero, and ran a second round after the first findings, which split 110 findings into 5 fix goals. I ran all five within three days.

AI Bible corpus mining11 Aug

1. One-line ask
2. 2 questions, answers never arrived
3. Claude invents the premise
4. Goal rewritten mid-run

2/10

OrcStrator audit25 Sep

1. 4 questions, each with a recommended option
2. Money fixed at zero
3. Second round after the findings
4. 5 fix goals, all run in 3 days

10/10

The obvious fix is to get better at writing goals. It does not work. A goal is the last step. By the time you are polishing its wording, three decisions have already been made, usually by accident: what the output is for, which exact questions it must answer, and what you will do differently once it exists. If those are wrong, a well worded goal executes the wrong thing very efficiently.

A time economics run on 15 August made the same point with money. I said “2,300 USD flat”, my fee per client, and the run took it as the revenue truth. The real monthly revenue in my own data was 20,400 USD, almost nine times higher. Nobody checked. My real question, whether I could be in bed by 22:00, only came out mid-run. My reply to the report: “wait, wtf? I asked 2 questions, you said words and didnt answer.”

So the skill does not trust me to write the goal. It makes me answer the questions that decide the goal, then checks my answers against the data before anything runs.

What you are building

A Claude Code skill that sits in front of /goal and handles any ask of the shape “give me a capability”: find me something worth building, answer these questions about my business, build me a skill that does what this expert does. Five moves:

1. Round 1, about three minutes: five open questions, then a block of proposed answers you accept with “fine”.
2. Recon, about six minutes, free by default: your past runs, your skills, your own data, and a small sample of the experts.
3. Round 2: three to five one-line possibilities from recon, then at most six questions and the settings.
4. The goal: a filled brief goes to a goal writer, which produces the plan and a /goal trigger under 4,000 characters.
5. The registry: one page per run, with your rating, so the next run reads it first.

It never writes the goal itself. That job belongs to my Build a Goal skill, which is public on GitHub. This skill decides what the goal is; Build a Goal decides how a goal is written.

Step 1: Ask five open questions before anything else

Round 1 is always the same five questions. Decision questions come first; method questions do not appear yet.

R1.1  The capability in one line, and who uses or buys the result?
R1.3  The exact questions the output must answer. Verbatim, numbered.
R1.4  What will you do differently on Monday when this exists?
R1.5  What would make you trust it without checking?
R1.7  Money, two lines: (a) this recon, (b) the goal it produces.
      Default: (a) ZERO DOLLARS. (b) ZERO DOLLARS, spend PAUSED.

Everything else is printed as proposed answers you accept with “fine”: the mode (finder, builder, or both), sources, output folder, automation level, prior runs it found, and one real example. That last one is where Nate’s tutorial went in for version 2. A real example is what the 10s had and the 7 did not.

Three rules ride on top, each from a failure on record:

• An answer must actually arrive. A tool error or “The user did not answer” is not consent. Ask again in plain text. That rule alone would have stopped the AI Bible run.
• The premise comes from you, never from Claude. If you give no question, it drafts one from your Monday answer and asks you to confirm it.
• Quote, never reference. Your questions go into the brief word for word, because the goal runs without access to this chat.

Step 2: Run a cheap recon, and let it say no

Between the rounds, the skill spends minutes, not hours, on what already exists:

1. The registry of past runs: same family, same client, or a shared keyword. A video ask reads the editor’s version 1 and 2 pages first.
2. Your own skills, by grepping every skill description for the topic.
3. Your own transcripts, counted by first message, deduplicated by session, machine-driven projects excluded by name. In one test that took 5,649 keyword hits down to 239 real ones.
4. Your own data, read only. Mine lives in Nask OS.
5. A small sample of the experts, if you allow it: one or two web searches, one to three YouTube searches, three to five caption files.

Then recon writes recon.md and checks two exits. Nothing here: the need is met, or not worth building. Already picked: one option clearly wins. Either one is confirmed with you in one line before it acts.

1

Round 15 open questions, proposed answers you accept with "fine"

about 3 min

2

Reconregistry, your skills, your transcripts, your data, a small web sample

about 6 min, $0

Exit: nothing here. Stop, and that counts as a success.Exit: already picked. Skip the finder goal, build number 1.

3

Round 23 to 5 possibilities first, then at most 6 questions and the settings

every question cites recon

4

The goala brief to the goal writer, a /goal trigger back

under 4,000 characters

The “nothing here” exit exists because of Jev’s decision-model audits, which researched for hours toward something that did not exist. My question afterwards: “If the need doesn’t exist, is it my fault or the audit’s fault?” Now recon says so in the first ten minutes, and that counts as a success.

One rule is fixed and never a question: no Meta surface is opened in a browser. Ad data comes through the API only, and the public Ad Library is the one read-only exception.

Step 3: Ask round two from what recon found

Round 2 opens with what recon found, as three to five one-line rows: what, evidence file, effort, cost. Then at most six questions, each citing a recon finding:

pattern	what it asks
The list	“Recon found these 4. Research all 4, the top 2, or build number 1 now?”
Already exists	“This skill already does part of it. Build on it, or what does it not cover?”
Contradicted figure	“You said X, the data says Y. Which is true? Default: report both.”
Pilot	“The full sweep is a second goal, started by you after a pilot. OK?”

The contradicted figure row is the 2,300 versus 20,400 mistake turned into a question. Round 2 ends with the settings block (auditors, iteration cap, image budget, web search, dollars, permissions), which is the goal writer’s confirmation step, so it never gets asked twice.

Step 4: Hand a brief to the goal writer, never a one-liner

The brief is a fixed template, and every line cites an interview row or a recon file:

Capability and audience:   R1.1, your words
Mode:                      finder | builder | finder then builder
Questions to answer:       R1.3, VERBATIM, numbered
Never-review-again test:   R1.5, as a checkable criterion
Money:                     a figure and a cap, or ZERO DOLLARS, spend PAUSED
Prior versions + lessons:  registry pages, one line each
Recon findings:            recon.md, cited
Criteria to include:       from the quality bar, by number

One line matters more than it looks: no step waits for you. A /goal that stops for your yes gets pushed forward by its own Stop hook and loops. So anything that needs you is written down and handed back at the end.

Then a checklist runs on the result: file times prove round 1 came before recon and recon before round 2, the trigger counts under 4,000 characters, your questions appear verbatim in the criteria, and a criterion labelled “Never review again” exists.

Step 5: Keep a registry, and turn ratings into criteria

Every run writes one page to runs/: the ask, sources, spend, outcome, my rating verbatim, one Lesson line. Version 3 of the editor is a page that points at versions 1 and 2. I seeded the registry with 18 past runs, rated from 2 to 11, and turned the ratings into a numbered quality bar, each criterion carrying the run that taught it:

• Q16, gap analysis first. From the video editor: version 2 compared against a reference, version 1 did not.
• Q2, your questions answered first. From the time economics run, the 5.
• Q4, a ranked list that ends in a pick. From the OrcStrator audit, the 10.
• Q15, outcome over hygiene. From the AI Bible run, the 2.

2

AI BibleQ15outcome over hygiene

5

Time economicsQ2your questions first

7

Video v1Q16gap analysis first

8

UGC catalogueQ6exact-id matching

10

OrcStrator auditQ4ranked list, one pick

10

Video v2Q13gates attacked

11

Weekly batchQ8automation level

Under the hood: the 4+1 audit loop and the blind test

I built the skill itself as a /goal. Every iteration, four auditing agents review it from four angles (correctness, adversarial, quality as the buyer reads it, what is missing), two on Fable and two on Opus. A fifth agent checks external claims against the live web, and a contradicted claim with a source outranks all four. Each auditor is a subagent with its own context, so their disagreements are real.

It found real defects. A YouTube scraping actor no longer had the input the skill told it to use. A pilot step waited for my yes inside a /goal. Each one was reproduced by hand before it was fixed; anything that could not be reproduced was rejected in writing.

capability-enhancer / iteration-log

$iteration 1 dry runs on v1, 2 blind audits

 27 findings. each reproduced before it was fixed

$iteration 2 4 auditors + 1 web agent

 CRITICAL a Meta rule could be waived in chat -> FIXED, now absolute

 WEB scraper input no longer exists -> FIXED, outranks all four

 REAL a pilot waited for a yes inside /goal -> FIXED, goal ends instead

 17 accepted, 5 rejected (could not reproduce)

$iteration 3 dry runs on v3

 11 PASS 1 FAIL (the checklist's own grep was wrong) -> FIXED

$iteration 4 final

 verifier ALL GREEN blind audits 8/8 Apify 0.03 of 20 USD

Then I replayed old asks through it. An auditor got two goals per ask, labelled A and B, without knowing which was new, and picked the one more likely to deliver. It picked the new goal 8 times out of 8, with the new goal at A four times and at B four times. The whole campaign spent 0.03 USD of a 20 USD Apify cap.

1

Apicked

B

2

Apicked

B

3

A

Bpicked

4

A

Bpicked

5

Apicked

B

6

A

Bpicked

7

A

Bpicked

8

Apicked

B

8 of 8new goal at A four times, at B four times

Hand it to Claude Code

The skill is wired to my own machine, so here is the prompt that builds your version. Paste it into Claude Code.

Read https://rodrigonask.com/claude-code-learns-skills-from-youtube-experts
and build me a skill called capability-enhancer in
~/.claude/skills/capability-enhancer/.

It must:
1. Never write a /goal from a one-line ask. Interview first.
2. Round 1: ask me R1.1, R1.3, R1.4, R1.5 and R1.7 as open questions, then
   print the rest as proposed answers I accept with "fine", including one
   real example (a video, a person, a page) to learn from. Log to
   interview-r1.md. A tool error is not an answer: ask again.
3. Recon, minutes not hours, zero dollars by default: read runs/INDEX.md,
   grep my skill descriptions, and if I allow it, pull captions from 3 to 5
   videos of the experts I named. Write recon.md with two exits, "nothing
   here" and "already picked", each confirmed with me in one line.
4. Round 2: show 3 to 5 possibilities first, then at most 6 questions, each
   citing recon. End with the settings block. Log to interview-r2.md.
5. Write brief.md from the template in the article, quoting my questions
   verbatim, then hand it to my goal-writing skill. Never copy that skill.
6. Run the checklist: file times in order, trigger under 4000 characters,
   my questions verbatim in the criteria, a "Never review again" criterion.
7. Write a registry page to runs/ and a row to runs/INDEX.md.
8. Seed QUALITY-BAR.md from my ratings: ask me for 5 past runs, the rating
   I gave each and one line on why, and turn each into a criterion.

Step 8 is the one people skip, and it is the one that makes the next run better than this one.

When not to do this

When you already know exactly what you want built and how you will check it. A bug fix, a known refactor, a page specified down to the copy. If the decision is made, write the goal, and close the session with an audit rather than a memory, which is what Safe to Close is for.

When the run is under twenty minutes. Ten to fifteen minutes of interview in front of a short run is overhead, not insurance.

And when nobody is there to answer. Inside a scheduled routine, the skill parks the round 1 questions as a card and stops, because a run built on answers nobody gave is the 2 out of 10 all over again.