{"id":17216,"date":"2026-07-21T16:18:50","date_gmt":"2026-07-21T16:18:50","guid":{"rendered":"https:\/\/dmsretail.com\/RetailNews\/make-ai-agent-skills-that-work-the-way-you-do\/"},"modified":"2026-07-21T16:18:50","modified_gmt":"2026-07-21T16:18:50","slug":"make-ai-agent-skills-that-work-the-way-you-do","status":"publish","type":"post","link":"https:\/\/dmsretail.com\/RetailNews\/make-ai-agent-skills-that-work-the-way-you-do\/","title":{"rendered":"Make AI Agent Skills that Work the Way You Do"},"content":{"rendered":"

\"Retail<\/a><\/p>
\n<\/p>\n

\n

So, you\u2019re a network engineer. You live in the CLI. You SSH into your devices. You work on your tickets. You read your logs. You get things done the way you\u2019ve always gotten them done.<\/p>\n

And like everyone else right now, you\u2019re asking yourself how AI fits into your daily routine.<\/p>\n

Imagine this. What if you could teach AI how you<\/em> work, right inside the environment you already live in? What if you could hand off the repeatable stuff while you stay in the loop\u2014without needing to learn a stitch of code?<\/p>\n

No more imagining. It\u2019s an AI reality, and this AI Break<\/em> will teach you how. Plus, it doesn\u2019t take moving your entire work life into some new tool\u2014just your workflow, your terminal, and an agent that works the way you do.<\/p>\n

It\u2019s called an agent skill. <\/strong>The easiest way to think about agent skills is the way you think about your own.<\/p>\n

You picked up a packet capture trick years ago, and it\u2019s been on your tool belt ever since. Learn it once, reach for it forever. An agent skill is the same thing, passed on to your AI.<\/p>\n

What is an agent skill, really?<\/strong><\/h2>\n

A skill teaches your AI how to handle a specific task the way you\u2019d handle it. Instead of re-explaining your process every conversation, you teach it once and get the payoff every time it runs.<\/p>\n

Think about years of expertise in your head right now. For example, a ticket lands and you already know the moves: Check this before you touch that. Pull these logs. Verify in a set order. You\u2019ve never written it down because you\u2019ve never had to. It just lives rent-free<\/em> in your head. A skill is your expertise, written down, one time, for the AI.
\u00a0<\/p>\n

Why agent skills are better than prompts:<\/strong><\/h3>\n
    \n
  • A prompt is disposable.<\/strong> Close the window, and it\u2019s gone. Next time, you start over.<\/li>\n
  • An agent\u2019s skill sticks around.<\/strong> It loads when the work calls for it and runs the same way every time.<\/li>\n
  • Skills stack.<\/strong> You build small ones that each do a job well, and the agent grabs the right one when the moment calls for it. Over time, you\u2019ve got a whole library working together.<\/li>\n
  • Skills can be shared. The benefits can become exponential by sharing across teams. Think repository of tried-and-true best practices.<\/li>\n
  • MCP gives it hands.<\/strong> On its own, a skill is just knowledge. Wire in MCP and it can pull the real ticket, read the live config, and act on what it finds, with you approving every step that matters.<\/li>\n<\/ul>\n

    How agent skills are built<\/strong><\/h2>\n

    \"Infographic

    A skill is a directory. SKILL.md<\/span><\/span><\/code>\u00a0does the work: YAML frontmatter on top, a Markdown body underneath.<\/p>\n

    The frontmatter is metadata. Two fields to start:<\/p>\n

      \n
    • name<\/span><\/span><\/code>: kebab-case, matched to the folder<\/li>\n
    • description<\/span><\/span><\/code>: what the skill does and when to load it, under 1024 characters<\/li>\n<\/ul>\n

      Don\u2019t sleep on that description<\/span><\/span><\/code>. It\u2019s the only part the agent sees by default, so it decides whether the rest even loads.<\/p>\n

      That\u2019s progressive disclosure<\/em>: The body loads only when it\u2019s relevant and reference files only when the agent reaches for them. Too vague, and the skill never wakes up. Too broad, and it fires when you don\u2019t want it to.<\/p>\n

      The body is your workflow, plus three optional folders:<\/p>\n

        \n
      • scripts\/<\/span><\/span><\/code>: code the agent runs<\/li>\n
      • references\/<\/span><\/span><\/code>: docs it pulls on demand<\/li>\n
      • assets\/<\/span><\/span><\/code>: templates it works from<\/li>\n<\/ul>\n

        This is where prompt engineering earns its keep. The body is a prompt, and the agent does what it says. \u201cGenerate the report\u201d leaves it guessing. Spell out the format and the sections, and you get the same result every time. For steps that can\u2019t drift, call a script instead of trusting ever-changing prose.<\/p>\n

        And here\u2019s the part that should make every network engineer sit up. That scripts\/<\/span><\/span><\/code> folder is where your automation comes back to life. The Ansible playbooks you wrote for deployments, the Terraform plans that stand up your infrastructure, the scripts you\u2019ve built over years of network ops: none of it is wasted. You drop it in scripts\/<\/span><\/span><\/code>, and the agent runs it on your terms, when your skill tells it to. Your automation doesn\u2019t compete with AI. It becomes the tool the agent reaches for. The work you already did just got more valuable.<\/p>\n

        Let the AI come to you<\/strong><\/h2>\n

        The core idea is not locked to one vendor. Agent skills are an open standard. This means the basic building blocks can move across skills-compatible agents. The details may change from tool to tool, but the pattern holds.<\/p>\n

        To build something real, though, I must pick one. For my use case, my AI of choice is Anthropic\u2019s Claude, running in Claude Code. And the reason matters more than the brand.<\/p>\n

        Most AI shows up as a chat window or a panel bolted onto an IDE. Useful, but it\u2019s not where we work. We work in the terminal. We SSH into boxes, run show<\/span><\/span><\/code> commands, pipe output through grep, and live at the prompt.<\/p>\n

        Claude Code runs right there in the CLI. The agent meets you in your environment instead of asking you to move into its. No new IDE to learn. No \u201crewrite your life in Python first.\u201d You stay at the terminal you already know, and the AI comes to you.<\/p>\n

        That\u2019s the unlock for network engineers. You don\u2019t have to become a developer to get the payoff. You bring your skill, your terminal, and your judgment, and the agent works alongside you right where you already are.<\/p>\n

        From here, the filenames get Claude-flavored. The pattern still maps to whatever agent you run. Only the names change.<\/p>\n

        Meet Iris, an agent skill for network operations<\/strong><\/h2>\n

        I built one. It\u2019s called Iris: the network agent that keeps an eye on your network. It also happens to be my daughter\u2019s name, so it felt fitting for a skill that watches over things. It\u2019s on my GitHub. It\u2019s a working agent skill for network operations, and you can clone it today<\/strong>.<\/p>\n

        The idea is simple. You still own every decision. Iris handles the work around those decisions: pulling device state, checking it against your source of truth, running pre-condition checks, drafting the change, verifying it after, and writing it up in the ticket. Iris is built from the exact blocks we just covered. Here\u2019s how they map.<\/p>\n

        `CLAUDE.md` is the operating contract.<\/strong> Iris\u2019s persona and its guardrails in one file. The rules are the part that matters:<\/p>\n

          \n
        • Discover before you assume<\/li>\n
        • Verify before you change<\/li>\n
        • Never push a change without explicit approval<\/li>\n
        • Stop if something looks wrong<\/li>\n
        • Close the ticket with enough detail that the next engineer can reconstruct what happened<\/li>\n<\/ul>\n

          You\u2019re handing an agent access to your network, so those rules aren\u2019t decoration. They\u2019re what keep it from doing something catastrophic at 2 a.m.<\/p>\n

          `SKILL.md` is the brain.<\/strong> The workflow Iris runs on every ticket, in the same order every time:<\/p>\n

          \"Horizontal

          The discipline doesn\u2019t change whether you\u2019re touching Catalyst CLI, the Meraki dashboard, or a Terraform plan. And human-in-the-loop is baked into the workflow itself. Iris proposes a plan and waits for your \u201cyes\u201d before it touches anything. It\u2019s not a setting you remember to turn on.<\/p>\n

          The `.claude` folder and `.mcp.json` are the connections.<\/strong> This is where Iris gets its hands. The MCP wiring points at the systems you run. You don\u2019t need all of them, but the more you connect, the more Iris can do:<\/p>\n

            \n
          • Ticketing<\/strong>: ServiceNow, Jira<\/li>\n
          • Device management<\/strong>: CML, Meraki, Catalyst Center, direct CLI<\/li>\n
          • Source of truth<\/strong>: NetBox<\/li>\n
          • Observability<\/strong>: Splunk, ThousandEyes<\/li>\n<\/ul>\n

            Two more folders are worth knowing:<\/p>\n

              \n
            • environment\/<\/span><\/span><\/code> is where Iris learns what your network looks like on first run, pulling from your MCPs, your docs, and any discovery scripts you drop in.<\/li>\n
            • automation\/<\/span><\/span><\/code> is that tool belt from earlier. Drop your playbooks and scripts in, and Iris learns them, tags each one read-only or state-changing, and only runs the state-changing ones you approve.<\/li>\n<\/ul>\n

              \"Animated

              Now picture a skill on the job. A ticket comes in: a new VPC needs to reach an on-prem staging environment. Normally you are the one reading the ticket, checking what\u2019s deployed, working out the routing and the firewall path, then SSHing in to make it happen.<\/p>\n

              With Iris, the AI agent is doing most of the work:<\/p>\n

                \n
              • Restates the ticket in plain language and confirms before touching anything.<\/li>\n
              • Discovers what\u2019s actually out there instead of assuming.<\/li>\n
              • Validates pre-conditions and stops if a check fails.<\/li>\n
              • Proposes a plan that includes the exact commands, exact API calls, and expected outcomes.<\/li>\n<\/ul>\n

                You approve or push back, because you\u2019re the engineer, and you know what right looks like. Only then does the agent execute, verify, and document.<\/p>\n

                You never left the terminal. You never stopped being the one in charge. The agent handled the busywork while you kept your eyes on the network.<\/p>\n

                \"Animated

                Build your own agent skill<\/strong><\/h2>\n

                Here\u2019s the thing about Iris: it\u2019s a starting point, not a destination. It works the way you<\/em> work. Your network is different, your process is different, your guardrails are different.<\/p>\n

                Take it and make it yours:<\/p>\n

                  \n
                • Clone the repo.<\/strong> It\u2019s on GitHub, MIT licensed. git clone<\/span><\/span><\/code> and you\u2019re in.<\/li>\n
                • Edit `CLAUDE.md` and `SKILL.md`.<\/strong> Change the rules to match your shop. Change the workflow to match how you and your network operate.<\/li>\n
                • Wire your own `.mcp.json`.<\/strong> Point it at your ticketing, your devices, your source of truth. Connect what you\u2019ve got.<\/li>\n
                • Drop in your automation.<\/strong> Those playbooks and scripts you already trust go in automation\/<\/span><\/span><\/code>, and the agent runs them on your say-so.<\/li>\n<\/ul>\n

                  If you want to go deeper on the skill format itself, Anthropic\u2019s guide to building skills is the best reference out there, and there\u2019s a skill-creator that walks you through building one from scratch. I\u2019ll link both below.<\/p>\n

                  The bigger point is this. Your job is not going away, and you\u2019re not being replaced by an agent that pushes config while you sleep. What\u2019s changing is how the work gets done. The engineers who get ahead are the ones who teach the AI their craft and stay in the loop to catch what it misses. Your knowledge is what makes any of this safe. The skill is just how you hand some of it off.<\/p>\n

                  Clone Iris, break it, rebuild it, and make it work the way you do. That\u2019s the whole point. A tool belt only works if it fits.<\/p>\n

                  \u00a0<\/p>\n\n

                  Frequently asked questions about agent skills<\/em><\/strong><\/h2>\n

                  \u00a0<\/p>\n

                  What is an agent skill?<\/strong><\/h3>\n

                  An agent skill is a reusable set of instructions that teaches your AI how to handle a specific task\u2014your way, every time. The easiest way to think about it: you\u2019ve spent years developing instincts for your job. A ticket lands and you already know the moves. An agent skill is that expertise, written down once, so your AI can run it the same way every time without you re-explaining it from scratch.
                  \u00a0<\/p>\n

                  How do I create an agent skill?<\/strong><\/h3>\n

                  A skill is a directory, and SKILL.md<\/span><\/span><\/code> does the work. Start with YAML frontmatter\u2014a name<\/span><\/span><\/code> and a description<\/span><\/span><\/code>\u2014then write your workflow in Markdown underneath. That\u2019s the brain. From there, three optional folders extend what it can do: scripts\/<\/span><\/span><\/code> for code the agent runs, references\/<\/span><\/span><\/code> for docs it pulls on demand, and assets\/<\/span><\/span><\/code> for templates it works from. The description field matters more than anything else\u2014it\u2019s the only part the agent sees by default, and it decides whether the rest even loads.
                  \u00a0<\/p>\n

                  What\u2019s the difference between an agent skill and a prompt?<\/strong><\/h3>\n

                  A prompt is disposable. Close the window and it\u2019s gone. Next time, you start over. A skill sticks around\u2014it loads when the work calls for it and runs the same way every time. Skills also stack. You build small ones that each do one job well, and over time you\u2019ve got a library the agent pulls from automatically. A prompt is a one-time conversation. A skill is institutional knowledge.
                  \u00a0<\/p>\n

                  Can agent skills be shared across teams?<\/strong><\/h3>\n

                  Yes\u2014and that\u2019s where they get powerful. One engineer builds a skill that reflects years of hard-won process, and the whole team inherits it. Think of it as a repository of tried-and-true best practices. The knowledge that used to live in one person\u2019s head, now accessible to everyone who needs it.
                  \u00a0<\/p>\n

                  Do I need to know how to code to build an agent skill?<\/strong><\/h3>\n

                  No. You can teach your AI how you work right inside the environment you already live in\u2014no coding required. And if you\u2019ve already got automation built up over the years\u2014Ansible playbooks, Terraform plans, scripts from a career in network ops\u2014none of it is wasted. Drop it into the scripts\/<\/span><\/span><\/code> folder and the agent runs it on your terms, when your skill tells it to. Your existing work doesn\u2019t compete with AI. It becomes the tool the agent reaches for.<\/p>\n

                  \u00a0
                  \u00a0<\/p>\n

                  \n

                  Let the AI Agent Fix the Drift<\/p>\n<\/blockquote>\n