# Build Capability Catalog > Create a CCC capability catalog (metadata.yaml + capabilities.yaml) for a cloud service, mapping equivalent offerings across AWS, Azure, and GCP and placing them in the correct catalogs / category folder. Use whenever the user asks to "create a capability catalog" / "capability catalog" for a cloud service, or "create a capability catalog for a service similar to ". - Skill: `finos/build-capability-catalog` (Agent Skill) - Install (CLI): `npx skillmds@latest add finos/build-capability-catalog` - Raw SKILL.md: https://api.skillmd.com/api/skills/finos/build-capability-catalog/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: finos (https://skillmd.com/u/finos) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/finos/build-capability-catalog --- # Capability Catalog Skill ## Purpose Create a capability catalog for a cloud service, supporting the onboarding process for new cloud service capabilities. ## Final Outcome `metadata.yaml` and `capabilities.yaml` files created for a new CCC service that maps to equivalent offerings across AWS, Azure, and GCP, with a new folder created in the correct category path in the repository. ## When to Use When the user asks to create a capability catalog for a cloud service. For example, "Create a capability catalog for a service similar to " or "Create a capability catalog". ## Step 1: Cross-Cloud Service Mapping 1. Request for the example service and the source cloud provider. - If No example is given, ask for an example. 1. Try to identify the cloud service provider from the example. - If cloud service provider is not identifiable, ask for clarification. Options allowed are AWS, Azure, GCP. 1. Resolve equivalent or closest offerings for AWS, Azure, and GCP. 2. Prefer official documentation domains: - AWS: `docs.aws.amazon.com` - Azure: `learn.microsoft.com/azure` - GCP: `cloud.google.com` 1. If multiple mappings exist, choose the closest functional match and list alternates briefly. ### Output Format First output line must be: **Step 1: Cross-Cloud Service Mapping** Return only the cross-cloud mapping in a markdown table: | Cloud | Service Name | Official Documentation | | --- | --- | --- | | AWS | `` | `` | | Azure | `` | `` | | GCP | `` | `` | Confidence: ## Step 2: Service Taxonomy Planning 1. Determine one provider-neutral common name that describes the three mapped offerings. 2. Propose one abbreviation with these rules: - Maximum length is 8 characters. - Use letters and numbers only. - Use ALL CAPS only. - Keep it recognizable and easy to read. 1. If the first abbreviation is ambiguous, propose one alternative. 2. Identify the appropriate category(s) for the service based on functionality and existing CCC categories in `catalogs/categories.yaml`. Determine one or more category ids (e.g., `CCC.Storage`). 3. Determine a folder name and full target path for the new service. 4. Validate the proposed category id(s) against `catalogs/categories.yaml`. 5. Determine the folder name and target path internally, but do not create the folder in this step. 6. Folder naming guidance: - Use lowercase kebab-case. - Keep names concise and descriptive. - Example: `object-storage`. 1. Example rule: - If category is `CCC.Storage`, create the service folder under `catalogs/storage/`. - If there is no folder for the category, create one with the category name in lowercase (e.g., `catalogs/storage/`). ### Output Format First output line must be: **Step 2: Service Taxonomy Planning** At the end of Step 2, return a single confirmation block in this format: Common Name: `` Abbreviation: `` Folder name: `` Target path: `` Categories: `` Reply with one of the following: 1. CONFIRM 2. EDIT Do not proceed to Step 3 until the user replies CONFIRM. If the user replies EDIT, apply the edits and return the updated Step 2 confirmation block, then wait for CONFIRM. ## Step 3: Create Target Folder 1. Use the confirmed target path from Step 2. 2. Create the target folder when it does not already exist. 3. If the folder already exists, do not recreate it and continue. ### Output Format First output line must be: **Step 3: Create Target Folder** Return folder creation result in this format: Target path: Folder Status: Confidence: ## Step 4: Create `metadata.yaml` 1. Use the confirmed values from Steps 1 to 3: - Confirmed cross-cloud mapping (AWS, Azure, GCP service names and links). - Confirmed common name. - Confirmed abbreviation. - Confirmed category id. - Confirmed target folder path. 1. Use `schemas/metadata-schema.json` as the source of truth for required and allowed metadata fields. 2. Build the metadata content from the confirmed inputs and the current schema: - Set `metadata.id` as `CCC.` where abbreviation is ALL CAPS, at most 8 characters, and uses only letters and numbers. - Set `metadata.title` to `CCC `. - Generate `metadata.description` as a concise provider-neutral summary of the service type. - Set `metadata.category-ids` to include the confirmed category id. - Populate `metadata.example-csp-services` with exactly AWS, Azure, and GCP entries from confirmed mapping. - Include any schema-required companion fields such as `version`, `last-modified`, `applicability-categories`, and `mapping-references` when they are defined in the schema. 1. Validate the final object against `schemas/metadata-schema.json` before writing the file. 2. Write the file to `/metadata.yaml`. 3. If a `metadata.yaml` already exists, show a diff-style summary and ask for confirmation before overwrite. ### Output Format First output line must be: **Step 4: Create `metadata.yaml`** Return the metadata creation result in this format: Metadata File: Metadata Status: Validation: Confidence: ## Step 5: Create `capabilities.yaml` 1. Create a `capabilities.yaml` file in the same target folder path as `metadata.yaml`. 2. Use `schemas/capabilities-schema.json` as the source of truth for required and allowed fields. 3. Review the official documentation links from Step 1 and identify the shared capabilities or features across AWS, Azure, and GCP. 4. Prefer granular, service-specific capabilities over broad umbrella statements when the service behavior is meaningfully distinct. 5. Decompose the service into the smallest useful capability units that still remain provider-neutral. For example, separate key-based access, secondary indexes, transactional writes, conditional updates, backup/restore, streams, capacity modes, replication, and change notification when the service supports them. - Include only capabilities that are genuinely shared across all three mapped providers (AWS, Azure, and GCP). Verify each candidate against every provider's official documentation before including it. - Exclude features that exist on only one provider, and exclude capabilities that belong to a different service category. For example, do not add relational SQL engine options (MySQL, PostgreSQL) to a NoSQL catalog, because the example NoSQL service cannot provide them. - Express each capability in terms of the provider-neutral behavior, not a single provider's product feature name. 6. Look at the imported core capabilities in `catalogs/core/core/capabilities.yaml` and select any matching shared capabilities that should be reused. 7. Do not duplicate capabilities already covered by `imported-capabilities` as service-specific entries in `capabilities`. - If a capability is imported from core, keep it in `imported-capabilities` only. - If a capability is already represented by a core capability such as `CCC.Core.CP11` or `CCC.Core.CP12`, do not create a second service-specific capability with the same intent. 1. Add matching core capabilities under `imported-capabilities` using the schema shape: ```yaml imported-capabilities: - reference-id: CCC entries: - reference-id: remarks: ``` 1. Add service-specific capabilities under `capabilities` using the schema and style guide only for capabilities that are not already covered by imported core capabilities: ```yaml capabilities: - id: CCC..CP01 group: title: description: | ``` 1. Follow `style-guides/catalogs/capability-style-guide.yaml` when writing titles and descriptions. - Write each `description` as 1 to 3 explanatory lines, not a single terse fragment. State what the capability does and how or why it is used, while remaining provider-neutral. - Start every description with "The service" and include a temporal term: "always" or "automatically" for behavior present by default, and "can" or "may be configured" for optional or configurable behavior. - Keep each `title` short and in title case (10 words or fewer); put the detail in the description, not the title. 1. Validate the final object against `schemas/capabilities-schema.json` before writing the file. 1. Write the file to `/capabilities.yaml`. 1. If a `capabilities.yaml` already exists, replace it with the validated content and record the update status. ### Output Format First output line must be: **Step 5: Create `capabilities.yaml`** Return the capabilities creation result in this format: Capabilities File: Capabilities Status: Validation: Confidence: