sure/CONTRIBUTING.md

Contributing to Sure

It means so much that you're interested in contributing to Sure! Seriously. Thank you. The entire community benefits from these contributions!

House Rules

• Before contributing, familiarize yourself with our project conventions. You should read through our Project Conventions Rule, which is intended for LLMs, but is also an excellent primer on how we write code for Sure.
• While totally optional, consider using Cursor + VSCode as it will automatically apply our project conventions to your code via the .cursor/rules directory.
• Before contributing, please check if it already exists in issues or PRs
• Given the speed at which we're moving on the codebase, we don't assign issues or "give" issues to anyone.
• When multiple PRs are submitted for the same issue, we take the one that most succinctly & efficiently solves a given problem and stays within the scope of work.
• Priority is generally given to previous committers as they've proven familiarity with the codebase and product.

What should I contribute?

As we are still in the early days of this project, we recommend heading over to the Wiki to get a better idea of what to contribute.

In general, full features that get us closer to our 🔜 Vision are the most valuable contributions at this stage.

Development

Setup

To get setup for local development, you have two options:

1. Dev Containers with VSCode (see the .devcontainer folder)
   • A selenium/standalone-chrome service is included in the Dev Container setup, so system tests work out of the box — no local Chrome required.
   • Run system tests: DISABLE_PARALLELIZATION=true bin/rails test:system
   • Watch the browser live at http://localhost:7900 or http://localhost:4444 (password: secret)
2. Local Development
   • Mac Setup Guide
   • Linux Setup Guide
   • Windows Setup Guide

Making a Pull Request

1. Fork the repo
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Add some feature')
4. Push to the branch (git push origin my-new-feature)
5. Create new Pull Request, and be sure to check the Allow edits from maintainers option while creating your PR. This allows maintainers to collaborate with you on your PR if needed.
6. If possible, link your pull request to an issue by adding the appropriate keyword (e.g. fixes issue #XXX)
7. Before requesting a review, please make sure that all Github Checks have passed and your branch is up-to-date with the main branch. After doing so, request a review and wait for a maintainer's approval.

All PRs should target the main branch.

Automated Security Scanning

Every pull request to the main branch automatically runs a Pipelock security scan. This scan analyzes your PR diff for:

• Leaked secrets (API keys, tokens, credentials)
• Agent security risks (misconfigurations, exposed credentials, missing controls)

The scan runs as part of the CI pipeline and typically completes in ~30 seconds. If security issues are found, the CI check will fail. You don't need to configure anything—the security scanning is automatic and zero-configuration.