Source: Dev.to

Prompting vs. Systems

I’ve been spending a lot of time lately trying to figure out where “prompting” ends and “systems” begin.

Most of us start our AI journey in a chat box. We learn to ask better questions and provide more context, eventually building massive, complex prompts. Yet, even the best prompts often miss the mark.

---

The Friction Remains

I expected the friction to disappear when I moved to Claude Code because the tool lives in my local environment. It didn’t work out that way. The overhead remains surprisingly high. Even with local access, if you want Claude to plan and execute a complex task, you still end up defining a massive instruction set for every single run. It becomes a tedious ritual of:

1. Specifying every parameter for the task.
2. Reminding the agent what to watch for.
3. Defining exactly how to take specific actions.

It feels less like doing the actual work and more like managing a micromanager.

---

From SOPs to Skills

When I started using Claude Code last year, “Skills” weren’t really on the radar yet. My workaround was building a library of SOPs (Standard Operating Procedures). This was a necessity because I work with legacy systems—specifically ancient Linux builds and fragile ecosystems that are decades old.

• Before every task, I had to manually point Claude toward that world.
• I would identify which SOPs were relevant, tell Claude Code to read them, and then wait for it to “load” that logic before it could finally act.

Recently, I stumbled upon Claude Skills. I’ve found them to be much more effective at handling this orchestration without the manual baggage of the SOP approach.

---

What a Skill Is (and Isn’t)

I’m not writing this as an expert who has mastered the architecture. I’m an explorer in the middle of an “Aha!” moment.

The first thing I had to unlearn is the idea that a Skill is just a “saved prompt.” It isn’t.

A normal prompt tells Claude what to do once. A Skill defines how Claude should operate across many related situations. It is a workflow abstraction layer that encodes agentic behavior into a reusable unit, including conditional logic, tool choices, and specific reasoning stages.

---

Technical Structure of a Skill

A Skill is essentially a folder. The magic lives in its internal structure:

my-skill/
│
├─ SKILL.md          ← the brain (metadata + routing)
│
├─ context/          ← specialist files (domain‑specific logic)
│   ├─ parsing.md
│   └─ reporting.md
│
└─ tools/            ← optional tool definitions

1. Front Matter (Identity)

A brief YAML block at the top of SKILL.md tells Claude what the skill is and how it can be discovered.

---
name: financial‑analysis
description: Parses financial reports and generates actionable insights.
version: 1.2.0
---

2. Main Body (The Router)

The body acts as a traffic controller. It does not hold all the instructions; instead, it routes tasks:

## Router

- **If** the input is a CSV → load `context/parsing.md` and use `tools/csv‑parser`.
- **If** the input is a PDF → load `context/pdf‑extraction.md`.
- **If** the expense total exceeds budget → load `context/planning‑recommendation.md`.

3. Contextual Files (The Specialists)

Separate files contain the deep, domain‑specific logic. Only the files needed for the current sub‑task are loaded, implementing Progressive Disclosure.

---

Benefits of Skills

• Token Savings – Progressive disclosure can reduce token usage by 60 %–70 % because only a tiny metadata snippet is loaded initially.
• Improved Reasoning – 2025 research on “Context Rot” shows that irrelevant information can drop reasoning performance by 13 %–85 %. Limiting context improves both cost and quality.
• Conditional Complexity – Skills shine when you need if/else flows, tool selection, and multi‑step reasoning (e.g., a financial workflow that parses, analyzes, decides, and generates an Excel report).

If you only need a fixed tone or a simple JSON output, a template is fine. Over‑engineering a Skill for a trivial task wastes effort.

---

Example: A Financial Workflow Skill

Input:  Monthly expense report (CSV or PDF)
Action: Parse expenses → analyze patterns
Condition:
  - If spending > budget → load "Planning Recommendation" context
Output:
  - Generate Excel file
  - Trigger tool to email summary to accountant

This Skill can orchestrate the entire flow automatically, without re‑prompting for each sub‑task.

---

Ongoing Exploration (Next Articles)

1. Observability – How to see the Skill flow in action, know when a specific context is triggered, and measure output optimization.
2. Versioning – Strategies for updating a Skill without breaking dependent workflows.
3. Dynamic Tool Selection – Claude uses a search pattern to manage massive libraries; I’m exploring custom search strategies for my own Skills.

---

Stay tuned for deeper dives into each of these topics.

Introduction

This is just the beginning. I’m currently building custom skills for my day‑to‑day work. While I can’t share the proprietary details, I’ll be documenting the broader architectural lessons I learn along the way.

Openclaw Public Skills

I’ll also be publishing public skills for Openclaw. It uses a similar system, but I’ve noticed it tends to be context‑heavy, which leads to significant token waste. I’m looking at how to port Claude’s efficient patterns over to Openclaw to lean out that workflow.

Call for Collaboration

I’m curious about what you’re building. What messy, repetitive workflows are you trying to turn into “systems” right now? If you’ve managed to incorporate skills into your day‑to‑day, I’d love to hear how it’s changing your approach.