Run any Skill in Manus with one click

sbom

Stars6

Forks0

UpdatedJune 18, 2026 at 22:36

Generate standards-compliant SBOMs (CycloneDX 1.6 + SPDX 2.3) for a project across stacks (npm, Python, Go, Rust, Java, containers), with optional quality scoring, vulnerability scan, VEX, and signing. Adds zero dependencies to the target project. Use when the user asks for a software bill of materials, dependency inventory, supply-chain manifest, or CycloneDX/SPDX output.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

diegocconsolini

diegocconsolini/ClaudeSkillCollection

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

5 files

SKILL.md

readonly

name	sbom
description	Generate standards-compliant SBOMs (CycloneDX 1.6 + SPDX 2.3) for a project across stacks (npm, Python, Go, Rust, Java, containers), with optional quality scoring, vulnerability scan, VEX, and signing. Adds zero dependencies to the target project. Use when the user asks for a software bill of materials, dependency inventory, supply-chain manifest, or CycloneDX/SPDX output.
argument-hint	[path-to-project]
metadata	{"skill-version":"0.2.0","author":"ClaudeSkillCollection","license":"MIT"}

SBOM Generator Skill

Produce a Software Bill of Materials for a project without adding any dependency to it. Wraps the workspace's zero-dependency generator (vendored at scripts/generate-sbom.mjs) and the per-stack ephemeral-runner approach, and adds the optional quality / scan / VEX / sign layers.

Grounded reference: references/sbom-knowledge.md. Detailed agent procedure: agents/sbom-generator.md.

Usage

/sbom                 # SBOM for the current directory (auto-detect stack)
/sbom ./path/to/repo  # SBOM for a specific project
/sbom --score         # also run sbomqs quality scoring (gate ≥ 7.0)
/sbom --scan          # also run a vulnerability scan over the SBOM (Grype/OSV)
/sbom --sign          # also create a cosign attestation (asks first; networked)

Hard rules (non-negotiable)

Ask before touching a repo. One repo at a time; show the plan first.
Never npm install (or any manifest-modifying install) to make an SBOM. Use the vendored lockfile reader for npm; ephemeral runners (npx -y, pipx run, go run …@latest, Docker) for everything else.
Never guess a project's stack/lockfile/scripts — read its manifest first.
SBOMs are written to the project's sbom/ directory and kept out of its bundle.
--scan and --sign are networked and opt-in — confirm before running.

What it emits

sbom/bom.cdx.json — CycloneDX 1.6
sbom/bom.spdx.json — SPDX 2.3 (3.0 only on explicit request — breaking JSON-LD)

Both satisfy the NTIA 7 minimum fields. See the knowledge pack for formats, per-stack tools, regulatory facts (US M-26-05 / EU CRA), VEX (OpenVEX), and signing (cosign v3) — all verified 2026-06-18.

Quick decision: which generator?

Detected	Generator
npm `package-lock.json` (v2/v3)	vendored `scripts/generate-sbom.mjs` (zero-dep)
pnpm / yarn / no npm lockfile	Syft (`syft dir:.`)
Python / Go / Rust / Maven / .NET	per-stack ephemeral runner (knowledge pack §4)
container image / mixed repo	Syft / cdxgen

Status: v0.2.0 — standalone skill (Option B), made loadable (2026-06-18).

Install: the loadable copy lives at .claude/skills/sbom/ (recognized location → invocable as /sbom). This directory (sbom-generator/) is the tracked canonical source; .claude/ is gitignored, so re-copy after edits: cp -r sbom-generator/{SKILL.md,agents,references,scripts} .claude/skills/sbom/.
Format fixed: SKILL.md (all caps), valid frontmatter (off-schema invocation/version/author/license removed; name: sbom drives /sbom).
npm path verified against a real 787-component project (valid CycloneDX 1.6 + SPDX 2.3, reproducible bytes); license expressions emit as {expression}; npm workspaces monorepos trigger an explicit under-report warning → route to Syft.
Non-npm stacks rely on ephemeral tools that must be available/fetchable. Not in marketplace.json (standalone skill); promote to a plugin later if desired.

More from this repository

same repository

batch-security-migration

diegocconsolini/ClaudeSkillCollection

Use when applying the same security fix across many files or repos at once — large-scale vulnerability remediation. Provides 7 copy-paste /batch recipes (XSS, HTTPS, SQLi, input validation, log PII, secret rotation, CVE patches) each with a safety tier and false-positive trap, plus scan_diff.py to prove the migration introduced no new HIGH/CRITICAL findings.

2026-06-266

security-hooks

