Tips and Tricks

Use /snapr analyze before /snapr develop

Before asking Snapr to start development, it’s often helpful to run /snapr analyze first.

This allows Snapr to review the Issue context, identify missing requirements, and ask clarifying questions before any code is written. Running /snapr analyze upfront helps avoid generating Pull Requests based on incomplete or unclear information

Refine before creating sub-issues

When breaking down large Issues into smaller tasks, it’s recommended to use /snapr refine before creating sub-issues.

This allows Snapr to analyze the Issue in detail and propose a structured breakdown into meaningful subtasks. Reviewing the proposal before creating Issues helps ensure tasks are well defined, properly scoped, and aligned with the original intent.

Control Snapr behavior with labels

Snapr reacts to events based on the labels applied to Issues and Pull Requests, which indicate the current phase of work, such as analysis, development, or review.

If you want Snapr to stop reacting at any point, simply remove the corresponding label. This immediately pauses Snapr’s activity. You can later re-add the label to resume the workflow when you’re ready.

Enable periodic housekeeping with the garbage collector

Snapr creates short-lived Kubernetes resources, such as Jobs, Pods, and ConfigMaps, while performing tasks. To keep your cluster tidy and predictable over time, it’s recommended to enable the Snapr garbage collector CronJob.

The garbage collector performs periodic housekeeping by:

• Removing completed Snapr Jobs and Pods
• Cleaning up temporary ConfigMaps created during execution
• Preventing resource accumulation without affecting active workloads

This process is strictly scoped to Snapr-managed resources and does not impact running Jobs or other components in your cluster.