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://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

references/search-substrate.md

Shared prerequisite owner

File/Blob/KB call this directly, never each other for infrastructure. Search selection/create/ready-reuse belongs to the Search service owner. For other unresolved dependencies use native bootstrap, then resume. An absent RG uses its RG-only branch before Search planning, never a recursive full-bootstrap call. Already verified ready infrastructure needs no setup. ARM-ready does not prove role propagation, ingestion or retrieval. No agents/apps, Storage content or unrequested networking. Absent IDs are outputs.

Discovery-first recommendations

Reuse resolved prompt/session/workspace choices; do not restart intake on handoff. Read az account show for caller/tenant/default subscription; explicit scope wins. Use that default unless overridden, never silently switch CLI context. Account context does not prove live access; missing CLI/sign-in or denied reads are blockers, not evidence that resources need creation. Pass chosen --subscription. Reuse supplied resource/intent, else ask USE EXISTING / FIND CANDIDATES / CREATE NEW before enumeration: resource intake. Only FIND lists, known RG before selected sub. Only a new group decision needs az group list --subscription <sub>. Do not fan out resource scans across all groups or subscriptions.

Inputs are required before execution, not necessarily questions for the user. Read IDs, roles, network state and inventories at the appropriate selected scope. Offer observed reuse/create/choose-another options and recommended names, region/capacity/costs; ask only the unresolved decision. Proposed owner/settings are not verified facts. Missing evidence blocks execution after discovery/handoff. Selection is not mutation consent; preserve valid concrete approval, never extend it to unknown future actions. Keep local roots and Blob container/folder boundaries explicit; discovery does not authorize uploads or whole-container ingestion. During source setup, not every retrieve request, source owners must learn content structure and answer needs before recommending unresolved Minimal/Standard: authorized representative samples or customer description, never filename/MIME inference or a silent Minimal default. Honor explicit choices and reuse supplied information; unavailable inspection means ask, not assume text-only. Scans/important visual or table layout can justify CU; a table alone does not require it. New unresolved search: recommend Hybrid; confirm tradeoffs. Hybrid needs selected embeddings. Neither choice determines KB reasoning effort or synthesis. Existing retrieval remains read-only; missing vectors: approved setup, never a silent configuration change.

Dependency stateAction
EmptySearch intent first; RG-only only for approved creation
RG-onlyReuse group; Search owner resolves selected service
Search-onlyReuse supplied Search through operation checks; no re-selection
Ready infrastructureNo infrastructure writes
Exact source/KBCaller reconciles zero-write
Multiple compatibleAsk exact-ID selection
Same-name incompatible/unowned driftConflict; never overwrite
Denied/unreadableUnknown, not absent

Read exact dependency IDs first. Enumerate only FIND selections within the chosen scope, all pages. Offer choices rather than demanding remembered IDs/model names. Never scan unrelated resource types/subscriptions. Reuse resolved choices, not stale verification; retain complete selected-boundary inventories and fresh pre-write checks. Search owner separates operation-compatible reuse from new-service defaults; no existing keys/identity/network/tag changes to fit provisioning. Other selected dependencies still require material region/SKU/capacity, identity/network/auth/tags/model/version/access readback. Never alter shared configuration to fit. Minimal lexical File needs no model; vectorization adds embeddings; synthesis/nonminimal KB reasoning adds chat; standard File adds CU, with independently selected embeddings/chat, not a KB. Skip model discovery on minimal lexical/extractive paths without model dependencies.

Azure Policy diagnostics after creation failure

Do not enumerate or refresh policy as a preflight for plans, approvals, creation, delegation, retrieval or reuse. Ordinary resource, identity, quota, network, cost and definition checks still apply. Preserve known organizational requirements and user-approved security settings; no policy scan is not a compliance claim. Do not knowingly submit a noncompliant request just to obtain an error.

Only read policy when an Azure resource creation failure gives evidence that policy may be responsible, such as RequestDisallowedByPolicy, a policy assignment/definition ID, or policy evaluation details in deployment errors. First inspect the actual failure: a 403 alone is not proof of policy denial. Authentication, RBAC, network, quota and invalid-body errors use their own diagnostics, not a policy scan. Distinguish ARM from data-plane operations.

Preserve the original status/code/message/request ID, operation, exact target, approved body and completed writes. Follow referenced assignment/definition IDs and relevant initiative members first. Only if that evidence requires it, inspect assignments at the failed target's scope and applicable ancestors, following every page within that narrowed scope. Never audit the whole subscription or management-group hierarchy by default; no global azqr scan. Resolve relevant parameters/defaults, effects, modes, enforcementMode, overrides/selectors, notScopes and exemptions/expiry only to explain this failure. Audit/disabled/non-enforcing policy is not an enforced denial.

Missing/unreadable policy details are diagnostic warnings, not new pre-creation blockers or proof of compliance. Keep the original creation failure unresolved if the cause or remedy cannot be established; hand off exact missing IDs to the resource/policy owner. Never turn an actual Azure denial into a warning/success.

Propose only a compliant correction, retaining exact required settings and tag values from authoritative input or one focused question. Never invent an owner or silently change region/SKU, permissions, networking or cost. Bind diagnostic evidence and body changes to a new plan_fingerprint and confirmation; pass them to delegated owners. A changed plan needs approval before retry. No unconditional policy refresh is required. Read back required settings and policy-applied changes after creation.

Known noncompliance (azure-policy-noncompliant) or a known required setting that cannot reach the request (azure-policy-setting-unsupported) still blocks. Never disable policy, create an exemption, alter an assignment, or retry through another name/surface to bypass it. Reconcile ambiguous writes read-only before any retry; never assume a failed command created nothing. If no writes occurred, use the shared blocked shape: blocked_at: verification, original code/message in first_blocker, HTTP status in first_blocker.status, request ID in first_blocker.request_id, and diagnostic warnings. Unavailable status/request IDs are null. After completed or ambiguous writes, return partial with remaining ownership. Cleanup remains separately approved.

Return dependencies/ownership and content assessment/uncertainty, answer needs and source mode for the calling KB owner; resume KB plus validated retrieval, never downscope to infrastructure/source-only. Technical-plan approval does not resolve unknown content structure; unavailable CU never implies Minimal. Preserve approval for its concrete unchanged Search artifact; never preapprove unknown bodies. Source/KB mutations and cleanup need their own approvals. Checkpoints are partial; preserve shared/reused resources.

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 or Microsoft.

Download ZIP

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