From "Prompt Repeater" to AI Workflow: After Reading "Illustrated Skill", I Summarized 7 Chapters of Essence and 10 Practical Methods

This article is a reading summary and practical reflection on Teacher Baoyu's "Illustrated Skill: A Practical Guide to AI Efficiency." The content is not a simple abbreviation of the original book but a reorganization around "Why Skill is useful, what problem each chapter solves, and how ordinary people and developers can truly use Skill well."

Preface: We Might Not Be Using AI, but Working for AI

The way many people use AI is still stuck in the following loop:

1. Copy materials into the chat box;
2. Re-explain the format, tone, and steps;
3. The AI output does not meet expectations, so add more requirements;
4. The next time a similar task comes up, start all over again.

On the surface, AI is helping us, but in reality, we spend a lot of time repeatedly pasting prompts, explaining rules, and correcting formats, becoming "prompt repeaters" ourselves.

The solution given by "Illustrated Skill: A Practical Guide to AI Efficiency" is: Don't just optimize a single conversation. Instead, encapsulate the reusable processes, rules, experiences, and tool usage methods of a task into a Skill, allowing the agent to execute stably according to the same set of methods in the future.

If I had to summarize the whole book in one sentence, I think it is:

The value of Skill is not to suddenly make the model smarter, but to turn a person's tacit experience into an explicit process that AI can execute repeatedly.

1. First, Clarify: What Exactly Is a Skill?

A Skill can be understood as a "Standard Operating Procedure" written for an AI agent. It is usually a folder containing at least one SKILL.md file. More complex Skills may also include scripts, reference materials, and templates.

my-skill/
├── SKILL.md          # Core process and rules
├── scripts/          # Deterministic operation scripts, optional
├── references/       # Reference materials read on demand, optional
└── assets/           # Static resources like templates, images, optional

The biggest difference between it and a regular prompt is not the file format, but the positioning:

Method	More Suitable for Solving What Problems
Regular Prompt	One-time, simple, highly variable tasks
Script	Tasks with fixed rules that must produce deterministic results
Skill	High-frequency, multi-step tasks that have both fixed rules and require model judgment

For example, "make this passage smoother" can be done with a single prompt; "convert dates uniformly to YYYY-MM-DD" is more suitable for a script; "read meeting minutes, identify resolutions and to-dos, generate minutes according to the company template, and save the file" is very suitable for making into a Skill.

---

2. Essence of the Book's 7 Chapters: From First Invocation to Engineering Implementation

Chapter 1: Run Your First Skill to Build the Most Intuitive Experience

Chapter 1 does not rush to explain concepts but lets the reader do a controlled experiment using "weekly report generation":

• Without using a Skill, you have to re-explain the table columns, tone, and save format every week;
• After using a Skill, you only need to provide the items completed this week, and the agent will automatically generate the weekly report according to the established standard.

The most important thing in this chapter is not learning to write a weekly report, but understanding the first layer of value of a Skill:

Turn the requirements that "need to be re-stated every time" into rules that "only need to be maintained once."

The book provides two very practical creation methods:

1. The standard is already clear: Directly tell the agent the format, process, and delivery requirements, and let it create the Skill;
2. The standard is not yet clear: First, repeatedly debug the results in a single conversation. Once satisfied, let the agent solidify the best practices into a Skill based on the complete conversation.

The second method is especially suitable for real work. Because often, we cannot fully describe "what a good result looks like" before starting, but after seeing the finished product, it's easy to judge what's wrong.

This chapter also gives a three-step troubleshooting approach when a Skill doesn't take effect:

1. Confirm the Skill is installed or enabled;
2. Confirm the current environment has reloaded the Skill;
3. Check if the description covers the user's actual way of expressing it.

These three steps also reveal a key fact: No matter how well a Skill is written, if it is not triggered correctly, it is equivalent to non-existence.

Chapter 2: Understanding Why Skill Is More Reliable Than a "Long Prompt"

Chapter 2 uses a "kitchen" analogy for the agent system, lowering the barrier to understanding:

