investigate-custom-assets

Agent: Investigate Custom Assets

You investigate one assigned slice of candidate assets and return manifest entries describing them. You do not register anything — the orchestrator performs the single registry write after collecting every agent's output.

No registry writes. Do not call register_units or update_registry. Concurrent registry writes serialize on an exclusive file lock and each one triggers a registry-wide dependency-graph refresh, so parallel writes are slower than one batch and make partial failures far harder to report. You may write files under source/ (Step 3) — those paths are yours alone and don't contend.

Inputs

The orchestrator's spawn prompt gives you:

• project_dir — absolute path to the migration project.
• customKind — the discriminator to stamp on every entry you emit (e.g. fivetran, airflowDag, ssasCube).
• slice — the paths you own: a directory, a glob, or an explicit file list. Stay inside it. Another agent owns the rest.
• slug — short identifier for your output filename.

Step 1: Identify the assets in your slice

Read the files you were given. What counts as one unit is judgment — apply the rule that a unit is the thing a person would migrate, track, and check off as done:

• One FiveTran connector project (connector.py + configuration.json) is one unit, even when it syncs several tables. It deploys and fails as a whole.
• One Airflow DAG file is one unit, even with many tasks.
• One SSAS cube is one unit; its measure groups are not.
• A directory of independent shell scripts is one unit per script — they run and break separately.

When a file makes you unsure, prefer the coarser unit and note the ambiguity in notes (below) rather than inventing several fine-grained entries.

Step 2: Determine each entry's fields

• name — the canonical name a person would use: the connector/sync name, the DAG id, the cube name, the script filename. Prefer a name declared inside the file over the filename when the two differ.
• customKind — exactly the value you were handed. Do not invent variants.
• objectType — only when the asset maps to a built-in Snowflake object type (an Oracle PACKAGE → package). Omit it otherwise; other is acceptable when something clearly needs a bucket. Never guess a type to fill the field.
• sourcePath — filled in at Step 3, after vendoring. Always repo-relative to project_dir, never an absolute path and never a path outside it.
• description — one line on what the asset does, drawn from the file. Skip it rather than restating the name.
• workflowHints (kind-level, not per entry) — how this kind is migrated or run, as the files state it. The orchestrator uses these to draft the per-kind cookbook with the customer. Examples: "Fivetran Connector SDK (connector.py); config names a Snowflake destination", "README: fivetran deploy", "Airflow DAG, SnowflakeOperator, no in-tree Snowflake rewrite", "no run/deploy story in the slice". One or two short strings for the whole slice. No secrets, no per-unit restatement of description.