Skip to navigation
DevelopmentDeveloper Onboardinginstruction files

pullrequest guidelines

Pull Request Title

  • Format: Autobots | <User Story ID> | <Developer-Written Summary>
  • Requirements:
    • Must include the team name, User story ID, and a concise developer-written summary
    • The summary should clearly describe the primary change or outcome
    • User story ID can be parsed from the branch name
    • Branch naming convention: <Developer-Initials>_<summary>_<User Story ID>

Pull Request Description

Required Order and Structure

  1. Pull Request Template
  • Always begin the Pull Request Description by pasting the full contents of pull_request_template.md as raw markdown at the very top.
  • Do not wrap the template in a code block, quote block, or fence.
  • Do not indent the template content.
  • Do not summarize, paraphrase, or partially include the template.
  • The template must render exactly as it does in its source file.
  • All other sections must appear after the full template content.
  1. Work Item Reference
  • The first line a work item reference.
  • Use the format: AB#<id>
  • Do not add explanatory text on this line.
  1. High-Level Summary
  • One concise paragraph
  • Describe what the PR introduces or changes and why
  • Focus on intent, scope, and system impact
  • Avoid low-level implementation detail
  • Do not include generic or inferred statements (e.g. “to enhance efficiency”, “to improve performance”, “to increase reliability”) unless the PR explicitly contains a concrete change that proves it and you can point to the exact file(s) and change(s) that support the claim.
  • If you cannot tie a summary statement directly to an explicit change listed in the File-by-File Change List, remove it.
  • When in doubt, write only what changed in observable terms (updated X, removed Y, added Z) and omit the implied motivation or outcome.
  1. Explicit File-by-File Change List
  • Required for all meaningful changes
  • One file per line
  • Format:
`path/to/file.ts` - Brief, action-oriented description
  • Use past tense and consistent wording
  • No headings, no blank lines, no trailing commentary

Content Rules

  • Start from pull_request_template.md if present
  • Consolidate and merge commit messages into a clean narrative
  • Insert consolidated changes under the correct sections
  • List every meaningful file that was modified
  • A reviewer should understand scope without opening files

Language and Style Rules

  • Clear, direct, technical language only
  • No emojis
  • No em dashes (—)
  • Use straight apostrophes (’)`
  • Avoid subjective terms like simple, quick, or minor

Review Checklist

Before submitting, confirm:

  • Title follows the required format
  • Developer-written summary is clear and specific
  • Work item link is present and correct
  • Summary explains the why, not just the what
  • All significant files are listed
  • Formatting matches this guide exactly