PRism Guide

Everything you need to get the most out of PRism.

Quick start

Install the extension and sign in (or create a free account).
Navigate to a PR creation page on GitHub or GitLab.
Click the Generate button in the PRism panel.
Review the generated title and description, make any edits, and submit your PR.

Templates

Templates control the structure and content of your generated PR description. PRism ships with 5 built-in templates:

Minimal

Quick and concise for small, self-explanatory changes

## Summary
{summary}

## Changes
{what_changed}

## Testing
{test_cases}

Standard

Balanced template for everyday PRs

## Summary
{summary}

## Changes
{what_changed}

## Environment Changes
{env_changes}

## Testing
{test_cases}

Feature

Comprehensive template for new features with dependencies and verification

## Summary
{summary}

## Feature Description
{feature_description}

## Implementation Details
{implementation_details}

## Environment Changes
{env_changes}

## Third-Party Changes
{third_party_changes}

## Breaking Changes
{breaking_changes}

## How to Test
{test_plan}

Bugfix

Structured for bug fixes with root cause analysis and blast radius

## Bug Summary
{bug_summary}

## Root Cause
{root_cause}

## Fix
{fix_description}

## Affected Areas
{affected_areas}

## How to Test
{test_plan}

Enterprise

Full-detail for enterprise teams with business context, compliance, and rollback

## Summary
{summary}

## Business Context
{business_context}

## Solution Approach
{solution_approach}

## User-Facing Changes
{user_facing_changes}

## Breaking Changes
{breaking_changes}

## Compliance & Security
{compliance_notes}

## How to Test
{test_plan}

## Rollback Plan
{rollback_plan}

Pro and Max plans can create unlimited custom templates with any combination of placeholders.

Placeholder reference

Placeholders are wrapped in curly braces (e.g., {summary}) inside template bodies. The AI fills each one based on the diff.

Placeholder	Description
`{summary}`	Concise 2-3 sentence summary of what this PR does and why. Focus on intent and outcome.
`{what_changed}`	Bullet-point list of specific changes made, grouped logically. Include affected file or module in parentheses where helpful.
`{test_cases}`	Brief bullet-point list of what was tested or should be tested — unit tests, integration tests, and manual verification.
`{test_plan}`	Step-by-step numbered instructions a reviewer can follow to verify the changes. Include preconditions, exact steps, and expected outcomes.
`{env_changes}`	New or changed environment variables, config files, feature flags, or infrastructure dependencies. Include variable name, purpose, and example value. Output "None" if not applicable.
`{breaking_changes}`	Breaking changes to public APIs, interfaces, data formats, or behavior with migration steps. Output "None" if not applicable.
`{feature_description}`	Clear description of the new feature — what it enables that was not possible before.
`{implementation_details}`	Bullet-point list of key implementation decisions, architectural approach, design patterns used, and technical trade-offs.
`{third_party_changes}`	New, updated, or removed third-party dependencies with version numbers. Output "None" if not applicable.
`{bug_summary}`	Concise description of the bug: incorrect behavior, who was affected, and under what conditions it occurred.
`{root_cause}`	Technical explanation of why the bug occurred — faulty logic, race condition, missing validation, or incorrect assumption in the code.
`{fix_description}`	How the bug was fixed, the approach taken, and why it is the correct solution.
`{affected_areas}`	Modules, components, endpoints, or features affected by this bug and its fix (blast radius).
`{business_context}`	Business problem or user need this PR addresses. Written for a product manager audience, avoid technical jargon.
`{solution_approach}`	Technical approach, architecture decisions, trade-offs considered, and why this approach was chosen.
`{user_facing_changes}`	Changes visible to end users: UI updates, new functionality, behavior changes, API modifications. Output "None" if not applicable.
`{compliance_notes}`	Security, privacy, accessibility, or regulatory considerations. Note if security review or audit is needed. Output "None" if not applicable.
`{rollback_plan}`	How to safely revert these changes if issues arise in production — migrations to reverse, flags to toggle, config to undo.

Tips

Set a default template — saves a click every time. Go to Templates in the extension popup and mark your favorite as default.
Use additional prompts — add context the AI can't infer from the diff, like "this is a hotfix for production" or "focus on the API changes."
Keep diffs focused — smaller, single-purpose PRs produce better descriptions. If your diff is huge, consider splitting the PR.
Edit after generation — PRism fills the form but doesn't submit. Always review and add any context the AI might have missed.

Need more generations?

Upgrade your plan for more monthly generations and custom templates.

View Pricing