Thanks for your interest in contributing to AgenticPay. This guide covers the expectations for code style, commits, pull requests, and testing so contributions are easy to review and merge.
frontend/: Next.js web applicationbackend/: Express.js API servercontracts/: Soroban smart contracts written in Rust
When possible, keep changes focused to a single area of the codebase. If a change spans multiple areas, call that out clearly in your pull request.
- Fork the repository and clone your fork.
- Create a branch from
main. - Install dependencies in the area you plan to change:
cd backend && npm install
cd frontend && npm install
cd contracts && cargo build- Configure any required environment variables described in README.md.
- Match the existing structure and naming patterns in the files you touch.
- Prefer small, focused pull requests over large mixed changes.
- Do not commit secrets, API keys, or
.envfiles. - Add or update tests when behavior changes.
- Use TypeScript for application code and keep types accurate.
- Run ESLint before opening a pull request.
- Avoid introducing
anyunless there is a clear reason and it is documented in the code. - Remove unused imports, variables, and dead code before submitting.
- Keep components, routes, and services narrowly scoped to one responsibility.
Useful commands:
cd frontend && npm run lint
cd frontend && npm test
cd backend && npm run lint
cd backend && npm test- Follow existing Rust and Soroban patterns in
contracts/src/lib.rs. - Keep contract interfaces explicit and deterministic.
- Build and test contract changes before submitting.
Useful commands:
cd contracts && cargo test
cd contracts && cargo build --target wasm32-unknown-unknown --releaseUse a short, imperative commit message in this format:
type: brief summary
Recommended commit types:
feat: new functionalityfix: bug fixesdocs: documentation updatesrefactor: code changes that do not change behaviortest: adding or updating testschore: maintenance work
Examples:
docs: add contributing guide
fix: handle missing invoice validation
feat: add project payment status badge
Try to keep the summary under 72 characters and make each commit represent one logical change.
- Create a descriptive branch name such as
feat/payment-statusordocs/contributing-guide. - Make your changes in the smallest reasonable scope.
- Run the relevant lint, test, and build commands for the areas you changed.
- Push your branch and open a pull request against
main. - In the pull request description, include:
- a short summary of the change
- linked issue or task reference, if available
- testing notes describing what you ran
- screenshots or recordings for UI changes, if applicable
- Respond to review feedback with follow-up commits unless a maintainer asks for a squash or rebase.
Every contribution should be verified before review.
- Frontend changes: run
npm run lintandnpm testinfrontend/. - Backend changes: run
npm run lintandnpm testinbackend/. - Contract changes: run
cargo testandcargo build --target wasm32-unknown-unknown --releaseincontracts/. - Cross-cutting changes: run checks for every affected area.
- If automated coverage is not practical, include clear manual verification steps in the pull request.
Pull requests may be sent back for updates if they do not include appropriate validation for the code they change.
If you are unsure about an implementation detail, open an issue or start a discussion before investing heavily in a large change. Early alignment helps us review and merge contributions faster.