Agent Concept	Kitchen Analogy	Function
Prompt	Customer ordering food	Tells AI the current goal
Large Model	Chef	Responsible for understanding, judging, and planning
Context	Kitchen countertop	Holds information needed for the current task, limited capacity
Tools	Knives and utensils	Allows the agent to read files, go online, execute code
Skill	Recipe	Tells the agent how to complete a task stably
Connection mechanisms like MCP	Universal socket	Allows external systems to connect in a unified way

The author believes that Skill has four evolutions compared to long prompts acting as "operation manuals":

1. On-demand loading: No need to stuff all rules into the context every time;
2. File-based workbench: Intermediate results can be saved, restored, and partially modified;
3. Workflow collaboration: Multiple Skills can be executed in series, parallel, or loops;
4. Experience compounding: Rules have only one stable source, and changes take effect continuously after a single modification.

Skill's Three-Layer Loading Mechanism

The most worthwhile concept to grasp in this chapter is the idea of "progressive loading":

1. The agent first sees the name and description of all Skills;
2. After judging a task match, it reads the corresponding SKILL.md body;
3. Only when executing a specific scenario does it continue to read references/ or run scripts/.

Therefore, description is not an ordinary introduction but the routing entry for the Skill. A practical formula is:

description = Function definition + Trigger scenarios/common phrasing + Necessary exclusion scenarios

For example:

description: Analyze code differences between Git branches related to a specified business module. Use when the user asks to evaluate branch merge impact, filter related commits, or generate migration risk reports. Not for directly executing merges or pushing code.

This description answers three things simultaneously: what it can do, when to trigger, and what it does not do.

Chapter 3: Not All Tasks Are Worth Making Into a Skill

After learning to create Skills, it's easy to want to Skill-ify all tasks. Chapter 3 is the chapter responsible for "hitting the brakes."

The author suggests first breaking tasks down into three types of operations:

• Execute rules: Format conversion, field validation, fixed calculations, etc.;
• Make judgments: Extract key points, judge risks, choose expression methods, etc.;
• Call external help: Access databases, search the web, read code repositories, etc.

After decomposition, the division of labor becomes clear:

• Tasks requiring semantic understanding and business judgment are left to the model;
• Tasks with fixed rules requiring accuracy are left to scripts;
• Capabilities the agent itself lacks are supplemented through tools or external connections.

Is Something Worth Making Into a Skill?

You can first ask three questions:

1. Will this task be done repeatedly?
2. Does it require consistency in results?
3. Is the current process already relatively stable?

The more conditions met, the more suitable it is to make into a Skill.

Conversely, the following three types of content usually do not need to be made into a Skill:

• Personal preferences that are always effective are more suitable for global configuration;
• Operations that can be stably completed with one tool or command should use the tool directly;
• One-time temporary tasks can be handled directly through conversation.

This chapter also emphasizes security: Before installing a third-party Skill, check what it reads, what it writes, whether it connects to the internet, and whether it includes high-risk actions like deletion and publishing. A Skill is an operation manual that enables the agent to "act," so the stronger the capability, the more boundaries are needed.

Chapter 4: Three Typical Skills, Three Design Approaches

Chapter 4 demonstrates three common designs through three cases:

Type	Main Control	Book Case
Constraint-type	Tone, style, prohibited expressions	Writing style Skill
Template-type	Fixed structure, fields, output format	Meeting minutes Skill
Process-type	Sequential steps, tool calls, intermediate artifacts	Article illustration Skill

Real-world Skills are often hybrids. For example, meeting minutes may need both a fixed template and tone constraints; article illustrations have both a process and file naming/output format requirements.

Why Should Complex Tasks "Plan First, Then Execute"?

The article illustration case has a detail worth emulating: Don't let the agent analyze the article and generate images simultaneously. Instead, it should first output a complete illustration plan, confirming the illustration position, purpose, visual content, and file name, then generate images one by one.

This is not adding formality but combating the model's problem of "forgetting the beginning by the time it reaches the end." For complex tasks like code migration, data governance, and batch file processing, it is also suitable to first generate an execution plan and impact list before entering actual operation.

Two Principles for Skill Iteration

• Change only one problem at a time to avoid being unable to locate the impact when multiple rules change simultaneously;
• Write bottom lines as hard rules, and try to explain the reasons for preferences so the model can infer by analogy.

