Review pull requests for the awesome-agentic-patterns repository. Use when asked to validate a PR, assess whether a contribution fits the repo, inspect pattern submissions under patterns/, check merge readiness, repair a small submission issue on top of a contributor branch, draft a polite contributor comment, or apply the repository's pattern-first and non-promotional contribution policy to a GitHub pull request.
Review PRs in this repository by applying the local contribution policy and checking the actual changed files. Treat CONTRIBUTING.md as the source of truth for acceptance criteria, TEMPLATE.md as the source of truth for expected pattern structure, and the validation scripts in scripts/ as the source of truth for structural checks and generated-file expectations.
CONTRIBUTING.mdREADME.mdTEMPLATE.mdscripts/lint_front_matter.pyscripts/pattern_validator.pyscripts/build-data.ts when the PR touches patterns, generated README sections, or generated site dataDo not restate repo policy from memory when those files are available. Quote or summarize the repository's own rules instead.
Use gh first:
gh pr view <number> --repo nibzard/awesome-agentic-patterns --json title,number,state,isDraft,author,baseRefName,headRefName,headRepository,headRepositoryOwner,maintainerCanModify,files,additions,deletions,mergeable,mergeStateStatus,reviewDecision,statusCheckRollup,labels,url,bodygh pr diff <number> --repo nibzard/awesome-agentic-patterns --patchgh pr checks <number> --repo nibzard/awesome-agentic-patternsIf you need the exact branch locally, fetch it with:
git fetch origin refs/pull/<number>/head:pr-<number>Capture these facts before deciding anything:
patterns/<slug>.md rather than editing generated docs directlyREADME.md or apps/web/public/ generated outputs changed because the contributor regenerated outputs, or because they hand-edited generated filesmaintainerCanModify is enabled and which fork/branch must be updated if you need to fix the PRUNKNOWN can be transient right after a pushFor pattern submissions, check the repository's exact contract before debating fit:
patterns/ and use kebab-case filenamesAdd: pattern-namedocs/index.md is only a compatibility symlink to README.mdtitle
status
category
tags
plus authors, based_on, and source when availablesource_link is invalid here; use source## Problem
## Solution
## ReferencesFor generated-file sync, check whether the PR also updated:
README.mdapps/web/public/data/patterns.jsonapps/web/public/ when the pattern catalog changedCall out structural violations explicitly. These are repository requirements, not style nits.
Use CONTRIBUTING.md for the actual acceptance rubric. Evaluate:
github.com, github.io, or neutral technical references for outside contributorsSeparate policy fit from technical mergeability. A PR can be in scope but still need a maintainer fix before merge.
When reviewing a local branch or checking CI behavior, run:
python3 scripts/lint_front_matter.pypython3 scripts/pattern_validator.py <pattern-file.md>python3 scripts/pattern_validator.py --allbun run build:data when checking generated README or site data changesTreat the scripts as structural checks, not the decision-maker. Human review still decides repository fit, novelty, promotion risk, and category choice.
If the PR is acceptable and the user wants it fixed or merged, prefer the smallest possible maintainer correction:
origin/mainREADME.md and site data with bun run build:data only if the PR already requires generated-file sync--force-with-leasegh pr view after the push because mergeable and mergeStateStatus may temporarily show UNKNOWNDo not turn a small submission repair into a broader cleanup.
Use a code-review mindset:
Accept, Request changes, or Closeclean, needs maintainer repair, or blockedcomment, fix and push, merge, or closeKeep the final review compact and consistent. Use this exact structure:
Summary
Findings
No blocking findings.Decision
Policy fit: Accept | Request changes | CloseMergeability: clean | needs maintainer repair | blockedRecommended action: comment | fix and push | merge | closeProposed comment to contributor
What next
Do you want me to post the comment, push the small fix, or merge it?