Conversational orchestrator that turns a plain business objective into a working Intel Edge AI application. It OWNS the conversation: it asks only business questions (what outcome you want, your inputs, where it runs, your hardware) — never which framework, model, or device — then DISCOVERS the relevant skills from the open-edge-platform/skills catalog, proposes a plan, and only after you confirm builds the deliverable by DELEGATING to the right skill(s). USE FOR any "I want to <business outcome> on Intel edge" request: 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 — when you do NOT already know which specific skill to run. DO NOT USE when the user already named a concrete skill (invoke that skill directly) or asks a pure code question with no deployable outcome.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Conversational orchestrator that turns a plain business objective into a working Intel Edge AI application. It OWNS the conversation: it asks only business questions (what outcome you want, your inputs, where it runs, your hardware) — never which framework, model, or device — then DISCOVERS the relevant skills from the open-edge-platform/skills catalog, proposes a plan, and only after you confirm builds the deliverable by DELEGATING to the right skill(s). USE FOR any "I want to <business outcome> on Intel edge" request: 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 — when you do NOT already know which specific skill to run. DO NOT USE when the user already named a concrete skill (invoke that skill directly) or asks a pure code question with no deployable outcome.
license
Apache-2.0
compatibility
Requires: Node.js 20+ and the `npx skills` CLI (from open-edge-platform/skills) to add delegate skills on demand; `git`/`gh` and network access to github.com to read the live skill index. Individual delegate skills add their own requirements (Docker + Compose v2, Intel CPU/GPU/NPU, Kubernetes/Helm, Python) — surface those to the user during planning, do not assume them.
Metro AI Apps 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:
Ask business questions — outcome, data/inputs, deployment target,
hardware, scale — never framework/model/precision/device.
Propose a plan — deliverable, which skill(s) will build it, and the
technology you inferred — and wait for explicit confirmation.
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
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.
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.
Confirming/refreshing the live catalog, checking which skills are installed, and adding a skill with . Load in Step 2 when the catalog is stale or a skill is missing locally.
npx skills
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:
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").
Inputs / data — what feeds it? (camera RTSP/USB/sample video; a folder of
videos; a document set/PDF corpus; a dataset for training; a robot + policy).
Deployment target — a quick local demo/POC, a single-host Docker Compose
solution, or a Kubernetes/Helm cluster? [Docker Compose]
Hardware — Intel CPU only, or Intel GPU/NPU available? [CPU]
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 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 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
"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 add command.
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:
Ensure the chosen skill(s) are available. If a delegate is not already
installed in the session, add it (see
references/DISCOVERY.md):
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-apps-recipe; vdms-dataprep-user → vss-*).
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.
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-apps-recipe
(metro-ai-suite/metro-vision-ai-app-recipe/.github/skills/metro-ai-apps-recipe/)
in this same repository; all other delegates live in
open-edge-platform/skills.
