$npx -y skills add avalonreset/legends-github --skill github-communityGenerate GitHub community health files — CONTRIBUTING, CODE_OF_CONDUCT, SUPPORT, CODEOWNERS, issue/PR templates, dependabot, devcontainer.
| 1 | # GitHub Community -- Health Files and Templates |
| 2 | |
| 3 | ## Deterministic Entrypoint |
| 4 | |
| 5 | For API agents and non-interactive runs, use the deterministic runner: |
| 6 | |
| 7 | ```bash |
| 8 | python3 scripts/run_headless.py community --path /path/to/repo |
| 9 | python3 scripts/run_headless.py community --path /path/to/repo --write-files |
| 10 | ``` |
| 11 | |
| 12 | Behavior: |
| 13 | |
| 14 | - Default mode is plan-only and does not mutate the repo. |
| 15 | - `--write-files` is the explicit approval gate for creating or refreshing |
| 16 | community-health files. |
| 17 | - The runner writes `.github-audit/community-data.json`, |
| 18 | `COMMUNITY-REPORT.md`, `COMMUNITY-PLAN.md`, and `COMMUNITY-SUMMARY.json`. |
| 19 | - Issue templates are written as YAML forms. |
| 20 | - Discussion templates are written as `.github/DISCUSSION_TEMPLATE/*.yml` only |
| 21 | when live discussion category slugs are discoverable. If discussions are |
| 22 | disabled or category metadata is unavailable, the runner skips them cleanly |
| 23 | instead of guessing invalid filenames. |
| 24 | |
| 25 | ## Process (GARE Pattern) |
| 26 | |
| 27 | ### 1. Gather |
| 28 | |
| 29 | **Step 0 -- Check shared data cache:** |
| 30 | Before gathering, check `.github-audit/` for cached data from other skills. |
| 31 | Reference: `github/references/shared-data-cache.md` for schemas. |
| 32 | |
| 33 | - `repo-context.json` (optional) -- repo type, intent, language, has_discussions. |
| 34 | If missing, gather yourself via `gh repo view`. |
| 35 | - `legal-data.json` (optional) -- SECURITY.md status. If present, use |
| 36 | `security_md_exists` to know whether to note "SECURITY.md: already exists" or |
| 37 | "SECURITY.md: not found -- run `github-legal` to generate." If missing, check |
| 38 | SECURITY.md existence yourself. |
| 39 | |
| 40 | - Check which community files already exist: |
| 41 | - README.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, SUPPORT.md |
| 42 | - CODEOWNERS, .github/FUNDING.yml |
| 43 | - .github/ISSUE_TEMPLATE/ (any .yml or .md files) |
| 44 | - .github/PULL_REQUEST_TEMPLATE.md |
| 45 | - .github/DISCUSSION_TEMPLATE/ |
| 46 | - .gitattributes |
| 47 | - .github/workflows/ (any .yml files -- for CI detection) |
| 48 | - .devcontainer/devcontainer.json |
| 49 | - .github/dependabot.yml |
| 50 | - .github/release.yml |
| 51 | - **Case and format fallbacks (important):** |
| 52 | - PR template: check BOTH `.github/PULL_REQUEST_TEMPLATE.md` (uppercase) AND |
| 53 | `.github/pull_request_template.md` (lowercase). GitHub accepts either. |
| 54 | - Community files: check `.rst` fallback for CONTRIBUTING, CODE_OF_CONDUCT, |
| 55 | SECURITY, SUPPORT (e.g., `CONTRIBUTING.rst`). Some projects (especially |
| 56 | Python/Sphinx-based) use reStructuredText instead of Markdown. |
| 57 | - Best approach: list `.github/` directory contents first, then check root files. |
| 58 | The directory listing catches case variants and unexpected filenames. |
| 59 | - **Org-level `.github` repo:** If the repo belongs to an organization, check |
| 60 | `{org}/.github` for inherited community health files. GitHub automatically |
| 61 | inherits CODE_OF_CONDUCT, CONTRIBUTING, SECURITY, SUPPORT, FUNDING.yml from |
| 62 | the org's `.github` repo. Use: `gh api repos/{org}/.github/contents --jq '.[].name'` |
| 63 | If inherited files exist, note them as "inherited from org" -- do NOT regenerate them. |
| 64 | - Check GitHub Community Standards: `https://github.com/{owner}/{repo}/community` |
| 65 | - Check if Discussions is enabled: `gh repo view {owner}/{repo} --json hasDiscussionsEnabled` |
| 66 | - If Discussions is NOT enabled, do NOT link to Discussions in config.yml -- use |
| 67 | Issues link instead, or omit the contact_links section |
| 68 | - Detect repo type and primary language (for devcontainer and dependabot config) |
| 69 | - Get user intent from orchestrator context |
| 70 | |
| 71 | ### 2. Analyze |
| 72 | |
| 73 | Reference: Read `github/references/community-files-guide.md` for file specs and priorities. |
| 74 | Reference: Read `github/references/community-templates.md` for YAML templates and code. |
| 75 | |
| 76 | **Branding consistency check:** For every existing file, verify it references the |
| 77 | correct project name. Forks, ports, and copied templates often contain the upstream |
| 78 | or source project's name (e.g., "legends-github" in a codex-seo repo, "wezterm" in a |
| 79 | BenjaminTerm repo). Flag any file where the project name, repo URL, or owner doesn't |
| 80 | match the current repo. These need updating even if the file is otherwise good quality. |
| 81 | |
| 82 | Fill in this table for every file. **For files that exist, read their content |
| 83 | and assess quality** -- don't just check existence. |
| 84 | |
| 85 | | File | Exists? | Quality | Action Needed | |
| 86 | |------|---------|---------|---------------| |
| 87 | | CONTRIBUTING.md | ? | ? | ? | |
| 88 | | CODE_OF_CONDUCT.md | ? | ? | ? | |
| 89 | | SECURITY.md | ? | ? | ? -- **Handled by `github-legal`** (note: do NOT generate here, just check existence) | |
| 90 | | SUPPORT.md | ? | ? | ? | |
| 91 | | CODEOWNERS | ? | ? | ? | |
| 92 | | FUNDING.yml | ? | ? | ? | |
| 93 | | Issue templates | ? | ? | ? | |
| 94 | | PR template | ? | ? | ? | |
| 95 | | Discussion templates | ? | ? | ? | |
| 96 | | .gitattributes | ? | ? | ? | |
| 97 | | devcontainer.json | ? | ? | ? | |
| 98 | | dependabot.yml | ? | ? | ? | |
| 99 | | release.yml | ? | ? | ? | |
| 100 | |
| 101 | #### Quality Assessment Criteria (for existing files) |
| 102 | |
| 103 | When a file e |