custom-property-author

Guides authoring and reviewing CycloneDX cdx: custom properties in cdxgen BOM output.

1.1k|260|Updated Dec 30, 2019
One-click install
npx skills add https://github.com/cdxgen/cdxgen --skill custom-property-author
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: custom-property-author
Source: https://github.com/cdxgen/cdxgen/tree/main/.agents/skills/custom-property-author
Command: npx skills add https://github.com/cdxgen/cdxgen --skill custom-property-author

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Adding custom properties to CycloneDX BOM output risks leaking secrets, duplicating standard fields, or breaking the build when properties are undocumented. This Skill enforces a gated workflow so every new cdx: or internal: property is namespaced correctly, value-safe, and documented.

Core Features & Use Cases

  • Standard-field-first gate: Checks whether data fits existing CycloneDX fields (supplier, externalReferences, evidence, pedigree, hashes, modelCard) before allowing a custom property.
  • Naming and value hygiene rules: Enforces the cdx:<ecosystem>:<field> convention and safe value shapes such as booleans, counts, and categories instead of raw secrets, URLs, or command lines.
  • Documentation gate: Ensures every new property is registered in docs/CUSTOM_PROPERTIES.md, since lib/customProperties.poku.js fails the build on undocumented properties.
  • Use Case: When adding a property like cdx:npm:hasInstallScript to cdxgen output, use this Skill to verify naming, redact secret-bearing values, update the documentation table, and add a test asserting no secrets are emitted.

Quick Start

Review my new cdx: custom property for cdxgen and tell me whether it passes the naming, value hygiene, and documentation gates.

Frequently Asked Questions about custom-property-author

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a custom property to CycloneDX BOM output in cdxgen?

First check whether a standard CycloneDX field like externalReferences, evidence, or pedigree fits the data. If not, name the property using the cdx:<ecosystem>:<field> convention, document it in docs/CUSTOM_PROPERTIES.md, and add a test asserting it emits safely.

What naming convention should CycloneDX custom properties use?

New properties use the cdx:<ecosystem-or-context>:<field> format, such as cdx:npm:hasInstallScript. Unnamespaced properties are rejected, internal: is reserved for unstable legacy details, and oci: and java:modules keep historical namespaces.

Can I put URLs or command lines in CycloneDX custom property values?

No. Raw URLs with query strings, tokens, or signature parameters and full command lines must not be emitted. Use safe derivatives like scheme, host, basename, counts, booleans, or category labels instead, since all values serialize as strings.

Why does the cdxgen build fail after adding a custom property?

The lib/customProperties.poku.js test scans all cdx: string literals in non-test lib*.js files and fails the build if any property is missing from docs/CUSTOM_PROPERTIES.md. Add the property to the appropriate table with its value shape and policy label.

When should I use a standard CycloneDX field instead of a custom property?

Always prefer standard fields when they fit: supplier or authors for entities, externalReferences for URLs, evidence for discovery locations, pedigree for lineage, hashes for digests, and modelCard or formulation for AI/ML data. Custom properties are a last resort.