DEV Community: Alex Shev

Your AI Agent Does Not Need More Context. It Needs a Smaller Workflow.

Alex Shev — Wed, 13 May 2026 22:38:18 +0000

A lot of AI agent workflows are becoming expensive for a very boring reason:

We keep giving the agent too much context and not enough direction.

The usual pattern looks like this:

Here is my whole repo.
Here are 12 tools.
Here are 9 docs.
Here is the bug.
Please figure it out.

Sometimes it works.

But it is also how you end up with huge token usage, messy tool calls, slow runs, and an agent that spends half the session rediscovering what a human already knows.

More context feels safer.

In practice, it often makes the workflow worse.

The problem is not context. The problem is unfiltered context.

AI agents do need context.

They need the right files, the right constraints, the right examples, and the right definition of done.

What they do not need is every possible thing that might be relevant.

That is where many workflows go wrong.

A small task becomes a giant investigation because the agent has no boundary.

For example, imagine asking an agent to update a pricing component.

Bad version:

Read the app and update the pricing page.

Better version:

Update the pricing card component.
Only inspect files under components/pricing and app/pricing.
Do not change billing logic.
Run the component test and TypeScript check.
Return a short summary plus changed files.

The second prompt is not just shorter.

It is a smaller workflow.

That is the part that matters.

Tools make this easier and harder

MCP and other tool protocols are useful because they give agents cleaner access to external systems.

That is a real improvement.

But tool access also creates a new problem:

The agent can now search more, read more, call more APIs, and collect more context than it actually needs.

A connected agent is powerful.

A connected agent with no workflow boundary is expensive.

This is why I think a lot of teams are asking the wrong question.

The question is not only:

What tools can my agent access?

The better question is:

What is the smallest reliable workflow this task needs?

That one question changes how you design the agent.

A workflow beats a giant prompt

When I say “workflow,” I mean a repeatable operating pattern:

when to use it
which files or tools are in scope
which files or tools are out of scope
what steps to follow
what checks to run
what output format to return
what should trigger a human handoff

This is different from a one-off prompt.

A prompt is a request.

A workflow is a habit.

And agents need good habits more than they need another 2,000 words of instructions.

Example: debugging without reading the universe

Here is a simple debugging workflow I use mentally all the time.

Instead of telling the agent:

Debug this issue.

I want the agent to follow a narrow loop:

1. Reproduce the error.
2. Identify the smallest failing command or test.
3. Inspect only the files directly involved.
4. Make one focused change.
5. Re-run the failing check.
6. Stop if the fix requires product judgment.

That workflow does two useful things.

First, it keeps the agent from wandering through unrelated code.

Second, it creates a clear stopping point.

A lot of agent waste happens because there is no stopping point.

The agent keeps searching, summarizing, and patching because “done” was never defined.

Example: code review with a smaller surface area

The same idea applies to code review.

A vague agent review sounds like this:

Review this PR.

That can produce a long list of generic comments.

A smaller workflow is better:

Review only for:
- data loss risks
- auth or permission mistakes
- broken edge cases
- missing tests for changed behavior

Ignore style unless it affects correctness.
Return only high-confidence findings.

This turns the agent from a noisy reviewer into a useful filter.

It also saves attention.

The goal is not to make the agent say more.

The goal is to make the agent say fewer, better things.

This is where skills help

This is why I like packaging repeatable workflows as skills.

A skill can tell the agent:

For this kind of task, use this workflow.
Use these tools.
Avoid these traps.
Verify with these checks.
Return this output.

That is much more useful than repeatedly writing giant prompts.

For example, a media-processing skill could teach the agent the standard FFmpeg workflow.

A deployment skill could teach it the exact deploy and verification steps.

A code-review skill could teach it what kinds of issues matter and what kinds of comments to ignore.

A security skill could tell it when to stop and ask for human approval.

The skill is not magic.

It is just reusable judgment.

And reusable judgment is exactly what most agent setups are missing.

The smallest workflow test

Before giving an agent a task, I like to ask:

What is the smallest workflow that can finish this safely?

Then I reduce the task until the answer is clear.

That usually means:

fewer files
fewer tools
fewer open-ended instructions
more explicit checks
a clearer definition of done

This sounds less impressive than “agent with full repo access and every tool connected.”

But it works better.

Small workflows are easier to test.

Small workflows are easier to repeat.

Small workflows are easier to trust.

My rule of thumb

If an agent keeps burning tokens, I do not immediately add a better model.

I ask:

