Agent skill

Init Catalog

by kubeflow in kubeflow/hub

Scaffold a new catalog plugin: run catalog-gen, replace all panic("TODO") stubs with minimal working implementations, generate OpenAPI server stubs, and verify the build compiles.

Apache-2.0Auto-check passedBackend & APIs

Install Init Catalog

skills CLI
$ npx skills add kubeflow/hub --skill init-catalog -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install kubeflow/hub init-catalog --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/kubeflow/hub.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/init-catalog .claude/skills/init-catalog && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
init-catalog
GitHub stars
186
Token cost
~3.9k tokens
SKILL.md length
1,113 words
Files
4
Skills in repo
5
Repo updated
First seen
Licence
Apache-2.0

At a glance

Scaffold a new catalog plugin: run catalog-gen, replace all panic("TODO") stubs with minimal working implementations, generate OpenAPI server stubs, and verify the build compiles.

  • Works in 11 steps: Gather Inputs → Run catalog-gen → Register Asset Type → …
  • Tasks that involve OpenAPI specifications
  • SKILL.md covers Phase 1: Gather Inputs, Phase 2: Run catalog-gen, Phase 3: Register Asset Type and Phase 4: Replace Panic TODOs, plus 7 more sections
  • Calls make and go

What it does

Init Catalog is an agent skill from kubeflow/hub. Scaffold a new catalog plugin: run catalog-gen, replace all panic("TODO") stubs with minimal working implementations, generate OpenAPI server stubs, and verify the build compiles. Produces a plugin that starts without crashes.

Its SKILL.md is about 3.9k tokens, which your agent loads only when the skill is triggered. The skill folder holds 3 other files (for example `panic-crud.md`, `panic-mapping.md` and `panic-ordering.md`).

It sits in Backend & APIs, covering OpenAPI specifications. It works with OpenAPI. The repository describes itself as: Model Registry provides a single pane of glass for ML model developers to index and manage models, versions, and ML artifacts metadata. It fills a gap between model… The licence is Apache-2.0.

When your agent uses it

  • Tasks that involve OpenAPI specifications

Example prompts

  • “/init-catalog”

Workflow steps

11 steps, taken from the step headings in SKILL.md.

  1. Gather Inputs
  2. Run catalog-gen
  3. Register Asset Type
  4. Replace Panic TODOs
  5. Generate OpenAPI Stubs
  6. Implement DB Provider
  7. Create OpenAPI Service Implementation
  8. Implement YAML Provider + Wire Loader
  9. Wire RegisterRoutes
  10. Verify Compilation
  11. Report

What it can do on your machine

Read from SKILL.md and the folder at commit 3369d7e. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • make
    • go

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Init Catalog loads about 3.9k tokens when it runs. Until then it costs about 60 tokens; SKILL.md has 1,113 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~60
When it runs · the whole SKILL.md, loaded when a task matches
~3.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from kubeflow/hub at commit 3369d7e, republished under its Apache-2.0 licence (© kubeflow). 1,113 words, ~3,850 tokens.

Download SKILL.mdSave it as .claude/skills/init-catalog/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
init-catalog
description
Scaffold a new catalog plugin: run catalog-gen, replace all panic("TODO") stubs with minimal working implementations, generate OpenAPI server stubs, and verify the build compiles. Produces a plugin that starts without crashes.
user-invocable
true

Init Catalog Plugin

Scaffold a new catalog plugin end-to-end so it compiles and starts without panics.

Phase 1: Gather Inputs

Ask the user for all three in a single prompt:

  • Plugin name — snake_case (e.g., agent, dataset, pipeline)
  • Description — human-readable (e.g., "Agent catalog")
  • Entities — comma-separated Name:type pairs where type is context, artifact, or execution (e.g., CatalogAgent:context,CatalogAgentArtifact:artifact)

Validate before proceeding:

  • Name contains only lowercase letters, digits, and underscores
  • At least one entity is provided
  • Each entity has exactly one colon separating PascalCase name from type
  • Each type is one of: context, artifact, execution

