DEV Community: Alex Shev

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.

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 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.