Open Source Triage GitHub Issue/PR Template Compliance Review Prompt

PROMPT.md

Please review this issue or pull request against the repository's own template and tell me whether the linked item itself follows it well enough:

[PASTE ISSUE OR PR LINK HERE]

What I want you to do:

1. Open the linked issue or pull request.
2. Find the relevant template in the repository that should apply to it.
   • Check common locations such as:
     • .github/ISSUE_TEMPLATE/
     • .github/ISSUE_TEMPLATE/config.yml
     • .github/pull_request_template.md
     • .github/PULL_REQUEST_TEMPLATE/
     • .gitlab/issue_templates/
     • .gitlab/merge_request_templates/
   • Also check whether the repository uses issue forms, contribution docs, or other linked guidance instead of plain template files.
3. Compare the actual content of the linked issue or PR itself against that template.
4. Decide which of these cases applies:
   • "Matches well enough"
   • "Slight deviation"
   • "Significant deviation"

Core rule: Evaluate whether the linked issue or PR itself follows the template. Do NOT give credit for information that exists only in:

• the linked issue from a PR
• the linked PR from an issue
• commit messages
• comments
• review threads
• changed files
• CI output
• any other external context

Only count something as present if it is actually included in the linked issue or PR body itself, unless the template explicitly says that the information may live somewhere else.

Important exception: For the final suggested comment, scan the entire linked issue or PR body and avoid asking for information that is already mentioned somewhere else in that same body, even if it is not in the expected template section.

Decision rule:

• Use "Matches well enough" only when the linked issue or PR itself substantially follows the template and includes the required sections or equivalent answers, so asking for more would mostly be cosmetic or unnecessary.
• Use "Slight deviation" when the linked issue or PR mostly follows the template, but a small number of specific required parts are missing, incomplete, incorrectly filled, or materially changed from the template in a way that reduces clarity.
• Use "Significant deviation" when the linked issue or PR does not substantially follow the template, omits several required parts, discards the structure to the point that review or triage is harder, or would be easier to fix by asking the author to follow the template directly.

Very important interpretation rules:

• Do not invent template requirements that are not actually present in the repository.
• Do not treat the linked issue or PR as compliant just because the missing information exists elsewhere outside the linked item's body.
• Be precise about what is missing.
• Prefer the repository's own wording and structure where possible.
• If you cannot find a relevant template, say so clearly instead of guessing.
• If the issue or PR is already good enough, say that and do not draft a comment.

How to judge content-equivalent answers:

• A section can count as present even if the author does not keep the exact template wording.
• A section can count as present even if the author removes instructional text from the template.
• A section can count as present even if the author slightly reformats it.
• A section can count as present if the author clearly provides the substance the template asks for in that section.
• Do NOT require verbatim copying of the template.
• Do NOT require unused checkbox options or helper text to remain unchanged.
• Do NOT treat harmless rewording as a problem if the meaning stays equally clear and complete.

Checkbox and option-list rules:

• For markdown checkbox lists, assume the author is supposed to check the relevant item or items.
• Do NOT treat it as a problem that unchecked options are still visible, unless the template explicitly says to remove non-applicable options or rewrite the section.
• If the template says "select one", then exactly one applicable option should be checked.
• If the template says "select all that apply", then one or more applicable options may be checked.
• If the template does not explicitly say "select one", assume multiple options may be checked.
• If the author removes non-applicable options and leaves only the selected or relevant ones, that is acceptable if the intended choice is still clear.
• If the author keeps the checkbox list but does not actually make the required selection, count that as incomplete.
• Only call a checkbox section incomplete if the required selection was not made, the wrong number of options was selected, or the template explicitly requires something else.

Very important rules for checkbox label alignment:

• Compare the labels of the selected options against the current template.
• If a selected option uses wording that is materially different from the template and becomes less precise, broader, narrower, or otherwise ambiguous, count that as a template-compliance gap.
• Examples of materially different selected labels:
  • template says "Bug fix", PR says "Issue"
  • template says "Refactor required for the fix", PR says "Refactor"
• In those cases, treat it as a deviation even if the general intent seems similar, because the template wording is more precise.
• For selected options, minor formatting-only differences are fine, but wording changes that affect meaning or clarity are not.
• Ignore differences in unchecked options unless they make the selected choices unclear.
• Ignore omitted unchecked options.
• Ignore renamed unchecked options.
• Do not treat unchecked-option differences by themselves as a reason to comment.

How to judge checkbox inconsistencies:

• If selected checkbox choices clearly conflict with the linked item's own body, count that as a possible issue to review.
• But do NOT automatically include such possible inconsistencies in the main comment unless the inconsistency is clearly supported by the linked body's text.
• Instead, put suspicious or possibly inconsistent selections into a separate "Things to check manually" section.
• Examples:
  • both "Bug fix" and "Feature" are selected, but the body clearly describes only a bug fix
  • "Security hardening" is selected, but nothing in the body suggests a security change
