Generated banner for Foundry Iq
Generated logo for Foundry Iq

Foundry Iq

MicrosoftOfficialCreated by Microsoft

  • Skill
  • Workflow
  • Data and AI
  • MIT
  • Medium risk
  • Has scripts

From the author

Foundry IQ knowledge bases. WHEN: make local or Blob documents searchable; create/diagnose KBs; triage unsupported connectors or multi-source KB creation/reconfiguration (even with classic-search terms); connect existing KB to agents (including multi-source KBs); create/reuse a Search service; retrieve from an existing knowledge base with citations; no brand words needed. Read its procedure before query/target questions. NOT: other KB providers, repository-file search, classic Azure AI Search index/query/app work with no Foundry IQ KB or connector request, generic agent creation.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Foundry IQ provides a structured framework for creating, diagnosing, and connecting knowledge bases to AI agents. It supports making local or Blob-based documents searchable, managing multi-source knowledge configurations, and retrieving information with citations. The skill emphasizes strict adherence to defined procedures for service discovery, resource creation, and troubleshooting to ensure reliable agent-knowledge integration.

What it does

  • Creates searchable knowledge bases from local or Azure Blob storage documents.
  • Connects existing knowledge bases to AI agents.
  • Diagnoses issues with knowledge base configurations or unsupported connectors.
  • Retrieves information from knowledge bases with source citations.
  • Manages the lifecycle of search services and knowledge sources.
  • Routes requests based on specific operational needs rather than source counts.

When to use it

  • When you need to make local or cloud-stored documents searchable by an AI agent.
  • When connecting an existing knowledge base to a new or current agent.
  • When troubleshooting or diagnosing a knowledge base configuration.
  • When you need to create a new search service or knowledge source.
  • When performing retrieval tasks that require citations from a knowledge base.

Advantages

  • Provides a clear, procedural approach to knowledge base management.
  • Ensures consistent handling of multi-source knowledge configurations.
  • Includes built-in diagnostic paths for troubleshooting.
  • Supports secure, citation-backed retrieval for agent responses.
  • Prevents unauthorized or unsupported configuration changes.

Usage examples

“Create a new knowledge base from my Azure Blob container.”
The agent will initiate the knowledge base creation procedure, validating the source and setting up the necessary search indexing.
“Connect my existing knowledge base to the current agent.”
The agent will follow the connection workflow to link the specified knowledge base to the agent's retrieval pipeline.
“Why is my multi-source knowledge base failing to index?”
The agent will trigger the diagnostic procedure to identify configuration drifts or unsupported connector issues.
“Retrieve information about project timelines from the knowledge base.”
The agent will query the knowledge base and provide an answer with citations from the source documents.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/microsoft/foundry-iq/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip foundry-iq.zip -d .agents/skills

Documentation by Microsoft

Foundry IQ

Read one procedure before questions/actions; invocation is not a read. Read the owning procedure before blocked/unsupported responses too. Before mutation plans/approval, successfully read its required pre-action references, selected branches only. Do not reload successful reads. On failure, try only permitted bounded exact-path reads with any supported reader; never bypass restrictions or search broadly. If still unavailable: blocked: reference-unavailable, name missing references and inability to plan. Never invent requirements/plans. Failures first.

Cleanup and receipt-backed execution go directly to their lifecycle/producer owner; do not reopen Search intake, provisioning or hardening.

Before expensive service discovery, reuse supplied resource/intent; otherwise ask one early USE EXISTING / FIND CANDIDATES / CREATE NEW choice. Only FIND enumerates; supplied identity uses exact/minimum scoped resolution. CREATE checks its proposed name, not existing-service inventories. Preserve these answers across source/KB/CU/model handoffs; selection is not write approval.

Searchable docs: KB + validated retrieval. Confirm intent once; KS-only must be explicit. Child success is not KB completion. Unclear/compound/mode/completion: read.

