github-legal
starsforks
How to install github-legal?
avalonreset/legends-github/github-legal
$npx -y skills add avalonreset/legends-github --skill github-legalGitHub legal compliance — generate LICENSE, SECURITY.md, CITATION.cff, NOTICE; handle fork attribution and dependency compatibility.
SKILL.md
| 1 | # GitHub Legal -- License, Compliance, and Security Policy |
| 2 | |
| 3 | ## Deterministic Entrypoint |
| 4 | |
| 5 | For API agents and non-interactive runs, use the deterministic legal runner: |
| 6 | |
| 7 | ```bash |
| 8 | python3 scripts/run_headless.py legal --path /path/to/repo |
| 9 | python3 scripts/run_headless.py legal --path /path/to/repo --write-files |
| 10 | python3 scripts/run_headless.py legal --path /path/to/repo --write-files --license MIT |
| 11 | ``` |
| 12 | |
| 13 | This writes: |
| 14 | |
| 15 | - `.github-audit/legal-data.json` |
| 16 | - `.github-audit/output/<repo>-<timestamp>/LEGAL-REPORT.md` |
| 17 | - `.github-audit/output/<repo>-<timestamp>/LEGAL-PLAN.md` |
| 18 | - `.github-audit/output/<repo>-<timestamp>/LEGAL-SUMMARY.json` |
| 19 | |
| 20 | By default this is a plan-only pass. `--write-files` is the explicit approval |
| 21 | gate for writing `LICENSE`, `SECURITY.md`, `CITATION.cff`, and `NOTICE`. |
| 22 | Complex or ambiguous legal situations must be flagged for human review instead |
| 23 | of being guessed. |
| 24 | |
| 25 | ## Disclaimer -- ALWAYS Include in Output |
| 26 | |
| 27 | This tool provides best-effort compliance assistance for common open source licensing |
| 28 | scenarios on GitHub. **It is NOT legal advice.** The output of this skill does not |
| 29 | constitute a legal opinion and should not be relied upon as such. |
| 30 | |
| 31 | Users are responsible for their own due diligence. For complex licensing situations |
| 32 | (dual licensing, contributor license agreements, patent disputes, commercial use of |
| 33 | copyleft code, trademark issues), consult a qualified attorney. |
| 34 | |
| 35 | **Include this disclaimer at the top of every output:** |
| 36 | ``` |
| 37 | > This analysis is automated compliance assistance, not legal advice. |
| 38 | > Always verify licensing decisions with your own due diligence. |
| 39 | > For complex or high-stakes situations, consult a qualified attorney. |
| 40 | ``` |
| 41 | |
| 42 | ## Process (GARE Pattern) |
| 43 | |
| 44 | ### 1. Gather |
| 45 | |
| 46 | **Step 0 -- Check shared data cache:** |
| 47 | Before gathering, check `.github-audit/` for cached data from other skills. |
| 48 | Reference: `github/references/shared-data-cache.md` for schemas. |
| 49 | |
| 50 | - `repo-context.json` (optional) -- repo type, intent, is_fork flag. If missing, |
| 51 | gather yourself via `gh repo view`. |
| 52 | |
| 53 | - Read existing LICENSE file (if any) |
| 54 | - **Fork and upstream detection (two checks):** |
| 55 | 1. GitHub fork flag: `gh repo view --json isFork,parent` |
| 56 | 2. **Upstream project scan** -- even if GitHub says `isFork: false`, scan the |
| 57 | README and repo description for upstream signals: |
| 58 | - "powered by [project]", "built on [project]", "based on [project]" |
| 59 | - "fork of [project]", "[project] distribution", "[project]-powered" |
| 60 | - "wrapper around [project]", "extends [project]" |
| 61 | - Config files that reference another project (e.g., wezterm.lua in a |
| 62 | terminal project means WezTerm is upstream) |
| 63 | If upstream is detected, treat it like a fork for compliance purposes: |
| 64 | fetch the upstream repo's LICENSE and check obligations. |
| 65 | **This catches projects like BenjaminTerm (WezTerm distro) that aren't |
| 66 | GitHub "forks" but still have upstream license obligations.** |
| 67 | - If fork or upstream detected, read upstream LICENSE and NOTICE files |
| 68 | - Scan dependency manifests for license compatibility: |
| 69 | - package.json, setup.py, pyproject.toml, Cargo.toml, go.mod, requirements.txt, |
| 70 | Gemfile, pom.xml, build.gradle, composer.json, Package.swift, *.csproj |
| 71 | - If no manifest files exist, scan the README for dependency mentions (e.g., |
| 72 | `pip install X`, import statements, "requires X") and note their licenses |
| 73 | - Check for existing SECURITY.md, CITATION.cff, NOTICE |
| 74 | - Check for vendored/copied code: look for third-party directories (vendor/, |
| 75 | third_party/, lib/external/) and check if they have their own LICENSE files |
| 76 | - Get user intent from orchestrator context |
| 77 | |
| 78 | ### 2. Analyze |
| 79 | |
| 80 | - Is the current license appropriate for the user's intent? |
| 81 | - **Fork/upstream compliance (both GitHub forks AND detected upstream projects):** |
| 82 | - Does the current license comply with upstream? |
| 83 | - Is the upstream copyright preserved? |
| 84 | - Are there NOTICE file obligations? |
| 85 | - For non-fork upstream projects: is the relationship acknowledged in LICENSE |
| 86 | or README? (e.g., "Based on WezTerm, licensed under MIT") |
| 87 | - Are there dependency license conflicts? |
| 88 | - Is SECURITY.md present and adequate? |
| 89 | - Is CITATION.cff present? **CITATION.cff is a default deliverable** -- generate it |
| 90 | for every repo unless the user explicitly declines. It costs nothing, takes 10 seconds |
| 91 | to generate, and enables GitHub's "Cite this repository" button. Academic intent is not |
| 92 | required -- any project benefits from a machine-readable citation file. The audit scores |
| 93 | it, so skipping it leaves free points on the table. |
| 94 | - **Vendored code check:** Do any third_party/vendor directories have their own |
| 95 | licenses that conflict with the project license? |
| 96 | - **Edge case flags** -- flag these for the user's attention (do not attempt to |
| 97 | resolve them, recommend consulting an attorney): |
| 98 | - Dual licensing situations |
| 99 | - CLA (Contributor Lic |
People who liked this also viewed
6 picksType
- caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026
- git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026
- finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026
