Getting Started
We welcome contributions to Prompts.dev! This guide will help you get started with contributing code, documentation, or bug reports.Prerequisites
Before contributing, make sure you have:- Completed the local development setup
- Read the architecture overview
- Familiarized yourself with the codebase structure
Contribution Workflow
Create a branch from main
feature/- New featuresfix/- Bug fixesdocs/- Documentation updatesrefactor/- Code refactoring
Make your changes
- Keep changes focused and atomic
- Write clear, self-documenting code
- Add tests for new functionality
- Update documentation when behavior changes
Commit your changes
Pull Request Guidelines
Keep PRs Focused and Small
Smaller pull requests are easier to review and merge faster. Aim for PRs that solve one problem or add one feature.
- Add search endpoint for prompts
- Fix JWT token expiry validation
- Update API documentation for versions endpoint
- Mixing multiple unrelated changes
- Large refactors combined with new features
- Reformatting entire files alongside logic changes
Include Tests or Verification Notes
Every PR should include one of:-
Automated tests (preferred)
-
Manual testing steps
-
Verification notes (for docs/config changes)
Update Documentation
Update documentation when:- API contracts change (update
docs/api/openapi.yaml) - New features are added (update relevant
.mdfiles) - Configuration options change (update
.env.exampleand docs) - Architecture changes (update
docs/architecture.md)
Code Quality Standards
Required Pre-PR Checks
Run these commands before opening a pull request:Code Formatting
We use gofmt for consistent Go code formatting:All Go code must be formatted with
gofmt. PRs with unformatted code will not be merged.Testing Guidelines
Write tests for:- New business logic
- Bug fixes (regression tests)
- Complex validation logic
- Repository methods
API Change Policy
OpenAPI Specification Updates
All API changes must updatedocs/api/openapi.yaml in the same PR.
Example scenario:
Adding a new field to the prompt response:
Error Response Consistency
Error envelopes must remain consistent withinternal/server/respond.go:
Versioning
Keep all routes under/v1 unless introducing a breaking API version:
Commit Style
Commit Message Format
Use concise, imperative commit messages:Explain the “Why”, Not Just the “What”
Commit messages should explain the motivation: Good:Atomic Commits
Each commit should be a logical unit:- ✓ One commit per feature/fix
- ✓ All tests pass at each commit
- ✗ Multiple unrelated changes in one commit
- ✗ “Fix previous commit” commits (use
git commit --amendinstead)
Documentation Style
Writing Documentation
When contributing to documentation:-
Prefer short sections with concrete examples
- Use real request/response examples Show actual API responses, not placeholders
- Keep docs aligned with implementation Documentation should reflect current behavior, not planned features
-
Use clear headings and structure
- Use
##for main sections - Use
###for subsections - Use code blocks with language hints
- Use
Code Review Process
What Reviewers Look For
-
Code Quality
- Follows Go best practices
- Properly formatted with
gofmt - Clear variable and function names
-
Testing
- Tests cover new functionality
- Edge cases are handled
- Tests are readable and maintainable
-
Documentation
- API changes include OpenAPI updates
- README or docs updated if needed
- Code comments for complex logic
-
Architecture
- Follows existing patterns
- Respects module boundaries
- Uses interfaces for dependencies
Responding to Feedback
- Address all reviewer comments
- Ask questions if feedback is unclear
- Push new commits (don’t force-push during review)
- Mark conversations as resolved when addressed
Common Tasks
Adding a New API Endpoint
Adding a Database Migration
Getting Help
Questions or Issues?
- General questions: Open a discussion on GitHub
- Bug reports: Open an issue with reproduction steps
- Feature requests: Open an issue with use case description
- Security issues: Email [email protected] (do not open public issues)