Route by requested operation, not existing KB source count. Connecting an existing KB with two or more sources, without changing the KB, uses Connect. Read-only operations use their owning procedure and actual helper constraints; this does not add retrieval modes or supported source kinds. Explicit unsupported provisioning or multi-source KB creation/reconfiguration uses Diagnose and stops before discovery, even when connecting an agent is also requested. This routing takes precedence over classic-search terms (e.g. hybrid search) in compound requests. Never end in a plain refusal: Diagnose gives the boundary, docs pointer and agent handoff; writes still need an approved concrete plan. Do not silently execute only the supported part of a compound request. If existing-KB connection versus KB creation/reconfiguration is unclear, read intent-routing and clarify that scope before Azure discovery. Never infer KB mutation.

OutcomeRead
CleanupPlan cleanup
Failure/driftDiagnose
Unsupported connector provisioning / multi-source KB creation or reconfigurationDiagnose
ConnectConnect
Read KBQuery
Search onlySearch
File KS onlyFile
Blob/ADLS KS onlyBlob
Searchable/KBKB

Generic agents: microsoft-foundry. Reads: no approval; approve unchanged plans before writes. Hide hashes. No Search/Storage keys, scope widening, guessed identity/boundaries, drift repair or joint cleanup/creation approval. Acceptance != success.

Files

helpers/model-discovery-contracts.md

Read-only model and CU selection

purpose: none means no dependencies, not minimal retrieval effort. Minimal+extractive can be model-free; minimal+answerSynthesis needs purpose: chat. Only FIND inventories; supplied IDs exact-read. KB/retrieve verifies API; no readiness/access/approval proof.

Invocation and closed input

From skill directory:

python helpers/model_discovery.py --input choices.json

Required JSON (UTF-8):

{"schema_version":"1.0","purpose":"embedding","subscription_id":null,"resource_group":null,"account_id":null,"account_name":null,"deployment":null}

purpose: none, embedding, chat, cu. Null is unresolved. GUID subscription; ARM names. RGs: 1-90 Unicode letters/decimal digits or _-.(); no final period. account_id: exact Cognitive Services account ARM ID. deployment: name or deployment ARM ID. IDs supply parent/scope; conflicting fields block before CLI. CU/none reject deployment selectors. Optional endpoint: observed HTTPS origin, only with an exact account selector. Null/omitted requires a unique origin; explicit selection must match ARM. Reuse IDs/choices; no setup attestations during discovery.

Three dependency types: CU service capability (Content Understanding, Standard extraction); embedding deployment (vectorization); chat deployment (enabled image verbalization/KB synthesis). No project/agent gate. Keep separate CU, embedding and chat selections. CU never selects models. Unresolved models keep scope; set account_id, account_name, deployment and endpoint to null; never repurpose CU's selection_input. Explicit model selectors win. Prefer one compatible existing Foundry/AIServices account: CU capability + two model deployments. Separate embedding/KB-chat: per consumer contract. CU image-description models must be in the Foundry resource attached to the skillset. Never provision/migrate/redeploy to consolidate. CU proves no model deployments. Empty model lists are not scope-wide absence: inspect another selected candidate before proposing creation. A 403/timeout is unresolved, not absence; no denied-scope broadening.

  • Known account ID or account name plus group: exact account GET.

  • Name without group: selected-subscription typed listing; unique match exact GET, otherwise choices.

  • Unknown account: group-scoped, otherwise subscription-scoped Cognitive Services accounts: AIServices/OpenAI for models; AIServices for CU. No deployment listing until an account is selected, even if only one exists.

  • Selected model account: exact deployment GET when named, else its deployment list. Validate each role's deployment/capabilities/auth; never infer support from names. Missing capabilities need owner validation.

  • CU: exact account metadata only; no deployment reads.

Bootstrap's shell-free runner disables installs/auto-upgrade/telemetry and raw logs. No login/context changes, secrets, writes, role/Policy/catalog/quota scans, content reads/uploads or model calls.

Exact CLI surfaces

Unresolved subscription only: az account show --query "{id:id}" --output json --only-show-errors. Otherwise skip context lookup; explicit scope wins. ARM calls:

az rest --method get --url <URL> --query <helper-projection> --subscription <GUID> --output json --only-show-errors

URL: https://management.azure.com<path>?api-version=2024-10-01. Encode paths, not IDs. A is the exact account path: /subscriptions/<sub>/resourceGroups/<group>/providers/Microsoft.CognitiveServices/accounts/<name>.

