- Work on
devbranch - Make atomic commits
- Do not merge to
mainunless the user explicitly asks for it - When a change is merged to
main, determine the next version bump automatically from the code changes, create the new tag automatically, and push all resulting commits and tags
Follow conventional commit format. First line must be less than 78 characters.
<type>(<scope>): <icon> <short description>
feat: ✨ A new featurefix: 🐛 A bug fixdocs: 📝 Documentation updatesstyle: 💄 Formatting, missing semi-colonsrefactor: ♻️ Code change that neither fixes a bug nor adds a featuretest: ✅ Adding or correcting testschore: 🔧 Build process or auxiliary toolsci: 👷 CI configuration files and scriptsbuild: 🏗️ Build system changesrevert: ⏪ Reverting changeswip: 🚧 Work in progress
- Long description should explain why the change was made
- Reference related issues (e.g.,
Fixes #123) - If breaking change, include
BREAKING CHANGE: <description>
- Write clear and concise comments for each function
- Use descriptive names with type hints
- Break down complex functions into smaller ones
- Prioritize readability and clarity
-
Use numpy-style docstrings (PEP 257)
-
Include docstrings immediately after
deforclass -
Docstring format:
def function(param: type) -> return_type: """Short summary. Longer description if needed. Parameters: param (type): Description Returns: return_type: Description """
- Follow PEP 8 style guide
- Use 4 spaces for indentation
- Max line length: 79 characters
- Group imports: stdlib, third-party, local (separated by blank lines)
- Include test cases for critical paths
- Account for edge cases (empty inputs, invalid types)
- For ImageJ/Fiji code, add "Works on" section (2D, 3D, 4D, etc.)
- Logo: Generate a project-specific logo
- Title: Project name as
#header - Purpose: 1-2 paragraph explanation
- Requirements: Dependencies, hardware, environment
- Input and Expected Output: Data formats, visualization types
- Detailed Explanation: Architecture, logic, inner workings
Follow all markdownlint (MDxxx) rules:
- Use ATX-style headers (
#,##, etc.) - Include a blank line after headers
- Use fenced code blocks with language identifiers
- Keep lines under 80 characters
- Use consistent indentation (2 or 4 spaces)
- No trailing whitespace
- Include alt text for images
- Use inline links, keep URLs on separate lines if long
- Use ordered lists for sequential steps, unordered for non-sequential
- Use consistent quote styles (double quotes)
- Include proper spacing between block elements