Is the task too broad?
Did I give it too many tools?
Did I define done?
Did I tell it what not to inspect?
Can this become a reusable skill?

Most of the time, the fix is not more intelligence.

It is less ambiguity.

Why this matters

AI agents are getting better fast.

But better models will not remove the need for workflow design.

If anything, stronger agents make workflow design more important because they can do more damage, spend more tokens, and move faster in the wrong direction.

The next layer of useful agent work is not just bigger context windows.

It is smaller, clearer, reusable workflows.

That is what I am collecting at Terminal Skills: practical examples of skills that give agents narrower, repeatable ways to do real work.

https://terminalskills.io

AI Receptionist Cost in 2026: How to Calculate ROI for Small Business Automation

Alex Shev — Thu, 07 May 2026 23:43:57 +0000

This is a practical breakdown for builders, consultants, and operators thinking about AI phone automation for small businesses.

The goal is not to hype “AI receptionists,” but to show what actually drives cost: call volume, integrations, booking workflows, follow-up, and missed-call recovery.

Small-business owners are not asking whether AI can answer the phone anymore. They are asking what an AI receptionist costs, what is included, and whether it pays for itself faster than hiring another front-desk person.

The honest answer is that AI receptionist cost depends on what you expect the system to do. A basic voice bot that takes messages is one category. A real AI employee that answers calls, texts missed callers, books appointments, updates your CRM, and follows up with leads is a different investment.

This guide breaks down AI receptionist pricing in practical terms so you can compare monthly cost against recovered calls, booked jobs, after-hours leads, and staff time saved.

What Affects AI Receptionist Cost?

Most pricing differences come from capability, not from the word “AI.” A cheap system may answer calls but fail when the caller asks a real question. A stronger system understands your business rules and turns conversations into outcomes.

The main drivers are:

call volume and whether pricing is per minute or flat monthly
voice quality and how natural the conversation feels
whether it can text, email, and follow up after the call
calendar, CRM, payment, and dispatch integrations
setup work: scripts, FAQs, service areas, offers, and escalation rules
reporting on missed calls, booked appointments, and revenue impact

Basic AI Answering vs. Full AI Receptionist

Basic call handling

Entry-level tools are useful if you only need a greeting, simple routing, or voicemail replacement. They are usually cheaper, but they often stop at message-taking. For businesses that depend on booked appointments, that is not enough.

Full AI receptionist

A full AI receptionist behaves more like a trained front-desk employee. It answers common questions, qualifies the lead, checks availability, books the next step, sends confirmations, and escalates edge cases. That is where ROI usually appears.

If an AI receptionist only saves labor, the math is decent. If it captures leads that were previously lost, the math gets much better.

How to Calculate ROI

Use a simple model before buying anything. Start with the calls you already receive, not fantasy traffic.

Ask:

How many calls do you miss each week?
How many after-hours calls go to voicemail?
What percentage of callers become booked appointments?
What is one booked job or consultation worth?
How much staff time goes into answering repeat questions?

If AI recovers just 5 to 10 extra leads per month and each booked customer is worth hundreds or thousands of dollars, the system can pay for itself quickly.

This is why phone-heavy businesses often see ROI faster than companies with low call volume.

Where Small Businesses Usually Overpay

Some businesses overpay for software that looks advanced but does not connect to operations. Others underpay for a cheap bot, then still need staff to clean up every conversation.

The goal is not the lowest monthly invoice. The goal is the lowest cost per qualified appointment.

Before choosing a tool, ask whether it can handle your actual calls:

pricing questions
service-area checks
emergency routing
appointment changes
lead qualification

If it cannot, the “savings” may disappear into manual cleanup.

Best Fit Businesses

AI receptionist systems tend to fit best when the phone is directly connected to revenue or operations.

Good examples include:

home service companies with technicians in the field
med spas, clinics, salons, and appointment-based local businesses
professional services that miss calls during client work
restaurants and hospitality businesses with repetitive phone questions
any company paying for Google Ads, Local Services Ads, or social traffic

Frequently Asked Questions

How much does an AI receptionist cost for a small business?

Pricing varies widely. Simple AI answering tools may be relatively low-cost, while full-service implementations with scheduling, CRM integration, follow-up, and reporting cost more.

Many full-service AI receptionist implementations can land around $1,000–3,000 per month, depending on scope.

The real cost depends on call volume, voice quality, scheduling, CRM integrations, and whether the system can book appointments instead of only taking messages.

Is an AI receptionist cheaper than hiring a human receptionist?

