Thank you for your interest in contributing. jitsudo is in early development — contributions, feedback, and design input are all welcome.

• Check open issues and discussions before opening a new one.
• For significant changes (new providers, CLI interface changes, policy engine design), open an issue first to align on approach before writing code.
• All contributions are subject to the Contributor License Agreement and must follow the Code of Conduct.

Prerequisites and setup instructions will be added once the initial implementation lands.
Watch jitsudo-dev/jitsudo for updates.

Open a GitHub issue with:

• A clear description of the unexpected behavior
• Steps to reproduce
• Your OS, shell, and jitsudo version output
• Any relevant logs (redact credentials and account IDs)

Open a GitHub Discussion describing:

• The problem you're solving
• The provider(s) involved
• How you'd expect the CLI or policy to behave

1. Fork the repository
2. Create a feature branch: git checkout -b feat/your-feature
3. Write tests for any new behavior
4. Run the test suite before submitting
5. Open a pull request against main with a clear description

Each provider lives in its own package under internal/providers/. A new provider must implement the Provider interface (documented in the main repo) and include:

• Elevation and revocation logic
• Integration tests against a real or mocked API
• Documentation in docs/providers/

• Follow standard Go formatting (gofmt, goimports).
• Keep public APIs minimal and well-documented.
• Prefer explicit error handling over panics.
• Security-sensitive code paths require inline comments explaining the invariant being upheld.

By submitting a pull request, you confirm that you have the right to contribute the code and that your contribution may be distributed under the project's open-source license.

Open a GitHub Discussion — that's the right place for design questions, provider support requests, and general feedback.