DEV Community: Alex Shev

Your Wix Site Is Not the Problem. The Migration Workflow Is.

Alex Shev — Fri, 19 Jun 2026 02:32:16 +0000

Wix is good at the thing it was built for.

It lets someone get a website online without opening a repo, choosing a framework, setting up hosting, wiring a CMS, or learning deployment.

That is useful.

For a lot of businesses, a Wix site is not a mistake. It is the reason they had a website at all.

The problem usually starts later.

The site grows. The business changes. Marketing wants better landing pages. SEO becomes more serious. Someone wants custom checkout logic. Someone wants the blog to behave differently. Someone wants better performance. Someone wants a dashboard, a pricing page, a gated area, a headless CMS, or a proper deployment workflow.

And suddenly the team says:

Can we move this Wix site to React?

That question sounds simple.

It is not.

There is no clean universal "export to Next.js" button for the real version of this job.

You are not just moving pixels.

You are moving a live website with content, layout decisions, SEO assumptions, forms, media, tracking, business logic, and usually a few messy surprises nobody documented.

That is why Wix-to-React migration is a workflow problem, not a framework problem.

The naive version of this task

The naive version sounds like this:

Take this Wix site and rebuild it in React.

An AI agent can try.

It can open the page, inspect the layout, create a component, copy some text, approximate the styling, and produce something that looks close enough in a screenshot.

That is fine for a demo.

It is not enough for a migration.

Because the first screenshot is not the website.

The website is also:

all the pages you forgot to mention
mobile layouts
navigation states
images and files
redirects
metadata
forms
blog posts
product pages
CMS collections
tracking scripts
accessibility issues
weird spacing that only exists on one page
business content that is hidden behind menus
SEO URLs that should not break

If you treat the job like a design clone, you miss the operational work.

If you treat it like an operational migration, the task becomes much clearer.

The real question

The real question is not:

Can React recreate this page?

Of course it can.

The better question is:

What exactly needs to survive the move?

That question changes the whole workflow.

A brochure site with five static pages is one thing.

A Wix site with blog content, member areas, forms, stores, bookings, and SEO history is another.

For a small static site, you might rebuild everything in Next.js and move on.

For a site using Wix CMS or Wix Stores, you have decisions to make:

do you migrate the data out of Wix?
do you keep Wix as a headless backend?
do you recreate the CMS somewhere else?
do you preserve the URL structure?
do you rebuild forms manually?
do you map products to a new ecommerce system?
do you keep any Wix SDK integration?

Those are not code-generation questions.

They are migration design questions.

And if you skip them, the React app may look fine while the business workflow breaks.

Why agents need a skill for this

AI agents are pretty good at writing React components.

They are less reliable when the task is open-ended and the definition of "done" is fuzzy.

That is exactly what a Wix migration is.

Without a workflow, the agent might do the most obvious thing:

open the homepage
copy the visual layout
create a few components
call it a migration

But a real migration needs a more boring sequence:

inventory -> classify -> extract -> rebuild -> migrate data -> verify -> report gaps

That is not glamorous.

It is also the difference between a useful migration and a pretty mockup.

This is where Terminal Skills becomes relevant.

Terminal Skills is a catalog of reusable skills for AI agents. The point is not to give the agent one magic command. The point is to give it a repeatable operating procedure.

For this exact problem, the useful skill is:

wix-to-react

The skill page is here:

https://terminalskills.io/skills/wix-to-react

The important part is the shape of the workflow.

It tells the agent to treat a Wix-to-React conversion as a migration with inspection, decisions, preservation rules, and verification, not as a one-shot clone.

What a Wix-to-React workflow should do first

The first step should not be code.

The first step should be inventory.

Before the agent builds anything, it should answer:

how many pages exist?
which pages are public?
which pages are hidden or linked only from menus?
what content is static?
what content comes from Wix CMS?
are there blog posts?
are there products?
are there forms?
are there bookings, events, or members-only areas?
what scripts are installed?
what URLs need to be preserved?
what assets need to be downloaded?

This is not busywork.

This prevents the classic migration failure:

The homepage was rebuilt, but half the website disappeared.

The homepage is usually the easiest page.

The risk is in the boring pages:

thank-you pages
old campaign landing pages
policy pages
blog detail templates
category pages
product variants
forms connected to business processes

If those pages are not inventoried, they are easy to lose.

The second step is classification

Once you know what exists, you need to classify it.

Not every part of a Wix site should be migrated the same way.

I would separate it like this:

Static marketing pages

These are usually safe to rebuild directly in React or Next.js.

Examples:

homepage
about page
service pages
contact page
pricing page
landing pages

The agent can rebuild these as components, sections, layouts, and reusable content blocks.

CMS-driven content

This needs a data decision.

Examples:

blog posts
case studies
team members
locations
service areas
resource libraries

You can migrate this to another CMS, keep it in files, move it into a database, or use Wix as a headless backend through the Wix SDK.

But the decision needs to be explicit.

Business logic

This is where a screenshot clone fails badly.

Examples:

forms
bookings
ecommerce
member areas
gated downloads
payment flows
email automations

These are not visual elements.

They are workflows.

If the old site uses Wix Forms or Wix Stores, the new React app needs a replacement plan.

SEO and analytics

This is easy to forget because it does not show up in the page design.

But it matters.

The migration should preserve or map:

page titles
meta descriptions
canonical URLs
open graph images
headings
structured data
redirects
analytics events
pixels
conversion tracking

If a business already gets traffic from the Wix site, migration is not just a design task.

It is a traffic-preservation task.

Rebuilding the UI is the easy part

Once the inventory and classification are done, the React work becomes much easier.

The agent can create:

a layout system
shared header and footer
reusable section components
page templates
image components
content loaders
route structure
SEO metadata helpers
form components

This is where React and Next.js shine.

Instead of editing every page manually inside a visual builder, you can create a system.

For example:

components/
  Header.tsx
  Footer.tsx
  Hero.tsx
  ServiceGrid.tsx
  TestimonialSection.tsx
  ContactForm.tsx

app/
  page.tsx
  about/page.tsx
  services/[slug]/page.tsx
  blog/[slug]/page.tsx

The goal is not to recreate Wix as code.

The goal is to turn the site into a maintainable product.

That means reusable components, clear content sources, predictable routes, and a deployment workflow the team can understand.

The Wix SDK option

There is one important nuance.

Moving to React does not always mean abandoning Wix completely.

For some teams, Wix still owns useful business data:

products
CMS collections
bookings
members
blog content

In that case, the migration may become:

React/Next.js frontend + Wix as backend

That is where @wix/sdk can matter.

Instead of ripping everything out immediately, the new app can use Wix data as a headless backend while the frontend becomes custom.

That is not the right answer for every project.

But it is a real migration option.

And it is exactly the kind of decision an agent should surface instead of guessing.

A good workflow should say:

If the site depends on Wix CMS, Stores, Blog, or Forms, decide whether to migrate the data out or keep Wix as a backend before rebuilding those features.

That is a much safer instruction than:

Convert Wix to React.

Verification matters more than generation

The most dangerous part of this workflow is false confidence.

The agent can generate a React app that looks convincing.

But the migration is not done until the output is checked.

A practical verification checklist should include:

every important URL has a matching route or redirect
desktop and mobile layouts are checked
images load from the right source
navigation works
forms submit somewhere real
blog or CMS pages render from data
metadata exists
old URLs are mapped
no obvious console errors appear
performance is acceptable
accessibility basics are not broken

For example:

npm run build
npm run lint
npm run test

Then check the running site:

npm run dev

And inspect actual pages in the browser.

This is the same pattern I keep coming back to in agent workflows:

inspect -> decide -> run -> verify -> report

The code generation part is only one step.

The verification is where the work becomes trustworthy.

Where Terminal Skills fits

This is why I like the Terminal Skills framing.

The useful thing is not "AI can write React."

We already know that.

The useful thing is:

AI can follow a repeatable migration workflow if the workflow is packaged clearly enough.

The wix-to-react skill gives the agent a more specific operating path.

It turns a vague request:

Move my Wix site to React.

Into something closer to:

Inventory the Wix site.
Classify static pages, CMS content, business logic, and SEO requirements.
Choose whether to migrate data or use Wix as a backend.
Rebuild the frontend in React or Next.js.
Verify routes, content, forms, metadata, and deployment readiness.
Report what was completed and what still needs human decisions.

That is much better.

It reduces the number of hidden assumptions.

It also makes the agent easier to supervise.

Instead of asking:

Did it convert the site?

You can ask:

What pages did it inventory?
What content sources did it find?
Which Wix features still need a migration decision?
What routes were rebuilt?
What checks passed?
What is still missing?

Those are better questions.

They produce better work.

The agent should report gaps, not hide them

One thing I would explicitly want in a Wix migration skill:

Do not pretend every Wix feature was migrated if it was only visually approximated.

This matters.

If the old Wix site had a booking workflow and the new React app has a button that looks like "Book Now" but does nothing, that is not a migration.

That is a visual placeholder.

Placeholders are fine if they are labeled.

They are dangerous if they are hidden.

A good final report should say:

rebuilt pages
skipped pages
assets copied
data exported
data not exported
forms recreated
forms still placeholder
SEO mappings completed
redirects still needed
manual decisions required

That kind of honesty is boring.

It is also what makes agent work usable in production.

A realistic migration plan

If I were using an agent for a Wix-to-React migration, I would want the workflow to look roughly like this.

Phase 1: Discovery

Open the Wix site.

Map the visible pages.

Check navigation, footer links, sitemap if available, blog index, product pages, and any public routes.

Create an inventory file.

Phase 2: Feature audit

Identify whether the site uses:

Wix CMS
Wix Blog
Wix Stores
Wix Bookings
Wix Forms
member login
custom code
third-party scripts

This decides how risky the migration is.

Phase 3: Content and asset extraction

Download or document:

images
logos
icons
copy
metadata
blog content
product data
form fields

