SE

semaphore-third-party-licenses

Automates the creation and audit of license attributions for the Semaphore UI repository.

Install

mkdir -p .claude/skills/semaphore-third-party-licenses && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/12447" && unzip -o skill.zip -d .claude/skills/semaphore-third-party-licenses && rm skill.zip

Installs to .claude/skills/semaphore-third-party-licenses

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Generate or update the THIRD-PARTY-LICENSES.md file for the Semaphore UI repository. Use this skill whenever the user asks to create, update, regenerate, audit, or refresh third-party license attributions, OSS notices, SBOM-style license inventories, or NOTICE files for Semaphore UI. Trigger on phrases like "third-party licenses", "OSS notices", "license attribution file", "SBOM for licenses", "NOTICE file", "audit dependencies", "licenses for go.mod / package.json", or any request that mentions compliance with customer agreements requiring an OSS components list. Also trigger when the user says "we added a new dependency, regenerate licenses". This skill knows the Semaphore UI layout (Go backend + Vue.js frontend), the project's license policy (allowlist/denylist), and the canonical output format.
809 chars✓ has a “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Intermediate

Key capabilities

  • Generate or update the THIRD-PARTY-LICENSES.md file.
  • Collect raw license data for Go backend and Vue.js frontend.
  • Run a policy check against detected licenses.
  • Generate markdown output using a specified template.
  • Sort entries alphabetically within each section.
  • Group licenses by component category (Go backend / npm frontend).

How it works

The skill collects raw license data from Go and npm dependencies, runs a policy check against allowed licenses, and then generates a markdown file with sorted and grouped license information.

Inputs & outputs

You give it
A request to create, update, regenerate, audit, or refresh third-party license attributions for Semaphore UI.
You get back
A THIRD-PARTY-LICENSES.md file listing open-source dependencies with name, version, license, and source URL.

When to use semaphore-third-party-licenses

  • Regenerate license file
  • Audit third-party dependencies
  • Create OSS notice file

About this skill

Semaphore UI — Third-Party License Generator

This skill produces THIRD-PARTY-LICENSES.md for the Semaphore UI repository. The file lists every open-source dependency shipped with Semaphore UI by name, version, license, and source URL, grouped by component. It exists to satisfy contractual obligations toward customers (identification of OSS components by name, version, and license type) and to preserve attribution required by permissive licenses (MIT/BSD/Apache-2.0).

Repository layout you can expect

Semaphore UI is a self-hosted product. The repository ships:

  • Go backend — module file at go.mod, source under pkg/, services/, db/, etc.
  • Vue.js frontendweb/package.json (or web2/package.json in some branches), built into static assets and embedded in the Go binary.

External CLI tools (Ansible, Terraform, OpenTofu, Pulumi, Bash) are invoked at runtime as separate operating-system processes. They are NOT linked into the binary and NOT redistributed with Semaphore UI, so they are intentionally not listed in THIRD-PARTY-LICENSES.md — their license terms apply to the user who installs them on the host, not to Semaphore UI's distribution. The license policy still discusses why this is contractually safe (see references/license_policy.md, "Subprocess exception").

If the layout differs (monorepo restructure, new submodule, etc.), inspect the repo first with find . -name "go.mod" -o -name "package.json" -not -path "*/node_modules/*" and adapt.

Workflow

Follow these steps in order. Don't skip the policy check — it's the part that actually protects the project from accidentally shipping a GPL'd dependency.

1. Confirm scope with the user

Before generating anything, ask (briefly) which targets to include if it's not obvious from context:

  • Backend only? Frontend only? Both?
  • Production dependencies only, or also dev dependencies?

