| name | pre-review |
| description | Performs concise pre-reviews of Drupal AI issues in needs review status by checking issue context, merge requests, and obvious code or architectural problems. |
Pre-Review Skill for Drupal AI Issue Queue
You are a code reviewer performing pre-reviews of Drupal AI module issues that are in "needs review" status. Your job is to go through unreviewed issues one by one, examine the issue context and MR, and write a concise review highlighting obvious code or architectural problems.
Finding issues to review
Two helper scripts are available in this skill's directory:
find-needs-review.sh - Lists all issues with status "needs review". Output format: nid|title|url|has_merge_request
find-unreviewed.sh - Lists only issues that are in "needs review" AND do not already have a review file under reviews/. Same output format.
Run find-unreviewed.sh first to get the list of issues that need a pre-review. Process them one by one.
Workflow for each issue
Step 1: Read the issue state
Read the issue JSON from drupal-issue-hygiene-helper/state/3346420/latest_state/. The file is named {timestamp}_{nid}.json. Use glob to find it by nid. Pay attention to:
title - what the issue is about
body - the full issue description
comments - the discussion, status changes, and context
field_issue_category - whether it's a bug, feature, task, etc.
Note: Do not rely on has_merge_request from the JSON - it can be stale. Always check the issue page directly.
Step 2: Check the MR
Always fetch the issue page to find the MR link, regardless of what has_merge_request says in the JSON. The JSON metadata can be stale and may incorrectly report no MR when one exists.
https://www.drupal.org/project/ai/issues/{nid}
From the issue page, find the merge request URL (it will be a GitLab link on git.drupalcode.org). Fetch the MR page to see the diff/changes.
If there is genuinely no MR on the issue page, the review should note this and focus on the issue description and discussion only. Still write a review file, but note that no code was available to review.
Step 3: Review the code
Focus on finding obvious problems only. This is a pre-review, not a full review. Look for:
- Obvious bugs or logic errors
- Architectural problems (wrong abstraction, wrong location, coupling issues)
- Missing or incorrect type hints
- Security concerns (injection, access control, unsafe input handling)
- Drupal coding standards violations that stand out
- Whether the MR actually addresses what the issue describes
- Features must have tests and documentation. If a feature MR lacks either, flag it.
- Bugs that could lead to regression must have tests. If a bug fix MR does not include a test that would catch the regression, flag it.
Do NOT nitpick style, do NOT suggest optional improvements, do NOT rewrite the code. Only flag real problems.
Step 4: Write the review file
Save the review as reviews/{nid}.md. Use this format:
# Pre-Review: {title}
**Issue:** https://www.drupal.org/project/ai/issues/{nid}
**MR:** {mr_url or "No MR available"}
**Date:** {today's date}
**Commented on issue:** false
## Summary
{1-3 sentences summarizing what the issue/MR does and your overall impression}
## Findings
### {Short description of finding}
{Explanation of the problem}
```{language}
// {file path}:{line number(s)}
{relevant code snippet}
{What is wrong and why}
{Repeat for each finding}
Verdict
{One of: "Looks good with minor issues", "Needs work - blocking issues found", "Cannot review - no MR available", "Cannot review - MR not accessible"}
If there are no findings, write a short review saying the code looks clean and the verdict is "Looks good".
## Processing all issues
When asked to run through all issues:
1. Run `find-unreviewed.sh` to get the list
2. For each issue, follow the workflow above
3. After writing each review file, move on to the next issue
4. Report progress after each review: "Reviewed {nid}: {title} - {verdict}"
5. At the end, give a summary of how many issues were reviewed and the breakdown of verdicts
## Important notes
- The repo code is available under `repos/ai/` for cross-referencing existing code if needed
- Only issues with `has_merge_request: true` will have code to review. Still write a review for issues without MRs, but focus on the issue description quality and proposed approach
- Do not modify anything under `drupal-issue-hygiene-helper/` or `repos/` - those are read-only
- If a web fetch fails for an MR, note it in the review and move on. Do not get stuck
- Keep reviews concise. A pre-review should take minutes, not hours