Do not start rebuilding until the content source is clear.

Phase 4: React/Next.js rebuild

Create the app structure.

Build shared components.

Recreate pages.

Wire content.

Add metadata.

Add forms or placeholder warnings.

Phase 5: Verification

Run build checks.

Open pages locally.

Compare important pages visually.

Check mobile.

Check forms.

Check SEO metadata.

Check old-to-new URL mapping.

Phase 6: Deployment readiness

Prepare environment variables.

Document backend dependencies.

Write redirect rules.

Create a final migration report.

Only then should anyone talk about launch.

The bigger lesson

Wix-to-React is a good example of where AI agent work is going.

The value is not just producing code faster.

The value is turning messy operational work into repeatable workflows.

Most real tasks are not one command.

They are sequences of judgment:

inspect the current system
understand what matters
choose the safest path
make the change
verify the result
explain the remaining risk

That is true for video processing.

It is true for deployment.

It is true for content publishing.

And it is definitely true for migrating a Wix site into React.

The framework is not the hard part.

The workflow is.

That is why skills matter.

Not because they make agents magical.

Because they make agents less random.

Final thought

If you have a small Wix site and it still works, you may not need to migrate it.

No-code tools are not automatically bad.

But if your site has outgrown the builder, the migration needs to be treated like a real software project.

Not a screenshot clone.

Not a prompt.

Not a one-click export fantasy.

A workflow.

That is the reason I like the wix-to-react skill on Terminal Skills.

It frames the job correctly:

inventory, classify, rebuild, verify, and report.

That is how you move from "the agent made something that looks like my Wix site" to "the agent helped migrate the actual website."

Explore the skill here:

https://terminalskills.io/skills/wix-to-react

And if you are building agent workflows around real work, not just demos, the broader Terminal Skills catalog is worth watching:

https://terminalskills.io

Solstice Cipher: a light-routing puzzle for the June Solstice Game Jam

Alex Shev — Sun, 14 Jun 2026 15:41:40 +0000

This is a submission for the June Solstice Game Jam.

What I Built

Solstice Cipher is a small browser puzzle game about the longest day, code-breaking, and the turning point between signal and shadow.

The player rotates mirrors to route a solstice beam through every cipher node before landing on the final beacon. Each level is a tiny circuit of light: if the beam misses a cipher gate, the beacon does not unlock.

The game is inspired by a few June themes from the challenge prompt:

the June solstice and the long arc of daylight
light versus darkness
turning points
Alan Turing, code-breaking, and computational thinking

Demo

Demo video: watch in browser / direct MP4

Playable game: https://desciple88.github.io/solstice-cipher-devto-game-jam/

Source code: https://github.com/desciple88/solstice-cipher-devto-game-jam

How It Works

The game is a dependency-free HTML/CSS/JavaScript canvas app.

The board is a 6x6 grid. A sunbeam enters from one side of the board, moves in one of four directions, and reflects when it hits a mirror:

/ turns east to north, south to west, and so on
\ turns east to south, north to west, and so on

Cipher nodes record whether the beam visited them. A level is solved only when the beam has touched all required cipher nodes and then reaches the beacon.

Controls

Click or tap a mirror to rotate it.
Use Reset or press R to restart the level.
Use Next or arrow keys to switch levels.
Use Hint or press H if the path gets stuck.

Why the Turing Angle

I wanted the Alan Turing category to feel like part of the mechanics, not just a label. The player is effectively debugging a simple signal machine: change one reflector, trace the path, see which gates activated, and iterate until the message resolves.

It is not an Enigma simulator, but it borrows the feeling of signal routing, symbolic gates, and systematic code-breaking.

What I Used

HTML
CSS
JavaScript
Canvas 2D
ffmpeg for the demo capture

AI assistance was used while preparing the implementation and write-up. I am not entering this under the Best Google AI Usage category because I could not complete a real Google AI toolchain step during the build; the local Gemini CLI was unavailable in my environment.

What I Learned

For a tiny jam game, the best scope was a mechanic that could be understood instantly: rotate mirrors, follow light, unlock the beacon.

The solstice theme gave the visual direction. The Turing theme gave the rules: the path is not just pretty, it has to carry a complete signal.

MCP Gives Your Agent Stripe Access. Skills Tell It What Not to Break.

Alex Shev — Sun, 14 Jun 2026 13:10:19 +0000

Stripe integrations are one of the places where AI coding agents look magical right up until they are dangerous.

The agent can read docs.

It can generate a checkout flow.

It can wire a webhook.

It can create a connected account, move money between a platform and a seller, and leave you with code that looks believable.

That last part is the problem.

Payments code does not fail like a todo app.

If a todo app has a bad edge case, someone cannot mark a task complete.

If a marketplace payment flow has a bad edge case, the wrong party collects fees, a seller cannot finish onboarding, a payout goes missing from your internal state, or a webhook retry silently creates a reconciliation mess.

This is why I do not think "just connect the agent to Stripe MCP" is enough.

MCP gives the agent access.

A skill gives the agent a playbook.

The access layer: Stripe MCP

Stripe has an MCP server for agentic workflows.

That matters because an agent can work with Stripe through a structured tool surface instead of guessing from memory or copy-pasting stale snippets from the web.

Stripe's own docs describe the MCP server as a set of tools agents can use to interact with the Stripe API and search Stripe's knowledge base.

That is a real improvement over asking an LLM:

"Build Stripe Connect for my marketplace"

and hoping it remembers the latest API shape.

But access is not the same thing as judgment.

If an agent has a Stripe tool, it still needs to know:

which Connect charge type fits the product model
whether sellers need Express, full dashboard access, or a fully embedded flow
where to store the connected account id
which events must update internal order state
when to use direct charges vs destination charges vs separate charges and transfers
how to handle refunds, disputes, onboarding requirements, and payout status

Those are not just API calls.

They are product decisions.

The instruction layer: a Stripe Connect skill

The latest Stripe-related skill I looked at on Terminal Skills is stripe-connect.

It is built for marketplace and platform payments:

two-sided marketplaces
seller/provider onboarding
splitting payments between buyers and sellers
platform fees
payouts
connected account management
Connect webhooks

The important detail is that the skill is not just a list of endpoints.

It tells the agent how to reason through the flow.

For example, the skill uses Stripe Accounts v2 for new Connect platforms. Instead of thinking in the old flat type: "express" shape first, it frames a connected account around configurations:

merchant for accepting payments
recipient for receiving transfers and payouts
customer for being billed as a customer

That is the kind of detail an agent can easily miss if it is only pattern-matching from older examples.

The skill also makes dashboard access explicit:

express for Stripe-hosted onboarding and dashboard
full for sellers who need a full Stripe dashboard or OAuth-style flow
none for embedded/custom platform control

That distinction matters because onboarding is not just a technical step. It changes who owns UX, support, compliance surface, and seller control.

Why this belongs in a skill, not just a prompt

You can tell an agent:

"Use Stripe best practices."

That sounds clear.

It is not.

Best practices for what?

A simple SaaS checkout?

A usage-based subscription?

A marketplace with sellers?

A white-label platform?

A service marketplace where money should be held until work is delivered?

Those are different systems.

A good skill narrows the task before code starts appearing.

For Stripe Connect, I want the agent to ask and encode questions like:

Is the platform the merchant of record, or is the seller?
Does the seller need dashboard access?
Should the platform collect the fee at charge time?
Is fulfillment immediate, delayed, or milestone-based?
What internal state changes when onboarding completes?
Which webhook events are the source of truth?
What happens on refund, dispute, failed payment, and failed payout?

That is the work.

The API call is the last mile.

The most useful part: choosing the charge model

A lot of marketplace payment bugs start with choosing the wrong charge model.

The stripe-connect skill separates the main options:

Direct charges

The charge happens on the connected account.

This can make sense when the seller should own more of the payment relationship and see the charge directly in their Stripe account.

Destination charges

The platform creates the charge and routes funds to the seller.

This is often the clean marketplace default when the platform controls the buyer experience and collects an application fee.

Separate charges and transfers

The platform charges the buyer first, then transfers funds later.

This is the flexible option when delivery, risk, escrow-like timing, or multi-party routing matters.

The agent needs to make this decision before it writes the PaymentIntent code.

Otherwise it may produce code that works in a test card happy path but does not match the business.

Webhooks are where the integration becomes real

Stripe integrations are not done when the payment succeeds in the browser.

They are done when the backend state survives reality.

That means webhooks.

For Connect, the platform may need to listen for:

onboarding updates
payment success and failure
transfers
payouts
disputes
connected-account events

The skill calls out an easy-to-miss detail: Accounts v2 emits thin events through event destinations, and onboarding status can require listening for account requirements updates.

That is exactly the kind of thing a generic prompt can skip.

It may build the happy path and leave the operational path unfinished.

Where Stripe MCP and skills fit together

The way I think about it:

MCP is the tool socket.

The skill is the operating procedure.

Stripe MCP can let the agent query Stripe knowledge, inspect resources, and work through a structured API-facing interface.

The stripe-connect skill tells the agent how a marketplace payment system should be assembled:

define the seller account model
create the connected account
generate onboarding
store the account id
choose the charge type
collect platform fees intentionally
wire webhooks
handle refunds, disputes, and payouts
test with Stripe CLI and test cards

That is the difference between "agent can call Stripe" and "agent can build the right Stripe flow."

The agent should not be trusted with vague money movement

This is the big lesson for me.

AI agents are getting better at implementation.

But money movement is not just implementation.

It is policy, product design, compliance boundary, risk handling, and state reconciliation.

So the workflow should look more like this:

Human defines the marketplace model
        |
        v
Skill frames the Stripe Connect decisions
        |
        v
MCP/API tools give the agent current Stripe access
        |
        v
Agent writes the implementation
        |
        v
Tests + webhooks + review prove the money flow

That is the stack I trust more than a big prompt.

Not "AI, build payments."

"AI, follow this payment architecture, use current Stripe tools, and show me the decisions before you move money."