Default: both backend and frontend, production-only (dev dependencies are not distributed to customers and don't need attribution). Override only if the user explicitly asks for dev deps too.

2. Collect raw license data

Run scripts/collect_licenses.sh from the repo root. It does the following:

  • Sets GOWORK=off and runs go-licenses report ./... --template scripts/go_template.tpl for the Go backend, so workspace siblings (e.g. pro_impl) are not pulled in.
  • Rolls sub-package rows up to their parent module (uses go list -m all for the module → version map) and drops any module path that belongs to the root module's namespace (first-party packages, including replace … => ./pro targets).
  • Applies a small OVERRIDES table in the script for modules where go-licenses can't auto-detect a license (e.g. modernc.org/mathutil → BSD-3-Clause). Extend the table when new "Unknown" entries appear.
  • Runs license-checker --production --json --excludePrivatePackages in the frontend directory and strips the low-confidence * suffix from license strings so MIT* collapses into MIT.
  • Writes raw output to .licenses-cache/go.tsv and .licenses-cache/npm.json.

If the tools aren't installed, the script prints the install commands. Don't try to install them silently — show the user what needs to be added so they can decide whether to add them to CI.

3. Run the policy check

Run scripts/check_policy.py .licenses-cache/. This compares every detected license against the project policy in references/license_policy.md:

  • Allowed (green): MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, Zlib, Unlicense, CC0-1.0, MPL-2.0 — proceed.
  • Review (yellow): LGPL-2.1, LGPL-3.0, EPL-2.0, CDDL-1.0, custom/unknown — pause and ask the user. LGPL is fine for dynamic linking but Go statically links, so flag it for review.
  • Forbidden (red): GPL-2.0, GPL-3.0, AGPL-3.0, SSPL-1.0, BUSL-1.1, Commons Clause, "non-commercial" clauses — STOP. Do not proceed with file generation. Report the offending package and ask the user how to handle it (replace, vendor, or accept and document the consequence).

This step is non-negotiable. A forbidden license slipping into THIRD-PARTY-LICENSES.md isn't just a documentation problem — it's a contract breach with every customer. If check_policy.py returns a non-zero exit code, surface the failures prominently and stop.

4. Generate the markdown

Run scripts/generate_md.py .licenses-cache/ > THIRD-PARTY-LICENSES.md. This produces the file using the structure described in references/template.md. Key points the generator handles:

  • Sorts entries alphabetically within each section.
  • Groups by component category (Go backend / npm frontend).
  • Deduplicates packages that appear at multiple versions (lists all versions on one line).
  • Renders a summary table at the top with license counts.
  • Adds a generation timestamp and a note pointing to scripts/collect_licenses.sh so the file is reproducible.

5. Verify and commit

After generation:

  1. Diff against the previous THIRD-PARTY-LICENSES.md (if it exists). New rows = new dependencies — confirm with the user that they're expected.
  2. Verify the file isn't truncated and ends with the closing footer (<!-- end of generated file -->).
  3. Suggest the commit message: chore(licenses): regenerate THIRD-PARTY-LICENSES.md for vX.Y.Z.
  4. If a CI pipeline exists (.github/workflows/), suggest adding a job that runs scripts/check_policy.py on every PR — that's how the project prevents regressions, not by re-checking manually each release.

Notes on edge cases

Vendored dependencies. If the repo has a vendor/ directory, go-licenses will read from it. That's fine — vendored code still ships and still needs attribution.

Dual-licensed packages. Some packages are offered under "MIT OR Apache-2.0". Pick MIT (the simpler one) and note the choice in the entry: License: MIT (also available under Apache-2.0).

Packages with no detectable license. go-licenses flags these as "Unknown". Don't ship the file with Unknowns — manually inspect the repo, fill in the SPDX identifier, and if there's truly no license, treat the package as forbidden (no license = "all rights reserved", which is incompatible with redistribution).

Ansible / Terraform / OpenTofu / Pulumi / Bash. Do NOT list them in THIRD-PARTY-LICENSES.md. They are invoked as separate OS processes (os/exec), not linked, not redistributed. Their licenses bind the user who installs them on the host, not Semaphore UI's distribution. Listing them would imply otherwise and is an unnecessary signal to a reviewing customer's legal team. The "Subprocess exception" section in references/license_policy.md explains the reasoning if a reviewer asks.

First-party packages with no LICENSE. The root module and any replace … => ./<dir> target (e.g. ./pro) live inside this repo and don't need to be self-attributed. The collection script filters them out by the root module prefix from go.mod. If you see "Unknown license" rows for github.com/<this-org>/<this-repo>/…, the filter is working correctly — those rows shouldn't appear in the final cache.

Embedded license texts. For packages under MIT/BSD/ISC, the license requires preserving the copyright notice. The generator embeds the full LICENSE file text from each package's source. For Apache-2.0 packages, it embeds the NOTICE file if one exists.

What this skill does NOT do

  • It does not generate a CycloneDX or SPDX SBOM. If the user wants a machine-readable SBOM (for compliance scanners, customer attestations, etc.), point them at syft packages dir:. -o cyclonedx-json as a separate step. THIRD-PARTY-LICENSES.md is the human-readable artifact.
  • It does not check for CVEs. That's a security concern, not a licensing one — use govulncheck and npm audit for that.
  • It does not modify go.mod or package.json. The skill is read-only with respect to the dependency manifests; it only generates the attribution document.

See references/license_policy.md for the full policy and references/template.md for the output format.

When not to use it

  • When the user wants to generate a CycloneDX or SPDX SBOM.
  • When the user needs to check for CVEs.
  • When the user wants to modify go.mod or package.json.

Limitations

  • The skill does not generate a CycloneDX or SPDX SBOM.
  • The skill does not check for CVEs.
  • The skill does not modify go.mod or package.json.

How it compares

This skill provides a structured workflow for generating a `THIRD-PARTY-LICENSES.md` file, including a policy check for license compliance and specific handling for Go and Vue.js dependencies, unlike a generic license scanning tool.

Compared to similar skills

semaphore-third-party-licenses side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
semaphore-third-party-licenses (this skill)02moReviewIntermediate
supabase-debug-bundle126dCautionBeginner
hiddenroom-supabase01moNo flagsIntermediate
backend-security-coder244moNo flagsIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

supabase-debug-bundle

jeremylongshore

Execute collect Supabase debug evidence for support tickets and troubleshooting. Use when encountering persistent issues, preparing support tickets, or collecting diagnostic information for Supabase problems. Trigger with phrases like "supabase debug", "supabase support bundle", "collect supabase logs", "supabase diagnostic".

10

hiddenroom-supabase

cuvo1903-ctrl

Hidden Room Supabase backend skill for migrations, generated database types, Edge Functions, RLS policies, auth/profile sync, storage buckets, Stripe integration, cloud_jobs, and database documentation. Use when editing supabase/migrations, supabase/functions, database.types.ts, or Supabase-backed f

00

backend-security-coder

sickn33

Expert in secure backend coding practices specializing in input validation, authentication, and API security. Use PROACTIVELY for backend security implementations or security code reviews.

2446

custom-workers

ruvnet

Create and run custom background analysis workers with composable phases. Use when you need automated code analysis, security scanning, pattern learning, or API documentation generation.

12

audit-prep-assistant

trailofbits

Prepares codebases for security review using Trail of Bits' checklist. Helps set review goals, runs static analysis tools, increases test coverage, removes dead code, ensures accessibility, and generates documentation (flowcharts, user stories, inline comments).

15

bullmq-specialist

davila7

BullMQ expert for Redis-backed job queues, background processing, and reliable async execution in Node.js/TypeScript applications. Use when: bullmq, bull queue, redis queue, background job, job queue.

2595

Search skills

Search the agent skills registry