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

Download the skill as a ZIP:
https://autogineer.com/agent-skills/microsoft/foundry-iq/download

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.

Outcome	Read
Cleanup	Plan cleanup
Failure/drift	Diagnose
Unsupported connector provisioning / multi-source KB creation or reconfiguration	Diagnose
Connect	Connect
Read KB	Query
Search only	Search
File KS only	File
Blob/ADLS KS only	Blob
Searchable/KB	KB

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

ATTRIBUTION.mdAdded by AutoGineer977 B
LICENSELicence file added by AutoGineer1.1 KiB
SKILL.md3.7 KiB
agents/connect-hosted-toolbox.md7.8 KiB
agents/connect-hosted.md7.8 KiB
agents/connect-prompt-sdk-fallback.md7.8 KiB
agents/connect.md7.8 KiB
agents/create-missing-agent.md7.8 KiB
helpers/_blob_observation.pyScript4.4 KiB
helpers/_blob_source_read.pyScript39.5 KiB
helpers/_bootstrap_io.pyScript30.1 KiB
helpers/_cleanup_dependencies.pyScript27.5 KiB
helpers/_cleanup_receipts.pyScript13.5 KiB
helpers/_common.pyScript36.2 KiB
helpers/_document_adapters.pyScript15.0 KiB
helpers/_document_limits.pyScript3.9 KiB
helpers/_embedding.pyScript7.0 KiB
helpers/_file_inventory.pyScript24.4 KiB
helpers/_file_source_config.pyScript15.6 KiB
helpers/_indexer_observation.pyScript7.1 KiB
helpers/_initial_prompt.pyScript12.5 KiB
helpers/_private_json.pyScript2.4 KiB
helpers/_progress.pyScript12.1 KiB
helpers/_prompt_read.pyScript17.7 KiB
helpers/_search_read.pyScript6.0 KiB
helpers/_source_readback.pyScript1.6 KiB
helpers/blob-contracts.md7.8 KiB
helpers/blob-cu-contracts.md7.8 KiB
helpers/blob_inventory.pyScript17.1 KiB
helpers/blob_recheck.pyScript64.6 KiB
helpers/blob_source.pyScript35.8 KiB
helpers/bootstrap-contracts.md7.8 KiB
helpers/bootstrap_azure.pyScript41.5 KiB
helpers/cleanup_plan.pyScript41.4 KiB
helpers/contracts.md7.8 KiB
helpers/cu_ingestion_auth.pyScript12.5 KiB
helpers/document-assessment.md7.8 KiB
helpers/document_assess.pyScript14.0 KiB
helpers/file-upload-recovery.md7.8 KiB
helpers/file_cu_canary.pyScript32.7 KiB
helpers/file_cu_mi.pyScript9.6 KiB
helpers/file_ingest.pyScript15.4 KiB
helpers/file_source.pyScript31.7 KiB
helpers/file_upload.pyScript53.7 KiB
helpers/hosted_connect.pyScript30.8 KiB
helpers/kb-contracts.md7.8 KiB
helpers/knowledge_base_retrieve.pyScript7.7 KiB
helpers/model-discovery-contracts.md7.8 KiB
helpers/model-discovery-scopes.md7.8 KiB
helpers/model_discovery.pyScript23.7 KiB
helpers/private-artifacts.md7.2 KiB
helpers/private_artifacts.pyScript4.8 KiB
helpers/prompt_cleanup.pyScript22.0 KiB
helpers/prompt_connect.pyScript62.3 KiB
helpers/requirements-assessment.txt103 B
helpers/retrieval-verification-contracts.md7.8 KiB
helpers/retrieval_verify.pyScript19.6 KiB
helpers/search-intake-contracts.md7.6 KiB
helpers/search_intake.pyScript18.4 KiB
helpers/search_reconcile.pyScript59.7 KiB
helpers/source_vector.pyScript33.2 KiB
helpers/throttle-recovery.md5.0 KiB
helpers/vector-contracts.md7.8 KiB
knowledge-bases/create.md8.1 KiB
knowledge-bases/retrieve.md7.8 KiB
knowledge-sources/create-azure-blob.md7.8 KiB
knowledge-sources/create-file.md7.8 KiB
lifecycle/cleanup.md7.8 KiB
references/abstention.md1.0 KiB
references/blob-binding-evidence.md7.8 KiB
references/blob-indexer-observation.md7.7 KiB
references/blob-ingestion-progress.md6.5 KiB
references/blob-readiness-recheck.md7.8 KiB
references/blob-vector-readiness.md2.6 KiB
references/bootstrap-azure.md7.8 KiB
references/content-fit.md7.8 KiB
references/cu-ingestion.md7.8 KiB
references/file-cu-canary.md7.8 KiB
references/intent-routing.md7.7 KiB
references/owner.md2.1 KiB
references/platform-contracts.md7.7 KiB
references/platform-interfaces.md7.8 KiB
references/resource-intake.md7.8 KiB
references/search-substrate.md7.8 KiB
references/standard-cu.md7.8 KiB
search-services/create.md7.8 KiB
troubleshooting/diagnose.md8.7 KiB

references/blob-indexer-observation.md

Generated Blob indexer observations

Read when Blob/ADLS generated schedule or version readback differs, including checkpoint recovery. Minimal/Standard/CU, lexical/vector use the same verifier. This is not schedule management, write resumption or a new planner.

Binding versus timing

