Contributing

Thanks for helping make Awesome DSH Plugins useful, fast-moving, and accurate.

Before opening a pull request

1. Search the generated catalog in content/plugins.generated.ts to avoid duplicates.
2. Update or replace a source snapshot in data/sources/ instead of hand-editing the generated file.
3. Run npm run generate-content after changing source data.
4. Keep descriptions factual and concise. Do not add performance claims, user counts, compatibility promises, security claims, or official-affiliation language without clear evidence.
5. Use community-discovered unless you personally checked both dsh.bundle.patch and the patch file it references. Structural verification only checks that expected files are present. It is not a security audit or endorsement.
6. Run npm run validate-content, npm run lint, and npm run build.

Listing policy

• Link directly to the public GitHub repository.
• Use the exact repository casing in repository and repoUrl.
• Use the expected command: dsh plugin --profile web add github:owner/repo.
• Use latest: true only for repositories newly added to the current source batch.
• Use featured: true sparingly. Featured status is an editorial display choice, not an endorsement.

Verification process

The repository is intentionally static and has no server-side trust system. A structural-verification review should record that the repository contains dsh.bundle.patch and that the file named by that bundle exists. Do not describe this as code review, security validation, or guaranteed compatibility.

Maintainers may adjust a submitted category, description, verification label, or launch flags to keep the collection consistent.