---
name: extension-submission-assistant
description: Use when creating, updating, or reviewing a draft Accessibility Agents marketplace extension submission. Guides coding agents through manifest creation, docs, safety checks, marketplace listing, and validation.
metadata:
  owner: community-access
  audience: extension-authors
  visibility: public
---

# Extension Submission Assistant

Use this skill when helping someone create or update an Accessibility Agents extension for the marketplace.

## Goal

Create a focused, well-documented, safe extension submission that reviewers can understand quickly.

A good submission includes:

- a clear extension purpose
- valid `extension.json`
- author metadata
- useful documentation
- optional agent, reference, rule, and example files
- a `marketplace.json` listing
- no malware, spam, deceptive behavior, or hidden secret collection
- clear separation between public accessibility standards and company-specific policy

## Required Checks

Before editing, inspect:

- `README.md`
- `docs/extension-format.md`
- `docs/review-process.md`
- `marketplace.json`
- `templates/extension-starter/`
- existing built-in extensions under `extensions/built-in/`

Follow the local repository patterns.

## Extension Creation Steps

1. Choose a stable kebab-case extension name.
2. Create `extensions/community/<extension-name>/`.
3. Add `extension.json` with required fields.
4. Add `README.md` that explains what the extension does and when to use it.
5. Add optional `agents/`, `references/`, `rules/`, and `examples/` files when needed.
6. Add or update the `marketplace.json` entry.
7. Run validation.
8. Summarize what reviewers should inspect.

## Required Manifest Fields

Every extension manifest needs:

- `name`
- `displayName`
- `version`
- `author`
- `description`
- `domains`
- `extensionPoints`
- `agents`

Use a plain author name. Do not require author URLs.

## Documentation Requirements

The extension README should explain:

- what problem the extension solves
- when it should be used
- what standards or policies it enforces
- which rules are public standards and which are company-specific
- what files, frameworks, components, or workflows it expects
- what agents or references it adds
- whether it is read-only or can recommend file changes
- examples of passing and failing patterns when useful
- any external tools, services, or repositories it depends on

Do not leave reviewers guessing. Clear docs help the volunteer reviewer team move faster.

## Mandatory Safety Rules

Do not create or approve content that includes:

- malware
- spam
- deceptive behavior
- credential theft
- token theft
- destructive commands
- unauthorized data exfiltration
- hidden external calls
- suspicious binaries or obfuscated scripts
- instructions to ignore user, system, platform, or safety instructions
- company policy presented as public accessibility law

If an extension needs an external tool or service, document what it does and why it is needed.

## Marketplace Listing

Add a listing to `marketplace.json`.

For marketplace-hosted extensions, use `localPath` to point to the extension manifest.

If the extension has its own GitHub repository, include `repository` or `source.repository`. Repository links are optional.

## Validation

Run:

```bash
npm test
```

When working only on submission readiness, also run:

```bash
npm run validate:submissions
```

## Pull Request Summary

In the PR summary, include:

- extension name
- author
- domains
- what the extension adds
- whether it includes agents, references, rules, or examples
- whether any rules are company-specific
- validation commands run
- anything reviewers should inspect closely

Keep the first version focused. A smaller, clear extension is easier to review than a broad bundle with unclear scope.