Observation	Decision
Wrong `dataSourceName`, `targetIndexName` or `skillsetName`	Hard binding failure; never a schedule warning
Equivalent interval/start-time formats	INFO; continue all readiness checks
Valid timing differs without an explicit approved constraint on that field	WARNING about possible recurring work/cost; continue verification
Explicit approved interval/start-time differs	Block constraint acceptance, not evidence that ingestion failed
Malformed/unknown schedule	Block; do not infer defaults
ETag-only revision	V3 core-equal observation: INFO; legacy unexplained revision: block
Any other indexer field changes	Hard drift failure, even alongside schedule changes

The approved original wire's ingestionSchedule constrains a supplied interval and non-null startTime. An omitted/null start time is unconstrained. New typed planners require ingestion_schedule: null: no schedule override, not guaranteed one-shot processing or absence of recurring work. No monetary cap, no-run constraint or cost acceptance is inferred from absent fields. Those constraints have no supported planner representation; if required, keep their acceptance unresolved with the caller/owner, not silently verified. Unknown schedule properties block rather than becoming invented approval.

Missing, null and scheduled observations remain distinct; pinned defaults below are not substituted for a run's readback. If an authorized GET observes P1D, disclose daily cadence and possible recurring processing/cost. Otherwise do not invent that cadence. Neither observation is cost approval or ingestion proof. Schedules contain only interval and optional startTime; empty objects, null/missing intervals, unexpected properties and invalid types block.

Normalize bounded XSD day/time durations, 5 minutes through 24 hours inclusive: P1D, PT24H, PT1440M, PT86400S are equivalent. Calendar years/months, weeks, negatives and unsupported forms do not pass. Timestamp equivalence requires a valid explicit timezone and exact instant, preserving up to seven fractional digits (100 ns). Reject naive/unknown-offset timestamps, invalid dates, leap seconds, excess precision and offsets outside +/-14:00; no rounding.

Versioned private proof

New immutable checkpoints use 3.0 creation, 3.1 reuse, or 3.2 reuse with paired creation binding. Write/source acknowledgements remain 1.0. configuration.indexer retains the actual ETag and:

digest: complete returned child definition.
non_schedule_digest: every field except schedule and @odata.etag.
schedule_digest: validated canonical timing, including presence state.
schedule_raw_digest: actual schedule representation and presence.
V3 core_digest/field_digests: independent semantic configuration and safe field diagnostics.

All other fields, including unknown fields, mappings, parameters, identity and description, remain in the non-schedule hash. V3 other-child core/binding policy: readiness recheck. Source identity stays strict.

Exact snapshots pass. In V2, a changed ETag/full hash can pass only when an observed schedule change explains it, every other observed field matches and current approved timing constraints hold. V2 ETag-only/unexplained changes block. V3 core-equal ETag-only changes are INFO; all explicit timing constraints still apply. Equal full hashes with inconsistent projection/version evidence block. Always retain actual current hashes; never substitute the old ETag as readback. Comparisons do not modify receipts or lock resources and cannot prove unseen intervening revisions.

Legacy 1.0/1.1/1.2 checkpoints retain exact full-hash/ETag comparison. Legacy 1.2 still requires paired creation proof; 1.1 does not. A changed legacy snapshot lacks a schedule preimage/projection and stays blocked; neither a warning nor a schema-version edit upgrades that proof. Preserve it. GET current definitions and compare legitimately retained preimages if available. Separately planned fresh read-only reuse capture is a new observation, not recovered historical configuration, cutoff or ownership.

Lifecycle and safe continuation

Keep acknowledgement-before-GET unchanged. Checkpointed creation captures generated configuration before polling and rechecks after successful ingestion/source/Storage readback. Recheck observes configuration before and after inventory/status; recovery brackets its inventory with configuration observations before retaining a checkpoint. Both capture/recovery results still mean readiness unverified.

Use existing commands with unchanged private inputs and genuine receipts:

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

For a separate unowned reuse operation:

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

Follow recheck contracts for private files, paired creation proof when needed, original context/ownership/cutoff, and excluded reuse cycles. Recovery cannot erase known contradictory retained configuration.

indexer_diagnostics contains severity/code, a safe field name, static message and request ID. indexer_observations contains actual hashes and hashed ETag, not raw timing/resource content. WARNING messages also appear in warnings; INFO is not promoted to WARNING. First failures and acknowledged partial ownership remain intact. A qualified cycle observed before later drift is retained, but overall readiness returns unverified.

Warnings never bypass native cycle/error checks, Storage/ACL inventory or source bindings. Read-only recheck additionally requires nonempty, zero-skip completion and rejects future completion; this does not change the original monitor's counter semantics. A checkpoint is not the separate nonempty creation proof required for zero-work vector reuse. Snippets cannot substitute. Denied/missing reads and unknown evidence remain blockers with provenance. GET/ADLS metadata HEAD only; no schedule edit, run/reset, PUT replay, new source, cleanup, query or model calls. KB/retrieval completion and separate cleanup approval remain with their owners.

Authorities

Authorities: failure/conflict/uncertainty only. On uncertainty, consult indexer scheduling for documented duration bounds, and the Blob generated pipeline for generated resources/status. Neither proves a particular unread generated schedule or a null knowledge-source schedule default.

Supplied read-only implementation trace: AzureSearch commit 2e241af8939a0891836b78278df113dab31a5964, Source\Search\Product\SearchAgentCore\RestClient\SearchRestIndexingPipelineManager.cs: DefaultIndexingScheduleDays is 1 (line 64); extraction passes the nullable ingestion schedule (521-548) through indexer creation/payload construction (297-301, 1497-1504, 1540-1544). BuildScheduleJson (1798-1816) maps null to {"interval":"P1D","startTime":null}. This establishes that pinned implementation, not every deployment or the reported manual run. Null-to-daily stays WARNING when unconstrained, never semantic equivalence; explicit constraints still block.

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

2026-11-09

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