That is where agents start becoming useful for serious backend work.

Source:

Terminal Skills stripe-connect: https://terminalskills.io/skills/stripe-connect
Stripe MCP docs: https://docs.stripe.com/mcp
Stripe AI build docs: https://docs.stripe.com/building-with-ai

Product Videos Should Be Build Artifacts, Not Manual Exports

Alex Shev — Tue, 09 Jun 2026 19:42:24 +0000

Every product launch needs the same small pile of video assets:

a 16:9 demo clip for the launch page
a square cut for social
a GIF preview for the changelog
a poster image for email

The weird part is how often that still means opening a video editor by hand.

Someone updates the product copy. Someone swaps the screen recording. Someone exports a new MP4. Someone crops another version. Then two weeks later the same release video cannot be reproduced exactly because the editor timeline, font version, plugin state, or export preset drifted.

For product teams, that is the wrong abstraction.

The launch video should be closer to a build artifact.

Change the source. Open a PR. Let CI render the exact same video every time.

The useful idea: HTML as the video source

Most product launch videos are not cinema.

They are structured compositions:

headline
short subcopy
screen recording
background audio
a few transitions
a logo or CTA

That maps surprisingly well to HTML and CSS.

Instead of keeping the source of truth in a visual editor, the source can live in a normal index.html file:

<div
  id="stage"
  data-composition-id="release-2-4"
  data-start="0"
  data-width="1920"
  data-height="1080"
>
  <video
    data-start="0"
    data-duration="8"
    src="assets/screencast.mp4"
  ></video>

  <h1
    id="headline"
    data-start="1"
    data-duration="5"
  >
    v2.4 - Realtime Collaboration
  </h1>

  <p
    id="sub"
    data-start="2"
    data-duration="4"
  >
    Comment, mention, resolve - live.
  </p>

  <audio
    data-start="0"
    data-duration="8"
    data-volume="0.7"
    src="assets/bed.wav"
  ></audio>
</div>

That one file now carries things a video editor usually hides:

canvas size
timing
copy
media references
animation hooks
composition id

And because it is text, it can be reviewed like any other product change.

The important part is deterministic rendering

Rendering HTML to video is only useful if the result is reproducible.

If a CI job renders a different file every time, the system is just another flaky media tool.

The better workflow is frame-seeking:

Load the HTML composition in headless Chrome.
Seek to each timestamp.
Capture the frame.
Encode the frames into MP4.
Produce the same output from the same source.

That is the reason HyperFrames is interesting here. It treats HTML, CSS, media, and seekable animation as a renderable video composition.

Then FFmpeg handles the boring but necessary production work:

# master render
npx hyperframes lint
npx hyperframes render

# 1:1 social cut
ffmpeg -i out/release-2-4.mp4 \
  -vf "crop=1080:1080:420:0" \
  -c:a copy \
  out/release-2-4-square.mp4

# lightweight GIF for changelog
ffmpeg -i out/release-2-4.mp4 \
  -vf "fps=12,scale=640:-1:flags=lanczos" \
  out/release-2-4.gif

# poster frame for email
ffmpeg -ss 2 \
  -i out/release-2-4.mp4 \
  -frames:v 1 \
  out/release-2-4-poster.jpg

One master render becomes every format the team needs.

Why CI is the right place for this

For a small SaaS team, the release note is already part of the engineering workflow.

The video can be too.

name: Render launch video

on:
  push:
    tags: ["v*"]

