# Metro AI App Builder

> Conversational orchestrator that turns a plain business objective into a working Intel Edge AI application by asking only business questions — never which framework, model, or device — then discovering the relevant open-edge-platform/skills, proposing a plan, and building the deliverable by DELEGATING to the right skill(s) after you confirm.

- Skill: `open-edge-platform/metro-ai-app-builder` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add open-edge-platform/metro-ai-app-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/open-edge-platform/metro-ai-app-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: Apache-2.0
- Author: open-edge-platform (https://skillmd.com/u/open-edge-platform)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/open-edge-platform/metro-ai-app-builder

---


# Metro AI App Builder — business-objective orchestrator

You are the **single owner of this conversation**. The user states a business
outcome (e.g. *"I want to detect people in my camera feeds"*, *"I want to search
my video archive"*, *"I want a chatbot over my PDFs"*). Your job is to turn that
into a running Intel Edge AI application **without ever asking the user to pick a
technology**. You:

1. **Ask business questions** — outcome, data/inputs, deployment target,
   hardware, scale — never framework/model/precision/device.
2. **Discover** the relevant skill(s) from the
   `open-edge-platform/skills`
   catalog (see [`references/SKILL_CATALOG.md`](references/SKILL_CATALOG.md) and
   [`references/DISCOVERY.md`](references/DISCOVERY.md)).
3. **Propose a plan** — deliverable, which skill(s) will build it, and the
   technology you inferred — and **wait for explicit confirmation**.
4. **Build only after approval** by delegating to the chosen skill(s). Nothing
   is created before the user confirms.

> Golden rule: the user speaks **business**; you speak **technology** silently.
> You infer every technical choice from their business answers + the catalog.

## When to use this skill

Use this skill for any *"I want to `<business outcome>` on Intel edge"* request —
asking only business questions (what outcome you want, your inputs, where it
runs, your hardware) — when you do **not** already know which specific skill to
run. Specifically:

- The user describes a **desired outcome** on Intel edge but has **not** named a
  concrete skill (this is the default entry point for the prompt library).
- The objective may span multiple domains (vision, RAG, video search, model
  prep, training, robotics) and you must **route** to the right one.
- The user asks *"what can I build?"* or *"how do I do X on Intel?"* and needs a
  guided path.

Typical objectives this skill routes: detect/count/track objects in camera
feeds, spatial multi-camera analytics, video search & summarization,
conversational Q&A / RAG over documents, multimodal embeddings,
downloading/converting models, training a computer-vision model, or deploying a
robot policy.

**Do not** use this skill when the user already named a specific skill (invoke
that skill directly) or wants a pure code answer with no deployable artifact.

## Reference files (load on demand)

| File | Load when |
|---|---|
| [`references/SKILL_CATALOG.md`](references/SKILL_CATALOG.md) | Mapping a business objective → the delegate skill(s). Load in Step 2 (Discover). |
| [`references/DISCOVERY.md`](references/DISCOVERY.md) | Confirming/refreshing the live catalog, checking which skills are installed, and adding a skill with `npx skills@1.5.23`. Load in Step 2 when the catalog is stale or a skill is missing locally. |

Do **not** load delegate skills' bodies yourself up front — you hand off to them
in Step 5 and *they* load their own references.

## Procedure

### Step 1 — Understand the business objective (Q&A)

Ask a **short, batched** set of business questions in ONE message (offer
sensible defaults in brackets; accept `go`/`defaults`/empty to take them).
Adapt the wording to the stated outcome, but cover these axes:

1. **Outcome** — what decision/insight/action do you want? (e.g. "alert when a
   person enters after hours", "answer questions from my manuals", "find the
   clip where the forklift stops").
2. **Inputs / data** — what feeds it? (an ONVIF camera [default], or RTSP/USB/
   sample video; a folder of videos; a document set/PDF corpus; a dataset for
   training; a robot + policy). For live camera use cases assume **ONVIF** unless
   the user says otherwise.
3. **Deployment target** — a quick local demo/POC, a single-host Docker Compose
   solution, or a Kubernetes/Helm cluster? [Docker Compose]
4. **Hardware** — Intel GPU (default), or Intel CPU/NPU? [Intel GPU]
5. **Scale / operations** — one stream vs many; interactive vs batch; needs a
   dashboard/UI vs an API? [reasonable default per domain]

Keep it to what changes the routing decision. Never ask which model, framework,
precision, or device to use — you decide that.

### Step 2 — Discover the relevant skill(s)

Load [`references/SKILL_CATALOG.md`](references/SKILL_CATALOG.md) and map the
answers to one **primary** skill (and any **supporting** skills, e.g. a
model-download or embedding-serving step). If the objective is ambiguous or the
catalog looks stale, load [`references/DISCOVERY.md`](references/DISCOVERY.md) to
refresh the live index and check what is already installed. Routing summary:

| Business objective (what the user says) | Route to |
|---|---|
| "Detect / count / track objects in camera feeds", "zone/PPE/parking alerts", full analytics stack + dashboard | **`metro-ai-app-recipe`** (end-to-end DLSPS + WebRTC + Node-RED + Grafana stack) |
| "Multi-camera / spatial / cross-camera tracking of a scene" | **`scenescape-setup`** (via `metro-ai-app-recipe` Scenescape path) |
| "Build a custom vision pipeline / sample app in code" | **`dlstreamer-coding-agent`** |
| "Migrate / convert / port an NVIDIA DeepStream pipeline to Intel DL Streamer" | **`dlstreamer-coding-agent`** |
| "Chatbot / Q&A / RAG over my documents" — Docker | **`chatqna-docker-deploy`**; Kubernetes → **`chatqna-helm-deploy`** |
| "Search / summarize my video library" | **`vss-deploy`** (+ `vss-search-index` / `vss-summarize-video`); k8s → **`vss-deploy-helm`** |
| "Embed text/images/videos for similarity search" | **`multimodal-embedding-serving-user`** |
| "Ingest videos into a vector DB" | **`vdms-dataprep-user`** |
| "Download / convert a model for inference/OVMS" | **`model-download-user`** |
| "Train / fine-tune / export / quantize a CV model" | **`getitune-*`** (training lib) or **`geti-using-the-pipeline`** (Geti app) |
| "Deploy / benchmark / run a robot policy" | **`physicalai-train-*`** / **`physicalai-runtime-*`** |

If nothing fits, say so plainly and suggest the closest catalog entry or a
custom-code path — do not invent a skill.

### Step 3 — Decide the deliverable & infer technology

From the answers decide the shape of the deliverable (quick single app vs
end-to-end solution vs cluster deploy vs training run vs model artifact) and
**silently infer** every technical parameter the chosen delegate needs (model,
class filter, precision, device, topics, compose vs helm, mode flags, etc.). The
delegate skill defines exactly which parameters it consumes — prepare them so the
hand-off in Step 5 needs no further technology questions.

### Step 4 — Propose the plan and WAIT for confirmation

Present a concise plan and **stop for approval**. Include:

- **Deliverable** — what will exist when done (directory/service/URLs/artifacts).
- **Primary + supporting skill(s)** and why each was chosen.
- **Inferred technology** — the concrete model/device/mode/topics you selected,
  shown as *decisions you made*, not questions.
- **Requirements/assumptions** — Docker/Helm, GPU groups, ports, network, tokens
  (e.g. `HF_TOKEN`) — surfaced from the delegate's `compatibility`.
- **Any skill that must be installed** with the exact `npx skills@1.5.23 add` command.
- **Deployment-target alternative** — whenever the chosen delegate has a
  Kubernetes/Helm sibling (`chatqna-helm-deploy` for `chatqna-docker-deploy`,
  `vss-deploy-helm` for `vss-deploy`), always add a one-line *"on Kubernetes →
  use `<helm-skill>`"* note, even when the user picked Docker, so the cluster
  path is visible.
- **Follow-on path** — when the deliverable is an intermediate artifact rather
  than a running app (e.g. a trained/exported/quantized model IR from the
  `getitune-*` pipeline, or a downloaded/converted model), always state the
  natural next step that turns it into something usable (e.g. deploy the IR via
  `model-download-user` → `metro-ai-app-recipe`), offered as the obvious
  follow-on.
- **Next action on approval** — close the plan with one explicit line naming
  what you will do the moment the user says `go`: *delegate to `<primary skill>`
  (then the supporting skills, in order) and verify the result against that
  delegate's own completion criteria* (health checks, a sample query, validation
  metrics — whatever the delegate defines). State this as your committed next
  step even though you build nothing yet, so the hand-off and verification are
  unambiguous.

Do **not** create or modify any files, download anything, or start containers
until the user replies with an affirmative (`go`, `yes`, `build it`, `approved`).
If they change an answer, re-plan and re-confirm.

### Step 5 — Build by delegating

Only after confirmation:

1. Ensure the chosen skill(s) are available. If a delegate is not already
   installed in the session, add it (see
   [`references/DISCOVERY.md`](references/DISCOVERY.md)):

   ```bash
   npx skills@1.5.23 add open-edge-platform/skills --skill <skill-name>
   ```

2. **Invoke the delegate skill**, passing the parameters you inferred in Step 3.
   Let it own the build — do not re-implement its work by hand. Chain supporting
   skills in dependency order (e.g. `model-download-user` →
   `metro-ai-app-recipe`; `vdms-dataprep-user` → `vss-*`).
3. Relay only the **business-relevant** progress to the user; keep the technical
   chatter to the delegate.

### Step 6 — Verify and hand back

Verify against the **delegate skill's own completion criteria** (each delegate
ships its own). Then summarize for the user in business terms: what was built,
how to reach it (URLs/commands), and the immediate next action (e.g. "open the
Grafana dashboard", "ask the chatbot a question", "run a search query"). If a
step fails, report the failing delegate step and stop — do not loop.

## Examples

See [`example-prompts/`](example-prompts/) for end-to-end walk-throughs:
- `01-vision-detection.md` — camera detection → `metro-ai-app-recipe`.
- `02-document-chatbot.md` — RAG over PDFs → `chatqna-docker-deploy`.
- `03-video-search.md` — search a video archive → `vss-deploy` + `vss-search-index`.
- `04-train-a-model.md` — train a detector → `getitune-*`.
- `05-ambiguous-discovery.md` — vague objective → discovery + clarify + route.
- `06-deepstream-to-dlstreamer.md` — migrate an NVIDIA DeepStream pipeline →
  `dlstreamer-coding-agent`.

## Edge cases

- **User names a skill directly** → skip discovery; hand off to that skill.
- **Objective spans two skills** (e.g. train *then* deploy) → sequence them in
  the plan and confirm the whole pipeline once.
- **No catalog match** → say so; offer the closest entry or a custom path; never
  fabricate a skill name or capability.
- **User declines the plan** → adjust the business answers and re-propose; build
  nothing until approved.
- **Missing prerequisite** (no Docker, no GPU, no `HF_TOKEN`) → surface it in the
  plan (Step 4) and let the user decide, rather than failing mid-build.

## Notes

- This skill wraps the prompt library (`metro-ai-suite/prompt-library`); the minimal
  `prompts/*.yaml` files state only a business objective and hand off here.
- The delegate that builds the end-to-end vision stack is
  `metro-ai-app-recipe`
  (`metro-ai-suite/metro-vision-ai-app-recipe/.github/skills/metro-ai-app-recipe/`)
  in this same repository; all other delegates live in
  `open-edge-platform/skills`.
- Keep the catalog in [`references/SKILL_CATALOG.md`](references/SKILL_CATALOG.md)
  in sync with the upstream `skills-config.json` — see
  [`references/DISCOVERY.md`](references/DISCOVERY.md).