Phase 2: Run catalog-gen

bash
make -C catalog gen/catalog-plugin NAME=<name> DESCRIPTION="<desc>" ENTITIES=<entity1>,<entity2>

Check exit code. Report files created.

Phase 3: Register Asset Type

New plugins must register their asset type in the shared catalog infrastructure so that sources can be scoped to the correct plugin via the model catalog's /sources endpoint.

The asset type value is derived from the primary entity's snake_case name, pluralized (e.g., entity CatalogAgent → catalog_agents, entity Agent → agents).

3a: Add to the OpenAPI enum

Edit api/openapi/src/catalog.yaml — find the CatalogAssetType enum and add the new value:

yaml
CatalogAssetType:
  type: string
  enum:
    - models
    - mcp_servers
    - <asset_type_value>    # e.g., agents
  default: models
3b: Add the Go constant

Edit catalog/internal/catalog/basecatalog/source_types.go — add to the AssetType constants:

go
const (
    AssetTypeModels     = "models"
    AssetTypeMCPServers = "mcp_servers"
    AssetType<PascalAssetType> = "<asset_type_value>"  // e.g., AssetTypeAgents = "agents"
)
3c: Add to the validation map

Edit catalog/internal/catalog/basecatalog/validation.go — add to the validAssetTypes map in ValidateNamedQueries:

go
validAssetTypes := map[string]bool{
    AssetTypeModels:     true,
    AssetTypeMCPServers: true,
    AssetType<PascalAssetType>: true,
}

Also update the error message format string to include the new constant.

3d: Add AssetType field to PluginSource (if not already present)

Check catalog/internal/catalog/basecatalog/source_types.go — the PluginSource struct must have an AssetType field. If missing, add it:

go
type PluginSource struct {
    Name       string                      `json:"name" yaml:"name"`
    ID         string                      `json:"id" yaml:"id"`
    Type       string                      `json:"type" yaml:"type"`
    Enabled    *bool                       `json:"enabled,omitempty" yaml:"enabled,omitempty"`
    Properties map[string]any              `json:"properties" yaml:"properties"`
    Labels     []string                    `json:"labels" yaml:"labels"`
    AssetType  *apimodels.CatalogAssetType `json:"assetType,omitempty" yaml:"assetType,omitempty"`

    Origin string `json:"-" yaml:"-"`
}

This matches the pattern used by MCPSource.

Phase 4: Replace Panic TODOs

All 8 panics are in the generated entity service files at: catalog/internal/catalog/<name>catalog/service/<entity_snake>.go

Read each generated service file first to get the exact function signatures with concrete entity names. Then replace each panic using the recipes below.

Type Reference Table

Use this table to select the correct types, mappers, and table names for each entity's datastore type:

Datastore TypeSchema TypeProperty TypeToProperties MapperToEntity MapperTableProperty TableJoin FieldName Type
contextschema.Contextschema.ContextPropertyservice.MapPropertiesToContextProperty(prop, entityID, isCustom)service.MapContextPropertyToProperties(prop)"Context""ContextProperty"context_idstring
artifactschema.Artifactschema.ArtifactPropertyservice.MapPropertiesToArtifactProperty(prop, entityID, isCustom)service.MapArtifactPropertyToProperties(prop)"Artifact""ArtifactProperty"artifact_id*string
executionschema.Executionschema.ExecutionPropertyservice.MapPropertiesToExecutionProperty(prop, entityID, isCustom)service.MapExecutionPropertyToProperties(prop)"Execution""ExecutionProperty"execution_id*string

The service alias refers to github.com/kubeflow/hub/internal/platform/db/repository (already imported in the generated file).

Reference implementations

Before writing code, read these files for the exact patterns:

  • Context entities: catalog/internal/catalog/mcpcatalog/service/mcp_server.go
  • Artifact entities: catalog/internal/catalog/modelcatalog/service/catalog_model_artifact.go
  • Execution entities: catalog/internal/catalog/mcpcatalog/service/mcp_server_tool.go
