• Cost: If infrequently used policy documents are included in each call, the value of converting Skills is high.
• Time: Initial design takes longer, but feature addition speed is actually faster. This is because new tasks can be handled by “adding skills” rather than “modifying prompts”.
• Accuracy: The correct answer rate does not automatically increase. However, since only necessary instructions are loaded, instruction conflicts and context contamination can be reduced.
• Difficulty: It is more difficult than a simple chatbot, but the sooner you invest in a multi-agent or operational agent, the more beneficial it is.

There are also opposite examples. For in-house bots with few features and rarely changing rules, the Skills structure may be overkill. Google also introduced inline skill, file-based skill, external import, and skill factory step by step, but does not say that all agents must use self-extending skill factory from the beginning.

3) Step-by-step execution method

1. Step 1: Break down the current system prompts into task units.
   Separate bundles of instructions like people divide team roles, for example “SEO review”, “Security review”, “Release check”, “Blog writing”. If a batch starts to exceed 300 to 800 words, you can consider it as a skill candidate.
2. Step 2: Move rules that are not frequently used to file-based skills.
   Leave only when to use and steps in SKILL.md, and separate detailed standards into references/. This way, even when calling a skill, it doesn't always load unnecessary detailed documents.
3. Step 3: Consider connecting external tools and modularizing instructions separately.
   MCP or API tool is a question of “what can be accessed”, and skill is a question of “what criteria will the tool be used for?” If you design the two as one, maintenance will be complicated.
4. Step 4: Fix the call order with a workflow agent.
   For example, fixing the order of Identify needs → Load relevant skills → Execute → Verify checklist → Report results with a sequential agent can reduce the problem of the same task taking a different path each time. There is
5. Step 5: Generative skills must have an evaluation loop attached.
   Google provides not only final response but also trajectory and tool through ADK Evaluate. We recommend that you rate up to use. In other words, you should not only look at “Was the answer plausible?” but also “Was the appropriate skill called and was there no unnecessary loading?”

#Recommended operating pattern example
1. The basic prompt contains only roles, safety rules, and skill usage principles.
2. Detailed work instructions are separated into skill metadata (L1) + instructions (L2) + references (L3).
3. External system connection is handled by MCP/API tool.
4. Sequential/parallel/loop execution is fixed with a workflow agent.
5. Compare token usage, call time, and success rate before and after adding a new skill.

In practice, it is safe to start with the criteria below. Leave common rules that are called repeatedly in the root instructions, and move specialized documents needed only in specific situations to Skills. For example, “All answers should be in Korean and sensitive information should be hidden” in the root, and “Apply OWASP checklist during security review” as a separate skill.

4) Mistakes/Pitfalls

1. Pitfall: Using Skills as a simple prompt fragment repository
   Prevention: For each skill, “when to use it, in what order to use it,” Write clearly “what needs to be calculated”
   Recovery: If the skills you have already created are ambiguous, rewrite SKILL.md as a checklist-type procedure, and move detailed documentation to references.
2. Pitfall: Removing all rules to skills leaves the root agent too empty
   Prevention: Always applied like safety, tone, and approval policies. Rules must be left in the root.
   Recovery: The criteria that must be followed even before skill call are compressed into about 5 to 10 and restored to system instructions.
3. Pitfall: Viewing Skills and MCP as the same problem
   Prevention: Separate tool connection into capability and skill into operating procedure. Document it.
   Recovery: “When and by what criteria to use this tool” is separately defined as skill.
4. Pitfall: Automating the skill factory too early
   Prevention: In the beginning, the operating pattern was stabilized with 3 to 5 human-created skills. It is better to attach a post-generated skill.
   Recovery: Add a gate so that automatically generated skills must undergo human review and eval sets.
5. Pitfall: Ignoring the fact that it is an experimental feature
   Prevention: Design for known limitations in the ADK official documentation, especially constraints such as not supporting scripts. Please specify in the document.
   Recovery: If the skill was designed to be responsible for execution, the role is currently redefined to focus on instructions/resource loading, and execution is separated into a separate tool.

5) Execution Checklist

• Identified a set of repetitive instructions of 300 words or more in the current system prompt
• For each bundle, we divided “rules to be left in the route” and “rules to be separated into skills”
• Terms of use and procedures are placed in SKILL.md, and detailed standards are placed in references
• Designed to separate external tool connection (MCP/API) and business procedures (skill)
• The workflow agent determines whether sequential, parallel, or loop control is needed
• We set an eval item to compare token usage, delay time, and success rate before and after skill introduction
• Experimental limitations (e.g. scripts not supported) were reflected in the operating document

Definition of Done: The introduction is complete if the agent does not carry all the instructions for every call, selectively loads only the necessary skills, and verifies the results with evaluation indicators.

6) Reference

• Google Developers Blog - Developer’s Guide to Building ADK Agents with Skills (Published date: 2026-04-01, Checked date: 2026-04-06)
• Google ADK Docs - Skills for ADK agents (Confirmation date: 2026-04-06)
• Google ADK Docs - Workflow Agents (Confirmation date: 2026-04-06)
• Google ADK Docs - Why Evaluate Agents (Confirmation date: 2026-04-06)
• Agent Skills - Specification (Confirmation date: 2026-04-06)

7) Author Viewpoint

My judgment is clear. ADK Skills are closer to “an operating structure that makes agents less expensive and less tangled” rather than “features that make agents smarter.” So, for teams that already have longer prompts and more roles, it is worth introducing them now. Separating skills is almost essential, especially if you are cramming multiple checklists, security rules, and domain-specific guides into one agent.

However, overestimation is prohibited. Adding skills does not automatically increase quality. If your skill design is poor, you end up with just a pile of shredded prompts. Additionally, as the ADK document directly states, it is still in the experimental stage, so in important operational areas, it is safe to add human review + eval + deterministic workflow together.

To summarize, is recommended for agents with increased number of functions and increased context cost. Conversely, it is not recommended for small bots with few rules. My practical recommendations are simple. First, select a skill that you don't use frequently at the prompt, then add workflow agent and eval. That order is the least risky and most effective.