The Industry Skill Submission Guide: How to Propose a Vertical Skill ASE Will Actually Accept

Industry collections on Agent Skill Exchange are not just labels. They are a promise that a skill belongs in a real operating workflow, has enough source evidence to be reviewed, and includes boundaries that make the agent safer to use in a specific domain. That bar matters more for vertical skills than for broad developer tools because the surrounding context is often regulated, document-heavy, customer-facing, or financially sensitive.

A good submission does not need to claim it can transform an entire industry. It needs to show a narrow, useful job: extract invoice fields before a finance review, expose FHIR resources with human review boundaries, search legal documents without pretending to give legal advice, or connect a CRM task to a documented API. The strongest submissions make that fit obvious before a reviewer has to guess.

In Short

To propose a vertical skill ASE will accept, frame it around a concrete operating workflow, link it to verifiable source material, name the systems it touches, and state what the agent must not do. Vertical skills are strongest when they help a human team prepare, inspect, reconcile, route, or summarize work. They are weakest when they read like category landing pages or product cards.

Who this is for

This guide is for creators submitting skills that belong in an industry context: finance, legal, healthcare, support, real estate, education, public sector, supply chain, media, or agency operations. It also helps maintainers decide whether a skill belongs in an industry collection, a general category, or nowhere until the source evidence improves.

If the skill is mostly a library wrapper, submit it as a normal technical skill first. If it clearly supports an industry workflow, explain that workflow in the body. For example, Connect accounting agents to Xero through MCP is not valuable because it mentions accounting. It is valuable because it ties an agent to a documented accounting system and can be bounded around lookup, reconciliation support, and review handoff.

Starter workflow

Start with the domain object, not the model. A vertical skill should name the thing a team already handles: vendor invoice, policy document, patient resource, filing, support ticket, lease packet, purchase order, campaign brief, or case note. Then describe what the agent does to that object and where the human review step happens.

A finance submission might say: “Extract vendor invoice fields, compare them against a spreadsheet review queue, and prepare exceptions for an accounting reviewer.” That is reviewable. A vague submission saying “automate finance operations with AI” is not. The first version lets ASE check fit against the Finance & Filings collection, source URLs, installation path, and failure modes. The second version gives reviewers nothing solid to validate.

Next, write the risk boundary as an instruction the agent can actually follow. “Do not approve invoices, move money, alter accounting records, or provide financial advice” is clearer than “be careful.” For legal and compliance work, the same rule applies: a skill can search, assemble, compare, and summarize documents, but it should not claim to replace legal judgment. That is why skills adjacent to the Legal Ops & Compliance collection need careful wording around advice, privilege, final review, and source citations.

Finally, include the practical run path. List required accounts, API credentials, local tools, and expected inputs. If a skill depends on a vendor API, link to the official documentation. If it depends on a repository, package, or CLI, point to the canonical source. ASE can leave unknown metadata blank, but it should not accept an industry placement built on guesses.

Recommended ASE skills

Use accepted skills as patterns, not as templates to copy blindly. The point is to understand how narrow workflow fit, source alignment, and review boundaries show up in real submissions.

• Extract invoice fields from vendor PDFs into structured records shows how a document task can stay focused on preparation rather than approval.
• Read Google Drive files and edit Sheets through MCP is useful when the submission names the exact spreadsheet handoff and permission boundary.
• Expose FHIR healthcare data resources to MCP agents with review boundaries is a good healthcare example because the boundary is part of the skill’s premise.
• Detect repository licenses before dependency approval or open-source due diligence fits compliance review because it produces evidence for a decision, not the decision itself.
• Use DocsGPT for document-grounded enterprise assistants works best when paired with a defined corpus, citation expectations, and escalation rules.
• Gate agent inputs and outputs with Superagent safety checks is relevant for higher-risk workflows where the submission needs explicit guardrails.

What to watch

Do not submit a vertical skill whose only industry signal is a title. “Healthcare assistant,” “legal copilot,” and “finance agent” are labels, not workflows. A reviewer should be able to answer three questions within the first minute: What artifact does this skill handle? What system or source does it rely on? What decision remains with a human?

Be especially careful with regulated claims. For healthcare, stay close to documentation, intake, formatting, retrieval, and review support. The Healthcare Documentation & Intake collection exists because useful administrative work can be separated from clinical decision-making. For finance, distinguish research, reconciliation support, extraction, and filing analysis from trading, lending, tax advice, or payment approval. For agency work, explain the operational workflow and link it through the broader industry collections rather than forcing every tool into a vertical bucket.

Also avoid product-card submissions. ASE is a skill exchange, not a brochure shelf. If the body only says what a product is, it is incomplete. A submission should teach an agent when to use the tool, how to set it up, what evidence to collect, and what to do when the source system returns partial or conflicting data.

Submission checklist

• Name the domain object and the workflow step.
• Link to official docs, a real repository, or another canonical source.
• State required credentials, accounts, local tools, and environment variables.
• Define what the agent may prepare, summarize, edit, or route.
• Define what the agent must not approve, decide, diagnose, advise, or send.
• Describe the review handoff and the evidence the agent should preserve.
• Place the skill in a real category or collection only when the workflow fit is clear.

Creators can browse current examples in Browse Skills before submitting. Look for skills that are narrow enough to test and specific enough to review. The best submissions feel almost boring: they tell the agent exactly what job to do, where the source truth lives, and when to stop.

FAQ

Does every industry tool deserve an industry collection placement?

No. A tool can be useful without being vertical. Put it in an industry collection only when the skill’s workflow, data objects, risk boundary, and reviewer handoff are clearly tied to that domain.

Can a skill support more than one industry?

Yes, but submit the primary workflow first. A document extraction skill might support finance, legal, and healthcare, but each placement should be justified by a specific artifact and review path.

What makes a submission safer for sensitive domains?

Clear limits. Say what the agent can inspect or prepare, then name the actions it cannot take. If a human must approve, sign, diagnose, advise, send, or pay, make that boundary explicit.