Panic recipes

Each group of panics is documented in a separate file. Read the file for each group before implementing.

  • Panics 1–3 (entity ↔ schema mapping): Read .agents/skills/init-catalog/panic-mapping.md
  • Panics 4–5 (filtering & ordering): Read .agents/skills/init-catalog/panic-ordering.md
  • Panics 6–8 (delete/query ops, imports, Save override): Read .agents/skills/init-catalog/panic-crud.md

Phase 5: Generate OpenAPI Stubs

Three make targets must run in order:

bash
# 1. Rebuild the merged catalog spec to include the new plugin
make api/openapi/catalog.yaml

# 2. Generate server stubs (controller, routes, type_asserts)
make -C catalog gen/openapi-server

# 3. Generate client model types (type_asserts.go references these)
make -C catalog gen/openapi

Step 3 is critical — gen/openapi-server produces type_asserts.go which references client model types (e.g., model.Agent, model.AgentList) from catalog/pkg/openapi/. Without gen/openapi, those types don't exist and the build fails.

Verify that these files were created or updated:

  • catalog/internal/server/openapi/api_<name>_catalog_service.go
  • catalog/internal/server/openapi/api_<name>.go
  • catalog/pkg/openapi/model_<entity_snake>.go (one per entity)

Phase 6: Implement DB Provider

The generated db_<name>.go has a TODO stub. Replace it with a working implementation that queries the repository and maps results to OpenAPI models.

  1. Export the type: rename the struct from db<PascalName>CatalogImpl to DB<PascalName>Catalog so the service implementation can reference it.

  2. Add a List<PascalName>sParams struct with fields: Name, SourceIDs, FilterQuery, OrderBy, SortOrder, NextPageToken, PageSize.

  3. Add List<Entity>s method: build ListOptions from params, call repository .List(), map each result via a mapping function, return the API list type with pagination. For pointer fields on the list struct (check catalog/pkg/openapi/model_<entity>_list.go), use &variable or new(value) (Go 1.26 builtin). The NextPageToken from the repository is a plain string; only assign to the response if non-empty (the API model field is *string).

  4. Add Get<Entity> method: parse ID string to int32, call repository .GetByID(), map via the mapping function, return or 404.

  5. Implement mapDB<Entity>ToAPI mapping function: map ID (format int64 → string), Name from attributes, then loop over Properties matching by name:

    • String fields: res.<Field> = prop.StringValue
    • Boolean fields: res.<Field> = prop.BoolValue
    • Array fields: json.Unmarshal from prop.StringValue into []string

    Reference: catalog/internal/catalog/modelcatalog/db_catalog.go function mapDBModelToAPIModel.

  6. Remove the var _ sharedmodels.CatalogSourceRepository placeholder and the TODO comments.

Show full SKILL.md (473 more words)Show less

Phase 7: Create OpenAPI Service Implementation

After gen/openapi-server runs, an interface <PascalName>CatalogServiceAPIServicer exists in catalog/internal/server/openapi/api_<name>.go. Create a service implementation that calls through to the DB provider.

  1. Read catalog/internal/server/openapi/api_<name>.go to get the exact interface methods and their signatures.

  2. Create catalog/internal/server/openapi/api_<name>_catalog_service_service.go with:

    • A struct holding a *<pkg>.DB<PascalName>Catalog provider field
    • A constructor New<PascalName>CatalogServiceAPIService(provider) that takes the provider
    • Each interface method delegates to the provider:
      • Find<Entity>s → call provider.List<Entity>s(ctx, params), return 200 or error
      • Get<Entity> → call provider.Get<Entity>(ctx, id), return 200 or 404
      • GetFilterOptions → call provider.GetFilterOptions(ctx)
    • For errors, use api.ErrNotFound / api.ErrBadRequest checks from github.com/kubeflow/hub/pkg/api
    • Note: Plugins do NOT implement a FindSources method — sources are managed by the model catalog via the shared /sources endpoint with assetType filtering.

    Match the exact method signatures from the interface.