• Only include a checkbox inconsistency in the main suggested comment when the mismatch is strong and directly supported by the linked body's own description.

How to judge non-checkbox internal inconsistencies:

• Also look for contradictions, unexplained scope shifts, or materially inconsistent wording anywhere in the linked issue or PR body itself.
• Compare statements across the body, and also compare the title against the body for possible contradictions or scope drift. You may use the title for inconsistency checking, but not for giving template-compliance credit.
• Examples of things to flag for manual checking:
  • the summary says this adds support for lemons, but a later section says it adds support for apples and removes lemon support
  • one section says this is a bug fix, but another says it is a new feature
  • the root cause section describes one problem, but the proposed solution appears to solve a different problem
  • the summary, impact, and user-visible changes describe materially different scopes
  • the PR says "no user-visible changes", but another section describes clear user-visible behavior changes
• Do NOT automatically treat every inconsistency as a template-compliance gap.
• If the inconsistency makes a required section unclear, self-contradictory, or unreliable, it can count as a compliance gap.
• Otherwise, put it into "Things to check manually".
• Only include a non-checkbox inconsistency in the main suggested comment when the contradiction is strong, materially affects understanding, and is directly supported by the linked item's own text.

How to judge sections:

• If a section is required by the template, the linked issue or PR should either:
  • fill it in clearly, or
  • explicitly answer "None", "Not applicable", or an equivalent response if that satisfies the template.
• If a section is conditionally required, check whether the condition applies.
• If a section is present only as a vague placeholder, heading, or one-word filler that does not answer the prompt, count it as incomplete.
• If a section is present but clearly self-contradictory, count it as unreliable.
• If multiple important required sections are missing, incomplete, or unreliable, prefer "Significant deviation".

Stricter classification guidance:

• Lean toward "Significant deviation" when the linked item has largely abandoned the template structure and replaced it with free-form text.
• Lean toward "Significant deviation" when several required sections are missing, even if the overall change is understandable from other context.
• Lean toward "Slight deviation" only when the template is mostly followed and the remaining gaps are truly limited and specific.
• Do not downgrade to "Matches well enough" just because the reviewer can infer the missing information from the PR title or issue title.
• A selected checkbox label that is materially changed from the template should usually prevent "Matches well enough", even if the rest looks fine.

Evidence rule:

• For every item you claim is missing, incomplete, or unreliable, quote or summarize the exact template instruction that makes it required.
• For every selected checkbox label you claim is misaligned, quote both:
  • the template label
  • the label used in the linked issue or PR and explain briefly why the change reduces clarity or changes meaning.
• For every internal inconsistency you flag, quote or summarize the conflicting statements.
• If you cannot point to a specific instruction in the template, do not count it as missing.

Very important comment-drafting rule: Before writing the suggested comment, do a second pass over the entire linked issue or PR body and separate each problem into these categories:

1. "Template compliance gap"

   • the template section is missing, incomplete, misplaced, not properly followed, unreliable because it is self-contradictory, or uses materially changed selected checkbox wording

2. "Genuinely missing information"

   • information that is not present anywhere in the linked issue or PR body and is still needed to satisfy the template or understand the item

3. "Possible internal inconsistency"

   • the linked issue or PR body appears to contradict itself, shift scope, or use materially inconsistent wording, but it is not certain enough to put into the main comment automatically

Rules for drafting the suggested comment:

• Do NOT ask the author to add information that is already present somewhere else in the same linked issue or PR body.
• If information is already present elsewhere in the same body, do not ask for that information again.
• If needed, ask the author to clarify or expand only the parts that are still genuinely missing.
• If a section is structurally incomplete but most of its substance already exists elsewhere in the same body, the comment should only ask for the still-missing substance, not for a full restatement.
• If the result is "Significant deviation", do NOT list lots of individual missing details in the comment. Instead, ask the author to follow the template and include a direct link to that template.
• If the result is "Slight deviation", ask only for the net-new information still missing from the linked body's content, plus any concrete template-alignment fixes that are needed, such as selected checkbox labels that should be aligned with the template wording.
• If the only real issue is that selected checkbox labels were materially changed from the template, the comment should mention that and ask the author to align those selections with the current template wording.
• Do NOT automatically include "Possible internal inconsistency" items in the main suggested comment.
• Instead, put them in "Things to check manually" and provide optional snippets I could add myself if, after manual review, I decide they are worth mentioning.
• Do NOT ask for pure reformatting unless the formatting problem itself makes the content unclear or makes the template meaningfully harder to follow.

Very important template-link rule for the suggested comment:

• If the comment asks the author to follow, align with, rework against, or update something according to the template, include a direct link to that template in the comment.
• If the comment already spells out exactly what to add or change in enough detail that the author does not need the template to act, the template link is optional.
• If there is any doubt, include the template link.
• For "Significant deviation", always include the template link.
• For "Slight deviation", include the template link whenever the comment refers to aligning with the template or following the template, including cases like mismatched checkbox labels or other wording that should match the template.

