feat(rulesets): add asyncapi v3 support

.spectral.yaml

@@ -0,0 +1 @@
+extends: ["spectral:asyncapi"]

docs/getting-started/1-concepts.md

@@ -8,7 +8,7 @@ To achieve this, Spectral has three key concepts:
 - **Functions** accept a value and return issues if the value is incorrect.
 - **Rulesets** act as a container for rules and functions.
 
-Spectral comes bundled with a [set of core functions](../reference/functions.md) and rulesets for working with [OpenAPI v2 and v3](./4-openapi.md) and [AsyncAPI v2](./5-asyncapi.md) that you can chose to use or extend, but Spectral is about far more than just checking your OpenAPI/AsyncAPI documents are valid.
+Spectral comes bundled with a [set of core functions](../reference/functions.md) and rulesets for working with [OpenAPI v2 and v3](./4-openapi.md) and [AsyncAPI v2 and v3](./5-asyncapi.md) that you can chose to use or extend, but Spectral is about far more than just checking your OpenAPI/AsyncAPI documents are valid.
 
 By far the most popular use-case of Spectral is automating [API Style Guides](https://stoplight.io/api-style-guides-guidelines-and-best-practices?utm_source=github&utm_medium=spectral&utm_campaign=docs), implementing rules that your Architecture, DevOps, API Governance or "Center of Excellence" teams have decided upon. Companies generally write these style guides as wiki pages, and several can be found on [API Stylebook](http://apistylebook.com/), but most of these rules could be automated with Spectral. For example:
 

docs/getting-started/3-rulesets.md

@@ -13,15 +13,15 @@ The fastest way to create a ruleset is to use the `extends` property to leverage
 Spectral comes with two built-in rulesets:
 
 - `spectral:oas` - [OpenAPI v2/v3 rules](./4-openapi.md)
-- `spectral:asyncapi` - [AsyncAPI v2 rules](./5-asyncapi.md)
+- `spectral:asyncapi` - [AsyncAPI v2/v3 rules](./5-asyncapi.md)
 
 To create a ruleset that extends both rulesets, open your terminal and run:
 
 ```bash
 echo 'extends: ["spectral:oas", "spectral:asyncapi"]' > .spectral.yaml
 ```
 
-The newly created ruleset file can then be used to lint any OpenAPI v2/v3 or AsyncAPI descriptions using the `spectral lint` command:
+The newly created ruleset file can then be used to lint any OpenAPI v2/v3 or AsyncAPI v2/v3 descriptions using the `spectral lint` command:
 
 ```bash
 spectral lint myapifile.yaml

docs/getting-started/5-asyncapi.md

@@ -1,6 +1,6 @@
 # AsyncAPI Support
 
-Spectral has a built-in [AsyncAPI v2](https://www.asyncapi.com/docs/specifications/v2.0.0) ruleset that you can use to validate your AsyncAPI files.
+Spectral has a built-in AsyncAPI [v2](https://www.asyncapi.com/docs/specifications/v2.0.0) and [v3](https://www.asyncapi.com/docs/reference/specification/v3.0.0) ruleset that you can use to validate your AsyncAPI files.
 
 Add `extends: "spectral:asyncapi"` to your ruleset file to apply rules for AsyncAPI v2.
 

docs/guides/4-custom-rulesets.md

@@ -30,6 +30,8 @@ Formats are an optional way to specify which API description formats a rule, or
 - `aas2_4` (AsyncAPI v2.4.0)
 - `aas2_5` (AsyncAPI v2.5.0)
 - `aas2_6` (AsyncAPI v2.6.0)
+- `aas3` (AsyncAPI v3.x)
+- `aas3_0` (AsyncAPI v3.0.0)
 - `oas2` (OpenAPI v2.0)
 - `oas3` (OpenAPI v3.x)
 - `oas3_0` (OpenAPI v3.0.x)