/managing-data-catalog

name: managing-data-catalog
description: >
  Writes and curates business metadata in an AWS data catalog: the
  Amazon SageMaker Catalog (Amazon DataZone), or the AWS Glue Data
  Catalog. Detects which catalog platform an account uses before
  writing. Triggers on: add a description to a table, document a
  dataset, write a README, set an owner, add column comments, tag with
  a glossary term, create a business glossary, create a metadata form,
  publish an asset, create a data product, run the data source crawl,
  delete a catalog asset, attach a conventions document to a table as
  a catalog skill asset, which assets in my project are missing
  descriptions or owners and what to fix first, which catalog does
  this account use and what can I do with it. Not for:
  inventorying or listing tables (use exploring-data-catalog),
  locating one table (use finding-data-lake-assets), counting gaps
  domain-wide with SQL over the exported metadata snapshot (use
  querying-aws-sagemaker-catalog), or granting or revoking access (use
  managing-data-asset-access)
metadata:
  version: "1"

Manage Data Catalog

The write path for catalog business metadata. Take a dataset from catalogued and undocumented to documented, classified and discoverable. And retire one without breaking the catalog.

Overview

You SHOULD execute commands through AWS MCP server tools when connected: they give validation, sandboxed execution and audit logging, which matter more than usual in a skill whose writes replace whole records. Fall back to the AWS CLI when the MCP server is unavailable; every step here is expressed as CLI calls, so it runs either way. You MUST explain each write before executing it.

**Runtime requirements**, stated before the first command block because this skill assumes no tooling you may not have:

• The **AWS CLI v2** and credentials for the target account and region.
• A **POSIX shell** for the multi-step blocks in the references.
• **`jq`**, used by the two canonical read-modify-write blocks to rebuild a

record without disturbing the parts you are not changing. If `jq` is unavailable, do the same rebuild in Python with `json` from the standard library. But do the rebuild. Do not hand-write a partial record instead.

Check the first two before running a block, and say so if either is missing rather than improvising around it.

Guardrail: where this skill's own files live (MCP vs local install)

This skill can be loaded two ways, and they resolve the skill's own bundled files from different places. Determine how the skill was loaded before reading a reference:

• **Loaded through a skill tool over MCP:** the skill is not installed on the

local filesystem, so `file_read` on these paths will fail. Fetch each reference with whatever skill-file tool your runtime exposes, passing the reference path in that tool's own file parameter (e.g. `references/platform-detection.md`). Tool names differ between runtimes, so use the one you actually have rather than one you expect to be there. If the only skill tool available takes a skill name and has no file parameter, it cannot fetch a reference at all: do not put a path in its name field, and read the file from the skill's own directory instead.

• **Installed locally** (e.g. `.kiro/skills/managing-data-catalog/` or

`~/.claude/skills/managing-data-catalog/`): Read files from the local skill directory using relative paths.

This distinction applies only to the skill's own packaged files. User data and session artifacts are always read from and written to the user's working directory. Never fetch or write customer data through a skill tool.

`references/` is a sibling of this `SKILL.md`, so resolve reference paths against that directory rather than your working directory. If a skill tool returns this overview instead of the file you asked for, it did not fetch it. Read it from that directory, and do not write API calls from memory because a reference read failed.

Three rules that outrank every chapter

Read these before any chapter. Each one caused failures across several different operations, so no single chapter is where you would meet it in time.

1. Establish capability by positive probe. Never infer absence

An `AccessDenied` means *this caller cannot see it*, not *it is not there*. An operation you do not recognise means *look it up*, not *it does not exist*. An empty list from the wrong lookup means *you asked the wrong question*.

• You MUST resolve the platform with the two probes in

`references/platform-detection.md` before recommending or performing anything.

• You MUST NOT tell a user a capability does not exist because a call was

denied, because a list came back empty, or because you have not seen the API before. Say what you probed and what it answered.

• If you can reach AWS more than one way (an MCP server tool and a shell running

the CLI), **those surfaces authenticate separately and may be different principals, or different accounts.** Before reporting any denial, run `aws sts get-caller-identity` on the surface that failed and retry the call on the other. A denial on one surface and a success on the other is not a permissions fact. See `references/troubleshooting.md`.

• The Glue Data Catalog **does** have native business glossaries, glossary

terms, custom metadata forms and catalog assets. They are not the SageMaker Catalog's, and they are not Lake Formation LF-Tags.

2. Some writes REPLACE the whole record rather than merging

Each of these succeeds, returns exit 0, and silently drops what you omitted. The user sees the field they asked for and assumes the rest survived.

| Platform | Operation | What it destroys | |---|---|---| | SageMaker Catalog | `CreateAssetRevision` | Any form omitted from `formsInput`. An omitted `glossaryTerms` clears every association. `AssetCommonDetailsForm` carries `summary`, `readMe` **and** `sourceIdentifier` together, so writing a README th