diegocconsolini/ClaudeSkillCollection

Use this skill to install ready-made Claude Code hooks for security — a ConfigChange compliance audit trail (logs every settings/skill change), plus PreToolUse guards and optional HTTP notifications for security-relevant events. Covers command, http, and prompt hook types.

2026-06-186

security-memory-templates

diegocconsolini/ClaudeSkillCollection

Use this skill to seed Claude Code's auto-memory with pre-built security/compliance patterns — known-safe code patterns, false-positive suppressions for the plugin-security-checker, org compliance rules, and supply-chain best practices. Helps Claude apply consistent security judgment across sessions.

2026-06-186

chrome-devtools-optimizer

diegocconsolini/ClaudeSkillCollection

Use this skill to reduce token consumption by 70-80% when using the Chrome DevTools MCP. Applies a snapshot-first strategy (text over images) with decision trees and pattern guides for navigation, forms, debugging, and visual checks, plus optional Gemini Flash vision processing for the cases that genuinely need an image.

2026-06-186

claude-guide

diegocconsolini/ClaudeSkillCollection

Navigate Claude Code documentation and get quick answers about configuration, MCP, plugins, and best practices.

2026-06-186

docx-smart-extractor

diegocconsolini/ClaudeSkillCollection

Use this skill to extract and analyze large Word documents (1MB-50MB+) with minimal token usage. Losslessly extracts text, tables, formatting, and structure while achieving 10-50x token reduction through local extraction, semantic chunking by headings, and intelligent caching. Use when a .docx is too large for the context window (policies, contracts, technical reports).

2026-06-186

name	sbom
description	Generate standards-compliant SBOMs (CycloneDX 1.6 + SPDX 2.3) for a project across stacks (npm, Python, Go, Rust, Java, containers), with optional quality scoring, vulnerability scan, VEX, and signing. Adds zero dependencies to the target project. Use when the user asks for a software bill of materials, dependency inventory, supply-chain manifest, or CycloneDX/SPDX output.
argument-hint	[path-to-project]
metadata	{"skill-version":"0.2.0","author":"ClaudeSkillCollection","license":"MIT"}

SBOM Generator Skill

Grounded reference: references/sbom-knowledge.md. Detailed agent procedure: agents/sbom-generator.md.

Usage

/sbom                 # SBOM for the current directory (auto-detect stack)
/sbom ./path/to/repo  # SBOM for a specific project
/sbom --score         # also run sbomqs quality scoring (gate ≥ 7.0)
/sbom --scan          # also run a vulnerability scan over the SBOM (Grype/OSV)
/sbom --sign          # also create a cosign attestation (asks first; networked)

Hard rules (non-negotiable)

Ask before touching a repo. One repo at a time; show the plan first.
Never npm install (or any manifest-modifying install) to make an SBOM. Use the vendored lockfile reader for npm; ephemeral runners (npx -y, pipx run, go run …@latest, Docker) for everything else.
Never guess a project's stack/lockfile/scripts — read its manifest first.
SBOMs are written to the project's sbom/ directory and kept out of its bundle.
--scan and --sign are networked and opt-in — confirm before running.

What it emits

sbom/bom.cdx.json — CycloneDX 1.6
sbom/bom.spdx.json — SPDX 2.3 (3.0 only on explicit request — breaking JSON-LD)

Quick decision: which generator?

Detected	Generator
npm `package-lock.json` (v2/v3)	vendored `scripts/generate-sbom.mjs` (zero-dep)
pnpm / yarn / no npm lockfile	Syft (`syft dir:.`)
Python / Go / Rust / Maven / .NET	per-stack ephemeral runner (knowledge pack §4)
container image / mixed repo	Syft / cdxgen

Status: v0.2.0 — standalone skill (Option B), made loadable (2026-06-18).

Install: the loadable copy lives at .claude/skills/sbom/ (recognized location → invocable as /sbom). This directory (sbom-generator/) is the tracked canonical source; .claude/ is gitignored, so re-copy after edits: cp -r sbom-generator/{SKILL.md,agents,references,scripts} .claude/skills/sbom/.
Format fixed: SKILL.md (all caps), valid frontmatter (off-schema invocation/version/author/license removed; name: sbom drives /sbom).
npm path verified against a real 787-component project (valid CycloneDX 1.6 + SPDX 2.3, reproducible bytes); license expressions emit as {expression}; npm workspaces monorepos trigger an explicit under-report warning → route to Syft.
Non-npm stacks rely on ephemeral tools that must be available/fetchable. Not in marketplace.json (standalone skill); promote to a plugin later if desired.