docs(references): secrets-inherit ban, config_data pitfall, archived-repo handling

skills/github-project/references/auto-merge-guide.md

@@ -406,6 +406,27 @@ gh pr merge NUMBER --repo OWNER/REPO --auto --merge
 - Some repos need the "Allow auto-merge" setting enabled in repository settings first
 - Repos where you lack admin/maintainer access will fail with permission errors
 
+## Archived Repos — Handle Dependabot/Renovate PRs with Care
+
+Archived repositories still receive Dependabot/Renovate PRs, but you cannot
+merge them or enable auto-merge — writes are blocked, and auto-merge fails with a
+permission error. Don't fight it:
+
+1. **Unarchive** the repo.
+2. **Close** the PR (or merge it, if the update is genuinely wanted).
+3. **Re-archive** the repo.
+
+Before any batch auto-merge sweep across an org, filter archived repos out first
+so they don't generate noise:
+
+```bash
+# gh filters archived repos out server-side:
+gh repo list ORG --no-archived --json name --jq '.[].name'
+```
+
+Never enable auto-merge on an archived repo — it errors and leaves the PR in a
+confusing half-state.
+
 ## Recommended Renovate Config for Auto-merge
 
 ```json

skills/github-project/references/reusable-workflow-pitfalls.md

@@ -62,3 +62,26 @@ jobs:
 See [GitHub docs — access and permissions](https://docs.github.com/en/actions/sharing-automations/reusing-workflows#access-and-permissions) for the full intersection rules.
 
 > **See also:** [`reusable-workflow-security.md`](./reusable-workflow-security.md) for SHA-pinning and supply-chain trust of *external* actions.
+
+## 5. Inline `config_data` overrides the repo's own config file
+
+Linter actions that accept an inline `config_data:` (e.g. yamllint via a
+reusable workflow) **replace** the consumer repo's own config file entirely —
+they do not merge. A repo with a carefully tuned `.yamllint.yml` (ignore paths,
+relaxed rules) silently has all of it discarded the moment the reusable workflow
+passes its own inline defaults.
+
+Provide inline defaults only as a *fallback*, when the repo has no config of its own:
+
+```yaml
+- name: Provide default config if the repo has none
+  run: |
+    if [[ ! -f .yamllint.yml ]]; then
+      cat > .yamllint.yml <<'EOF'
+    extends: default
+    rules: { line-length: disable }
+    EOF
+    fi
+- name: Lint
+  uses: some/yamllint-action@<sha>   # picks up the repo's config, or the fallback
+```

skills/github-project/references/reusable-workflow-security.md

@@ -107,3 +107,31 @@ jobs:
 ```
 
 > **See also:** [`org-security-settings.md`](./org-security-settings.md) for org-level SHA pinning and allow-list configuration.
+
+## Never Use `secrets: inherit`
+
+`secrets: inherit` forwards **every** secret available to the calling workflow
+into the reusable workflow — and transitively into any action it calls. One
+compromised action in the chain (cf. the chain-compromise risk above) then has
+access to the full secret set: Docker credentials, publish tokens, signing keys.
+
+Pass only what each workflow needs, explicitly by name:
+
+```yaml
+# Bad — hands the whole keyring to the reusable workflow and its dependencies
+jobs:
+    release:
+        uses: org/ci-workflows/.github/workflows/release.yml@<sha>
+        secrets: inherit
+
+# Good — least privilege; blast radius limited to the named secrets
+jobs:
+    release:
+        uses: org/ci-workflows/.github/workflows/release.yml@<sha>
+        secrets:
+            CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
+```
+
+Org secrets do **not** auto-propagate into reusable workflows either — each
+caller must forward them explicitly, which is what makes `inherit` look
+convenient. Resist it; the explicit form is also the audit trail.