Review New Submissions to a Technical Resource List
Use it when people send new entries to a list of technical tools and links through pull requests. It checks only the ones you name for format, duplicates, and secure links, asks before commenting or merging, and reports new problems apart from old ones.
To use this AI rule
## Keep One Main List File and Build the Site and Data from It
Treat one human-readable catalog document as the source of truth.
Generate indexes, structured datasets, and static pages from that source instead of editing derived artifacts independently.
Organize entries under subject categories rather than implementation-language headings.
Store language support as inline tags on each entry so one resource can declare multiple languages without changing its subject category.
Document the data flow:
1. The catalog document stores curated entries.
2. A parser validates entries, enriches approved external metadata, and writes a structured dataset.
3. A site generator reads the dataset when available and otherwise parses the catalog directly for local previews.
4. Continuous integration runs the parser and generator, then publishes only the generated site directory.
Keep parser, generator, and deployment behavior aligned with this contract.
Do not make a generated page or dataset a competing source of truth.
## Write Every List Entry in One Format with Language Tags
Define one parser-recognizable entry shape and treat punctuation as part of the contract.
A typical entry contains a linked name, one or more inline language tags, and a description: ``- [Name](https://example.org) - `Language` - Description.``
Apply these rules:
- new non-commercial entries must contain at least one language tag followed by the required separator;
- descriptions must end with a period before any optional source-repository link;
- new links must use `https://`;
- commercial or proprietary resources belong in a dedicated category;
- language tags may be omitted only in commercial or explicitly non-language categories;
- user-facing contribution guidance remains authoritative for submitters.
Accept multiple language tags without changing the surrounding structure.
Allow an optional repository link after the completed description.
Keep ecosystem-specific package links valid when they follow the same entry grammar.
Do not loosen the parser pattern for one malformed submission.
## Check New Entries Strictly and Report Old Entries Only as Warnings
Use the repository's documented environment and task wrappers for validation, parsing, and publication.
Respect the required runtime version and install dependencies through the canonical dependency command.
Use two validation modes:
1. Change validation checks only entries added relative to the chosen base revision.
2. Full-catalog validation checks every entry.
For newly added entries, treat duplicate, malformed-link, and URL-policy findings as errors.
For the full catalog, report equivalent legacy issues as warnings unless strict flags are explicitly selected.
Do not let tolerated legacy debt weaken the admission standard for new entries.
Run the parser only when required credentials are available.
Allow the site generator to use an existing structured dataset or its documented direct-parse fallback for local previews.
## Review Only the Submissions You Name and Check for Duplicates
Limit review to the submissions the user named.
Use the configured repository connector for pull-request operations rather than an unrelated command-line client.
Before any modifying action:
1. Inspect the proposed files and differences.
2. Check category placement and the exact entry format.
3. Search the source-of-truth catalog for duplicates.
4. Verify secure URL formatting.
5. Assess current project activity and documentation with evidence.
6. Present findings before changing external state.
Do not review additional submissions merely because they are open.
Do not infer popularity or maintenance status from the submitted description alone.
Distinguish catalog-format compliance from the quality and continued usefulness of the resource.
## Ask Before Commenting on or Merging a Pull Request
Always ask the user before commenting, labeling, closing, or merging a pull request.
Apply the review-complete label only after the user approves the review comment.
Merge only after explicit approval for that merge.
Use connected repository tools to list open requests, inspect details, files, comments, labels, and differences, fetch the default-branch catalog for duplicate checks, and perform approved changes.
Never substitute a different external tool when the required connector is unavailable.
If the connector is missing, report that repository operations are blocked and ask the user to configure it.
Separate read-only evidence gathering from external mutations.
An instruction to review does not by itself authorize a comment, label, closure, or merge.
## Keep the Access Key Secret and Publish the Site Only Through the Automatic Build
Treat external metadata enrichment as a credentialed operation.
Do not run it without the required access credential, and never expose the credential in commands, reports, generated pages, or committed files.
Keep publication reproducible:
- parse the canonical catalog into the documented structured dataset;
- let local previews use only the documented fallback;
- generate the static page from current validated input;
- publish only through the configured continuous-integration workflow;
- review generated changes when parser or template behavior changes.
Do not claim that publication succeeded from a local preview alone.
Verify the generated artifact and the publication workflow separately.
## Report What Was Checked, Keeping New Errors Apart from Old Warnings
Report the reviewed submissions, findings, validation mode, and any blocked operation.
State whether checks covered only new entries or the full catalog.
Identify warnings that originate from legacy content separately from errors introduced by the current change.
Before completion, confirm:
- the catalog remained the source of truth;
- entry grammar, punctuation, tags, categories, and secure URLs were checked;
- duplicates were checked against the current default branch;
- activity and documentation claims were evidence-based;
- no external state changed without approval;
- generated artifacts were not mistaken for authoritative source content.
Keep the report concise enough to support a decision, but include every finding that can change acceptance.