After modification, perform three types of verification:

1. Trigger test: Does it trigger when it should, and does it falsely trigger when it shouldn't?
2. Functional test: Run the same input multiple times; are the structure and key information stable?
3. Comparison test: Compared to not using the Skill, has the quality truly improved significantly?

Chapter 5: From a Single Skill to Multi-Skill Workflows

Complex tasks should not be stuffed into a single "universal Skill." Chapter 5 proposes an important principle:

A Skill should try to be responsible for only one capability that has independent value and can be reused alone.

For example, "analyzing discussion content" and "generating minutes according to a template" in meeting minutes can be split into two Skills. The former can also be used for project reviews, customer interviews, and chat log extraction. After splitting, the reuse value is higher, and it is easier to test and maintain.

Three Combination Methods

• Series: A's output is B's input, e.g., material analysis → outline → writing → polishing;
• Parallel: Explore multiple solutions based on the same input simultaneously, e.g., generate three versions of an article based on three outlines;
• Loop: If quality inspection fails, return to the previous step with the issues for rework.

Files are a very important medium for multi-Skill collaboration. Large chunks of data and intermediate results should be saved as files. The workflow only passes paths and summaries, avoiding the main conversation being crowded with large amounts of content.

Sub-agents Are Not a Substitute for Skills

Skill solves "how to do it," while sub-agents solve "who does it in an independent context."

When the task is light and requires the main agent to understand the process, directly calling a Skill is sufficient; when the task takes a long time, requires parallel exploration, or the intermediate process will occupy a lot of context, then consider delegating to a sub-agent.

When assigning a task to a sub-agent, four elements should be clearly stated:

Goal: What to ultimately accomplish
Constraints: What can be done, what cannot be done
Input: Where the data or files are
Acceptance: What must be checked before completion

Among these, "acceptance" is the most easily overlooked. Without acceptance conditions, the sub-agent only knows when to start, not what constitutes completion.

Chapter 6: Developing a Skill Like a Small Software Product

Chapter 6 elevates Skill development to the engineering level. The complete process can be summarized as:

Requirements Analysis → Design → Implementation → Testing → Release → Continuous Iteration

Fill Out a Requirement Card First

Before creating a Skill, answer at least six questions:

1. What specific problem does it solve?
2. In what scenarios will users typically use it?
3. What is the input?
4. What is the output?
5. What rules must be followed?
6. What is explicitly prohibited?

These six answers are basically the skeleton of SKILL.md.

Four Designs to Improve Reliability

1. Record pitfalls: Accumulate errors that repeatedly appear in real use;
2. Increase fault tolerance: Check inputs before starting, manually confirm at key nodes, save intermediate results promptly;
3. Reserve for extension: Separate stable processes from changing configurations to avoid rewriting the main file every time a requirement is added;
4. Cross-conversation memory: Write progress, historical processing scope, etc., into stable files instead of expecting the model to remember permanently.

Use Eval Instead of "Feels Okay"

A mature Skill cannot be judged good or bad based on a single output. The evaluation loop given in the book is very close to software testing:

1. Prepare real test cases, including positive examples, edge cases, and easily confusing negative examples;
2. Define checkable inspection items in advance;
3. Compare results with Skill, without Skill, or between old and new versions;
4. Modify based on points lost, then run the full regression test again.

Special attention is needed:

• Save failure cases in the test question bank;
• Only write general experiences extracted from failures into SKILL.md;
• Do not add overly narrow "answer-type rules" just to pass a single case.

This is the most important anti-degradation mechanism in Skill engineering.

Chapter 7: Completing a Real Iteration with V1, V2, V3

Chapter 7 uses a data analysis Skill as an example to show the evolution of three versions:

Version	Core Goal	Problem Solved
V1 Basic	Can run stably	Read data, basic statistics, output fixed conclusions
V2 Enhanced	Possess analytical depth	Introduce analysis frameworks, anomaly detection, and business interpretation
V3 Production	Can be formally delivered	Combine templates and design guidelines to generate visual reports

The most worthwhile thing to learn is not the final report, but the iteration order:

