skills/datahub-mfe-configure-app/SKILL.md
Configure a DataHub instance to load and display a Micro Frontend (MFE) app. Use when the user wants to register an MFE with DataHub, add an MFE to the nav sidebar, set up MFE config for local dev or production/k8s, or troubleshoot MFE loading issues.
npx skillsauth add datahub-project/datahub-skills datahub-mfe-configure-appInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Walks through registering a Micro Frontend app with the DataHub frontend so it
loads at /mfe/<path> and optionally appears in the navigation sidebar. Covers
local development, production/k8s deployment, and troubleshooting.
Use the AskQuestion tool to collect the following in a single call.
| Question | ID | Options |
| ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Are you configuring for local development or production/k8s? | env_target | Local development / Production / Kubernetes |
| MFE app name — the name field inside new ModuleFederationPlugin({ name: '...' }) in the MFE's webpack.config.js. Must match exactly. | mf_name | testAppMFE / N/A - I'll fill it in later |
| URL path where the MFE should be accessible, e.g. /dashboard (must start with /) | mfe_path | /test_page / N/A - I'll fill it in later |
| remoteEntry.js URL, e.g. http://localhost:3002/remoteEntry.js | remote_entry_url | http://localhost:3002/remoteEntry.js / N/A - I'll fill it in later |
| Display label for navigation, e.g. Team Dashboard | display_label | Test Dashboard / N/A - I'll fill it in later |
| Should the MFE appear in the left nav sidebar? | show_in_nav | Yes / No |
| Nav icon | nav_icon | ChartBar / Trophy / Gear / HandWaving / Lightning / MagnifyingGlass / Database / Users / Shield / Bell / Flag / Star / Heart / Cube / Table / Code / Globe / Rocket |
If env_target is Local development, ask one follow-up question using
AskQuestion before proceeding:
| Question | ID | Options |
| ------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
| How are you running DataHub locally? | local_mode | Docker / datahub-dev.sh (standard) / Play server directly (sbt / IntelliJ) |
For the N/A - I'll fill it in later fields (mf_name, mfe_path,
remote_entry_url, display_label), do NOT invent or suggest values from the
workspace. The user will type their own.
Finding the MFE app name: Open the MFE's
webpack.config.jsand look for theModuleFederationPluginblock. Thenameproperty is what goes here:new ModuleFederationPlugin({ name: 'teamDashboardMFE', ... }) // ^^^^^^^^^^^^^^^^^ ← this valueIf the name in the YAML config doesn't match this exactly, the MFE will fail to load. If you used the
datahub-mfe-create-appskill, the name was printed in the summary as "Module Federation name".
Build the config entry from the gathered values:
- id: __MFE_ID__
label: __DISPLAY_LABEL__
path: __MFE_PATH__
remoteEntry: __REMOTE_ENTRY_URL__
module: __MF_NAME__/mount
flags:
enabled: true
showInNav: __SHOW_IN_NAV__
navIcon: __NAV_ICON__
Where __MFE_ID__ is derived from the path (strip leading /, replace /
with -), e.g. path /dashboard becomes id dashboard.
datahub-dev.sh (standard)The Docker image has MFE_CONFIG_FILE_PATH baked in at build time pointing to
/datahub-frontend/conf/mfe.config.dev.yaml (set in docker/datahub-frontend/Dockerfile).
This is the file to edit for any Docker-based workflow.
datahub-frontend/conf/mfe.config.dev.yaml.microFrontends:. If the file is empty, use:subNavigationMode: false
microFrontends:
- id: ...
...
scripts/dev/datahub-dev.sh rebuild --wait
datahub-frontend/run/frontend.env points MFE_CONFIG_FILE_PATH to
../conf/mfe.config.local.yaml. Edit that file instead.
datahub-frontend/conf/mfe.config.local.yaml.microFrontends:.cd datahub-frontend/run && ./run-local-frontend
Tell the user:
Since you selected Production / Kubernetes, I won't edit any local config files — instead here's what you need.
Show the user the complete YAML config to add to their production config file (which may live in a separate config repo).
Explain the env var and volume mount setup. See reference.md for the full k8s ConfigMap pattern.
Remind the user about MFE_PUBLIC_PATH:
When deploying your MFE to a CDN or static host, set the
MFE_PUBLIC_PATHenv var during the MFE's production build so webpack knows the correct public URL for chunk loading.MFE_PUBLIC_PATH=https://cdn.example.com/my-mfe/ npm run build
Guide the user through these checks:
Standalone check: Open __REMOTE_ENTRY_URL__ in a browser — should
return JavaScript content (not 404 or HTML).
Integration check: Navigate to http://localhost:9002/mfe__MFE_PATH__
(local) or the equivalent production URL. The MFE should render inside the
DataHub chrome.
Nav check (if showInNav: true): The sidebar should show the
__DISPLAY_LABEL__ item with the chosen icon. Click it to navigate.
If any check fails, see the Troubleshooting section in reference.md.
Provide the user with a summary. Show only the config file relevant to their
env_target — do not mention local config files if they selected Production.
If local development:
MFE registered in DataHub:
Path: /mfe__MFE_PATH__
Remote entry: __REMOTE_ENTRY_URL__
Module: __MF_NAME__/mount
Nav sidebar: __SHOW_IN_NAV__ (icon: __NAV_ICON__)
Config file: datahub-frontend/conf/mfe.config.dev.yaml (Docker / datahub-dev.sh)
datahub-frontend/conf/mfe.config.local.yaml (Play server / IntelliJ)
If Production / Kubernetes:
MFE registered in DataHub:
Path: /mfe__MFE_PATH__
Remote entry: __REMOTE_ENTRY_URL__
Module: __MF_NAME__/mount
Nav sidebar: __SHOW_IN_NAV__ (icon: __NAV_ICON__)
Config file: <your production config file>
data-ai
This skill provides routing guidance for all DataHub interaction skills. It is injected at session start and helps map user intent to the correct skill. Do not invoke this skill directly — it is loaded automatically.
development
Loads all 22 DataHub connector golden standards into context. Use before starting connector development or review work to ensure the full set of standards is available for reference. Triggers on: "load standards", "show standards", "what are the connector standards", "load golden standards", "review standards", or any request to load DataHub connector development guidelines.
tools
Use this skill when the user needs to set up a DataHub connection, install the DataHub CLI, configure authentication, verify connectivity, set default scopes, or create agent configuration profiles. Triggers on: "set up DataHub", "connect to DataHub", "install datahub CLI", "configure DataHub", "set default platform", "focus on domain X", "create profile", or any request to establish, configure, or troubleshoot DataHub connectivity.
testing
Use this skill when the user wants to search the DataHub catalog, discover entities, answer ad-hoc questions about their data, find datasets, or browse by platform or domain. Triggers on: "search DataHub", "find datasets", "who owns X", "what tables contain PII", "what columns does X have", or any request to search, discover, browse, or answer one-off questions about DataHub metadata. For lineage questions ("what feeds into X"), use `/datahub-lineage`. For systematic audits ("how complete is our metadata"), use `/datahub-audit`.