What Is SkillOps? Agent Skill Operations and Maintenance at Google
What you’ll learn
- The similarities and differences between Google’s published practices and the SkillOps research paper
- How to compare answer accuracy and work efficiency with and without a Skill
- The basics of combining maintainers, automated checks, and recurring evaluations
SkillOps Manages Skills Continuously from Creation Through Maintenance
An Agent Skill is a package of instructions and knowledge that helps AI perform a job. Creating and publishing one is not the end of the work. A procedure that once worked can fail after a connected service or AI model changes. As the collection grows, a team must also decide who fixes each Skill and which version to distribute.
SkillOps is a way to manage Skill creation, publication, evaluation, and maintenance as one continuous operation.
Google Cloud’s published case treats Skills as assets that require ongoing management. Using that case and the research paper, this article explains who owns updates, what should be checked before release, and how to maintain quality afterward. The goal is to provide criteria for designing an operating model that fits your organization.
Google’s Published Case and the Meaning of “SkillOps”
Google Cloud described how it operates Google Agent Skills in “Behind the scenes: How we build, test, and scale Google Agent Skills.” Google Agent Skills package knowledge in fields such as Google Cloud into a shared format that AI can use and the public can inspect.[1]
Google did not announce a product or new standard named “SkillOps.” Its article explains quality control, evaluation, publication, and maintainer responsibilities. This article interprets those practices as an example of SkillOps.
Separately, Hongji Pu, Xinyuan Song, and Liang Zhao used the name SkillOps in a research paper released on May 13, 2026. Their paper addresses duplicated and outdated procedures that accumulate in a Skill library, and proposes maintaining the library separately from day-to-day use.[2]
The Google article and the research paper are independent publications. They share some ideas, but they should not be treated as one initiative.
The Quality-Control Challenge as the Skill Collection Grew
Google Agent Skills began as a cross-functional effort ahead of Google Cloud Next 2026. Developer Advocates and Technical Writers led the work. After release, product teams beyond Cloud also wanted to contribute Skills, so Google needed to expand participation while preserving quality.[1]
Google identifies vague instructions, broken links, and missing edge cases as recurring problems. Even one poor Skill can degrade how an AI agent works and how people experience it.
Google therefore combines shared rules, automated checks for each change, continuous delivery and evaluation, and explicit ownership rather than treating a Skill contribution as an unrestricted document submission.[1]
The operating scope goes beyond how to write SKILL.md, the file that stores a Skill’s name, description, and procedures. It also covers who may change a Skill, what must pass before publication, and whether the Skill still works after a connected service or AI model changes.
Six Mechanisms Behind Google’s Operating Model
Google’s published process can be organized into six mechanisms.[1]
| Mechanism | Google’s practice | Problem it helps prevent |
|---|---|---|
| Shared format | Standardize folder structure and naming rules | Each team uses a different format, making material hard to find |
| Connections to outside tools | Prefer remote MCP, using direct computer commands or individual service connections only when needed | Authentication and permission management spreads across locations, while custom connection methods multiply |
| Publication to GitHub | Automatically publish only externally approved material from content created and checked internally | Internal documents, maintainer information, or test data is exposed |
| Automatic checks on changes | Check metadata, names, locations, links, and safety rules | Broken links, nonexistent URLs, and malformed files go unnoticed |
| Recurring effectiveness checks | Compare results with and without the Skill on submission and every week | A service or AI change reduces quality |
| Clear maintainers | Separate collection maintainers from the maintainer of each Skill | A known problem remains unfixed because responsibility is unclear |
Remote MCP is a shared way to connect AI to external tools over a network. It can make authentication and permission management more consistent. GitHub is a service for storing files and tracking their change history.
Format checks alone cannot determine whether a Skill is ready for publication. Passing lint, a mechanical check of file and writing conventions, does not guarantee more accurate answers.
Google therefore evaluates “is it in the required form?” separately from “does it improve results in practice?”
Generating a Public Version from the Internal Version
Google first creates and evaluates Skills internally. Defined export rules then extract the files needed for a public GitHub repository. Internal documents, maintainer information, and evaluation suites are removed during that process.[1]
In this design, the internal version serves as the management baseline. Generating a separate public version preserves the boundary between information needed for internal operations and information intended for external distribution.
A practical adaptation could follow this sequence.
- Manage the Skill, maintainer, tests, and private references in an internal repository
- Check both format and actual behavior before accepting a proposed change
- Extract only publishable SKILL.md files, scripts, and references
- Recheck the public destination for secrets and internal links
The public destination contains only the files required to distribute the Skill. It does not show the maintainer or the conditions under which the Skill passed evaluation, so the organization also needs a durable mapping between each public version and its internal management record.
Comparing Accuracy and Efficiency With and Without a Skill
At Google, Skill authors supply multiple test cases. Each test includes a prompt for the AI and a set of expected results. Google runs the same test with and without the Skill, then compares answer accuracy and work efficiency.[1]
Efficiency covers tokens (units of information processed by the AI) and the time required to finish the task. Google also runs evaluations multiple times across different agent frameworks to determine whether the results are statistically meaningful.[1]
The combinations of accuracy and efficiency produce four possible outcomes. The decisions below are this article’s interpretation of the 2x2 evaluation axes published by Google.[1]
| Result compared with no Skill | Meaning | Example decision in this article |
|---|---|---|
| Accuracy and efficiency improve | The Skill’s value is easiest to demonstrate | Consider publication |
| Accuracy improves, efficiency declines | Quality rises, but token use or completion time increases | Limit use to work where higher accuracy matters |
| Accuracy declines, efficiency improves | Work is faster, but quality suffers | Revise the expected results or instructions |
| Accuracy and efficiency decline | No adoption benefit is visible | Stop publication and consider redesign or retirement |
Consider a Skill for safely deploying an application to Cloud Run, Google’s service for running applications. “The command completed without an error” is not enough to show that the deployment was safe.
The expected results could include these conditions:
- It operates with the minimum required permissions
- It uses the requested region
- The deployed application passes an availability check
- It does not include a prohibited public-access setting
The evaluation can then measure whether the Skill satisfies those conditions more accurately than the no-Skill run.
This is a practical application of Google’s evaluation method, not an individual test case published by Google.
Responsibilities for Ongoing Maintenance and Authoring Support
Google says that “skills are products, not snippets”: a Skill should be treated as a maintained product rather than a short piece of text.[1]
Responsibility is divided between collection maintainers and the maintainer of each Skill.
| Role | Main responsibilities |
|---|---|
| Collection maintainers | Manage the repository, shared automated checks, and architectural standards |
| Individual Skill maintainer | Maintain the assigned Skill over time, respond to service changes, and fix quality degradation found by weekly evaluations |
Google also provides authoring support. Internal Skills help contributors, while agentic workflows built with ADK (Agent Development Kit) use multiple agents for authoring and self-critique.[1]
In addition to the public Google Agent Skills collection, Google runs an internal “DevRel Skills” initiative. These Skills standardize Developer Relations work such as content transformation, search engine optimization, and internal reporting.[1]
Skills can therefore encode standard internal procedures as well as product knowledge for external users.
However, AI-assisted authoring does not remove the need for an Owner who is responsible for updates and retirement, or an evaluation gate that determines whether a Skill may be published. Automation can accelerate drafting and self-critique, while people and tests remain responsible for the publication decision.
Similarities and Differences from the SkillOps Research Paper
The research paper represents each Skill as a contract that records when it may be used, what operation it performs, what output it produces, how that output is validated, and which failures are already known.[2]
It also manages relationships between Skills, including dependencies, alternatives, compatibility, and duplication.
The maintenance model separates repair for the current task from library-wide work such as merging duplicates, repairing persistent problems, and retiring obsolete Skills.[2]
| Dimension | Google’s published case | SkillOps research paper |
|---|---|---|
| Primary concern | Organizational creation, checks, evaluation, publication, and ownership | Diagnosing and maintaining duplicated or outdated procedures across the Skill library |
| Skill representation | Shared folder structure and instruction format | Explicit usage conditions, operation, artifact, validation method, and failure conditions |
| Quality checks | Format and link checks, AI-assisted validation, and actual behavior | Utility, redundancy, compatibility, failure risk, and validation gaps |
| Maintenance timing | Effectiveness checks on submission and every week | Separate flows for the current task and the whole library |
| Maintainer | Collection maintainers and individual Skill maintainers | A maintenance layer that works with existing AI agents |
Both approaches treat Skills as assets that must be tested and updated as related services and tools change, not as prompts written once.
Google describes a real organizational process, while the paper formalizes relationships among Skills and automated maintenance rules. No published statement says that Google adopted the research paper’s SkillOps framework.
Operating Items for a Small Initial Adoption
The Google case and the research proposal suggest starting with one Skill instead of applying a new process to a large collection at once.
| Item | What to decide or check |
|---|---|
| 1. Maintainer and purpose | Who decides on updates and retirement, and what the Skill is for |
| 2. Static checks on changes | Configuration at the start of SKILL.md (frontmatter), naming, structure, links, and information that must not be included |
| 3. Comparison with and without the Skill | Test cases for comparing accuracy, token use, and completion time |
| 4. Recurring reevaluation | Weekly or monthly checks for degradation caused by API, model, or agent-platform changes |
| 5. Skill register | Records of duplication, compatibility, and failure used to decide on merging, repair, or retirement |
| 6. Separate internal and public versions | Export rules and automated checks that prevent information leakage |
A static check examines file contents and structure without running the Skill. An API is an interface through which software exchanges data or functionality.
This site manages shared Skills in shared/skills/ and runs npm run harness:check to verify alignment between Skills and runtime configuration.
One possible improvement would be to associate every Skill with a maintainer, evaluation prompts, expected results, and the date of the previous evaluation, then retain the measured difference between runs with and without the Skill.
That proposal adapts Google’s published operating principles to this site’s collection of AI rules, procedures, and checks. It does not reproduce Google’s internal implementation.
Limits of the Published Information
Google’s article explains its operating principles, but it does not publish every implementation and evaluation detail. The following remain undisclosed.[1]
- The evaluation models, pass thresholds, and number of test cases
- The implementation of the weekly evaluation jobs
- The procedure for transferring ownership
- Per-Skill accuracy gains or token reductions
Although the article describes a four-quadrant comparison of accuracy and efficiency, it does not report how much any individual Skill improved.
The SkillOps paper reports a 79.5% task success rate on ALFWorld, a text-based benchmark that models household tasks, with a 200-Skill library. This is the mean over three different seeds with 185 tasks per seed, and it is 8.8 percentage points above the strongest baseline.[2]
That result cannot be directly generalized to Google’s operations or ordinary enterprise work. A team still needs to choose evaluation criteria and a maintenance interval for its own Skills and work, then compare results on a small scope.
Summary: Comparative Evaluation and Ownership Sustain Skill Quality
In this article, SkillOps is not a product name. It is an operating model for continuously managing Skill creation, publication, evaluation, repair, merging, and retirement. Google’s case and the research paper both emphasize maintaining quality over time, not merely increasing the number of Skills.
The foundation for that decision is a comparison against a run without the Skill. Repeating the comparison after connected services or AI models change shows whether the effect persists.
A practical starting point is one Skill with a limited impact, together with its maintainer, baseline result, expected result, and next evaluation date. Each organization must set pass thresholds and ownership-transfer conditions according to its work and risk. This evaluation and maintenance structure makes it possible to grow a Skill collection while preserving quality.
References
- Remigiusz Samborski, Behind the scenes: How we build, test, and scale Google Agent Skills, Google Cloud Blog, August 3, 2026
- Hongji Pu, Xinyuan Song, Liang Zhao, SkillOps: Managing LLM Agent Skill Libraries as Self-Maintaining Software Ecosystems, May 13, 2026
For the latest releases and updates, check the official website and official documentation.