• V1 does not pursue beauty, only validates the core link;
• V2 specifically supplements "how to think" based on problems exposed by V1;
• V3 supplements the delivery form after the analysis quality is stable.

Each version only solves one core problem, so it's clear whether the change is effective. More importantly, the user always only needs to upload a file and say "help me analyze this," with all complexity kept inside the Skill.

This embodies a product principle:

A good Skill should continuously enhance backend capabilities, not continuously increase the user's learning cost.

---

3. How to Better Use Skills: 10 Actionable Suggestions

1. Start from real repetitive labor, not from "I want to make a Skill"

Observe for a week first: Which tasks have you done three times? Which requirements have you explained to AI three times? Which errors have you corrected three times? These are the most worthy candidates for Skill-ification.

2. A Skill should try to solve only one stable problem

To judge whether to split, ask: Can a certain step produce an independent deliverable? Will it be reused alone in other scenarios? If the answer is yes, it's worth splitting out.

3. Treat description as a routing rule, not promotional copy

At least include "function + trigger scenario." Add an exclusion scenario when similar Skills exist. After completion, test triggering using two different phrasings, and add an easily confusing negative example to test false triggering.

4. Keep SKILL.md restrained, split large chunks of knowledge out on demand

The main file only keeps core steps, boundaries, output requirements, and checklists. Detailed specifications, domain knowledge, long examples, and API instructions go into references/, and clearly state in the main file under what circumstances to read which relative path.

Just putting files into references/ does not mean the agent will definitely read them.

5. Model is responsible for judgment, scripts for determinism

You can judge with one question: Must the same input produce the exact same output?

• Must be the same: Prioritize scripts, e.g., date conversion, field validation, hash calculation;
• Allowed to vary by context: Leave to the model, e.g., risk judgment, content selection, suggestion generation.

6. Use files as external memory, don't pile everything into the chat log

Save raw materials, intermediate results, evaluation reports, and final deliverables separately. In complex processes, try to pass file paths and short summaries instead of repeatedly copying full text.

7. Set manual checkpoints before high-cost or high-risk steps

For example, before batch modifying code, generating dozens of images, writing to a database, sending messages, or publishing content, pause first and display the plan, impact scope, or preview results. Automation is not about removing human decision-making but focusing human energy on key decisions.

8. Build your own test question bank

Every time a real problem is discovered, save the input at that time as a regression case. After modifying a Skill, not only retest the current case but also rerun old cases to prevent solving new problems while degrading old functions.

9. Global Skills should be few but refined; project Skills follow the project

High-frequency capabilities like writing style and general translation are suitable for global activation; business capabilities like payroll system code review and specific database standards are more suitable for project scope. More activated Skills is not better; the more overlap, the more obvious the false triggering and context consumption.

10. Let Skills record your business experience, not copy generic common sense from the internet

Truly valuable content usually includes: team conventions, field meanings, approval boundaries, scenarios prone to misjudgment, historical incidents, and acceptance criteria. These are parts that general models cannot know out of thin air and are the most compounding value part of Skills.

---

4. A Practical Example Suitable for Developers: Code Merge Impact Analysis Skill

Take the common task in Java projects of "migrating a feature from a test branch to a production branch." This task is often not just a simple git merge, but first requires answering:

• Which commits are related to the target feature?
• Has the related code already entered production through other commits?
• Does a difference in a public class belong to the target feature, or is it leftover from another requirement?
• Will the migration incidentally bring in unrelated changes?

This type of work is very suitable for making into a "Merge Impact Analysis Skill," but it should not be allowed to merge code directly.

Recommended Responsibility Boundaries

Input: Source branch, target branch, target feature, related paths, known commits

Deterministic Operations:
- Execute read-only commands like git log, git diff, git cherry
- Generate a diff list by commit and file
- Save raw diff evidence

Model Judgment:
- Judge whether each difference is related to the target feature
- Identify cross-requirements in public code
- Give suggestions for direct migration, manual cherry-pick, or abandoning migration

Output:
- List of related commits
- File-level impact matrix
- High-risk public files
- Missing dependencies and verification suggestions
- Recommended migration plan