Style rules for the suggested comment:

• Always use the word "template", never "form".
• Sound like a contributor, not a maintainer giving orders.
• Be concise, polite, and direct.
• Prefer phrasing like:
  • "Could you please update the description to follow the template more closely?"
  • "Could you please align the selected change types with the current template?"
  • "Can you please update this to match the template here: [link]?"
• Avoid weak phrasing such as:
  • "Would you mind..."
  • "If you want..."
  • "You may want to..."
• Avoid empty praise or filler such as:
  • "Thanks for opening this"
  • "This looks good otherwise" unless it clearly improves the tone without weakening the request.
• If useful, include one short reason such as:
  • "This would make it easier to review."
  • "This would make it easier to triage."
  • "This would make the intended scope clearer."
• Make the comment feel connected as a whole. Prefer one connected comment over two loosely related paragraphs.
• If the comment says the issue or PR is close to the template, immediately connect that to the concrete request in the same sentence or the very next sentence.
• Keep the main comment actionable. It should tell the author exactly what to do next.

Final sanity check before producing the suggested comment:

• Re-read the linked issue or PR body.
• Re-check that the comment does not ask for anything already present somewhere else in that same body.
• Re-check that every requested change is either:
  • genuinely missing information, or
  • a real template-alignment fix that improves clarity.
• Re-check that the comment uses "template", not "form".
• Re-check that the template link is included whenever required by the rules above.
• Re-check that the comment is not weaker than intended.

Examples of how to apply this:

• If the template asks "who is affected, severity, frequency, and practical consequence", and the issue body already makes "who is affected" clear elsewhere, do not ask for that again. Only ask for severity, frequency, and practical consequence if those are still missing.
• If the PR body already explains the root cause in a different section, do not ask for root cause again just because it is not under the exact heading.
• If the template says "Bug fix" and the PR uses "Issue" as a selected option, treat that as a slight deviation and ask the author to align the selected change type with the template wording, and include the template link in that comment.
• If the template says "Refactor required for the fix" and the PR uses "Refactor" as a selected option, treat that as a slight deviation and ask the author to align it with the template wording, and include the template link in that comment.
• If an unchecked option differs, such as "Chore/infra" in the template vs "CI" in the PR, ignore it unless it makes the selected choices unclear.
• If one part of the text says support is being added for lemons, but another part says support is being added for apples and lemon support is removed, do not automatically include that in the main comment. Put it in "Things to check manually" and provide an optional snippet I could add if that contradiction is real and worth mentioning.

Output format:

Result

One of:

• Matches well enough
• Slight deviation
• Significant deviation

Template found

• Give the exact template you found
• Include a link to it
• Briefly summarize what it asks for

Template compliance gaps

• List the actual template-following problems in the linked issue or PR itself
• For each one, explain why it is a gap based on the template's actual instruction
• If the gap is a selected checkbox label mismatch, quote both the template label and the actual label used
• If none, say "None"

Information already present elsewhere in the linked body

• For each compliance gap, note any relevant information that is already present somewhere else in the same issue or PR body
• This section exists to prevent over-asking in the final comment
• If none, say "None"

Genuinely missing information

• List only the information that is not present anywhere in the linked issue or PR body and is still needed
• If none, say "None"

Things to check manually

• List only suspicious checkbox selections, contradictions, scope shifts, or other internal inconsistencies that might be wrong but are not certain enough to put into the main comment
• Do not include harmless unchecked-option differences
• For each item, quote or summarize the conflicting text and explain briefly why it looks suspicious
• If none, say "None"

Suggested comment

Rules for the comment:

• Be concise
• Be polite
• Sound like a contributor, not a maintainer giving orders
• If it is a slight deviation, mention only the genuinely missing information and any concrete template-alignment fixes that are actually needed
• Do not ask for information that is already present elsewhere in the same linked issue or PR body
• If it is a significant deviation, ask the author to follow the template and include a direct link to that template
• Do not list lots of individual missing details for significant deviation
• Do not mention anything that is already present in the linked issue or PR body
• Always say "template", never "form"
• Include the template link whenever the comment asks the author to align with or follow the template, unless the comment already explicitly states exactly what to add or change
• Put the comment in a four backtick markdown code block so I can easily copy it

Optional comment snippets for manual use

• Only include this section if "Things to check manually" is not "None"
• Give short optional snippets I could add to the comment manually if, after my own review, I decide those suspicious items are worth mentioning
• Keep these snippets separate from the main suggested comment
• Each snippet should correspond to one manual-check item
• The snippets should be phrased as tentative checks, not accusations

For "Matches well enough", write:

• "No comment needed"

Please do the analysis first, then provide the final suggested comment exactly as I could post it.