Marketplace repo-metadata
This skill should be used when the user asks to "generate repository metadata", "create catalog-info.yaml", "add repo metadata", "document repository structure", or mentions generating structured metadata for service catalog or architecture documentation.
install
source · Clone the upstream repo
git clone https://github.com/aiskillstore/marketplace
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/aiskillstore/marketplace "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/astrabit-cpt/repo-metadata" ~/.claude/skills/aiskillstore-marketplace-repo-metadata && rm -rf "$T"
manifest:
skills/astrabit-cpt/repo-metadata/SKILL.mdsource content
Repository Metadata
Generate structured
catalog-info.yaml metadata for repositories using industry-standard conventions (based on Backstage catalog format). This metadata enables cross-repository architecture analysis and service catalog functionality.
Purpose
Create and maintain
catalog-info.yaml files that describe a repository's role in the broader architecture. This metadata feeds into architectural views, dependency graphs, and service groupings across the entire organization.
When to Use
Trigger this skill when:
- User asks to "generate repo metadata" or "create catalog-info.yaml"
- User wants to document a repository for a service catalog
- User needs to prepare a repository for cross-repo architecture analysis
- User mentions "service catalog" or "component metadata"
Metadata Schema
The
catalog-info.yaml file follows Backstage conventions with Astrabit-specific extensions:
apiVersion: astrabit.io/v1 kind: Component metadata: name: service-name # Required: Unique identifier description: Brief description tags: - backend - user-management spec: # Service Classification type: service # Required: service, gateway, worker, library, frontend, database category: backend # Broader category domain: trading # Business domain owner: platform-team # Team responsible # Dependencies (Upstream) dependsOn: - component: auth-service type: service - component: user-db type: database # APIs Provided providesApis: - name: User API type: REST definition: ./openapi.yaml # APIs Consumed consumesApis: - name: Auth API providedBy: auth-service # Events Produced eventProducers: - name: user-events type: kafka topic: user.created schema: avro # Events Consumed eventConsumers: - name: order-events type: kafka topic: order.placed group: user-service-group # HTTP Routes (for gateways/services) routes: - path: /api/users/* methods: [GET, POST, PUT, DELETE] handler: this - path: /api/auth/* methods: [POST] forwardsTo: auth-service # Infrastructure runtime: nodejs # nodejs, python, go, java, etc. framework: nestjs # nestjs, fastapi, spring, etc.
Generation Workflow
Phase 1: Analyze Repository
Gather information about the repository:
-
Use existing analysis scripts:
python skills/repo-docs/scripts/analyze-repo-structure.py /path/to/repo python skills/repo-docs/scripts/find-integration-points.py /path/to/repo -
Read existing documentation:
- Check for
- contains upstream/downstream relationshipsINTEGRATIONS.md - Check for
- contains service role and dependenciesARCHITECTURE.md - Check for
- contains basic description and tech stackREADME.md
- Check for
-
Detect from code:
- Language from file extensions and package files
- Framework from dependencies
- Integration points from import patterns
Phase 2: Generate Metadata
Based on analysis, generate
catalog-info.yaml with detected values:
| Field | Detection Method |
|---|---|
| Repo name or field |
| README title/description or generated from code |
| Inferred from code patterns (gateway has routes, worker has consumers only) |
| From package files (, , ) |
| From dependencies (, , , etc.) |
| From integration point scanning |
| From or similar patterns |
| From , , or similar patterns |
| From , , router definitions |
Phase 3: Present and Refine
Present the generated metadata to the user in a table format:
Generated catalog-info.yaml: | Field | Value | Source | |-------|-------|--------| | name | user-service | repo name | | type | service | detected: has routes and consumers | | runtime | nodejs | package.json | | framework | nestjs | dependencies | | domain | unknown | ❌ needs input | | owner | unknown | ❌ needs input | | dependsOn | auth-service, user-db | integration scan |
Prompt user to review and fill in missing fields (marked with ❌).
Phase 4: Write Metadata File
Write
catalog-info.yaml to the repository root.
Phase 5: Update Related Documentation
Offer to update related docs to reference the new metadata file:
- Add link to
incatalog-info.yamlREADME.md - Update
to be consistent with metadataINTEGRATIONS.md
Service Type Detection
| Type | Indicators |
|---|---|
| gateway | Has with , handles external requests, minimal business logic |
| service | Has both and , business logic |
| worker | Only , no HTTP routes, background processing |
| library | No APIs consumed, only provides, shared utilities |
| frontend | in package.json, has build artifacts |
| database | Contains migrations, schemas, no application code |
Script Usage
Use
scripts/generate-metadata.py to automate metadata generation:
# Generate from current directory python skills/repo-metadata/scripts/generate-metadata.py # Generate from specific repo python skills/repo-metadata/scripts/generate-metadata.py /path/to/repo # Output as JSON for inspection python skills/repo-metadata/scripts/generate-metadata.py --format json
The script:
- Runs repo structure analysis
- Scans for integration points
- Reads existing docs
- Outputs
contentcatalog-info.yaml
Additional Resources
Reference Files
- Complete catalog-info.yaml schema referencereferences/schema.md
- Patterns for detecting service characteristicsreferences/detection-patterns.md
Example Templates
- Full template with all fieldsexamples/catalog-info-template.yaml
- Example gateway serviceexamples/catalog-info-gateway.yaml
- Example worker serviceexamples/catalog-info-worker.yaml
- Example shared libraryexamples/catalog-info-library.yaml
Quality Checklist
Before finalizing metadata, verify:
-
is unique across the organizationname -
correctly classifies the servicetype -
anddomain
are filled (not auto-detected)owner -
lists all upstream dependenciesdependsOn -
andeventProducers
are completeeventConsumers - Routes are documented if this is a gateway/service
- File is valid YAML
- File is at repository root (
)catalog-info.yaml