Usually yes, especially when the goal is 24/7 coverage. A full-time receptionist includes salary, payroll taxes, benefits, training, management, and coverage gaps.

An AI receptionist can provide round-the-clock call coverage and lead capture for a predictable monthly cost.

What gives an AI receptionist the fastest ROI?

The fastest ROI usually comes from recovering missed calls, booking after-hours leads, reducing voicemail leakage, and following up instantly with people who would otherwise call a competitor.

The Bottom Line

An AI receptionist should be judged by booked outcomes, not novelty.

If it answers calls, responds after hours, follows up instantly, and gets more prospects onto the calendar, it is not just a phone tool. It is a revenue-protection layer.

Originally published on AIEmployees:
https://aiemployees.us/blog/ai-receptionist-cost-small-business-2026

How I Built a CLI Skill to Batch-Process YouTube Shorts

Alex Shev — Thu, 07 May 2026 23:38:39 +0000

Last month, I had to process 16 YouTube Shorts.

Trim intros. Normalize audio. Add watermarks. Export multiple formats. Generate thumbnails.

Doing that manually in Premiere would have taken me most of an afternoon.

So I built a CLI skill instead.

It took about 2 hours to put together. On my machine, the batch itself finished in under 3 minutes once everything was set up.

This is the kind of repeatable workflow I think of as a Terminal Skill: small, documented, reusable automation that turns a messy manual task into one command.

Here’s the exact structure I used.

What I mean by a CLI skill

For me, a CLI skill is a reusable shell workflow with:

input validation
sensible defaults
predictable output
error handling
lightweight docs

Instead of retyping a long FFmpeg command every time, I run one script and get the same result every time.

# Instead of this:
ffmpeg -i input.mp4 -ss 00:00:02 -to 00:00:35 -vf "scale=1080:1920" -af "loudnorm=I=-14" -c:v libx264 -preset fast output.mp4

# I run this:
./process-short.sh input.mp4

That difference sounds small, but it removes the part that always breaks in real work: remembering the flags, the order, and the output steps.

Step 1: List the manual steps first

Before I wrote anything, I wrote down the full workflow:

trim the first 2 seconds
cut after 35 seconds
scale to 1080×1920
normalize audio to -14 LUFS
add watermark
export MP4
export WebM
generate a thumbnail

That gave me a real pipeline instead of a vague automation idea.

Step 2: Build one script that does the boring work

#!/bin/bash
set -euo pipefail

TRIM_START="00:00:02"
TRIM_END="00:00:35"
RESOLUTION="1080:1920"
AUDIO_TARGET="-14"
WATERMARK="./assets/watermark.png"
THUMB_TIME="00:00:05"

INPUT="${1:?Usage: process-short.sh <input.mp4>}"

if [[ ! -f "$INPUT" ]]; then
    echo "Error: File '$INPUT' not found."
    exit 1
fi

BASENAME=$(basename "$INPUT" .mp4)
OUTDIR="./output/${BASENAME}"
mkdir -p "$OUTDIR"

ffmpeg -y -ss "$TRIM_START" -to "$TRIM_END" -i "$INPUT" \
    -vf "scale=${RESOLUTION}" \
    -af "loudnorm=I=${AUDIO_TARGET}" \
    -c:v libx264 -preset fast -crf 23 \
    "${OUTDIR}/trimmed.mp4"

if [[ -f "$WATERMARK" ]]; then
    ffmpeg -y -i "${OUTDIR}/trimmed.mp4" -i "$WATERMARK" \
        -filter_complex "overlay=W-w-20:H-h-20" \
        "${OUTDIR}/${BASENAME}_final.mp4"
else
    cp "${OUTDIR}/trimmed.mp4" "${OUTDIR}/${BASENAME}_final.mp4"
fi

ffmpeg -y -i "${OUTDIR}/${BASENAME}_final.mp4" \
    -c:v libvpx-vp9 -crf 30 -b:v 0 \
    "${OUTDIR}/${BASENAME}.webm"

ffmpeg -y -i "${OUTDIR}/${BASENAME}_final.mp4" \
    -ss "$THUMB_TIME" -frames:v 1 \
    "${OUTDIR}/${BASENAME}_thumb.jpg"

rm -f "${OUTDIR}/trimmed.mp4"

A few choices mattered a lot:

set -euo pipefail so failures don’t get ignored
-y because this is a pipeline, not an interactive tool
temp file cleanup so output folders stay usable

Step 3: Make it batch-capable

One file is a demo. A directory is the real use case.

#!/bin/bash

