chore: add anti-slop PR screening workflow (#81)

* chore: add anti-slop PR quality workflow

* docs: add required PR template and screening guidance

* chore: pin anti-slop action to full SHA

* chore: document PR workflow guardrails

* docs: clarify anti-slop maintainer guardrails

* chore: tighten anti-slop canary handling

* fix: avoid canary token in PR template body

* fix: rerun PR quality on label changes

* fix: remove PR template canary hint

* fix: protect PR screening files

---------

Co-authored-by: ndycode <ndycode@users.noreply.github.com>

Author: ndycode

.github/pull_request_template.md

@@ -0,0 +1,24 @@
+<!-- Maintainer note: the anti-slop canary token is configured in .github/workflows/pr-quality.yml under blocked-terms. Keep the template and workflow in sync, and do not put the raw token in contributor-facing files. -->
+
+## Summary
+
+- What changed?
+- Why is this needed?
+
+## Testing
+
+- [ ] `npm run lint`
+- [ ] `npm run build`
+- [ ] `npm test`
+- [ ] Not applicable
+
+## Compliance Confirmation
+
+- [ ] This change stays within the repository scope and OpenAI Terms of Service expectations.
+- [ ] This change uses official authentication flows only and does not add bypass, scraping, or credential-sharing behavior.
+- [ ] I updated tests and documentation when the change affected users, maintainers, or repository behavior.
+
+## Notes
+
+- Linked issue:
+- Follow-up work or rollout notes:

.github/workflows/pr-quality.yml

@@ -0,0 +1,55 @@
+name: PR Quality
+
+permissions:
+  contents: read
+  issues: read
+  pull-requests: write
+
+on:
+  # Use pull_request_target so the action can comment on fork PRs without
+  # checking out or executing contributor code from the PR branch.
+  pull_request_target:
+    types:
+      - opened
+      - reopened
+      - synchronize
+      - edited
+      - ready_for_review
+      - labeled
+      - unlabeled
+
+jobs:
+  anti-slop:
+    runs-on: ubuntu-latest
+    concurrency:
+      group: pr-quality-${{ github.event.pull_request.number }}
+      cancel-in-progress: true
+    steps:
+      - name: Screen pull request quality
+        uses: peakoss/anti-slop@85daca1880e9e1af197fc06ea03349daf08f4202 # v0.2.1
+        with:
+          max-failures: 1
+          require-pr-template: true
+          # Keep this public canary aligned with the hidden template note below.
+          # It is best-effort only, so rotate it if it becomes noisy or stale.
+          blocked-terms: |
+            OBSIDIAN1455
+          # anti-slop documents exact file and folder entries here, so this
+          # list guards the canonical metadata files and PR screening surfaces.
+          blocked-paths: |
+            SECURITY.md
+            LICENSE
+            CODE_OF_CONDUCT.md
+            CODEOWNERS
+            .github/workflows/pr-quality.yml
+            .github/pull_request_template.md
+          exempt-label: exempt
+          exempt-draft-prs: true
+          close-pr: false
+          lock-pr: false
+          failure-pr-message: |
+            Thanks for the contribution. This repository automatically screens pull requests for incomplete, low-signal, or non-compliant submissions before maintainers spend review time.
+
+            Please review CONTRIBUTING.md, complete the PR template with concrete summary and testing details, and update the PR if anything important is missing.
+
+            If this looks like a false positive, a maintainer can override the workflow with the `exempt` label after review.

CONTRIBUTING.md

@@ -64,7 +64,12 @@ The project does not accept work aimed at:
 4. **Update documentation** (README.md, config examples, etc.)
 5. **Ensure compliance** with guidelines above
 6. **Test thoroughly** with the most appropriate validation for the change
-7. **Submit PR** with clear description of changes
+7. **Complete the pull request template** with summary, testing, and compliance details
+8. **Submit PR** with clear description of changes
+
+Pull requests are automatically screened for incomplete or suspicious submissions. Legitimate contributions are still welcome, but low-signal PRs may be flagged for maintainer review before they move forward.
+
+If a PR is flagged incorrectly, a maintainer can override the workflow with the `exempt` label after review.
 
 ## Reporting Issues