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

references/blob-readiness-recheck.md

Blob readiness recheck

Retained evidence

New minimal/Standard/CU, lexical/vector and admitted legacy modes/schedules: Blob GA 2026-04-01 or preview 2026-08-01-preview; ADLS requires preview/ACLs. Keyless/system-assigned only; no asset stores, new settings or other connectors. Retain original approved input; --receipt-dir requires an existing private directory outside plugin. Check privacy/context before cloud work. No mkdir/ACL changes/overwrite. Conditional PUT acknowledgement precedes post-write GET. Binding/recovery owns acknowledgement recovery. Immutable <operation_id>.blob-readiness.json binds approval/owner, pre-write cutoff, context, generated identities/ETags/digests and request IDs. No credentials/text/ACLs. Persistence failure retains partial ownership, without polling/write retry/cleanup.

Fresh reuse capture

Retain unchanged private reuse execution_input (approval.confirmed: false):

python helpers/blob_recheck.py --capture <reuse-input.json> --receipt-dir <absolute-private-directory>

Capture checks source/configuration/Storage/context and retains cutoff/first cycle. Exit 0, blob-readiness-capture: checkpoint retained, not readiness. No writes/new ownership/polling. Creation artifacts/ambiguous PUTs cannot use capture.

Checkpoints: 3.0 creation; 3.1 reuse; 3.2 paired binding_digest. Legacy 1.0/1.1/1.2 and 2.0/2.1/2.2 remain readable, never upgraded; acknowledgements stay 1.0. V3 retains full digest/ETag for cleanup, independent core_digest, allowlisted field_digests, and datasource credential_digest. Datasource binding_proof is observed ResourceId or unverified; hidden initial snapshots cannot grant readiness. No secrets/skill text; unknown core stays protected. Reuse retains excluded_cycle and no owned resources.

Recheck only

python helpers/blob_recheck.py --input <original-input.json> --receipt <operation_id.blob-readiness.json> --compact

Validate private UTF-8 records: no links/duplicates; bind integrity/approval/owner/ plan/ownership before reads. Public-cloud CLI tenant/subscription/principal must match; no login/switching/grants. Tokens are ephemeral, not access-proof/locks.

Cloud reads:

  • Source GET knowledgesources('{name}') and /status, original API version.

  • Four exact returned datasources, indexers, skillsets, indexes: GET {collection}('{name}')?api-version={original-version}. Concealed datasource credentials permit one extra GET per verification pass, adding only &includeConnectionString=true: sanitized selected keyless ResourceId plus matching current plain/sanitized ETag/core is proof. Null/masked keys/SAS cannot prove binding. No redirects/retries; 60-second/8-MiB read bounds.

  • Existing bounded two-pass Storage inventories plus ADLS metadata HEADs, before and after monitoring; both must match the original inventory digest.

Configuration brackets inventory/status: nonempty ETags, exact source/generated identities and indexer datasource/skillset/index relationships. For timing read indexer observations: equivalent formats are INFO, unconstrained timing WARNING, explicit violations block. V3 core-equal ETag-only changes are INFO, not readiness failures. Datasource type/container/prefix/system identity must match. Concealment requires independent current child Storage binding proof. Root identity/old receipts cannot prove mutable child credentials. Missing proof is datasource-binding-unverified, not misconfiguration. Visible conflicts/core drift block, even during ingestion. CU/source-vector endpoint/auth checks still apply. Masked/nonempty/malformed keys or changed identities block; no model calls or query claims.

Reuse _blob_source_read.monitor with retained cutoff and bounded watch limits. Reuse excludes its retained first completion (normalized times). Require nonempty zero-failure/zero-skip completion, valid times/counters and no errors/active cycle/future completion. Stale/denied/malformed/missing evidence blocks. Active work at a watch limit is paused/in-progress, not failed ingestion. Legacy ingestion-timeout uses readiness.watch to distinguish pauses. Primary knowledge-source status drives progress interpretation. Missing endTime waits; missing counts stay unknown. Current runs supersede older last runs; replace counters without cross-run sums or file arithmetic. Supplemental indexer lastResult reports attempted/failed items within the shared status-request/time budget, never primary readiness or unique file counts. No run/reset, queries/models, PUT/PATCH/DELETE or data/RBAC changes.

Bounded continuation
python helpers/blob_recheck.py --input <original-input.json> --receipt <checkpoint.json> --watch-seconds 1800 --watch-max-requests 300 --watch-interval 5 --compact

Three overrides together, only with --input: maxima 3600 seconds, 1000 status requests, 60-second initial interval. Otherwise use original limits. One bounded window per invocation; no daemon/renewed approval. Unchanged/transient reads back off exponentially to 60 seconds; progress resets. Retry-After beyond the window/cap pauses. Socket timeout ≤30 seconds; windows aren't hard DNS deadlines. Ctrl+C during polling pauses; library cancelled() stops before the next request. Resume the same receipt after a pause; never recreate/run/reset/delete. watch.latest: actual synchronization start/state/counters, not independently ready documents. No ETA/percentage/assumed file or pending count. Item errors remain failures; unchanged observations don't prove a stall.

Output

Exit 0: source readiness only. Historical provenance: original_run; fresh IDs: read_only_evidence.request_ids. writes_performed: [], no follow-up ownership. Retrieval/KB remain unverified. original_run.historical_created discloses retained creation separately. creation_acknowledgement v1: state/type/name/http_status/request_id, observed before receipt IO. <operation_id>.blob-result.json retains full original result/IDs/integrity for historical reporting, not authority. original_run.original_failure.watch retains v1 pause context; missing legacy results stay unavailable. Persistence failure is terminal. generated_diagnostics covers all four children with sanitized field/severity/code; indexer_diagnostics retains its prior timing/binding contract. datasource_binding_observations: v1 records (schema_version, status verified/ unverified, request_id, plain, sanitized). Read fields: etag_digest, definition_digest, core_digest; unavailable sanitized read is null. No checkpoint replacement/cleanup proof.

--compact: closed blob-operation-summary 1.1 adds versioned readiness.progress; without progress retain 1.0. Fields: status/outcome, current writes/acknowledgement, historical creations, generated identities, readiness/watch, first retry, current/historical failure code/status/ID (watch pauses aren't failures), diagnostics, unique request-ID count, private evidence/checkpoint leaf files and next decision. Full native JSON is retained privately first; without the flag output stays compatible. No hashes/raw skills in summaries. Retention failure emits full native output and nonzero exit, preserving the original error.

Exit 2: blocked, not reversed creation. Preserve resources/evidence/first failure.

--no-progress disables stderr; libraries default silent. Local integrity isn't service/lock/initiator proof. No reconstructed cutoffs or replacement zero-work vector creation proof. Return to KB/retrieval/agent owners. Cleanup needs separate approval and strict full-definition/ETag ownership; semantic exceptions never authorize deletion.

Authorities: failure/conflict/uncertainty only. Indexer status.

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