INPUT_DIR="${1:?Usage: batch-process.sh <directory>}"
PROCESSED=0
FAILED=0

for file in "$INPUT_DIR"/*.mp4; do
    [[ -f "$file" ]] || continue
    if ./process-short.sh "$file"; then
        ((PROCESSED++))
    else
        echo "FAILED: $file"
        ((FAILED++))
    fi
done

echo "Batch complete: $PROCESSED processed, $FAILED failed"

This is where it actually became useful. I didn’t want a cool script. I wanted to stop babysitting repetitive exports.

Step 4: Add docs, even if it’s just for yourself

I also added a tiny SKILL.md with:

what the script does
requirements
usage
config variables
output files

That sounds boring, but it matters. A script without docs becomes archaeology in two weeks.

Step 5: Test annoying edge cases

This was the part that caught real bugs:

empty files
files with missing or unexpected audio tracks
short clips
weird filenames with spaces and brackets

That testing found multiple issues immediately. If I had skipped it, the batch version would have failed silently later.

One of the first things I ran into was how quickly “works on one file” falls apart on real footage. A weird filename, a silent clip, or a shorter-than-expected video is enough to break the whole flow if you never test for it.

The simplified script above assumes the input has an audio stream. In my real version, I added a small ffprobe check before applying loudnorm, because silent clips need a different path.

The result

Before: most of an afternoon for 16 videos

After: one command, then the machine does the repetitive part

./batch-process.sh ./raw-videos/

It’s still less flexible than Premiere. If I want one-off polish, I’ll still do it manually.

But for repeatable batch work, the tradeoff is absolutely worth it.

That’s why I like building CLI skills.

Not because they’re clever. Because they turn something fragile and repetitive into something boring and reliable.

If you build little terminal workflows or CLI skills like this too, I’d genuinely love to hear what you’ve automated.

What would you automate first?

MCP Is Not the Product — Reusable Skills Are

Alex Shev — Tue, 24 Mar 2026 22:20:07 +0000

Right now, a lot of people are talking about MCP.

And I get why.

It’s a clean idea: connect an AI agent to tools, data, and actions through a standard interface, and suddenly the model can actually do things.

That matters.

But I think a lot of people are still confusing the plumbing with the product.

MCP is useful. MCP is not the product.

The product is what happens after the connection exists.

The product is a reusable skill.

Tools are not enough

Giving an agent access to tools sounds powerful.

But in practice, raw tool access is messy.

If you just hand an agent ten tools, you usually get one of these outcomes:

it uses the wrong one
it uses the right one in the wrong order
it calls the same thing three times with weak assumptions
it produces output that technically worked, but isn’t reusable

That’s because tools are still too low-level.

A tool is a capability.
A skill is a workflow.

That difference is everything.

A simple example

I’ve seen this in boring, practical work more than once.

An agent with raw shell access and FFmpeg access can absolutely process a video.

But “can process a video” is not the same as “can reliably produce the same short-form output every time.”

The raw-tool version tends to drift:

wrong trim point
audio forgotten
watermark missing
output naming inconsistent
thumbnail skipped

The skill version is much narrower, but much more useful.

It knows the sequence.
It knows the defaults.
It knows what “done” looks like.

That’s the part people actually want in production.

Not possibility.
Reliability.

What a skill actually is

A skill is not just “the agent can run a command.”

A useful skill packages:

the goal
the right sequence of actions
defaults
constraints
output expectations
failure handling
context about when to use it

Compare these two ideas:

Tool: FFmpeg is available

Skill: Turn a raw clip into a 1080x1920 short with trimmed intro, normalized audio, watermark, and thumbnail

The second one is what people actually want.

No one wakes up thinking:
“I hope my agent has access to a media binary.”

They want the result.

Why this matters for AI agents

The current wave of agent demos still over-indexes on tool access.

You see a lot of:

database access
filesystem access
browser access
shell access
API access

That’s all necessary.
But it’s still not enough.

Because once the novelty wears off, teams ask a more practical question:

Can this do the same useful task reliably more than once?

That’s where most agents still fall apart.

They can improvise.
They can explore.
They can sometimes solve a task.

But reliable repeated execution comes from skills.

Skills are what turn “the agent figured it out once” into “the agent can do this whenever I need it.”

MCP helps. Skills deliver.

This is why I think the framing matters.

MCP is important because it standardizes access.

That’s good.

But once access is standardized, the real differentiation shifts somewhere else:

which workflows are packaged well
which tasks are reusable
which skills are trustworthy
which outputs are predictable
which agent behaviors are actually worth repeating

In other words:

MCP gives agents hands. Skills give them habits.

And habits are what make a system valuable.

The more useful pattern

The better pattern is:

use MCP to expose capabilities
use skills to package outcomes

That way the agent is not just connected.
It is directed.

And that is a much more practical way to build.

Why I care about this

This is exactly why I’m bullish on skill-based systems.

Because once you start packaging repeatable terminal workflows into reusable skills, a lot of noisy AI hype suddenly becomes much simpler.

You stop asking:

what tools can this model access?

And start asking:

what useful work can this system repeat reliably?

That is a better question.

And in my experience, it leads to much better products.

Tools unlock possibility. Skills unlock reliability.

And reliability is what people actually pay for.

If you want to see how we think about packaging repeatable terminal workflows into reusable skills, that’s exactly what we’re building at Terminal Skills.

How I Built a CLI Skill to Batch-Process YouTube Shorts

Alex Shev — Wed, 18 Mar 2026 04:16:33 +0000

Last month, I had to process 16 YouTube Shorts.

Trim intros. Normalize audio. Add watermarks. Export multiple formats. Generate thumbnails.

Doing that manually in Premiere would have taken me most of an afternoon.

So I built a CLI skill instead.

It took about 2 hours to put together. On my machine, the batch itself finished in under 3 minutes once everything was set up.

Here’s the exact structure I used.

What I mean by a CLI skill

For me, a CLI skill is a reusable shell workflow with:

input validation
sensible defaults
predictable output
error handling
lightweight docs

Instead of retyping a long FFmpeg command every time, I run one script and get the same result every time.

# Instead of this:
ffmpeg -i input.mp4 -ss 00:00:02 -to 00:00:35 -vf "scale=1080:1920" -af "loudnorm=I=-14" -c:v libx264 -preset fast output.mp4

# I run this:
./process-short.sh input.mp4

That difference sounds small, but it removes the part that always breaks in real work: remembering the flags, the order, and the output steps.

Step 1: List the manual steps first

Before I wrote anything, I wrote down the full workflow:

trim the first 2 seconds
cut after 35 seconds
scale to 1080×1920
normalize audio to -14 LUFS
add watermark
export MP4
export WebM
generate a thumbnail

That gave me a real pipeline instead of a vague automation idea.

Step 2: Build one script that does the boring work

#!/bin/bash
set -euo pipefail

TRIM_START="00:00:02"
TRIM_END="00:00:35"
RESOLUTION="1080:1920"
AUDIO_TARGET="-14"
WATERMARK="./assets/watermark.png"
THUMB_TIME="00:00:05"

INPUT="${1:?Usage: process-short.sh <input.mp4>}"

if [[ ! -f "$INPUT" ]]; then
    echo "Error: File '$INPUT' not found."
    exit 1
fi

BASENAME=$(basename "$INPUT" .mp4)
OUTDIR="./output/${BASENAME}"
mkdir -p "$OUTDIR"

ffmpeg -y -ss "$TRIM_START" -to "$TRIM_END" -i "$INPUT" \
    -vf "scale=${RESOLUTION}" \
    -af "loudnorm=I=${AUDIO_TARGET}" \
    -c:v libx264 -preset fast -crf 23 \
    "${OUTDIR}/trimmed.mp4"

if [[ -f "$WATERMARK" ]]; then
    ffmpeg -y -i "${OUTDIR}/trimmed.mp4" -i "$WATERMARK" \
        -filter_complex "overlay=W-w-20:H-h-20" \
        "${OUTDIR}/${BASENAME}_final.mp4"
else
    cp "${OUTDIR}/trimmed.mp4" "${OUTDIR}/${BASENAME}_final.mp4"
fi

ffmpeg -y -i "${OUTDIR}/${BASENAME}_final.mp4" \
    -c:v libvpx-vp9 -crf 30 -b:v 0 \
    "${OUTDIR}/${BASENAME}.webm"

ffmpeg -y -i "${OUTDIR}/${BASENAME}_final.mp4" \
    -ss "$THUMB_TIME" -frames:v 1 \
    "${OUTDIR}/${BASENAME}_thumb.jpg"

rm -f "${OUTDIR}/trimmed.mp4"

A few choices mattered a lot:

set -euo pipefail so failures don’t get ignored
-y because this is a pipeline, not an interactive tool
temp file cleanup so output folders stay usable

Step 3: Make it batch-capable

One file is a demo. A directory is the real use case.

#!/bin/bash

INPUT_DIR="${1:?Usage: batch-process.sh <directory>}"
PROCESSED=0
FAILED=0

for file in "$INPUT_DIR"/*.mp4; do
    [[ -f "$file" ]] || continue
    if ./process-short.sh "$file"; then
        ((PROCESSED++))
    else
        echo "FAILED: $file"
        ((FAILED++))
    fi
done

echo "Batch complete: $PROCESSED processed, $FAILED failed"

This is where it actually became useful. I didn’t want a cool script. I wanted to stop babysitting repetitive exports.

Step 4: Add docs, even if it’s just for yourself

I also added a tiny SKILL.md with:

what the script does
requirements
usage
config variables
output files

That sounds boring, but it matters. A script without docs becomes archaeology in two weeks.

Step 5: Test annoying edge cases

This was the part that caught real bugs:

empty files
videos without audio
short clips
weird filenames with spaces and brackets

That testing found multiple issues immediately. If I had skipped it, the batch version would have failed silently later.

The result

Before: most of an afternoon for 16 videos

After: one command, then the machine does the repetitive part

./batch-process.sh ./raw-videos/

It’s still less flexible than Premiere. If I want one-off polish, I’ll still do it manually.

But for repeatable batch work, the tradeoff is absolutely worth it.

That’s why I like building CLI skills.

Not because they’re clever. Because they turn something fragile and repetitive into something boring and reliable.

If you build little terminal workflows like this too, I’d genuinely love to hear what you’ve automated. I keep more reusable terminal workflow patterns on Terminal Skills.

What would you automate first?

8 FFmpeg Recipes I Use Every Week (That Most Developers Don't Know Exist)

Alex Shev — Wed, 11 Mar 2026 15:21:39 +0000

I've been using FFmpeg almost every day for the past year.

Mostly for boring real work: cutting Shorts, cleaning voice tracks, exporting web versions, generating thumbnails, and fixing weird media issues at the last minute when something breaks five minutes before publish.

Most FFmpeg tutorials cover the basics and stop there. These are the commands I actually come back to in production.

Here are 8 recipes I use constantly. Copy-paste ready.

1. Extract Audio from Video (and Clean It Up)

# Extract audio only
ffmpeg -i video.mp4 -vn -acodec libmp3lame -q:a 2 audio.mp3

# Extract + normalize loudness to broadcast standard
ffmpeg -i video.mp4 -vn -af "loudnorm=I=-16:TP=-1.5:LRA=11" -ar 44100 clean_audio.mp3

When I use it: Podcast edits, voiceover cleanup, and those annoying cases where a track sounds fine in headphones but way too quiet after upload. The loudnorm filter saved me from re-exporting more than once.

2. Create a GIF from a Video Clip (That Doesn't Look Terrible)

Most GIF conversions look like they were made in 2004. The trick is a two-pass approach with a custom palette.

# Generate optimized palette first
ffmpeg -ss 00:00:05 -t 3 -i video.mp4 \
    -vf "fps=15,scale=480:-1:flags=lanczos,palettegen" \
    palette.png

# Then use that palette for the GIF
ffmpeg -ss 00:00:05 -t 3 -i video.mp4 -i palette.png \
    -filter_complex "fps=15,scale=480:-1:flags=lanczos[x];[x][1:v]paletteuse" \
    output.gif

# Cleanup
rm palette.png

Why it matters: Single-pass GIFs use a generic 256-color palette. The two-pass method generates a palette optimized for your specific clip.

I learned this the hard way after making a product GIF that looked fine in preview and terrible after export. Washed-out gradients, ugly banding, weird skin tones. Two-pass fixed it immediately.

3. Batch Convert an Entire Folder

# Convert all MKV files to MP4 (preserving quality)
for f in *.mkv; do
    ffmpeg -i "$f" -c:v libx264 -crf 18 -c:a aac "${f%.mkv}.mp4"
done

# Convert all WAV to MP3 at 192kbps
for f in *.wav; do
    ffmpeg -i "$f" -codec:a libmp3lame -b:a 192k "${f%.wav}.mp3"
done

The pattern: ${f%.ext} strips the original extension. This is bash string manipulation, not FFmpeg — but it's the glue that makes FFmpeg scriptable.

This one saved me the most time in practice. Converting one file is nothing. Converting 40 files before lunch is where FFmpeg starts earning its keep.

4. Split a Video into Equal Chunks

Perfect for breaking long recordings into social-media-sized pieces.

# Split into 60-second chunks
ffmpeg -i long_video.mp4 -c copy -map 0 \
    -segment_time 60 -f segment \
    -reset_timestamps 1 \
    chunk_%03d.mp4

Output: chunk_000.mp4, chunk_001.mp4, chunk_002.mp4, etc.

The -c copy flag means no re-encoding — it's almost instant regardless of file size. The split happens at keyframes, so chunks might be slightly longer or shorter than 60 seconds.

5. Add Subtitles (Burned In)

# From an SRT file
ffmpeg -i video.mp4 -vf "subtitles=captions.srt:force_style='FontSize=24,FontName=Arial,PrimaryColour=&HFFFFFF,OutlineColour=&H000000,Outline=2'" output.mp4

# Quick one-liner subtitle (no SRT file needed)
ffmpeg -i video.mp4 -vf "drawtext=text='Hello World':fontsize=36:fontcolor=white:x=(w-text_w)/2:y=h-th-40:box=1:boxcolor=black@0.6:boxborderw=8" output.mp4

Pro tip: The force_style parameter in the SRT method lets you override subtitle styling without editing the SRT file. Useful when you get captions from auto-transcription services and need them to look consistent.

6. Picture-in-Picture (Two Videos Overlaid)

# Main video with small webcam overlay in bottom-right
ffmpeg -i main.mp4 -i webcam.mp4 \
    -filter_complex "[1:v]scale=320:240[pip];[0:v][pip]overlay=W-w-20:H-h-20" \
    -c:a copy \
    pip_output.mp4

Variations:

Top-left: overlay=20:20
Center: overlay=(W-w)/2:(H-h)/2
Animated (slide in): overlay='if(lt(t,1),W,W-w-20)':H-h-20

I use this for tutorial videos — screen recording as the main video, webcam as the PiP.

7. Speed Up / Slow Down Video

# 2x speed (video + audio)
ffmpeg -i input.mp4 -filter_complex "[0:v]setpts=0.5*PTS[v];[0:a]atempo=2.0[a]" -map "[v]" -map "[a]" fast.mp4

# 0.5x speed (slow motion)
ffmpeg -i input.mp4 -filter_complex "[0:v]setpts=2.0*PTS[v];[0:a]atempo=0.5[a]" -map "[v]" -map "[a]" slow.mp4

# 4x speed (atempo max is 2.0, so chain them)
ffmpeg -i input.mp4 -filter_complex "[0:v]setpts=0.25*PTS[v];[0:a]atempo=2.0,atempo=2.0[a]" -map "[v]" -map "[a]" 4x.mp4

The gotcha: setpts changes video speed, atempo changes audio speed. They're separate filters. If you only use setpts, you get a fast video with normal-speed audio — which is funny exactly once.

Also: atempo only accepts values between 0.5 and 2.0. For 4x, you chain two atempo=2.0 filters. I still have to look that up sometimes because it’s one of those FFmpeg details that never stays in my head.

8. Generate a Video from Images (Slideshow / Timelapse)

# From numbered images (img001.png, img002.png, etc.)
ffmpeg -framerate 24 -i img%03d.png -c:v libx264 -pix_fmt yuv420p slideshow.mp4

# From a folder of images (simple slideshow)
ffmpeg -framerate 1/3 -pattern_type glob -i '*.jpg' \
    -c:v libx264 -vf "fps=25,format=yuv420p" -pix_fmt yuv420p \
    slideshow.mp4

When I use it: Generating timelapse videos from screenshot sequences. Also useful for turning design mockups into a quick presentation video.

The -framerate 1/3 means each image shows for 3 seconds. Change the denominator to control display time.

The Cheat Sheet

Task	Key flags
Extract audio	`-vn` (no video)
No re-encode	`-c copy`
Quality control	`-crf 18` (lower = better, 0-51)
Normalize audio	`-af "loudnorm=I=-16"`
Scale video	`-vf "scale=1920:1080"`
Trim	`-ss START -to END`
Overwrite	`-y`

If you want more of these, I keep a small collection of terminal-first FFmpeg patterns on terminalskills.io.

What's your go-to FFmpeg recipe? Mine is still the two-pass GIF trick — not glamorous, but I use it constantly because bad GIF exports are way more common than they should be. If you have a better one, drop it in the comments 👇

I Ditched GUI Tools and My Productivity Doubled — Here Are the 5 Terminal Tools That Did It

Alex Shev — Sat, 07 Mar 2026 22:03:59 +0000

I used to be a GUI person. Premiere for video. Tower for git. Finder for files.

Then last year, I started building automation pipelines — video production, data processing, server deploys — and I kept hitting the same wall: GUI tools don't scale. You can't loop a drag-and-drop. You can't pipe a button click.

So I went terminal-first. And I'm not going back.

Here are the 5 tools that made the difference.

1. ripgrep (rg) — Search That Actually Respects Your Time

grep works. ripgrep works fast.

It respects .gitignore by default, searches recursively, and handles Unicode. On a 50GB monorepo, the difference isn't seconds — it's minutes.

# Search for "TODO" across your entire project, skip node_modules automatically
rg "TODO" --type ts

# Case-insensitive search with context lines
rg -i "deprecated" -C 3

Why it matters in 2026: Codebases are bigger than ever. AI-generated code means more files, more boilerplate, more things to search through. You need a search tool that scales.

Install: brew install ripgrep / cargo install ripgrep

2. jq — JSON Surgery from the Command Line

Every API returns JSON. Every config file is JSON. Every log pipeline outputs JSON.

jq lets you slice, filter, and transform it without opening a browser tab or writing a Python script.

# Extract all error messages from an API response
curl -s api.example.com/logs | jq '.entries[] | select(.level == "error") | .message'

# Reshape data — pull specific fields into a new structure
cat data.json | jq '[.users[] | {name: .name, email: .contact.email}]'

The real power: Piping. Chain curl | jq | xargs and you've built an API automation pipeline in one line. No dependencies. No virtual environments. No "let me spin up a quick script."

Install: brew install jq / apt install jq

3. FFmpeg — The Swiss Army Knife Nobody Teaches You

Most developers know FFmpeg exists. Few know it can replace an entire video editing suite.

I recently produced a 49-second educational short — compositing multiple video layers, syncing audio, adding animated subtitles — entirely from the terminal. No Premiere. No DaVinci Resolve.

# Trim a video with frame-accurate precision
ffmpeg -ss 00:01:30 -to 00:02:45 -i input.mp4 -c copy trimmed.mp4

# Overlay a watermark with position control
ffmpeg -i video.mp4 -i logo.png -filter_complex "overlay=W-w-10:H-h-10" output.mp4

# Generate a thumbnail from a specific timestamp
ffmpeg -i video.mp4 -ss 00:00:15 -frames:v 1 thumbnail.jpg

The unlock: Once you can script video processing, you can automate content pipelines. Batch process 100 videos. Auto-generate thumbnails. Convert formats at scale. I've been collecting FFmpeg patterns on terminalskills.io because the documentation alone could fill a textbook.

Install: brew install ffmpeg / apt install ffmpeg

4. lazygit — Git, But You Can Actually See What's Happening

I love git. I hate remembering whether it's git rebase -i HEAD~3 or git rebase -i HEAD~4.

lazygit gives you a terminal UI for git — staging hunks, interactive rebasing, cherry-picking — without leaving the terminal or touching a mouse.

# Just run it in any git repo
lazygit

What changed for me: I stopped being afraid of interactive rebases. The visual diff panel means you SEE what you're about to do before you do it. Conflict resolution went from "let me open VS Code" to "done in 10 seconds."

Pro tip: Hit ? inside lazygit for the full keybinding list. space to stage, c to commit, p to push. That's 90% of your workflow.

Install: brew install lazygit / go install github.com/jesseduffield/lazygit@latest

5. zoxide — cd, But It Remembers Where You've Been

This is the smallest tool on the list and the one I'd miss the most.

zoxide replaces cd with a smart directory jumper. It learns which directories you visit most and lets you jump to them with partial names.

# Instead of: cd ~/projects/company/backend/services/auth
# Just type:
z auth

# It knows you mean that specific auth directory
# because you've been there 50 times this week

Why it's not trivial: I timed it. On an average workday, I cd about 80 times. Each full path takes 3-5 seconds to type. zoxide cuts that to under 1 second. That's 5-6 minutes saved daily. Over a year, that's nearly a full workday of just... not typing paths.

Install: brew install zoxide / curl -sSfL https://raw.githubusercontent.com/ajeetdsouza/zoxide/main/install.sh | sh

The Pattern

None of these tools are new. But together, they changed how I think about work.

GUI tools are great for one-off tasks. But the moment you need to do something twice — the terminal wins. Every time.

I went from "let me open the app" to "let me write the command" and my throughput doubled. Not because I'm faster at typing. Because scripts don't forget steps, don't get tired, and don't need a mouse.

What's your terminal setup look like? I'm always looking for tools I've missed — I bet someone here has a workflow that would blow my mind. Drop it in the comments 👇

Some parts of this article were refined with AI assistance.