chore: add repo contribution guardrails

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,16 @@
+name: Bug Report
+description: Report a bug or regression
+title: "fix: "
+labels: [bug]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Use generic descriptors instead of partner, customer, or brand names in public issue titles, bodies, and screenshots unless a maintainer explicitly approves naming them.
+  - type: textarea
+    id: summary
+    attributes:
+      label: Summary
+      description: Describe the bug and its impact on runtime, Nostr behavior, auth, or deployment.
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1 @@
+blank_issues_enabled: true

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,16 @@
+name: Feature Request
+description: Propose an enhancement
+title: "feat: "
+labels: [enhancement]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Use generic descriptors instead of partner, customer, or brand names in public issue titles, bodies, and screenshots unless a maintainer explicitly approves naming them.
+  - type: textarea
+    id: summary
+    attributes:
+      label: Summary
+      description: Describe the requested capability.
+    validations:
+      required: true

.github/pull_request_template.md

@@ -0,0 +1,17 @@
+## Summary
+- describe the change
+
+## Motivation
+- explain why this change is needed
+
+## Related Issue
+- link the issue or write `N/A`
+
+## Testing
+- describe local verification
+
+## Runtime / Rollout Notes
+- include any auth, Nostr, deployment, or infra notes when relevant, or write `None`
+
+## Sensitive Information Check
+- confirm that public titles, descriptions, branch names, and screenshots do not mention partner/customer/brand names or other sensitive external identities unless explicitly approved

.github/workflows/semantic_pr.yml

@@ -0,0 +1,12 @@
+name: Semantic PR
+
+on:
+  pull_request_target:
+    types: [opened, edited, synchronize, reopened]
+
+permissions:
+  pull-requests: read
+
+jobs:
+  semantic-pull-request:
+    uses: VeryGoodOpenSource/very_good_workflows/.github/workflows/semantic_pull_request.yml@v1

AGENTS.md

@@ -1206,4 +1206,12 @@ The validation ensures code quality and catches errors before deployment, regard
 
 If git is available in your environment (through a `shell` tool, or other git-specific tools), you should utilize `git log` to understand project history. Use `git status` and `git diff` to check the status of your changes, and if you make a mistake use `git checkout` to restore files.
 
-When your changes are complete and validated, create a git commit with a descriptive message summarizing your changes.
+When your changes are complete and validated, create a git commit with a descriptive message summarizing your changes.
+
+## Repo Guardrails
+
+PR titles must use Conventional Commit format: `type(scope): summary` or `type: summary`, and the correct title should be set when the PR is opened rather than fixed later. If the PR title changes after opening, verify that the semantic PR title check reruns successfully.
+
+Keep PRs tightly scoped. Do not mix unrelated cleanup, formatting churn, or speculative refactors into the same change. Temporary or transitional code must include `TODO(#issue):` with the tracking issue for removal.
+
+Public issues, PRs, branch names, screenshots, and descriptions must not mention corporate partners, customers, brands, campaign names, or other sensitive external identities unless a maintainer explicitly approves it. Use generic descriptors instead.