Phase 8: Implement YAML Provider + Wire Loader

Add a YAML provider so the plugin can load data from YAML files at startup.

7a: Create the YAML provider

Create catalog/internal/catalog/<name>catalog/yaml_provider.go with:

  1. A YAML struct matching the data file format (using the primary entity's field names). CRITICAL: Every field MUST have both yaml and json struct tags. The k8s.io/apimachinery/pkg/util/yaml.Unmarshal used to read YAML data files converts YAML→JSON internally, then uses encoding/json to populate the struct. Without json tags, fields with underscores or camelCase names silently fail to parse (Go's JSON decoder only falls back to case-insensitive matching, which doesn't handle underscores).

    go
    type yaml<PascalName> struct {
        Name        string            `yaml:"name" json:"name"`
        Description *string           `yaml:"description,omitempty" json:"description,omitempty"`
        // ... string/bool/array fields from the spec
        CustomProperties map[string]any `yaml:"customProperties,omitempty" json:"customProperties,omitempty"`
    }
    
    type yaml<PascalName>Catalog struct {
        Source string           `yaml:"source" json:"source"`
        Items  []yaml<PascalName> `yaml:"<entity_plural>" json:"<entity_plural>"`
    }
  2. A provider function that reads a YAML file and converts each entry to a domain entity (using the models.<Entity>Impl type with Properties from the YAML fields).

  3. Registration via init() — but since this is a generic plugin using PluginSource, the loader already knows the source type from source.Type. The provider should be called when source.Type == "yaml".

7b: Wire PerformLeaderOperations in the loader

Update the generated loader.go to replace the TODO in PerformLeaderOperations:

go
func (l *<PascalName>Loader) PerformLeaderOperations(ctx context.Context, allKnownSourceIDs mapset.Set[string]) error {
    glog.Infof("%s loader performing leader operations", "<name>")

    ctx, cancel := context.WithCancel(ctx)
    l.setCloser(cancel)

    allSources := l.Sources.AllSources()

    for id, source := range allSources {
        if !source.IsEnabled() {
            basecatalog.SaveSourceStatus(l.services.CatalogSourceRepository, id, basecatalog.SourceStatusDisabled, "")
            continue
        }

        if source.Type != "yaml" {
            glog.Warningf("unknown %s provider type: %s", "<name>", source.Type)
            basecatalog.SaveSourceStatus(l.services.CatalogSourceRepository, id, basecatalog.SourceStatusError, "unknown provider type: "+source.Type)
            continue
        }

        if err := l.loadFromYAML(ctx, id, source); err != nil {
            glog.Errorf("error loading %s from source %s: %v", "<name>", id, err)
            basecatalog.SaveSourceStatus(l.services.CatalogSourceRepository, id, basecatalog.SourceStatusError, err.Error())
            continue
        }

        basecatalog.SaveSourceStatus(l.services.CatalogSourceRepository, id, basecatalog.SourceStatusAvailable, "")
    }

    glog.Infof("%s loader leader operations complete", "<name>")
    return nil
}

The loadFromYAML method reads the YAML file from source.Properties["yamlCatalogPath"] (resolving relative paths via source.Origin), parses each entry, converts to a domain entity, and saves via the repository. The Save call signature depends on datastore type:

  • Context entities: l.services.<Entity>Repository.Save(entity) (1 param)
  • Artifact/execution entities: l.services.<Entity>Repository.Save(entity, parentID) (2 params)

Reference: catalog/internal/catalog/mcpcatalog/providers.go for path resolution and catalog/internal/catalog/mcpcatalog/loader.go updateDatabase for the save pattern.

Phase 9: Wire RegisterRoutes

Update catalog/internal/plugins/<name>/plugin.go:

  1. Add import: "github.com/kubeflow/hub/catalog/internal/server/openapi"

  2. Replace the RegisterRoutes method:

go
func (p *Plugin) RegisterRoutes(router chi.Router) error {
    provider := <pkg>.NewDB<PascalName>Catalog(p.services, p.loader.Sources)
    svc := openapi.New<PascalName>CatalogServiceAPIService(provider)
    ctrl := openapi.New<PascalName>CatalogServiceAPIController(svc)

    for _, route := range ctrl.OrderedRoutes() {
        router.Method(route.Method, route.Pattern, route.HandlerFunc)
    }

    return nil
}

Phase 10: Verify Compilation

bash
go build ./catalog/...

If compilation fails, read the error output, fix the issues (typically unused or missing imports, pointer vs value mismatches on list struct fields), and retry.

Phase 11: Report

Print a summary with:

  1. Created — list all files catalog-gen created
  2. Modified — entity service panics replaced, db_provider wired, loader implemented, plugin.go wired
  3. Generated — OpenAPI server stubs + service implementation
  4. Build — pass/fail

Then print Next Steps the developer must complete manually:

Next steps:
  1. Edit the OpenAPI spec (api/openapi/src/plugins/<name>.yaml) to add entity-specific fields.
     The generated spec already uses `allOf` with `BaseResource` (which provides
     customProperties, description, externalId, and timestamp fields) and includes
     q, sourceLabel, and filterQuery parameters on the list endpoint.

     Add entity-specific properties under the second `allOf` entry alongside source_id.
     For URL fields use `format: uri`. Follow MCP's camelCase naming for new fields
     (e.g., repositoryUrl, not repository_url) — exception: source_id stays snake_case
     because it's a cross-plugin convention.

  2. Run /sync-catalog to propagate spec changes
  3. Run /catalog-sample-data to generate test data
  4. Add list filter logic in apply<Entity>ListFilters if needed
  5. Add entity-specific properties to *_entity_mappings.go

© kubeflow, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files in .agents/skills/init-catalog of kubeflow/hub.

  • SKILL.md
  • panic-crud.md
  • panic-mapping.md
  • panic-ordering.md

Open the folder on GitHubat commit 3369d7e

Compare with similar skills

Init Catalog next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Init Catalog compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Init Catalog this skillkubeflow/hub186—~3.9kAutomated safety check: PassApache-2.0
ToolJet Marketplace Plugin BuilderToolJet/ToolJet41k—~2.1kAutomated safety check: PassAGPL-3.0
Step Partsearthtojake/text-to-cad18k1 repos~1.5kAutomated safety check: PassMIT
API DesignerJeffallan/claude-skills12k2 repos~2kAutomated safety check: PassMIT
OpenAPI to MCP Servermcp-use/mcp-use11k—~5.2kAutomated safety check: PassApache-2.0
Use Yaakmountain-loop/yaak19k—~1.9kAutomated safety check: PassMIT

Similar skills

  • Turns an API description, such as an OpenAPI file or a Postman collection, into a connector plugin for ToolJet's marketplace and checks it with the repo's validator.

    41k GitHub stars~2.1k tokensUpdated today
    Backend & APIsAuto-check passed
  • Step Parts

    earthtojake/text-to-cad

    Find, evaluate, and download common purchasable CAD parts from step.parts, including named off-the-shelf actuators, servos, motors, electronics boards, connectors, screws, bolts, nuts, washers…

    18k GitHub starsUsed in 1 repo~1.5k tokens
    Backend & APIsAuto-check passed
  • API Designer

    Jeffallan/claude-skills

    Designs REST and GraphQL APIs from resource modeling to an OpenAPI 3.1 contract, with versioning, pagination and RFC 7807 error handling.

    12k GitHub starsUsed in 2 repos~2k tokens
    Backend & APIsAuto-check passed
  • OpenAPI to MCP Server

    mcp-use/mcp-use

    Turns an OpenAPI or Swagger spec into an MCP server with the mcp-use TypeScript SDK, mapping each operation to a tool, wiring auth, testing and deploying.

    11k GitHub stars~5.2k tokensUpdated today
    Backend & APIsAuto-check passed
  • Use Yaak

    mountain-loop/yaak

    A skill your agent uses when the user mentions Yaak, a Yaak workspace, or the yaak command, or asks to call, hit, or smoke test HTTP/REST endpoints, save or organize API requests for reuse or manual…

    19k GitHub stars~1.9k tokensUpdated yesterday
    Backend & APIsAuto-check passed
  • Old Coder API Design

    AmazingAng/old-coder

    Reviews or designs an HTTP/JSON API's endpoints, auth, pagination, versioning and deprecations, guarding against inventing a bespoke interface or silently breaking consumers.

    749 GitHub starsUsed in 1 repo~3.4k tokens
    Backend & APIsAuto-check passed

More from kubeflow/hub

  • Generate or update sample YAML data for a catalog plugin. An agent skill from kubeflow/hub.

    186 GitHub stars~1.1k tokensUpdated yesterday
    Auto-check passed
  • A skill your agent uses when the user asks to "create an agent catalog", "generate agent catalog source", "build agent catalog from repo", "catalog my agents", or wants to scan a repository…

    186 GitHub stars~5.4k tokensUpdated yesterday
    Auto-check: notes
  • Catalog Add Route

    kubeflow/hub

    Add an endpoint or query parameter to a catalog plugin's OpenAPI spec.

    186 GitHub stars~1.3k tokensUpdated yesterday
    Auto-check passed
  • Sync Catalog

    kubeflow/hub

    Sync a catalog plugin's generated code and domain layer after OpenAPI spec changes.

    186 GitHub stars~2.1k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Init Catalog

What does Init Catalog do?

Scaffold a new catalog plugin: run catalog-gen, replace all panic("TODO") stubs with minimal working implementations, generate OpenAPI server stubs, and verify the build compiles. Init Catalog is an agent skill from kubeflow/hub. Scaffold a new catalog plugin: run catalog-gen, replace all panic("TODO") stubs with minimal working implementations, generate OpenAPI server stubs, and verify the build compiles.

When should I use Init Catalog?

Init Catalog fits situations like: tasks that involve OpenAPI specifications.

How do I install Init Catalog in Claude Code?

Run `npx skills add kubeflow/hub --skill init-catalog -a claude-code`. Or copy the skill folder (.agents/skills/init-catalog in kubeflow/hub) into .claude/skills/init-catalog in your project. Claude Code loads it when a task matches its description.

How do I install Init Catalog in Codex?

Run `npx skills add kubeflow/hub --skill init-catalog -a codex`. Or copy the skill folder (.agents/skills/init-catalog in kubeflow/hub) into .agents/skills/init-catalog in your project. Codex loads it when a task matches its description.

Can I use Init Catalog in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add kubeflow/hub --skill init-catalog -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/init-catalog, .gemini/skills/init-catalog, .github/skills/init-catalog and .opencode/skills/init-catalog in your project.

What does Init Catalog need to run?

Going by SKILL.md and its folder, Init Catalog needs the command-line tools its instructions call (make and go).

Does Init Catalog access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Init Catalog safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Init Catalog use?

Init Catalog is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Init Catalog use?

About 3.9k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Init Catalog?

Skills that share tags, products or a category with Init Catalog: ToolJet Marketplace Plugin Builder (ToolJet/ToolJet, 41k stars), Step Parts (earthtojake/text-to-cad, 18k stars), API Designer (Jeffallan/claude-skills, 12k stars) and OpenAPI to MCP Server (mcp-use/mcp-use, 11k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Init Catalog?

kubeflow (a GitHub organization) maintains it in kubeflow/hub, which has 186 GitHub stars. The repository holds 5 skills in this directory. The repository was last updated on October 6, 2026.

Source: kubeflow/hub on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.