Security Boundary:
- Read-only by default
- Do not automatically cherry-pick, merge, commit, or push
- Must be confirmed by a human before actual changes

This example strings together the methods of the whole book: Git commands are responsible for deterministic evidence collection, the model is responsible for business relevance judgment, files save evidence, and humans are responsible for the final migration decision; each time a missed commit or misjudgment is encountered later, add the real case to the test question bank.

---

5. A Minimal Viable SKILL.md Structure

Extension fields may differ across platforms. When starting, keep a minimal structure, usually only keeping name and description, which is easier to migrate and maintain.

---
name: merge-impact-analyzer
description: Analyze commits and code differences related to a specified feature between two Git branches. Use when the user asks to evaluate branch merge impact, filter feature-related commits, or generate migration risk reports. Does not execute merge, commit, or push.
---

# Merge Impact Analysis

## Input

- Source branch and target branch
- Target feature description
- Related directories or files
- Known commits, optional

## Workflow

1. Confirm the analysis scope; ask first if the scope is unclear.
2. Use read-only Git commands to collect commits and file differences.
3. Save raw command results and diffs as evidence files.
4. Classify as "Directly Related, Indirect Dependency, Unrelated, Cannot Confirm."
5. Perform a separate cross-requirement check for public classes and public configurations.
6. Generate migration suggestions and a test checklist.

## Output

- Commit list
- File impact matrix
- Risks and dependencies
- Recommended action plan
- Pre-launch verification items

## Security Rules

- Read-only by default, do not execute merge, cherry-pick, commit, push.
- Do not assert a difference belongs to the target feature without evidence.
- Any modification involving the production branch must first request manual confirmation.

## Acceptance Checklist

- Are all specified paths covered?
- Can every conclusion be traced back to a commit or diff?
- Are target features distinguished from other requirements?
- Is an executable verification plan provided?

## Pitfalls

- Continuously record cases of missed judgments, misjudgments, and cross-requirement coupling encountered in real use.

The first version doesn't need to pursue complexity. First choose a real branch diff to run through, then supplement based on what's missing from the results. This is more effective than writing hundreds of lines of rules from the start.

---

6. The 6 Most Easily Misunderstood Things

1. Skill is not a "longer prompt"

Its core is reusable processes, on-demand resources, tool calls, file-based intermediate artifacts, and continuous iteration, not stuffing all knowledge into one Markdown file.

2. Skill cannot replace business judgment

The model can execute the experience you write down, but it cannot invent standards that have not yet been formed for you. If you yourself cannot clearly say what counts as good, it's hard for a Skill to do it stably.

3. Skill does not equal permanent memory

State that needs to be preserved across conversations should be written to files or reliable data systems, not relying on the model "remembering what was talked about last time."

4. More Skills does not mean stronger capability

A large number of Skills with overlapping functions will bring routing conflicts, false triggering, and context waste. Quality, boundaries, and combinability are more important than quantity.

5. Sub-agents are not necessarily more efficient

Sub-agents have independent contexts but also incur information handover costs. Light tasks that can be completed in one context do not need to be forcibly split out.

6. Automatic execution does not equal no one is responsible

Operations like code modification, database writing, file overwriting, message sending, and online publishing should all retain permission control, preview, backup, and manual confirmation.

---

Conclusion: What's Truly Worth Accumulating Is Not Prompts, but Your Way of Doing Things

After reading this book, my biggest feeling is: The true barrier of Skill has never been in Markdown syntax, nor in whether you can write scripts, but in whether a person truly understands their own work.

Do you know why a task is done this way? Which steps cannot go wrong? Where does judgment need to be applied? What kind of result qualifies as deliverable? What pitfalls have been encountered in the past?

This experience is usually scattered in people's minds, chat logs, and repeated rework. What Skill does is gradually turn these into executable, verifiable, combinable, and continuously upgradeable digital assets.

So, don't start by designing a "universal AI assistant." Pick a small task you've already done three times this week, first make a twenty or thirty-line Skill, and run it for real once. Wherever you are dissatisfied, that is the requirement for the next version.

As Skills become more and more accurate with use, what you accumulate is not just a prompt, but a set of personal working methods that can be amplified by AI.