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-binding-evidence.md

Concealed Blob binding and read-only recovery

For concealed Blob/ADLS credentials or missing checkpoints; no repair/cleanup.

What proves binding

Redaction is not a mismatch. Source and mutable datasource binding are distinct:

  1. Fresh azureBlobParameters.connectionString exposes selected ResourceId; or unchanged approved keyless wire/creation acknowledgement binds source endpoint/name/API/ETag/definition and generated IDs.

  2. Source and generated definitions match selected type/container/prefix, system-assigned identity, datasource/indexer/skillset/index relationships and approved timing. Child Storage binding requires current ResourceId readback, including the sanitized read below when concealed. Read all four.

  3. Bounded Storage inventories and ADLS ACL/property observations match the original inventory. CLI context remains unchanged throughout observation.

Missing/null/empty or <redacted> connection values disclose no credential. Opaque strings, malformed credential objects, another ResourceId, account keys/SAS (even masked keys), another identity or conflicting relationships still block. Planning/execution/vector source readbacks share this rule; never echo credentials.

V3 compares credential-free core separately from ETags. Initially hidden snapshots retain binding_proof: unverified, not readiness; actual binding must be observed. Concealment changes warn. Each verification pass permits one extra exact HTTPS GET: GET datasources('{name}')?api-version={original-version}&includeConnectionString=true. Both APIs support sanitized Blob/ADLS readback: ResourceId for managed identity, masked keys/SAS; never raw credentials. Require the exact selected keyless ResourceId and identical current plain/sanitized ETag/core; the original checkpoint ETag may differ. No redirects/other options/retries; 60-second/8-MiB bounds. Sanitization/decryption failure can return null: not proof. Concealed, masked, malformed, wrong-account or raced readback remains datasource-binding-unverified. Retain resources; investigate the specific gap. Root identity/names/old receipts cannot prove mutable child credentials. No key retrieval, source repair or invented immutability. Retain current proof separately in datasource_binding_observations; never relabel checkpoint hashes. Legacy full-hash changes fail closed; no core projection is reconstructed. Legacy concealed readback may match a retained visible-ResourceId full preimage at the unchanged child ETag; a concealed-only preimage still needs sanitized proof. Cleanup always retains strict original full-digest/ETag checks. See readiness semantics and indexer timing. Readback is not a lock.

Checkpoint missing after creation

New-source modes retain private approved input and use:

python helpers/blob_source.py --input <approved.json> --receipt-dir <absolute-private-directory>

After successful If-None-Match: * PUT, before the first post-write GET, retain exclusive/ flushed <operation_id>.blob-write.json: approved wire digest/URL/condition, response status/request ID/ETags/generated IDs, original operation/cutoff/context. recheck_write_acknowledgement identifies it. No tokens/credentials/text; acknowledgement is not readback/readiness.

Use body @odata.etag or HTTP ETag; conflicts block. Missing both: never borrow a later GET ETag. Retain acknowledgement and report creation-version-unproven; intervening edits are possible. Duplicate/conflicting ETags stay recorded. Ambiguous creates retain the original error; resources_remaining.reused means observation, never creation ownership. After exact version-bound source readback, retain separate .blob-ack.json; after generated checks, .blob-readiness.json. Never overwrite earlier evidence. recheck_acknowledgement selects the enriched record, or write record if enrichment failed; recheck_checkpoint describes the full checkpoint. Persistence failure preserves the first error and acknowledged owned resources; no write retry. 429: read recovery; no ownership proof.

After denied/interrupted GET, retain first error/request ID and acknowledgement. When authorized reads resume:

python helpers/blob_recheck.py --recover <original-approved.json> --receipt <acknowledgement.json> --receipt-dir <absolute-private-directory>
python helpers/blob_recheck.py --input <original-approved.json> --receipt <operation_id.blob-readiness.json>

--recover accepts either acknowledgement. Verify original context, successful conditional-write provenance, exact response/source ETag, definition/generated bindings, inventory and before/after configuration. Missing PUT-generated IDs require fresh exact source-version readback, never inferred names. Preserve original operation/cutoff/ownership; no timestamp or write proof is invented. Only a new local checkpoint is written; never overwrite evidence. outcome: blob-readiness-recovery-capture, status: completed means checkpoint retained, with readiness.status: unverified. Run the second command next. Recovery observes current configuration, never a historical revision.

Older creation, no checkpoint

Planner reuse_input_file/reuse_result_file bind concealed source accounts; retain fresh unapproved reuse execution_input. Never edit creation artifacts into reuse.

python helpers/blob_recheck.py --capture <reuse-input.json> --receipt-dir <absolute-private-directory> --reuse-input-file <approved-create.json> --reuse-result-file <completed-create.json>
python helpers/blob_recheck.py --input <reuse-input.json> --receipt <new-operation.blob-readiness.json> --reuse-input-file <approved-create.json> --reuse-result-file <completed-create.json>

Private reuse schema 3.2 binds the pair's canonical digest; recheck requires that validated pair. Verify current source identity/ETag/definition/generated IDs, owner/inventory against creation proof. Booleans/snippets/partial results cannot prove it.

Fresh observation, not recovered creation/consent/ownership/historical CLI identity. Bind current context/cutoff and exclude first completion. Without a later qualifying cycle, unscheduled reuse remains unverified; never start/reset an indexer to force it.

Readiness and next action

Recovery: Search/Storage GETs and ADLS metadata HEADs only. No queries/model calls, PUT, indexer run/reset, deletes, RBAC or data mutation.

Native verification requires a relevant nonempty completed cycle, zero failed/skipped items, valid times/counters, no active cycle/relevant errors/future completion. Checkpoints/acknowledgements cannot replace nonempty creation proof for zero-work vector reuse.

Snippets prove only query text. Report actually observed indexed content separately from unverified source/KB readiness. Never issue queries solely for this report.

Unknown binding: inspect exact definitions/retained evidence. Resolve denied reads with the access owner; not CU unsupported or cleanup-only.

Lost cutoff/readback/context, ambiguous PUTs or missing records cannot prove ownership/readiness. Name missing evidence; no manufactured receipts or guessed times.

Preserve original failure; return to finish authorized KB attachment, retrieval and agent steps; not overall completion. Cleanup needs separate approval; preserve shared data/roles.

Authorities

Authorities: failure/conflict/uncertainty only. Blob source/generated pipeline, datasource GET identity/credentials. Supplied service-source contract: AzureSearch 2e241af8939a0891836b78278df113dab31a5964 datasource GET and GetSanitizedBlobConnectionString; source inspection, not live evidence or immutability.

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