jobs:
  render:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"

      - run: sudo apt-get update && sudo apt-get install -y ffmpeg

      - working-directory: launch-video
        run: |
          npx hyperframes lint
          npx hyperframes render
          ffmpeg -i out/release-2-4.mp4 -vf "crop=1080:1080:420:0" -c:a copy out/square.mp4

      - uses: actions/upload-artifact@v4
        with:
          name: launch-video
          path: launch-video/out/*.mp4

Now the video is attached to the release process:

copy changes are visible in PRs
timing changes are versioned
release tags regenerate the same artifacts
reviewers can inspect the rendered output
social cuts come from the same master file

The team is not replacing creative work with CI.

It is removing the repetitive export layer around a video that is mostly structured product information.

Where this fits

This works best for videos that are template-driven:

product launch clips
changelog videos
feature teasers
onboarding explainers
social demos
doc/video snippets

It is probably the wrong tool for a cinematic brand film.

But most weekly product videos are not cinematic. They are release communication.

And release communication should be repeatable.

The agent angle

The interesting part is what happens when an AI coding agent can edit the video source.

An agent can:

update the release copy
swap in a new screencast
adjust timing
add a maintained transition block
run the lint step
render the preview
post-process the output

That is much more useful than asking an AI tool to generate a random video from a prompt.

The agent is working inside the same system as the product team: files, PRs, CI, artifacts, and review.

That is where AI video automation starts to feel practical.

I wrote up the full workflow here:

https://terminalskills.io/use-cases/automate-product-videos-from-html

The short version:

If the video changes every release, put the video source next to the release.

Then let the build system render it.

How to Write Terminal Skills That AI Agents Can Actually Use

Alex Shev — Mon, 08 Jun 2026 21:07:58 +0000

Most AI agent advice still sounds like prompt advice.

Add more context.
Write clearer instructions.
Give the model examples.
Use a better system prompt.

That helps, but it misses the part that breaks in real work.

The problem is not always that the agent does not know a command. The problem is that the agent does not know your workflow.

It does not know when to inspect first.
It does not know which defaults are safe.
It does not know what "done" means.
It does not know when to stop instead of guessing.
It does not know which checks matter before something leaves the local machine.

That is where Terminal Skills become useful.

A Terminal Skill is not just a command shortcut. It is a small reusable operating procedure for an agent.

It teaches:

when to use a workflow
what inputs are acceptable
which commands or scripts are preferred
what output should exist
how to verify the result
when to stop and ask for help

That last part is the difference between a useful agent workflow and a confident mess.

Here is the pattern I use when writing one.

Start with the task, not the tool

The easiest mistake is to begin with a tool name.

Bad starting point:

Make an FFmpeg skill.

Better starting point:

Make a skill that turns a raw video file into an X-ready MP4, then verifies the upload is likely to work.

Those are different scopes.

The first one is a tool wrapper.

The second one is a workflow.

Agents do not need every possible FFmpeg flag. They need a stable path through a common problem.

The same applies to any terminal workflow:

not "make a git skill"
but "review a dirty worktree without touching unrelated user changes"
not "make a deploy skill"
but "deploy a Next.js app to Vercel and verify the live URL"
not "make a search skill"
but "inspect a repo and find the smallest safe file set for this task"

The more specific the workflow, the more useful the skill.

A useful skill has a contract

I like thinking about a Terminal Skill as a contract between the human, the agent, and the machine.

The contract says:

If this kind of task appears,
and these inputs exist,
follow this workflow,
produce this output,
run these checks,
and stop under these conditions.

That sounds simple, but it removes a lot of randomness.

Without a contract, the agent improvises.

With a contract, the agent has a default operating path.

That does not make the agent less intelligent. It makes the work less dependent on fresh reasoning every time.

The basic structure

For most Terminal Skills, I would start with a folder like this:

my-skill/
  SKILL.md
  scripts/
    run.sh
  examples/
    input-example.txt
  README.md

Not every skill needs a script.

Some skills are mostly procedural. Some are wrappers around existing CLIs. Some are just strong instructions plus verification commands.

But the SKILL.md is the important part.

It should tell the agent how to work, not just what the tool does.

Here is a practical template.

# Skill Name

## Use When

Use this skill when the user asks to:
- ...
- ...

## Do Not Use When

Do not use this skill when:
- ...
- ...

## Inputs

Expected inputs:
- source file or directory
- target format
- optional config

## Workflow

1. Inspect the input.
2. Choose the smallest safe action.
3. Run the script or command.
4. Verify the output.
5. Report the result with file paths and any warnings.

## Commands

```bash
./scripts/run.sh input-file
```

## Verification

Check:
- output file exists
- output format is correct
- command exited successfully
- logs contain no obvious errors

## Stop Conditions

Stop and ask the user if:
- required input is missing
- output validation fails
- the task would publish, delete, charge, email, or deploy something
- the command could overwrite user data

That is already more useful than a loose prompt.

It gives the agent a map.

The most important section is "Stop Conditions"

Most people underwrite this part.

They document the happy path and skip the failure boundaries.

But agents need stop conditions badly.

A good skill should say things like:

stop if the repo has unrelated user changes
stop if the API token is missing
stop if the public page cannot be verified
stop if the output file has no video stream
stop if the command would delete or overwrite source files
stop if the user approved a draft but did not approve publishing

This is where agent workflows become safer.

For example, a social publishing skill should not only say:

Open the composer and publish the post.

It should say:

Before posting, verify the composer contains the exact approved text.
After posting, verify the final permalink shows the full text and attached media.
If media is missing, do not report success.

That is a real operating rule.

It captures the part of the workflow that normally lives in someone's head.

Verification should be concrete

"Check that it worked" is not enough.

A good Terminal Skill names the actual check.

For a video skill:

ffprobe -v error -show_streams -show_format output.mp4

For a code skill:

npm test
git diff --check

For a content publishing skill:

Open the final live URL.
Confirm the title, body, tags, canonical URL, and media are visible.
Do not trust the editor preview as final verification.

For a data export skill:

Check row count, headers, encoding, and sample records before sending the file.

Agents are very good at saying "done" too early.

Verification commands make "done" harder to fake.

Keep the skill narrow

The best skills are boringly specific.

Bad:

content-automation

Better:

devto-draft-from-markdown
x-safe-video-export
reddit-comment-visibility-check
vercel-preview-deploy-and-verify

Narrow skills have clearer triggers and fewer hidden assumptions.

They are also easier to improve.

If a video export fails, fix the video skill.
If a DEV.to draft misses a canonical URL, fix the DEV.to skill.
If a Reddit comment is visible to the owner but not public, fix the visibility check.

One giant "content automation" skill would hide all of those failures inside one vague blob.

Small skills make the workflow inspectable.

Use scripts for mechanics, instructions for judgment

I do not think every skill should become a huge script.

Scripts are good for mechanical repeatability:

convert this file
validate this JSON
resize this image
call this API
generate this report

Instructions are better for judgment:

when to use the script
which candidates to reject
how to handle approval
what counts as verification
when not to continue

The skill should combine both.

For example:

SKILL.md explains the workflow.
scripts/export.sh performs the conversion.
Verification commands prove the output.
Stop conditions prevent the agent from bluffing.

That is the useful shape.

Not "the agent has a tool."

"The agent has a way of working."

Example: a tiny repo-inspection skill

Here is a small example that does not need a script.

# Repo Inspection

## Use When

Use this before editing an unfamiliar codebase.

## Workflow

1. Print the current directory.
2. Check git status.
3. List top-level files.
4. Identify package/framework files.
5. Search for relevant code with ripgrep.
6. Read the smallest useful files before editing.

## Preferred Commands

```bash
pwd
git status --short
rg --files | head -80
rg -n "keyword|component|route" .
```

## Stop Conditions

Stop before editing if:
- the user has unrelated changes in the target file
- the task requires a destructive git command
- the repo structure is unclear after inspection

## Verification

Before reporting done:
- show changed files
- run the smallest relevant test or check
- explain any test that could not be run

This is not glamorous.

But it prevents a lot of common agent mistakes.

It teaches the agent the shape of careful work.

What makes a skill good?

I usually judge a skill by five questions.

1. Does it have a clear trigger?

The agent should know when to use it.

If the trigger is vague, the skill will either be ignored or overused.

2. Does it reduce repeat reasoning?

A good skill saves the agent from rediscovering the same workflow again.

If the workflow is only used once, it may not need a skill yet.

3. Does it define done?

The skill should say what output must exist and how to verify it.

If "done" is subjective, the agent will guess.

4. Does it include stop conditions?

This is the safety layer.

The skill should prevent confident continuation when the workflow is missing a required input, external approval, or verification.

5. Is it small enough to maintain?

If the skill becomes a giant manual for everything, it stops being useful.

Small, composable skills are easier to trust.

The bigger point

AI agents are getting better at tool use.

That does not mean every workflow should be improvised in chat.

The more capable the agent becomes, the more important operating procedures become.

Prompts are good for intent.
Tools are good for capability.
Skills are good for repeatable work.

That is the layer I think more developers should build.

Not because it is flashy.

Because boring, reusable workflows are what turn agents from demos into something you can actually depend on.

I am collecting more examples of this pattern at Terminal Skills.

If you are building your own agent workflows, start with one annoying task you repeat every week.

Write down the trigger, workflow, verification, and stop conditions.

That is your first skill.

Building an AI Short Video Generator: Why the Workflow Needs Skills, Not Just Prompts

Alex Shev — Fri, 05 Jun 2026 21:20:25 +0000

Most AI short-form video demos skip the boring part.

They show a finished TikTok, Reel, or YouTube Short. Maybe they show the prompt. Maybe they show the generated script or the final render.

But the hard part is not making one video.

The hard part is making the fifteenth video without the whole system turning into a pile of one-off scripts, half-remembered FFmpeg commands, broken captions, inconsistent hooks, and manual upload steps.

That is where I think the conversation around AI video automation gets more interesting.

Not:

Can an AI generate a Short?

But:

What workflow does an AI agent need to generate Shorts repeatedly?

I was looking at a Terminal Skills use case for building an AI short video generator, and the useful part is not the fantasy of "push one button, print infinite content."

The useful part is the stack.

The real job is a pipeline

A short-form video generator sounds like one tool.

In practice, it is a pipeline:

topic research
  -> script
  -> voiceover
  -> footage or visual generation
  -> subtitles
  -> assembly
  -> platform formatting
  -> upload
  -> analytics

Each step has different failure modes.

Topic research can produce generic ideas.
Scripts can be too long.
Voice can drift from the brand.
Footage can mismatch the narration.
Subtitles can land under platform UI.
FFmpeg can export a technically valid file that a platform still hates.
Uploads can succeed in the API but fail the actual publishing workflow.

If you try to solve all of that with one giant prompt, the agent has to keep too much operational knowledge in its head.

That is fragile.

The better pattern is to split the workflow into skills.

What a skill gives the agent

A skill is not just a code snippet.

For this kind of workflow, a useful skill tells the agent:

when to use this capability
what inputs are expected
what output should exist afterward
what validation is required
when to stop instead of pretending success

That last point matters.

For media automation, "the command ran" is not enough.

The agent needs to verify things like:

is the video actually 9:16?
is the duration within the target range?
does the file have an audio stream?
are captions inside the safe area?
is the codec platform-friendly?
did upload verification happen from the final published page, not just the composer?

This is the difference between an automation demo and an operating workflow.

A practical skills stack for short-form video

The Terminal Skills use case frames the AI short video generator as a stack, not a monolith.

I would break it down like this.

1. Research skill

This skill should not just "find trending topics."

It should produce usable candidates:

topic
why it is timely
target audience
hook angle
risk level
source links

For a YouTube Shorts pipeline, the research skill should bias toward ideas that can be explained visually in under 60 seconds.

Not every good article becomes a good Short.

2. Script skill

Short-form scripts need constraints.

A useful script skill should enforce:

one idea per video
hook in the first 1-2 seconds
short sentences
a clear visual beat for each section
no long intro
no vague CTA unless the channel actually uses CTAs

The output should be structured, not just prose:

{
  "hook": "This one missed call can cost a local business hundreds.",
  "beats": [
    { "time": "0-5s", "line": "Most small businesses do not lose leads in ads.", "visual": "phone ringing unanswered" },
    { "time": "5-15s", "line": "They lose them after the click.", "visual": "call log with missed calls" }
  ],
  "cta": "Follow for more local business automation ideas."
}

Now the renderer has something it can work with.

3. Voice skill

Text-to-speech is easy to call.

Brand-consistent voice is harder.

A voice skill should know:

preferred provider
voice ID or style
pacing
loudness target
whether to use pauses
file naming conventions
retry rules

It should also validate that the audio duration roughly matches the script timing before video assembly starts.

4. Caption skill

Captions are not decoration for Shorts.

They are part of the format.

A caption skill should own:

line length
word grouping
font size
contrast
bottom safe zone
whether to use word-level highlighting
SRT or burned-in output

This is where a lot of AI video pipelines become visibly cheap.

The content might be fine, but the captions are too low, too wide, too fast, or hidden under the TikTok/Shorts interface.

5. FFmpeg or assembly skill

This is the mechanical layer.

It should assemble the finished asset into predictable platform-ready output:

1080x1920
H.264
AAC
yuv420p
faststart metadata
30-60 seconds
safe captions
consistent naming

The important part is not memorizing the FFmpeg flags.

The important part is that the agent knows the output contract.

For example:

ffprobe -v error -show_streams -show_format -of json output/short.mp4

That check should happen after render, not after a human complains that the upload failed.

6. Upload skill

Upload automation is where I would be most conservative.

It is one thing to render a local MP4.
It is another thing to publish externally.

The upload skill should separate:

prepare upload
verify metadata
draft/schedule
publish
confirm public URL

Those should not all be one invisible step.

If a human approval gate is required, the skill should say so plainly.

The useful mental model

The mistake is thinking of this as:

prompt -> video

The better model is:

brief -> structured assets -> render -> verify -> publish decision

That model is slower to explain, but much more reliable in production.

It also gives the agent smaller jobs.

The research skill does not need to understand FFmpeg.
The caption skill does not need to know the YouTube Data API.
The upload skill does not need to invent the script.

Each skill owns a boundary.

That boundary is what makes the workflow debuggable.

What I would automate first

If I were building this from scratch, I would not start with full auto-publishing.

I would start with a local generator that produces a review folder:

shorts/
  001/
    script.json
    voiceover.wav
    captions.srt
    final.mp4
    checks.json
    publish-notes.md

Then the agent reports:

Generated 12 Shorts.
10 passed validation.
2 need review:
- #04 captions exceed safe zone
- #09 audio duration is longer than target

That is already valuable.

It removes the repetitive production work while keeping a human in control of the final publishing decision.

Only after that is reliable would I add scheduling or upload automation.

The bigger point

AI video automation is not just a model problem.

It is a workflow problem.

The teams that win here will not be the ones with the longest prompt.

They will be the ones that turn each fragile part of the process into a small, documented, reusable skill:

research
scripting
voice
captions
rendering
validation
upload
analytics

That is how you move from "I made one cool video" to "I can produce a repeatable content pipeline without babysitting every export."

And that is the part I care about most.

The demo is the video.

The product is the workflow.

Source use case: Build an AI Short Video Generator

AI Answering Service Pricing: The Small Business Cost Model That Actually Matters

Alex Shev — Fri, 05 Jun 2026 17:23:52 +0000

Most small businesses compare answering services the wrong way.

They ask:

What is the cheapest way to get the phone answered?

That sounds reasonable, but it misses the point.

For a phone-driven business, the real question is:

What does it cost to stop losing ready-to-buy callers?

An AI answering service is not valuable because it sounds futuristic. It is valuable when it handles the first few minutes of a lead better than the current workflow: voicemail, missed calls, front-desk overload, slow callbacks, or an answering service that only takes a message.

This is the practical pricing lens I would use before buying or building one.

The Monthly Price Is Only One Line Item

Two vendors can both say "AI answering service" and mean completely different things.

One may only answer the call, follow a simple script, and create a message log.

Another may:

answer calls when staff are busy
qualify the caller
identify urgency
collect service area and contact details
book appointments
send missed-call text-back
update the CRM
route urgent work to a human
trigger follow-up if the caller does not book

Those are not the same product.

One is call coverage. The other is a revenue workflow.

That difference matters more than whether the invoice is a few hundred dollars higher or lower.

The Four Options Businesses Are Really Comparing

Most owners are not choosing between AI and nothing. They are choosing between imperfect options they already understand.

1. Hiring a full-time receptionist

This gives the most control during business hours, but the cost is not just salary.

You also have payroll taxes, training, turnover, management time, sick days, lunch breaks, vacations, and the fact that one person cannot cover every spike in call volume.

It may still be the right choice for complex, relationship-heavy calls. It is not automatically the best option for overflow, after-hours, or repetitive intake.

2. Using a virtual receptionist

A virtual receptionist can be a good middle ground when the business needs a human voice but does not want another full-time hire.

The tradeoff is usually pricing complexity:

minutes
call volume
scripts
after-hours rules
handoff rules
add-on services

If the service only takes messages, the business still has to do the expensive part later: call back, qualify, schedule, and log everything.

3. Using a live answering service

Live answering services are useful for basic overflow and after-hours coverage.

They are often better than voicemail.

But answering the phone is not the same as moving the lead forward.

If the service cannot connect to your calendar, qualify the job, log CRM details, handle SMS follow-up, or route urgent work correctly, the business can still lose the lead after the call is "handled."

4. Using an AI answering service

AI answering works best when the workflow is repeatable:

intake
FAQs
booking
missed-call recovery
service-area checks
urgency triage
callback requests
follow-up

It is not the right tool for every sensitive edge case. Humans are still better at unusual judgment calls and emotionally complex conversations.

But for many local businesses, the first response is the part that breaks most often. AI can make that layer faster, more consistent, and available outside staffed hours.

What Actually Drives AI Answering Service Pricing?

The cost usually depends on workflow scope, not just "AI."

The main pricing drivers are:

call volume and expected minutes
business-hours coverage vs 24/7 coverage
voice quality and conversation depth
custom scripts, FAQs, services, and escalation rules
calendar, CRM, phone system, and SMS integrations
missed-call text-back
appointment booking
quote request handling
human escalation
multi-location routing
reporting on recovered leads and booked appointments

That is why a cheap plan can still be expensive.

If it answers calls but cannot take action, staff may spend time cleaning up incomplete notes, chasing callers, and manually updating systems.

The better pricing question is:

What will this system do after the caller says what they need?

Watch For Hidden Costs

When comparing vendors, I would look beyond the headline monthly price.

Common hidden costs include:

setup fees
per-minute overages
per-call charges
SMS fees
call recording charges
phone number fees
extra location or department fees
calendar or CRM integration fees
after-hours limits
human escalation costs
internal staff time needed to fix messy call notes

The cleanest pricing model is the one you can connect to business outcomes:

calls answered
missed calls recovered
leads qualified
appointments booked
response time improved
staff time saved

If the vendor cannot explain how pricing connects to those outcomes, they are probably selling an answering layer rather than an operating workflow.

A Simple ROI Model

You do not need a perfect industry benchmark to decide whether AI answering service pricing makes sense.

Start with the business's own numbers.

Ask:

How many calls are missed each month?
How many after-hours calls go to voicemail?
How many callers ask the same questions every day?
What percentage of phone leads become appointments, estimates, consultations, or jobs?
What is one booked customer worth?
How much staff time goes into intake, callbacks, reminders, and CRM updates?

For some businesses, one recovered customer can cover the monthly cost.

That is especially true in categories where a single booked job has meaningful value:

home services
dental offices
med spas
legal intake
auto repair
appointment-based local services

The ROI case should not be built on "AI saves labor" only.

The stronger case is:

AI protects leads that were already paid for or already trying to buy.

Where AI Answering Usually Pays Off First

The first version should not try to automate every call.

It should start where revenue is already leaking.

Good first targets:

missed calls during busy hours
after-hours calls from urgent buyers
Google Business Profile and Google Maps calls
paid ad calls
quote requests
appointment requests
repeated intake questions
service-area and urgency qualification

If missed calls are the obvious leak, start with missed-call text-back and quick qualification.

If calls are coming in but staff cannot cover them consistently, AI answering becomes the stronger front layer.

The first five minutes of the lead are often where the sale is won or lost.

AI vs Human Is The Wrong Framing

The useful comparison is not "AI or human?"

It is:

Which parts of the call workflow need speed and structure,
and which parts need judgment?

AI is stronger for:

instant response
24/7 availability
structured intake
repeat questions
CRM logging
booking flows
follow-up triggers

Humans are stronger for:

sensitive complaints
unusual exceptions
relationship-heavy sales
emotional judgment
high-value handoffs

The best setup may use AI for the first response and humans for the moments that actually need a human.

That is how the pricing starts to make sense. You are not replacing the whole front desk. You are protecting the part of the workflow where speed, consistency, and routing matter most.

What To Know Before Asking For A Quote

Before talking to vendors, prepare the inputs that actually affect price.

Bring:

monthly call volume
missed-call volume
business hours
after-hours needs
main call sources
service areas
locations
urgent-call rules
current CRM
calendar or booking tools
phone system
who handles escalations
what counts as a qualified lead

If the vendor does not ask about those things, be careful.

They may be pricing a generic voice layer, not the workflow your business actually needs.

The Bottom Line

The best AI answering service is not the one with the lowest monthly number.

It is the one where the price makes sense after you count:

missed calls
after-hours leads
front-desk time
booking gaps
manual follow-up
lost paid traffic
the value of a recovered customer

If a business only needs basic message-taking, a simple answering service may be enough.

If the business needs intake, booking, CRM updates, missed-call recovery, and follow-up, AI answering starts to look less like a phone expense and more like revenue infrastructure.

Originally published on AIEmployees:
https://aiemployees.us/blog/ai-answering-service-pricing

HVAC Missed-Call Automation: The AI Workflow That Actually Protects Revenue

Alex Shev — Thu, 04 Jun 2026 17:48:20 +0000

Most HVAC companies do not lose good jobs because the customer was impossible to convince.

They lose them because the customer had a hot house, a cold office, or a broken system, and the first helpful company answered faster.

That is why the strongest AI automation case for HVAC is usually not a generic website chatbot. It is a missed-call and emergency-intake workflow that responds in seconds, asks the right questions, routes the lead, and gives the team clean context.

The promise is not "replace your office staff with AI."

The promise is simpler:

No urgent HVAC lead should wait until tomorrow
just because everyone was busy today.

This is a practical breakdown of what that workflow should look like.

The Real Leak Is Speed

HVAC demand is urgent, seasonal, and local.

When air conditioning fails during a heat wave or a furnace stops working before a cold night, the buyer is not casually researching vendors. They are trying to get help.

That creates a simple operational problem.

Calls spike when the team is already under pressure:

the office coordinator is dispatching technicians
the owner is moving between estimates and crews
technicians are on jobs
after-hours calls go to voicemail or an answering service
emergency and routine requests get mixed together

If the caller reaches voicemail, they usually do not wait patiently. They call the next company.

The missed call is not just a phone event. It is a revenue event.

What The Workflow Needs To Do

A useful HVAC missed-call workflow has five parts.

1. Detect The Missed Call

The system should know when a call was missed and respond quickly.

The first text should be short and useful:

Sorry we missed you. Is this for no cooling, no heat,
maintenance, or a quote? Reply with your address and
what is happening, and we will help route it.

The goal is not to sound clever. The goal is to restart the conversation before the customer books someone else.

2. Separate Emergency From Routine

The AI should not treat every request the same.

It needs to ask a few questions that decide urgency and routing:

Is this no cooling, no heat, water around the unit, unusual smell, noise, thermostat issue, or maintenance?
Is anyone in the home vulnerable to heat or cold?
Is this residential, commercial, landlord, or property manager work?
What is the service address and ZIP code?
Is the caller new, returning, or on a maintenance plan?
Does the issue need same-day dispatch, next available booking, or an estimate?

Those answers turn a messy missed call into a usable intake record.

3. Hand Off Cleanly

For routine work, the workflow can collect preferred appointment windows.

For urgent work, it can alert dispatch or the on-call person with a summary.

A good handoff includes:

caller name
phone number
service address
issue type
urgency
equipment notes if available
source of the lead
preferred timing
transcript or short summary

This matters because the dispatcher should not have to call back just to ask the same first questions.

4. Log The Lead

If the workflow only sends a text, it is useful but limited.

The better version updates the CRM or lead tracker:

lead source
service type
urgency
booked status
assigned owner
follow-up outcome
lost lead reason if known

This turns the workflow into an operating report.

Now the company can answer questions like:

How many missed calls became booked jobs?
Which ad sources produce urgent calls?
Which service types go cold most often?
How many after-hours leads are worth staffing or automating?

That is where AI stops being a novelty and becomes management infrastructure.

5. Follow Up Without Spamming

Some HVAC leads are ready to book immediately. Others need a little context before they say yes.

Follow-up should match the situation:

no reply after missed-call text: send one short check-in
quote request: explain the next step and ask for photos if useful
replacement lead: route to owner or comfort advisor
maintenance customer: offer plan renewal or seasonal tune-up
completed job: trigger review request and future maintenance reminder

The key is that follow-up should be tied to the customer's actual intent. Generic drip messages are how automation starts to feel cheap.

Why "AI Receptionist" Is Too Vague

Many companies sell this as an AI receptionist.

That phrase is not wrong, but it is too broad.

An HVAC owner does not wake up thinking, "I need an AI receptionist." They think:

We missed three calls during dispatch.
The after-hours service did not qualify the lead.
The coordinator forgot to follow up on a replacement quote.
We do not know which Google Ads calls actually became jobs.
We are paying for leads that disappear before anyone responds.

So the offer should be framed around the leak:

Recover missed HVAC calls before competitors answer.

That is much more concrete than "AI chatbot" or "AI receptionist."

A Simple ROI Model

The cleanest sales conversation is not a giant industry claim.

It is a worksheet based on the company's own numbers:

How many calls do you miss per week?
How many after-hours calls go unanswered?
What percentage of emergency calls usually become jobs?
What is the average repair ticket?
What is the average replacement estimate value?
How many quote follow-ups go cold each month?

If the company recovers even a few extra jobs per month, the workflow can pay for itself.

But the math should come from call logs and job history, not a generic promise.

That is also useful for implementation. The first version should focus on the highest-value leak, not every possible automation.

A Practical Four-Week Rollout

The first version does not need to automate the whole business.

It needs to catch the leads that currently leak.

Week 1: Map The Intake

Document call sources, service area, emergency criteria, escalation contacts, booking rules, and the questions dispatch already asks.

Week 2: Launch Missed-Call Text-Back

Start with instant missed-call response, basic qualification, and internal alerts.

Week 3: Add Booking And CRM Logging

Connect appointment collection, CRM updates, source tracking, and follow-up status.

Week 4: Review Outcomes

Look at response rate, booked jobs, dead leads, emergency routing accuracy, and the questions customers keep asking.

Then tune the workflow.

Do not start by automating everything. Start by protecting the moment where money is currently escaping.

Where Video Can Help

HVAC buyers often hesitate because they do not know what happens next.

They may wonder:

Is there a service fee?
How fast can someone arrive?
Is this repair or replacement?
Will I get pressured into a new system?
Can I trust this company in an emergency?

Short video assets can help here.

For example:

what happens after an emergency service request
how repair vs replacement is diagnosed
what to check before the technician arrives
why maintenance plans prevent emergency calls
a short owner introduction for high-value replacement leads

The AI workflow can send the right video at the right moment. The video builds trust. The automation keeps the lead moving.

The Bottom Line

For HVAC companies, AI works best when it is attached to a real business moment.

A homeowner needs help. The phone is busy. The next useful response decides who gets the job.

That is the moment worth automating.

The workflow should reply instantly, qualify urgency, prepare dispatch, log the lead, follow up, and support the sale with useful proof.

That is a stronger story than a generic AI chatbot because it is tied to a specific revenue leak.

Originally published on AIEmployees:
https://aiemployees.us/blog/hvac-missed-call-ai-workflow

Stop Teaching Terminal Commands. Teach Terminal Workflows.

Alex Shev — Mon, 01 Jun 2026 15:35:38 +0000

Most terminal education teaches commands.

That makes sense at the beginning.

You need to know what grep does. You need to know how find works. You need to understand pipes, redirects, exit codes, environment variables, and shell scripts.

But after a while, the command is not the hard part.

The hard part is the workflow.

Not:

grep -R "TODO" .

But:

Inspect the repo.
Find the risky files.
Decide what needs changing.
Run the smallest useful command.
Verify the result.
Recover cleanly if the command was wrong.

That is the part most people are not taught.

And it is also the part AI agents need most.

Commands are vocabulary

Knowing terminal commands is useful.

But commands are vocabulary.

Workflows are how you actually get work done.

A beginner asks:

What command lists files?

A more experienced developer asks:

What am I trying to learn from the filesystem, and what is the safest way to inspect it?

Those are different questions.

For example, this command is easy to memorize:

ls

But the real workflow might be:

pwd
ls -la
find . -maxdepth 2 -type f | head
git status --short

That sequence tells you where you are, what is around you, what kind of project you are in, and whether the workspace is already dirty.

The command is small.

The judgment around the command is the skill.

A terminal workflow has stages

I like this simple model:

inspect -> decide -> run -> verify -> recover

That pattern shows up everywhere.

1. Inspect

Before you change anything, learn the shape of the problem.

pwd
git status --short
find . -maxdepth 2 -type f | sort | head -50

This is not busywork.

It prevents the most common terminal mistake: running the right command in the wrong place.

2. Decide

Once you inspect, choose the smallest useful action.

Do not start with the most powerful command.

Start with the command that gives you more information or makes a reversible change.

For example:

git diff -- path/to/file

before:

git add .

Or:

ffprobe input.mp4

before:

ffmpeg -i input.mp4 output.mp4

3. Run

Run the command with a clear expectation.

You should know what success looks like before you press Enter.

Bad:

Let's try this and see what happens.

Better:

This should produce one MP4 in the output folder, keep the source file unchanged, and exit non-zero if the input is invalid.

4. Verify

The command finishing is not the same as the workflow being done.

If you converted a video, inspect the output.

ffprobe output.mp4

If you changed code, run a relevant test.

npm test

If you edited content, check the final rendered page, not just the local markdown.

Verification is where a terminal habit becomes a production workflow.

5. Recover

Every useful workflow needs a recovery path.

What happens if the command fails?

What happens if it succeeds but produces the wrong output?

What happens if the workspace already had unrelated changes?

For example:

git diff
git restore --staged .

or:

mkdir -p output_failed
mv broken-output.mp4 output_failed/

Recovery should not be improvised after something breaks.

It should be part of the workflow.

Why this matters more with AI agents

AI agents are very good at discovering commands.

They can usually find the right shell syntax faster than a human can.

But they can still fail in familiar ways:

running commands before inspecting the project
using broad commands when a narrow one would do
trusting success output too early
overwriting files without a recovery plan
skipping platform-specific verification
treating a tool capability as a finished workflow

That is why "give the agent terminal access" is not enough.

Tool access gives the agent hands.

The workflow tells the agent what careful work looks like.

Example: teaching `grep` vs teaching search

You can teach someone this:

grep -R "stripe" .

That is a command.

But a real search workflow might be:

git status --short
find . -maxdepth 3 -type f | sort | head -100
grep -R --exclude-dir=node_modules --exclude-dir=.git "stripe" .
grep -R --include="*.ts" --include="*.tsx" "createCheckout" .

The difference is not just syntax.

The workflow says:

check the workspace first
avoid dependency folders
search broadly, then narrow by file type
search both product terms and implementation terms
do not edit until you know where the real boundary is

That is what developers actually do.

The command is only one piece.

Example: teaching `ffmpeg` vs teaching media prep

You can teach:

ffmpeg -i input.mov output.mp4

That is fine for a demo.

But if the file needs to be uploaded to a platform, the workflow matters more:

Inspect input.
Check duration, codec, pixel format, audio, and dimensions.
Convert to a safe default.
Inspect output.
Check file size.
Upload.
Verify the real platform preview.
Publish.
Verify the final post.

The important lesson is not "use FFmpeg."

The important lesson is:

Never trust a media conversion until the destination platform accepts it.

That is workflow knowledge.

This is where Terminal Skills fits

Terminal Skills is useful because it gives agents a way to package workflows, not just commands.

A good skill does not only say:

Run this command.

It says:

Use this when the task looks like this.
Inspect these inputs.
Run these steps.
Stop in these cases.
Verify these outputs.
Report the result in this format.

That is the missing layer between raw tool access and reliable automation.

For example, a media skill can teach an agent how to prepare upload-safe video.

A Git skill can teach an agent how to inspect a dirty worktree without destroying user changes.

A deployment skill can teach an agent how to build, test, deploy, and verify a live URL.

The point is not that the terminal becomes easier.

The point is that the workflow becomes repeatable.

A useful skill has a definition of done

This is the part I care about most.

A command can finish successfully and still not solve the problem.

A skill should define done.

For a code change:

Done means the targeted files were changed, tests passed, no unrelated files were touched, and the result was summarized with exact file paths.

For a video conversion:

Done means the output file is readable, uses the expected codec and pixel format, is under the target size, and has been accepted by the upload composer.

For a content workflow:

Done means the draft exists, the links work, the target platform format is respected, and publishing approval was recorded.

That last line matters.

In real work, verification and approval are part of the system.

They are not optional admin details.

The better way to teach terminal work

I still think people should learn commands.

But I would not stop there.

Teach commands inside workflows.

Instead of:

Here are 20 useful Linux commands.

Teach:

Here is how to inspect an unfamiliar repo.
Here is how to safely search a codebase.
Here is how to prepare a video for upload.
Here is how to debug a broken script.
Here is how to verify a deployment.
Here is how to recover after a bad command.

That is closer to how developers actually work.

It is also closer to what AI agents need.

Because the future of terminal automation is not agents memorizing more commands.

It is agents following better workflows.

If you are building with AI agents, ask this:

What terminal task do I keep explaining from scratch?

That is probably not a prompt problem.

It is probably a workflow that should become a skill.

Disclosure: I used AI assistance to draft and edit this article, then reviewed the examples, commands, and claims before publishing.

How I Made AI Video Uploads Boring with a Terminal Skill

Alex Shev — Sat, 30 May 2026 23:18:20 +0000

AI video demos are getting easier to generate.

Publishing them is still weirdly fragile.

Last week I had a simple task: take an AI-generated demo video, attach it to a post, and publish it without the platform silently dropping the media.

The video looked fine locally.

The upload did not.

Wrong codec. Too large. Slow processing. Missing preview. No clear error. The browser said the upload was okay, but the composer did not actually register the file.

That is the kind of problem I do not want to solve from memory at 11 PM.

So I turned it into a Terminal Skill.

Not a giant automation platform. Not a magic agent prompt. Just a small repeatable workflow that takes a messy video file and produces an X-safe default MP4 with checks before and after the conversion.

Here is the use case.

The actual problem

AI video tools often export files that are technically valid but awkward for social platforms.

Common issues:

file is too large
codec is accepted by QuickTime but not by the platform
pixel format is not yuv420p
metadata is not optimized for web playback
resolution is higher than needed
audio track is missing or weird
duration is fine visually but platform processing hangs

You can fix most of this with FFmpeg.

But the problem is not knowing that FFmpeg exists.

The problem is remembering the exact flags, running them consistently, checking the output, and not trusting the browser upload until the platform shows a real preview.

That is where a Terminal Skill helps.

What I mean by a Terminal Skill

For this workflow, a Terminal Skill is a small folder with:

one script that does the conversion
one validation step before conversion
one validation step after conversion
a short SKILL.md explaining when to use it
predictable input and output paths
logs that make it obvious what happened

The important part is not the script itself.

The important part is that the workflow becomes reusable by a human or an agent without rediscovering the rules every time.

The skill answers:

When should I use this?
What input does it expect?
What output should it produce?
How do I know it worked?
When should I stop instead of publishing?

That last question matters a lot.

For external platforms, "the command succeeded" is not the same as "the post is safe to publish."

The folder structure

I kept the structure boring:

x-safe-video/
  SKILL.md
  make-x-safe.sh
  examples/
  output/

The script does the mechanical work.

The SKILL.md documents the operating rules:

# X-Safe Video

Use this when preparing generated video for X/Twitter upload.

Input:
- MP4, MOV, or WebM
- preferably under 2 minutes

Output:
- MP4
- H.264 video
- AAC audio if audio exists
- yuv420p pixel format
- faststart metadata
- scaled down if needed

Stop if:
- ffprobe cannot read the file
- output has no video stream
- output is larger than the target platform limit
- upload composer does not show a real video preview
- platform does not show Uploaded 100%

That is the difference between a script and a skill.

A script says:

Run this command.

A skill says:

Here is the workflow, the boundary, and the definition of done.

The conversion script

Here is the simplified version.

#!/usr/bin/env bash
set -euo pipefail

INPUT="${1:?Usage: ./make-x-safe.sh input-video}"
OUTDIR="${OUTDIR:-./output}"
mkdir -p "$OUTDIR"

if [[ ! -f "$INPUT" ]]; then
  echo "Input file not found: $INPUT" >&2
  exit 1
fi

BASENAME="$(basename "$INPUT")"
NAME="${BASENAME%.*}"
OUTPUT="$OUTDIR/${NAME}_x_safe.mp4"

echo "Inspecting input..."
ffprobe -v error \
  -select_streams v:0 \
  -show_entries stream=codec_name,width,height,pix_fmt,duration \
  -of default=noprint_wrappers=1 \
  "$INPUT"

echo "Converting to X-safe MP4..."
ffmpeg -y -i "$INPUT" \
  -vf "scale='min(1280,iw)':-2" \
  -c:v libx264 \
  -profile:v high \
  -pix_fmt yuv420p \
  -preset medium \
  -crf 23 \
  -movflags +faststart \
  -c:a aac \
  -b:a 128k \
  "$OUTPUT"

echo "Inspecting output..."
ffprobe -v error \
  -select_streams v:0 \
  -show_entries stream=codec_name,width,height,pix_fmt,duration \
  -of default=noprint_wrappers=1 \
  "$OUTPUT"

BYTES=$(wc -c < "$OUTPUT")
MB=$((BYTES / 1024 / 1024))

echo "Output: $OUTPUT"
echo "Size: ${MB}MB"

This is not the most advanced FFmpeg command in the world.

That is the point.

The goal is not to make the cleverest media pipeline. The goal is to make a reliable default that works under pressure.

Why these flags matter

The important pieces:

-c:v libx264

H.264 is still the safest default for social uploads.

-pix_fmt yuv420p

This avoids the classic "works locally, fails elsewhere" problem with pixel formats.

-movflags +faststart

This moves metadata to the beginning of the file so web playback can start faster.

-vf "scale='min(1280,iw)':-2"

This keeps smaller videos unchanged and scales oversized ones down to a practical width.

-crf 23

Good enough quality without creating a monster file.

Could I tune this per video? Yes.

Do I want to think about that every time I need to publish a 20-second AI demo? No.

The verification step is the real skill

The conversion is only half the workflow.

The platform check matters more.

My rule now:

Do not trust "upload succeeded."
Trust only the composer state.

For an AI video post, I want to see:

video preview visible
upload progress completed
platform disclosure selected if needed
post button enabled
final published post shows the video

If the browser automation says the file was uploaded but the composer does not show the video, the workflow stops.

That sounds obvious, but this is where a lot of automation breaks.

It checks the API call or file input state, not the actual user-facing publishing state.

The skill's job is to keep that distinction explicit.

Making it agent-friendly

The next step is making the workflow easy for an AI agent to use.

That means the skill needs plain instructions:

## Agent Instructions

1. Run `./make-x-safe.sh <video>`.
2. Read the output path from stdout.
3. Confirm `ffprobe` shows:
   - codec_name=h264
   - pix_fmt=yuv420p
4. Check file size.
5. Upload through the real platform composer.
6. Verify visual preview before posting.
7. After posting, open the final URL and verify the video is embedded.

Notice what is missing:

No vague "make it work."

No "post when ready."

No giant prompt with 40 edge cases.

The skill gives the agent a small operating procedure with a clear stop condition.

That is much easier to trust.

What changed

Before the skill:

Generate video.
Try upload.
Watch it fail.
Search old commands.
Re-encode.
Try again.
Hope the preview appears.

After the skill:

Generate video.
Run one command.
Check output.
Upload.
Verify preview.
Publish.
Verify final post.

The workflow is not glamorous.

It is better than glamorous: it is boring.

And boring is what I want from production media prep.

The bigger lesson

This is why I keep coming back to Terminal Skills.

A useful AI workflow is usually not one huge autonomous agent.

It is a set of small, documented, reusable capabilities:

prepare a video for upload
inspect a repo
generate thumbnails
validate a draft
resize images
check links
publish only after approval

Each skill removes one fragile piece of manual memory.

Each skill gives the agent a narrower job.

Each skill creates a cleaner definition of done.

That is the part I think a lot of AI tooling conversations miss.

The future is not just "agents can use tools."

The useful version is:

Agents can use well-defined skills with clear boundaries.

That is how the work becomes repeatable.

And for AI video uploads, repeatable beats clever every time.

If you build with AI agents, what is the workflow you keep fixing manually?

That is probably your next Terminal Skill.

Disclosure: I used AI assistance to draft and edit this article, then reviewed the workflow, commands, and claims before publishing.

Approval Gates for AI Agents: Draft Approval Is Not Publish Approval

Alex Shev — Wed, 27 May 2026 16:52:45 +0000

One of the easiest ways to make an AI agent dangerous is to give it a vague approval.

Not because the agent is malicious.

Because humans use words like "ok", "approved", and "ship it" casually.

In a normal conversation, that is fine. In an automated workflow, it can become a bug.

If an agent is drafting an article, writing a tweet, preparing a pull request, generating social posts, or touching an external platform, the question is not just:

Did the human approve this?

The better question is:

What exactly did the human approve?

That distinction matters more than most agent tooling discussions admit.

The small approval bug that becomes a big workflow problem

Imagine this simple flow:

An agent prepares 10 social posts.
The human says "looks good".
The agent publishes all 10 immediately.

Maybe that was correct.

Maybe it was not.

The human might have meant:

The copy looks good.

The agent interpreted it as:

Publish everything now.

That is not a model intelligence problem. It is a workflow design problem.

When an action leaves the local workspace, ambiguity gets expensive.

Publishing, emailing, commenting, deploying, charging a card, posting to social media, and modifying production systems should not depend on a loose interpretation of "ok."

They need explicit gates.

The approval types I separate now

For agent workflows, I like separating approval into at least four different meanings.

1. Approval to draft

This means:

Yes, prepare the thing.

The agent can research, outline, write, generate assets, create local files, and prepare a proposal.

But it cannot publish.

This is the safest default for content work.

For example:

Prepare a DEV.to draft about approval gates.

That should create a local markdown draft or an unpublished draft, depending on the workflow.

It should not post the article publicly.

2. Approval of the draft

This means:

The content direction is acceptable.

The human may be approving the argument, the structure, the tone, or the asset selection.

But that still does not automatically mean:

Publish it right now.

This is where many agent systems get sloppy.

Draft approval is not publish approval.

3. Approval to publish

This needs to be explicit.

The agent should know:

what platform
what asset or draft
whether to publish now or schedule
whether comments/replies/source attribution are included
whether the approval applies to one post or a batch

For example:

Publish this DEV.to article now.

or:

Post only the first X drafts, with the source as the first reply.

That is much safer than letting the agent infer a public action from a vague "ok."

4. Approval for automation reminders

This one is subtle.

A reminder or cron job should often prepare work, not perform external actions.

For example:

Every morning, find 3 candidate topics and ask me which one to use.

That is different from:

Every morning, publish a post.

The first one keeps the human in the loop.

The second one creates a recurring external action, which is much riskier.

Most teams should start with reminder-based automation before action-based automation.

Why this matters for CLI and agent workflows

CLI workflows make this even more important because agents can act fast.

A coding agent can edit files, run scripts, create branches, call APIs, deploy apps, write comments, and open browser sessions.

That speed is useful only if the boundaries are clear.

The workflow should define what the agent may do locally without asking and what requires a human gate.

For example, I am comfortable letting an agent do this freely:

inspect a repo
write a local draft
run tests
generate local assets
prepare a post
create a report
summarize findings

I want a stronger gate before this:

publish to DEV.to
post on X
send email
comment on Reddit
deploy to production
spend money
modify customer data

The difference is not whether the agent is capable.

The difference is whether the action is reversible, private, and low-risk.

Local work is cheap to revise.

External work creates a public or operational footprint.

A simple pattern: declare the gate in the task

One practical fix is to write the gate directly into the task.

Instead of:

Write an article about approval gates.

Use:

Prepare a local draft only. Do not publish. Return the file path and wait for explicit publish approval.

Instead of:

Make comments for Reddit.

Use:

Prepare comment drafts only. Do not post. Recommend the safest first set and wait for approval.

Instead of:

Deploy this.

Use:

Create a preview deployment first. Do not promote to production until I explicitly approve production.

This sounds boring, but boring is good here.

Good agent workflows are often just normal operational discipline written down clearly enough that the agent cannot guess wrong.

If the workflow supports metadata, make the gate machine-readable:

gate: draft_only
external_actions: false
next_approval_required: publish_to_devto
scope: single_article

That tiny block is not bureaucracy. It gives the agent a state it can report, verify, and refuse to exceed.

The agent should report its current gate

The agent should also say what state the work is in.

For example:

Status: local draft only.
No external publication happened.
Next gate: human approval to publish.

or:

Status: posted.
Verified final URL.
No additional replies published.

This makes the workflow auditable.

It also prevents the human from having to infer what happened.

When agents are doing real work, "done" is not enough.

The agent should report:

what changed
where the artifact is
what was verified
what did not happen
what approval is needed next

That last part is important.

Good agents should not only complete tasks. They should make the boundary of the next task clear.

Batch work needs an even stronger gate

Batch publishing is where approval ambiguity gets especially risky.

If an agent prepares 25 comments, does approval mean:

publish all 25 now?
publish the safest 5?
publish one per day?
publish only after checking each target again?
publish drafts after human edits?

Those are very different actions.

For batch workflows, I like adding two fields:

Approval scope:
Cadence decision:

Example:

Approval scope: first 5 comments only
Cadence decision: publish today, one by one, stop on warning

or:

Approval scope: all 10 posts approved as drafts
Cadence decision: schedule one per day at 10 AM

That tiny bit of structure prevents a lot of mistakes.

It also gives the agent a concrete stop condition.

This belongs inside skills

This is one reason I care about reusable agent skills.

A skill should not only say:

Here is how to perform the task.

It should also say:

Here is what requires approval.
Here is what can be done locally.
Here is how to verify the result.
Here is when to stop.

That is the difference between a tool and a workflow.

A tool gives the agent power.

A skill gives the agent operating rules.

It can encode approval gates as reusable policy, not just task steps.

For example, a publishing skill should define:

draft-only mode
review mode
publish mode
source/comment behavior
verification steps
rollback or correction process
rate-limit and spam-warning stop conditions

Without that, the agent has to infer the process from the conversation.

That is exactly where mistakes happen.

The rule I use

My current rule is simple:

If the action is external, public, paid, destructive, or hard to undo, the approval must name the action.

"Looks good" is enough for a draft.

It is not enough for publication.

"Ok" is enough to continue local work.

It is not enough to spend money, post publicly, email someone, or modify production.

For those actions, the approval should be explicit:

Publish this now.
Send this email.
Deploy to production.
Post these 5 comments.
Charge this card.

The goal is not to slow the agent down.

The goal is to make speed safe.

Final thought

The fix is not complicated: write the gates down.

Make the agent report which gate it is at.

And never let draft approval silently become publish approval.

I am collecting and building practical examples of this kind of agent workflow discipline at Terminal Skills: reusable skills that teach agents not only which tools to use, but how to work safely and repeatably.

Disclosure: I used AI assistance while drafting this article, then reviewed and edited it manually.

MCP Gave AI Agents Tools. A2A Gives Them Coworkers.

Alex Shev — Mon, 25 May 2026 15:30:15 +0000

Most AI agent conversations eventually run into the same question:

What happens when one agent is not enough?

A single agent can write code, search docs, run tests, call APIs, summarize files, and generate reports.

That already feels useful.

But real work rarely fits into one neat box.

A software project might need:

one agent to research requirements
one agent to write code
one agent to generate tests
one agent to review the result
one agent to deploy or monitor the system

A customer support workflow might need:

a billing agent
a technical support agent
a sales agent
a human handoff agent

A content workflow might need:

a research agent
a writing agent
an SEO agent
an editor
a publishing assistant

At that point, the interesting problem is no longer just:

Can an agent use a tool?

It becomes:

Can agents work with each other?

That is where the A2A protocol becomes interesting.

And that is why the a2a-protocol skill on Terminal Skills is worth looking at.

MCP vs A2A in one sentence

MCP gave agents tools.

A2A gives agents coworkers.

That is the simplest way I think about it.

MCP, or Model Context Protocol, is mostly about connecting an agent to tools, APIs, files, databases, search systems, and external data sources.

A2A, or Agent2Agent, is about connecting one agent to another agent.

The difference matters.

If an agent needs to query a database, call a calendar API, or inspect a repo, MCP is a good fit.

If an agent needs to delegate work to another autonomous agent with its own capabilities, state, task lifecycle, and output format, A2A is the better mental model.

A tool usually does one specific thing.

An agent can own a whole domain of work.

Why agents need a collaboration layer

Right now, many agent workflows are still stitched together with prompts.

Something like:

First research the topic.
Then write a draft.
Then review it.
Then create a final version.

That can work for small tasks.

But it gets messy as soon as the workflow becomes more serious.

What happens when research takes five minutes?
What happens when the writing agent needs structured data, not a paragraph?
What happens when the reviewer rejects the output?
What happens when the task needs human input?
What happens when the work should continue asynchronously?

At that point, a prompt chain is not enough.

You need something closer to a protocol.

The A2A model introduces concepts like:

an Agent Card for discovery
declared skills and capabilities
task lifecycle states
messages between agents
artifacts as outputs
streaming updates
push notifications
cancellation
structured data exchange

That sounds boring in the best possible way.

Boring protocols are what turn demos into infrastructure.

The Agent Card is the underrated part

One of the most useful ideas in A2A is the Agent Card.

An Agent Card is basically a description of what an agent is, where it lives, and what it can do.

It describes identity, capabilities, skills, endpoints, and auth without exposing the agent's internal tools, memory, or private state.

It can include:

the agent name
description
endpoint URL
version
capabilities
skills
input modes
output modes
authentication requirements

A standard discovery endpoint like this:

/.well-known/agent-card.json

may not sound exciting.

But it solves a real problem.

If agents are going to collaborate, they need to know who they are talking to.

A coding agent should be able to discover a code review agent.
A support router should be able to discover a billing agent.
A research agent should be able to discover a writer agent.

Without a discovery layer, every multi-agent workflow becomes custom glue.

With one, agents can start to behave more like services.

Example: a code pipeline made of agents

Imagine a simple software pipeline.

You do not want one giant agent doing everything.

Instead, you split the workflow:

Code writer generates the implementation.
Test writer creates tests.
Code reviewer checks both.
Orchestrator coordinates the flow.

Each agent can have a narrow responsibility.

The code writer does not need to know everything about test strategy.
The test writer does not need to own product requirements.
The reviewer does not need to write the initial implementation.

This makes the workflow easier to inspect.

If the tests are weak, improve the test agent.
If the review is shallow, improve the review agent.
If the handoff fails, improve the orchestrator.

That is much cleaner than debugging one giant prompt with five hidden roles inside it.

Example: a customer support router

A2A also makes sense for support.

A support router agent receives a customer message:

I was charged twice and my account still says inactive.

The router should not try to solve everything itself.

It can delegate:

billing question -> billing agent
account activation -> technical agent
refund eligibility -> policy agent
unclear or sensitive issue -> human handoff

The router's job is classification, coordination, and response assembly.

The specialized agents own their own domains.

This is how real teams work.

Not everyone does everything.

The interesting part is making agents follow that same pattern.

Where Terminal Skills fits

This is where Terminal Skills becomes useful.

The a2a-protocol skill is not just a link to a spec.

It gives an AI coding agent a practical operating guide for building A2A systems:

when to use A2A
how to define an Agent Card
how to build a server
how to build a client
how to handle task states
when to use streaming
how to orchestrate multiple agents
how A2A differs from MCP
what implementation guidelines to follow

That matters because agents often fail not from lack of intelligence, but from lack of workflow structure.

A model may understand A2A in general.

But a skill gives it a repeatable path:

terminal-skills install a2a-protocol

After that, the agent has a focused reference for the task instead of relying on vague memory or generic web knowledge.

This is the bigger idea behind Terminal Skills:

Agents do not just need more context. They need reusable operational instructions.

A2A is not a replacement for MCP

It is tempting to turn every new protocol into a winner-takes-all comparison.

I do not think that is the right framing here.

A2A and MCP solve different problems.

A practical way to separate them:

Need	Better fit
Call a tool or API	MCP
Read from a data source	MCP
Give an agent access to external systems	MCP
Delegate a task to another agent	A2A
Discover agent capabilities	A2A
Coordinate long-running agent work	A2A

MCP is agent-to-tool.

A2A is agent-to-agent.

In real systems, you probably want both.

An agent might use MCP internally to access tools, while exposing an A2A interface so other agents can delegate work to it.

That combination is where things get interesting.

What makes this useful for developers

For developers, the value is not the protocol acronym.

The value is fewer fragile workflows.

Instead of hardcoding every handoff, you can start thinking in terms of:

discoverable agents
declared capabilities
explicit task states
structured messages
cancellable work
streaming progress
artifacts as outputs

That is closer to software engineering than prompt engineering.

And honestly, that is the point.

The next generation of agent systems will not be built from one giant prompt.

They will look more like networks of specialized workers with clear contracts between them.

Some of those workers will call tools.

Some will call other agents.

The quality of the system will depend less on one model being magical and more on whether the handoffs are well designed.

The small shift that matters

The first wave of AI agents was about giving models tools.

That was a huge step.

But tools are not the whole story.

If agents are going to handle real work, they need coordination.
They need delegation.
They need discovery.
They need contracts.
They need ways to say:

I can do this task.
Here is how to call me.
Here is what I return.
Here is how I report progress.
Here is how I fail.

That is why A2A is worth watching.

Not because every project needs a multi-agent architecture today.

Most do not.

But because the direction is clear:

Agents are moving from isolated assistants to interoperable workers.

MCP gave agents tools.

A2A gives them coworkers.

And skills like a2a-protocol help agents learn how to build that future without starting from a blank prompt.

If you want to try it, the skill is here:

https://terminalskills.io/skills/a2a-protocol

Install:

terminal-skills install a2a-protocol

Then ask your coding agent to build one tiny A2A loop: Agent Card -> server -> client -> delegated task.

Start small.

One focused agent.
One clear capability.
One verifiable handoff.

That is usually where the real workflow begins.