Custom PR prompts let you teach DevDaily AI how to write PR descriptions that match your team’s conventions, tone, and structure. Think of it like a “CLAUDE.md” file but specifically for PR descriptions.
When generating a PR description, DevDaily searches for a custom prompt file in your repository. If found, the file contents are injected into the AI prompt as “team guidelines” that the AI must follow.This allows you to:
Enforce team-specific PR description formats
Control tone and style (formal vs. casual, technical vs. business-focused)
Require specific sections (testing instructions, breaking changes, etc.)
Create a file at .devdaily-pr-prompt.md in your repo root:
Copy
# PR Description GuidelinesThese guidelines tell DevDaily AI how to generate PR descriptions for your team.## Tone & Style- Write in a professional but approachable tone- Be concise — aim for clarity over verbosity- Use bullet points for lists of changes- Avoid jargon unless it's well-known in the team- No emojis in the description body## Description Format- Start with a one-sentence summary of what the PR does- Follow with bullet points of specific changes- Group related changes together- Mention any architectural decisions or trade-offs## Ticket References- Always include ticket IDs (e.g., PROJ-123) when available- Link to the ticket URL when possible- Explain how the changes relate to the ticket's acceptance criteria## Testing Instructions- Provide step-by-step instructions for reviewers to test- Include any required environment setup- Mention edge cases that should be verified- Include expected vs actual behavior for bug fixes## Breaking Changes- Clearly call out any breaking changes- Explain migration steps if applicable- Tag breaking changes with a warning## What NOT to Include- Don't list every file changed (that's in the diff)- Don't repeat commit messages verbatim- Don't include implementation details that are obvious from the code- Don't include TODOs — create follow-up tickets instead
The prompt file is parsed into structured sections based on markdown headings (h1-h3). Each section becomes a “guideline” that the AI follows.From src/core/pr-prompt.ts:89:
Copy
export function parsePRPrompt(content: string): PRGuideline[] { const guidelines: PRGuideline[] = []; const lines = content.split('\n'); let currentHeading: string | null = null; let currentContent: string[] = []; let insideCodeBlock = false; for (const line of lines) { // Track code blocks so we don't treat headings inside them as real headings if (line.trimEnd().startsWith('```')) { insideCodeBlock = !insideCodeBlock; } // Only match headings when NOT inside a code block const headingMatch = !insideCodeBlock ? line.match(/^#{1,3}\s+(.+)$/) : null; if (headingMatch) { // Save previous section if (currentHeading !== null) { guidelines.push({ heading: currentHeading, content: currentContent.join('\n').trim(), }); } currentHeading = headingMatch[1].trim(); currentContent = []; } else if (currentHeading !== null) { currentContent.push(line); } } return guidelines;}
Headings inside code blocks are ignored so you can safely include examples.
When a custom prompt is found, it’s formatted and injected into the AI prompt:
Copy
export function formatPRPromptForAI(promptConfig: PRPromptConfig): string { const lines: string[] = [ '', '=== TEAM PR DESCRIPTION GUIDELINES (follow these strictly) ===', '', ]; if (promptConfig.guidelines.length > 0) { for (const guideline of promptConfig.guidelines) { lines.push(`### ${guideline.heading}`); if (guideline.content) { lines.push(guideline.content); } lines.push(''); } } else { // No structured guidelines — just include the raw content lines.push(promptConfig.raw); lines.push(''); } lines.push('=== END TEAM GUIDELINES ==='); lines.push(''); return lines.join('\n');}
This clear delineation tells the AI to treat these as strict rules.
## Business ValueEvery PR description MUST explain:- What problem this solves for users- Why this change is important now- What the expected impact is (revenue, conversion, retention, etc.)Do NOT write technical descriptions without business context.
## Visual ChangesFor any UI changes:- Include before/after screenshots- Show both desktop and mobile views- Highlight the specific areas that changedUse this format:
## Ticket ReferencesAlways include:- Jira ticket ID in the format: `[PROJ-123]`- Link to ticket: `https://company.atlassian.net/browse/PROJ-123`- Quote the acceptance criteria from the ticketExample:
## Tone- Use first-person ("I implemented..." not "This PR implements...")- Be conversational and friendly- Celebrate wins ("This was tricky but we nailed it!")- Acknowledge reviewers ("@alice might want to review the API changes")
