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

troubleshooting/diagnose.md

Diagnose and repair Foundry IQ

When to use

For Foundry IQ access/ingestion/retrieval/citation/connection/toolbox/identity/network or preserved-agent deployment failures. Diagnose read-only; external causes get owner/handoff.

Scope-only: unsupported connector provisioning or multi-source KB creation/reconfiguration. Read this procedure, state the boundary and stop: no credentials, Azure discovery, repair, source substitution or partial compound execution. Never terminate with a plain "not supported" refusal or a passive lecture. Foundry IQ procedures directly automate single-source File, Blob, and ADLS Gen2 KBs. For unsupported sources or connectors (e.g. Web, OneLake, SharePoint, SQL) as well as multi-source KB creation/reconfiguration, inform the user of this boundary, provide the Azure AI Search public documentation pointer (https://learn.microsoft.com/azure/search/), and release workflow control back to the calling agent. The calling agent must take active charge—discovering prerequisites, planning, scripting REST/SDK API calls, or configuring Azure resources using its general tools to get the task done, just like executing without this skill. The original request is not write approval: show the concrete plan and get explicit user approval before any REST/SDK or Azure mutation. Existing multi-source KB connection uses Connect, without KB mutation. Read-only operations retain their owners/helper constraints, not new source/retrieval support. Unclear scope: intent-routing, clarify before discovery. Operational failures follow below.

Do not use

Do not patch source content, inventory, boundary, schedule, extraction, permissions, definition, or generated children; those require separately planned source recreation. Never broaden RBAC/network, switch region/SKU/model, use keys, create parallel resources, or repeat arbitrary retries.

Inputs and discovery order

Resolve prompt, explicit session choice, unambiguous workspace, exact Azure readback, documented non-consequential default, then one focused question. Label the source; missing required input blocks, silence is not approval, and read-only diagnosis needs no approval.

InputWhy neededRequired?Discovery orderSafe defaultIf missing or unansweredReconfirmation trigger
Operation/time and expected/observedReproduceRequiredPrompt, baseline, direct checkNoneAskExpectation change
Status/message/request IDFirst failureWhen emittedExact response/logNoneRecord unavailableNew first failure
API/plane/target IDInterfaceRequiredTrace/readbackNoneBlockAPI/target change
Principal/auth/RBACIdentityRequired/roles conditionalClaims metadata/readbackNoneBlockIdentity/assignment change
Network/reachabilitySecurityRequiredResource/execution readbackPreserve postureBlockNetwork or reachability posture changed
Source/base definition digestDriftRequiredReadback/baselineNoneBlockSource or base definition changed
Agent connection/tool/toolbox/environmentBindingConditionalExact readbackPreserve unrelated stateBlockConnection, tool/toolbox, or environment changed
Retry evidenceBounded transientConditionalService status/readbackOne service-signaled 408/429/5xxNo retry otherwiseService status or retry evidence changed
Repair/cleanup ownerAccountabilityConditional for writePrompt, sessionNoneBlock mutationOwner change

Decisions

Preserve the first failure. Run the nearest read-only discriminator in order: target/API existence and access, source/base definition equality, ingestion, identity/exact roles, network, connection, tool/toolbox/environment, direct base response, agent invocation. Stop at first proven cause; unknown stays unknown.

For Hosted connection failures, use Hosted connection: an omitted audience/unknown typed auth may be a projection gap, not resource drift. Verify through its nonsecret ARM readback before declaring incompatibility; do not rewrite a matching connection. An explicitly empty TOOLBOX_ENDPOINT can prevent name fallback and crash startup despite active deployment metadata. Inspect emitted environment and validate resolution offline; any binding repair and required redeployment need a new fingerprinted plan, not a source patch, permission increase or speculative retry.

Repair only exact identity/RBAC, network reachability without downgrade, project connection, MCP tool, toolbox, environment binding, or preserved deployment. Source content/inventory/schedule/extraction/permissions/definition/generated drift is recreate required: report exact diff and hand off. Replacement cannot start until exact absence or approved replacement identity/ownership proof; never suffix. Unsupported source, generic lifecycle, classic Search, or outage gets explicit owner/handoff.

If an Azure creation failure implicates policy, use targeted policy diagnostics; pass findings to the creation owner and obtain approval for changed repair plans. Do not scan policy before repair creation. A 403 alone is not proof of a policy denial or missing role; preserve the response and distinguish the cause.

Proposed plan

Show first proven cause and at most one exact repair with before/after, target, API/plane, principal/role/scope, network, protected-state diff, verification, rollback/cleanup owner, retained resources, and cost. No mutation occurs.

Confirmation

Present one immutable proposed repair plan with complete plan_fingerprint and cleanup_approved: false. Plain approval applies only to one unchanged pending plan. Any target/status/definition/identity/role/network/connection/protected readback change requires new review. Recreation uses its own plan.

Mutation

After approval, perform exactly one bounded repair and no adjacent improvement. Use only the authoritative owning surface: helpers/search_reconcile.py for an exact Search source/base identity or role-free definition repair, helpers/prompt_connect.py for the conditional existing-Prompt fallback, or the exact Hosted azd sequence in Connect. There is no generic diagnosis repair script. Open-ended cause selection, ambiguity resolution, approval, and unsupported Hosted states remain human decisions. If no listed surface owns the proven repair, return repair-surface-unavailable with the required owner/handoff; do not improvise REST, SDK, CLI, or MCP syntax. Preserve unrelated fields, sources/children, models, telemetry, versions, network, and permissions. For service-signaled 408/429/5xx only, wait the indicated/bounded delay, read back, and retry once within the approved operation; never a new name.

Verification

Rerun failed check plus one adjacent invariant: permission/exact scope, network/ unchanged posture, connection/tool/full agent baseline, or deployment/model/ telemetry/source digest. Require exact readback and request evidence. A repaired call without citation/grounding proof is incomplete.

Failure and partial completion

Return first failure unchanged plus repair result. Unproven cause, insufficient rights, inaccessible readback, failed retry, or protected drift stops. blocked records phase/blocker/input, read evidence, no writes/ownership, and safe next decision. partial records completed write, failed/unverified condition, remaining run-owned/reused resources, exact rollback, separate cleanup, owner, and warnings.

Cleanup

Repair approval excludes cleanup. A separate fingerprinted cleanup plan and explicit approval may revert only the run-owned repair artifact with exact ownership/dependency order. Never delete reused resources, source content, generated children independently, or prior versions. Unclear ownership blocks.

Return contract

Return completed, blocked, or partial with named diagnosis/handoff, fingerprint when applicable, blocked_at, first failure status/message/request ID/time/API/plane/target, discriminators, repair identity/before/after, auth/RBAC/network/protected-state verification, retry count, warnings, ownership, and cleanup.

References

Authorities: failure/conflict/uncertainty only.

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