ReadPath
Accounts in subscription/subscriptions/<sub>/providers/Microsoft.CognitiveServices/accounts
Accounts in group/subscriptions/<sub>/resourceGroups/<group>/providers/Microsoft.CognitiveServices/accounts
Exact accountA
Selected account deploymentsA/deployments
Exact deploymentA/deployments/<name>

Complete pagination: 10 pages/200 raw rows aggregate; 20 seconds/command, 120 seconds total. Partial results block; narrow resource_group or use an exact ID. At most ten supported endpoint origins per account. Continuation retains ARM host/collection/API; only skip-token parameters. Native CLI JMESPath projects before capture: inventory IDs/names/kinds/locations, exact account endpoints/state, deployment identity/model/state/public capabilities. No ARM $select; all rows and nextLink survive. One MiB per stream, aggregate captured bytes and final JSON; post-capture checks are not memory bounds. No retries, fanout, denied-scope broadening or absence inference.

Closed output

Fields: schema_version, status, purpose, scope, accounts, deployments, selected, limits, warnings, first_failure, writes_performed (always []). Exit 0 returns skipped, no-candidates, account-choice-required, deployment-choice-required or selected; exit 2: blocked. No-candidates covers only the completed query. Scope: null or {subscription_id, resource_group}; limits: bounds above. first_failure is null or {code, status, message, request_id, message_digest}. Original service code/status/request ID and message digest survive CLI failure; No raw text/invented IDs; unreadable is not absent.

Account rows: {account_id, name, resource_group, location, kind, provisioning_state, endpoint, endpoint_sources, endpoint_state, endpoint_candidates, selection_input}. Deployment rows: {deployment_id, name, model_name, model_version, model_format, capabilities, provisioning_state, selection_input}. Metadata fields may be null; capabilities: safe string map, not support/capacity proof: embeddings, chatCompletion and validated numeric maxContextToken, maxOutputToken only. Missing/invalid values remain unknown; internal/unknown fields never emit. selected is null or {account, deployment} (deployment null for CU). endpoint_candidates is the sorted observed-origin list. Endpoint resolution failure retains the exact account row, never deployments or a selected result. Other failures discard choices. Inventory endpoint_state is not-assessed; endpoints/state are null/empty until GET.

Present observed compatible deployments together in existing flow. Keep complete scoped rows internally for ambiguity checks; never paste full inventories/JSON to the customer. Show at most five concise account/deployment choices, total count and a more/other choice from retained rows, not new discovery. Show account/group/region and deployment/model names distinctly. Known Storage location or selected region can rank suggestions, not prove CU/model availability. Explicit locations/reuse win; no hidden regional filter or absence claim. For choices, save the chosen row's selection_input unchanged. For ambiguous origins, copy it and set endpoint to a listed origin; rerun. No caller filtering, ID stitching or CLI glue. Exact readback revalidates choices. Selection is metadata only: owner verifies model suitability, version/capacity/cost/residency, selected CU dependencies, actual access and network before concrete approval.

Endpoint metadata, not a CU readiness assertion

ARM 2024-10-01 does not document endpoints["ContentUnderstanding"] as a stable CU discriminator. Never infer hosts from map keys/customSubDomainName.

Inspect the exact account's primary endpoint and every map value locally. CU: services.ai.azure.com; embedding/chat also accept openai.azure.com and cognitiveservices.azure.com. HTTPS origins only; strip only a trailing slash; without a selector require exactly one matching origin. Missing/multiple matching origins block; no rewriting, arbitrary fetch, paths/query/user-info/ports or readiness inference. For diagnostics: scope/endpoint rules.

File CU MI/explicit key and Blob Search identity stay distinct; neither is accessed. Existing source planners own exact-name collision checks; no extra preflight, suffixes, writes or auth changes.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

The author says: Azure

Security

What our scanner noticed· Medium risk

  • References to credential files
  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills · .github/plugins/foundry-iq-skills/skills/foundry-iq · commit 0696600
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from .github/plugins/foundry-iq-skills/LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download foundry-iq.zip