{"id":50699636,"url":"https://github.com/specmatic/specmatic-linter-sample","last_synced_at":"2026-06-09T08:32:50.837Z","repository":{"id":361104747,"uuid":"1252430852","full_name":"specmatic/specmatic-linter-sample","owner":"specmatic","description":null,"archived":false,"fork":false,"pushed_at":"2026-05-29T08:21:40.000Z","size":95,"stargazers_count":0,"open_issues_count":1,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-05-29T08:31:22.435Z","etag":null,"topics":["linter","sample-project","specmatic-linter"],"latest_commit_sha":null,"homepage":"","language":"PowerShell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/specmatic.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-05-28T14:09:55.000Z","updated_at":"2026-05-29T08:21:44.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/specmatic/specmatic-linter-sample","commit_stats":null,"previous_names":["specmatic/specmatic-linter-sample"],"tags_count":null,"template":false,"template_full_name":null,"purl":"pkg:github/specmatic/specmatic-linter-sample","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/specmatic%2Fspecmatic-linter-sample","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/specmatic%2Fspecmatic-linter-sample/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/specmatic%2Fspecmatic-linter-sample/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/specmatic%2Fspecmatic-linter-sample/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/specmatic","download_url":"https://codeload.github.com/specmatic/specmatic-linter-sample/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/specmatic%2Fspecmatic-linter-sample/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34098932,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-09T02:00:06.510Z","response_time":63,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["linter","sample-project","specmatic-linter"],"created_at":"2026-06-09T08:32:50.025Z","updated_at":"2026-06-09T08:32:50.829Z","avatar_url":"https://github.com/specmatic.png","language":"PowerShell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Specmatic Linter Interactive Lab\n\nSpecmatic Linter is an enterprise-grade linting solution for modern API and interface specifications. It helps teams detect and report issues during local development and in CI/CD pipelines, enabling consistent quality, stronger governance, and compliance with both industry standards and organization-specific policies.\n\nIt provides a scalable way to enforce shared standards with rules, maturity levels, types, profiles, and central configuration, while still adapting linting rigor to different API contexts.\n\n## Key Capabilities\n* **Semantic intelligence**: Understands the intent of your API, not just its syntax.\n* **Executable contracts**: Lints specifications and validates examples so they can serve as enforceable contracts.\n* **High performance**: Uses a concurrent engine designed for enterprise-scale workloads.\n* **Precision-engineered**: Delivers high-confidence validation with deterministic rules and low-noise results.\n* **Mission-critical reliability**: Supports large-scale systems and CI/CD-driven governance workflows.\n* **Extensibility**: Provides an approachable DSL for custom rules and organization-specific policies.\n* **Flexible integration**: Supports shift-left feedback in local development environments and enforcement in CI/CD pipelines.\n* **Auto-fix**: Establishes the foundation for automated remediation of semantic and syntax issues.\n* **Best-of-breed architecture**: Built on proven patterns to address the practical limitations of conventional linting approaches.\n\nThis sample project is a guided, hands-on lab for learning Specmatic Linter in the following order:\n\n\u003c!-- TOC --\u003e\n* [Specmatic Linter Interactive Lab](#specmatic-linter-interactive-lab)\n  * [Key Capabilities](#key-capabilities)\n  * [Prerequisites](#prerequisites)\n  * [Folder Layout](#folder-layout)\n  * [1. Rules Intro](#1-rules-intro)\n    * [Step 1: Run Built-in Rules](#step-1-run-built-in-rules)\n      * [Minimal rule-set](#minimal-rule-set)\n      * [Recommended rule-set](#recommended-rule-set)\n    * [Step 2: Enable Configurable Rules](#step-2-enable-configurable-rules)\n    * [Step 3: Enable Custom JS Rules](#step-3-enable-custom-js-rules)\n  * [2. Maturity Levels](#2-maturity-levels)\n    * [Step 1: Run the Initial Setup](#step-1-run-the-initial-setup)\n    * [Step 2: Raise One Rule's Maturity Level](#step-2-raise-one-rules-maturity-level)\n    * [Step 3: Remove One Rule From Maturity Participation](#step-3-remove-one-rule-from-maturity-participation)\n  * [3. Rule Types](#3-rule-types)\n    * [Step 1: Run All Rules](#step-1-run-all-rules)\n    * [Step 2: Run rules only of type `examples`](#step-2-run-rules-only-of-type-examples)\n    * [Step 3: Run rules of type `examples` or `schema`](#step-3-run-rules-of-type-examples-or-schema)\n  * [4. Profiles](#4-profiles)\n    * [Step 1: Run Without Any Profile](#step-1-run-without-any-profile)\n    * [Step 2: Run the `internal` Profile](#step-2-run-the-internal-profile)\n    * [Step 3: Run the `public-api` Profile](#step-3-run-the-public-api-profile)\n    * [Step 4: Tweak A Profile](#step-4-tweak-a-profile)\n  * [5. Central Config Repo](#5-central-config-repo)\n    * [Step 1: Run with the Default Profile](#step-1-run-with-the-default-profile)\n    * [Step 2: Run with `internal-api` profile](#step-2-run-with-internal-api-profile)\n    * [Why the Central Config Repo Flow Helps](#why-the-central-config-repo-flow-helps)\n  * [6. High-Performance Engine](#6-high-performance-engine)\n      * [macOS / Linux](#macos--linux)\n      * [Windows](#windows)\n\u003c!-- TOC --\u003e\n\n## Prerequisites\n\n- Docker Engine must be running.\n\n## Folder Layout\n\n- `demo/rules-intro/`\n- `demo/maturity/`\n- `demo/rule-types/`\n- `demo/profiles/`\n- `demo/central-config-repo/`\n- `performance/`\n\nStart at the top and work through the lab step by step. Each section below explains:\n- which files to inspect\n- what to edit\n- which command to run\n- what output to expect\n\n## 1. Rules Intro\n\nProblem: Teams need more than one kind of linting rule because some standards are universal, some are organization-specific, and some require contextual/custom logic.\n\nBenefit: Specmatic Linter lets you combine built-in, configurable, and custom JavaScript rules in one governance flow.\n\nThis demo introduces the three kinds of rules:\n- built-in rules\n- configurable rules\n- custom JS rules\n\n### Step 1: Run Built-in Rules\n\n#### Minimal rule-set\n\n```bash\ndocker run --rm -v ./demo/rules-intro:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml\n```\n\n```terminaloutput\n  \"totals\": {\n    \"errors\": 5,\n    \"warnings\": 4,\n    \"ignored\": 0\n  },\n  \"maturity\": {\n    \"level\": \"Gold\"\n  }\n```\n\nThis command lints `openapi.yaml` using the built-in **`minimal` ruleset**, which contains **54 rules**, configured in `specmatic-linter.yaml`.\n\nYou should see the following semantic issues being reported:\n\n- enum values that contradict the declared schema type\n- numeric bounds that make a value impossible\n- regex and length constraints that cannot both be satisfied\n- array schemas without an `items` definition\n- `$ref` definitions that incorrectly include sibling fields\n- `GET` operations with request bodies\n\n#### Recommended rule-set\n\nOpen [demo/rules-intro/specmatic-linter.yaml](demo/rules-intro/specmatic-linter.yaml) and update \n\n```yaml\n      extends:\n        - minimal\n```\n\nto\n\n```yaml\n      extends:\n        - recommended\n```\n\nRun the same command again:\n```bash\ndocker run --rm -v ./demo/rules-intro:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml\n```\n\n```terminaloutput\n  \"totals\": {\n    \"errors\": 7,\n    \"warnings\": 22,\n    \"ignored\": 0\n  },\n  \"maturity\": {\n    \"level\": \"Non compliant\"\n  }\n```\n\nThis lints `openapi.yaml` spec file using the **`recommended` ruleset**, which contains **84 rules**.\n\nSpecmatic Linter can detect issues such as the following:\n\n| Issue Type                  | Other Linters | Specmatic                            |\n|-----------------------------|---------------|--------------------------------------|\n| Constraint Contradictions   | Valid         | Error (Enum/schema contradiction)    |\n| Regex Incompatibility       | Valid         | Error (Pattern vs Length)            |\n| Boundary Violations         | Valid         | Error (Max \u003c Min)                    |\n| Incomplete Schema Shape     | Valid         | Error (Missing data type for arrays) |\n| HTTP Semantic Conflicts     | Valid         | Error (Get with requestBody)         |\n| Schema Composition Problems | Valid         | Error (Ref has siblings)             |\n| Security Overlaps           | Valid         | Warning (Shadowed Schemes)           |\n\nYou can review the full list of Specmatic semantic rules in `demo/rules-intro/specmatic-linter.yaml` under the `### Specmatic's Advanced Semantic Rules ###` section.\n\nAt this point only built-in rules are active.\n\n### Step 2: Enable Configurable Rules\n\nOpen [demo/rules-intro/specmatic-linter.yaml](demo/rules-intro/specmatic-linter.yaml) and uncomment the `include:` block under the `Step 2` comment.\n\nRun the same command again:\n\n```bash\ndocker run --rm -v ./demo/rules-intro:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml\n```\n\n```terminaloutput\n  \"totals\": {\n    \"errors\": 10,\n    \"warnings\": 22,\n    \"ignored\": 0\n  },\n  \"maturity\": {\n    \"level\": \"non_compliant\"\n  }\n```\n\nYou should now see 3 additional violations (errors) from organization-specific YAML DSL rules, including:\n\n- forbidding the parameter name `error`\n- requiring every parameter to include a description\n- allowing only OIDC-based security schemes\n\nTo understand how these rules are structured, see [demo/rules-intro/configurable-rule-anatomy.md](demo/rules-intro/configurable-rule-anatomy.md).\n\n### Step 3: Enable Custom JS Rules\n\nOpen [demo/rules-intro/specmatic-linter.yaml](demo/rules-intro/specmatic-linter.yaml) and uncomment the block under the `Step 3` comment.\n\nThis adds 2 more custom JS rules:\n- `corp-standards/pagination-range`\n- `corp-standards/operation-id-naming`\n\nRun the same command again:\n\n```bash\ndocker run --rm -v ./demo/rules-intro:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml\n```\n\n```terminaloutput\n  \"totals\": {\n    \"errors\": 11,\n    \"warnings\": 23,\n    \"ignored\": 0\n  },\n  \"maturity\": {\n    \"level\": \"non_compliant\"\n  }\n```\n\nYou should now see violations that require JavaScript-based evaluation, including:\n\n- a derived `operationId` naming check reported as a warning\n- a pagination safety rule that validates `limit + offset` reported as an error\n\nCustom JavaScript rules are useful when a rule depends on cross-field logic, computed values, or dynamic expectations that the YAML DSL cannot express cleanly.\n\nFor more detail, see [demo/rules-intro/custom-js-rule-anatomy.md](demo/rules-intro/custom-js-rule-anatomy.md).\n\n## 2. Maturity Levels\n\nProblem: Teams often need a way to measure API quality progressively instead of treating all governance rules as equally mandatory from day one.\n\nBenefit: Maturity levels help teams roll out standards in stages and clearly show the highest quality bar a specification currently satisfies.\n\nThis demo shows:\n- maturity is configured per rule\n- overall maturity is computed from failing error-level rules\n- maturity uses the following hierarchy:\n  - Non Compliant\n  - Baseline\n  - Bronze\n  - Silver\n  - Gold\n  - Platinum\n\n### Step 1: Run the Initial Setup\n\n```bash\ndocker run --rm -v ./demo/maturity:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml\n```\n\n```terminaloutput\n  \"totals\": {\n    \"errors\": 2,\n    \"warnings\": 0,\n    \"ignored\": 0\n  },\n  \"maturity\": {\n    \"level\": \"baseline\"\n  }\n```\n\nThere are 2 errors reported here:\n- `info-license`, which is at the `Gold` level\n- `operation-summary`, which is at the `Bronze` level\n\nSince a rule at the bronze level failed, the maturity is set to `baseline`, the highest level at which all rules are passing.\n\n### Step 2: Raise One Rule's Maturity Level\n\nIn [demo/maturity/specmatic-linter.yaml](demo/maturity/specmatic-linter.yaml), change:\n\n```yaml\nmaturity: bronze\n```\n\nto:\n\n```yaml\nmaturity: silver\n```\n\nRun the same command again:\n\n```bash\ndocker run --rm -v ./demo/maturity:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml\n```\n\n```terminaloutput\n  \"totals\": {\n    \"errors\": 2,\n    \"warnings\": 0,\n    \"ignored\": 0\n  },\n  \"maturity\": {\n    \"level\": \"bronze\"\n  }\n```\n\nThe same 2 rules still fail, but because the failing rule now has a higher maturity level, the overall spec maturity moves up to `bronze`.\n\n### Step 3: Remove One Rule From Maturity Participation\n\nChange the severity for rule `operation-summary` from:\n\n```yaml\nseverity: error\n```\n\nto:\n\n```yaml\nseverity: warn\n```\n\nRun the same command again:\n\n```bash\ndocker run --rm -v ./demo/maturity:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml\n```\n\n```terminaloutput\n  \"totals\": {\n    \"errors\": 1,\n    \"warnings\": 1,\n    \"ignored\": 0\n  },\n  \"maturity\": {\n    \"level\": \"silver\"\n  }\n```\n\nSince `operation-summary` no longer reports an error as it now reports a warning, it no longer participates in the maturity computation. Only rules with severity `error` participate.\n\n## 3. Rule Types\n\nProblem: Running every rule for every use case can create noise when teams want to focus on a specific quality area such as examples, schema, or security.\n\nBenefit: Rule types let teams filter the active ruleset so linting stays targeted, relevant, and easier to adopt.\n\nThis demo shows how `types` lets you filter rules.\n\nBuilt-in rule types:\n- `security`\n- `schema`\n- `examples`\n- `operations`\n- `parameters`\n- `metadata`\n\n### Step 1: Run All Rules\n\n```bash\ndocker run --rm -v ./demo/rule-types:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml\n```\n\n```terminaloutput\n\"totals\": {\n  \"errors\": 9,\n  \"warnings\": 12,\n  \"ignored\": 0\n}\n```\n\n### Step 2: Run rules only of type `examples`\n\nIn [demo/rule-types/specmatic-linter.yaml](demo/rule-types/specmatic-linter.yaml), uncomment:\n\n```yaml\n    types:\n      - examples\n```\n\nRun the same command again:\n\n```bash\ndocker run --rm -v ./demo/rule-types:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml\n```\n\n```terminaloutput\n\"totals\": {\n  \"errors\": 1,\n  \"warnings\": 2,\n  \"ignored\": 0\n}\n```\n\n### Step 3: Run rules of type `examples` or `schema`\n\nIn [demo/rule-types/specmatic-linter.yaml](demo/rule-types/specmatic-linter.yaml), update:\n\n```yaml\n    types:\n      - examples\n``` \nwith\n\n```yaml\n    types:\n      - examples\n      - schema\n``` \n\nRun the same command again:\n\n```bash\ndocker run --rm -v ./demo/rule-types:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml\n```\n\n```terminaloutput\n\"totals\": {\n  \"errors\": 5,\n  \"warnings\": 2,\n  \"ignored\": 0\n}\n```\n\n## 4. Profiles\n\nProblem: Different APIs often need different governance levels, but maintaining separate rule files for each API type quickly becomes hard to manage.\n\nBenefit: Profiles let teams reuse the same base ruleset while adjusting severities and applicability for contexts such as internal and public APIs.\n\nProfiles let teams share one rule catalog while varying enforcement by API type.\n\n### Step 1: Run Without Any Profile\n\n```bash\ndocker run --rm -v ./demo/profiles:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml\n```\n\n```terminaloutput\n\"totals\": {\n  \"errors\": 2,\n  \"warnings\": 8,\n  \"ignored\": 0\n}\n```\n\n### Step 2: Run the `internal` Profile\n\n```bash\ndocker run --rm -v ./demo/profiles:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml --profile internal\n```\n\n```terminaloutput\n\"totals\": {\n  \"errors\": 2,\n  \"warnings\": 7,\n  \"ignored\": 2\n}\n```\n\n### Step 3: Run the `public-api` Profile\n\n```bash\ndocker run --rm -v ./demo/profiles:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml --profile public-api\n```\n\n```terminaloutput\n\"totals\": {\n  \"errors\": 6,\n  \"warnings\": 6,\n  \"ignored\": 0\n}\n```\n\n### Step 4: Tweak A Profile\n\nIn [demo/profiles/specmatic-linter.yaml](demo/profiles/specmatic-linter.yaml), change this inside `public-api`:\n\n```yaml\noperation-summary: error\n```\n\nto:\n\n```yaml\noperation-summary: warn\n```\n\nRerun the `public-api` command:\n\n```bash\ndocker run --rm -v ./demo/profiles:/usr/src/app specmatic/enterprise lint openapi.yaml --config specmatic-linter.yaml --profile public-api\n```\n\n```terminaloutput\n\"totals\": {\n  \"errors\": 5,\n  \"warnings\": 7,\n  \"ignored\": 0\n}\n```\n\n## 5. Central Config Repo\n\nProblem: Governance breaks down when every team copies and edits its own lint configuration, creating drift across local development and CI.\n\nBenefit: A central config repository keeps rule ownership and versioning in one place while allowing teams to opt into the right policy through profile selection.\n\nThis demo shows the central governance model.\n\nLocally, you keep only the spec. The rule config lives in a central Git repository, and the only thing you change is `--profile`.\n\nThis walkthrough uses the public repo:\n- [specmatic/central-linter-config.git](https://github.com/specmatic/central-linter-config.git)\n\n### Step 1: Run with the Default Profile\n\n```bash\ndocker run --rm -v \"./demo/central-config-repo:/usr/src/app\" specmatic/enterprise lint openapi.yaml \\\n  --config-repo-url=https://github.com/specmatic/central-linter-config.git \n```\n\n```terminaloutput\n\"totals\": {\n  \"errors\": 2,\n  \"warnings\": 9,\n  \"ignored\": 0\n}\n```\n\nIf your Specmatic linter config file, `specmatic-linter.yaml`, is not at the top level, pass its path like this:\n\n```bash\ndocker run --rm -v \"./demo/central-config-repo:/usr/src/app\" specmatic/enterprise lint openapi.yaml \\\n  --config-repo-url=https://github.com/specmatic/central-linter-config.git \\\n  --config=specmatic-linter.yaml\n```\n\nIf your central config repo is private, set:\n\n```bash\nexport CENTRAL_CONFIG_REPO_TOKEN=\u003cyour-pat\u003e\n```\n\nThe PAT should have access to that private repo.\n\n### Step 2: Run with `internal-api` profile\n\n```bash\ndocker run --rm -v \"./demo/central-config-repo:/usr/src/app\" specmatic/enterprise lint openapi.yaml \\\n  --config-repo-url=https://github.com/specmatic/central-linter-config.git \\\n  --profile=internal-api\n```\n\n```terminaloutput\n\"totals\": {\n  \"errors\": 6,\n  \"warnings\": 7,\n  \"ignored\": 2\n}\n```\n\n### Why the Central Config Repo Flow Helps\n- no local rule file\n- avoid duplication - each team does not need to tune and maintain rules\n- only profile selection changes locally\n- the central platform or API governance team owns the linting rules\n- one place to manage rules, profiles, severities, and maturity gates\n- simpler org-wide rollout of new standards\n- consistent behavior across local development and CI\n- easier auditing because governance changes are versioned in one repository\n\n## 6. High-Performance Engine\n\nSpecmatic Linter is designed for demanding validation workloads:\n* **Architected for scale**: Processes thousands of specifications in seconds.\n* **Built for parallel execution**: Handles large enterprise workloads efficiently.\n* **Precision-engineered**: Provides deterministic validation and low-noise output.\n* **CI/CD ready**: Delivers lightweight execution with detailed reporting.\n\nThe performance benchmark sample demonstrates that our linter can perform equally well for larger workloads without slowing you down.\n\n`performance/` remains the large benchmark sample.\n\n#### macOS / Linux\n```bash\ncd performance\n./scripts/run-performance-benchmark.sh\n```\n\n#### Windows\n```bat\ncd performance\n.\\scripts\\run-performance-benchmark.cmd\n```\n\n```terminaloutput\n--- Starting Performance Benchmark (Enterprise Estate) ---\nNote: Detailed results for each spec will be saved to performance/results/\nSpecification File        |    Lines |   Errors |   Warnings\n--------------------------+----------+----------+-----------\nspec-1.yaml               |     3409 |      651 |       1902\n...\n...\nspec-50.yaml              |     2167 |      383 |       1384\n--------------------------+----------+----------+-----------\nTOTAL ESTATE              |   102713 |    18041 |      68343\n\nResource Utilization\nAverage CPU Usage: 589.25%\nPeak CPU Usage:    754.46%\n\n✅ SUCCESS: Linted 50 specifications (~12550 paths)\n⏱️  Total Execution Time: 3991ms\n\n📂 Detailed reports saved to: results/\n```\n\nThe benchmark lints 50 large specifications and reports execution time, resource utilization, and generated result artifacts.\n\nFor a meaningful evaluation, compare both the depth of validation and the execution speed of Specmatic Linter against your current linting solution.\n\n## Future Roadmap\n* **Architecture improvements**: Continued investment in the underlying architecture to further improve performance and scalability.\n* **Broader specification support**: Current support focuses on OpenAPI 3.x, with planned linting support for AsyncAPI, Arazzo, GraphQL SDL, Protobuf, Open-RPC, MCP, A2A, and additional formats.\n* **Auto-fix capabilities**: Planned support for automatic remediation of semantic and syntax issues in specifications and examples.\n* **Expanded built-in rulesets**: Broader coverage through additional industry-standard rulesets, including OWASP and JSON Schema-aligned validations.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fspecmatic%2Fspecmatic-linter-sample","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fspecmatic%2Fspecmatic-linter-sample","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fspecmatic%2Fspecmatic-linter-sample/lists"}