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

search-services/create.md

Create or reuse a Search service

When to use

Create/ready-reuse Search for direct/File/Blob/KB requests.

Do not use

Not classic Search index/query/app work or administration. No existing-resource hardening to fit a template. Unsupported operations block; never change keys, identity, networking or tags to make reuse pass.

Inputs and discovery order

Reuse prompt/session/workspace; otherwise az account show supplies caller/tenant/default subscription. Explicit scope wins; no silent az account set. Missing CLI/sign-in blocks; account context is not access proof. Reads need no approval. One focused question before enumeration if resource/intent unresolved: USE EXISTING / FIND CANDIDATES / CREATE NEW. Carry answers across handoffs.

InputWhy neededRequired?Discovery orderSafe defaultIf missing or unansweredReconfirmation trigger
Scope/group/regionTargetBefore planCLI/IDsPropose existingOffer choicesScope
Service/actionIntentBefore planExact Azure GETRecommend reuseReuse/new/anotherAction/ID
Capacity/auth/network/costCost/accessBefore writeReadback/pricesPreserveAskSettings
Owner/tags/requirements/receipts/limitsExecutionBefore planEvidence/contractBounded/privateAskRequirements/limits

Decisions

Honor explicit reuse/new intent; never repeat resolved choices. Read supplied IDs first. Use Search intake:

python helpers/search_intake.py --select intake.json

Supplied identity: exact/minimum scoped reads. Only FIND CANDIDATES lists in known RG, else selected sub; all pages, five-row display, cross-region rows/counts. Never unrelated resource types/subscriptions or absence/uniqueness from a subset. CREATE NEW: collision read, no service inventory.

Use the selected source/KB mode and execution helper, not creation defaults. Recheck actual operation before planning. Allow keys-enabled Entra-compatible reuse without key use/configuration changes. MI remains required for actual File CU-MI/Blob/embedding/KB-chat needs. Private/UAMI selection is unsupported. Statistics GET proves caller read, not write RBAC/feature-region/outbound access: owner verifies remaining API/tier/region/data boundaries. Unknown is not a pass. No speculative model discovery/calls or semantic/vector requirements for model-free lexical paths. Hybrid embeddings imply neither CU nor KB chat.

After actual compatibility checks, offer compatible choices; never rank by name. Show excluded/unknown reasons. An incompatible explicit selection stays blocked: ask another/new; never modify it or silently switch. FIND still needs a choice even for one candidate; multiple compatible services require exact-ID selection behind displayed names. No match in a narrower scope is not subscription-wide absence. Unreadable/denied is unknown, not absent. New intent requires exact-name absence; existing/conflicting state is not permission to overwrite or suffix-create.

Only FIND for an unresolved group uses az group list --subscription <sub>. Propose task-derived name/group/owner and supported region near data, respecting residency. Small public-network trial: recommend Basic, one replica/partition, subject to price/quota/requirements; offer Standard for scale. Not a production SLA or automatic capacity choice.

Creation planning requires an existing ready resource group. If absent, use resource-group-only prerequisite: approve RG-only, verify readiness, then resume. No other dispatch or unknown-body approval.

Unresolved region: --regions scope.json; present canonical available_locations for selection. Freeform answers need Search-specific --plan validation before approval. New Search: az search usage list --location <region> --subscription <sub>; Quota is not capacity; verify prices/requirements. Ready reuse skips setup/catalog discovery; requires no embeddings, chat, CU or Storage provisioning.

Proposed plan

Operational reuse: qualified selected evidence, mutation_approval_required: false, without an apply step or mutation consent. reuse intent always needs fresh readbacks through Search intake, not strict bootstrap reuse.

Creation only: Read bootstrap helper contract: schema 2.0 choices/storage/limits. Do not author nested execution envelopes; hashes stay internal. ASCII case/whitespace: East US → eastus; not availability proof. Creation: reuse a valid unexpired artifact for unchanged choices; otherwise plan.

python "<skill-root>/helpers/bootstrap_azure.py" --plan choices.json

action: create. Planning reads Azure; writes private unapproved <artifact_id>.plan.json, returns approval summary; no Azure writes. New only: Basic/Standard, disabled local auth, public networking, system MI/capacity/tags.

Confirmation

Disclose exact target/group/region, SKU/capacity/cost, network/auth, system identity, tags/owner, limits, intended write and retained resources. Obtain actual consent before the write; silence or a stored approval flag is not consent. Reuse valid consolidated approval for this exact retained Search artifact without another question or regeneration. Never extend that approval to unknown future bodies, source/KB writes or cleanup. Target/cost/access/identity/operation drift invalidates it; harmless metadata/defaults/ordering or casing does not renew consent.

Mutation

After approval:

python "<skill-root>/helpers/bootstrap_azure.py" --apply "<private-directory>/<artifact_id>.plan.json" --approve

Helper revalidates artifact/context/supported region/fresh exact-name absence, then one approved az rest PUT (2025-05-01, body-file @). No write retry/deletion/role assignment. GET/PUT is not atomic: exclusive new-name authority is required. Expired/used/changed: replan, never edit envelopes.

Verification

Creation: az resource wait, then authoritative raw GET verifies target and required material settings. Matching precedes ownership/readiness claims. Require provisioning succeeded, status running, endpoint and system identity/principal/tenant; existence is not ready. Wait failure remains primary even if the final GET is ready. CLI timeout/cleanup: best-effort; rejection is post-capture, not a memory or hard end-to-end bound.

ARM readiness is not Search data-plane authorization, role propagation, source ingestion, vector verification or KB grounded retrieval; caller checks required.

Failure and partial completion

Preserve first code/status/request ID, attempted writes and private receipt ID. Blocked before writes; partial after writes/uncertainty. Retain run-owned versus unverified resources. Names do not prove ownership. Only policy-implicated creation failure loads policy diagnostics; no preflight policy audit. Secondary diagnosis cannot replace the original failure, authorize changes or prove compliance. Reconcile uncertainty read-only.

Cleanup

Cleanup is unapproved and separate; the helper does not execute it. Preserve shared/reused resources. If requested, hand off native cleanup with retained operation evidence, fresh exclusive ownership/configuration, children/scoped roles and separate approval. Never delete services still in use; failed commands do not prove absence.

Return contract

Return selection/choice blockers or planned, applied completed, blocked/partial; artifact/receipt/resource IDs, endpoint/settings, writes/ownership/remaining resources. Planning isn't readiness; ARM isn't data-plane/ingestion/retrieval proof. Keep paths/raw errors/hashes private. Resume the original caller, not new KS/KB calls.

References

Other links conditional.

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