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

lifecycle/cleanup.md

Plan exact cleanup

When to use

Optional lifecycle: plan run-created KB/KS and Prompt cleanup. Read helper contracts.

Do not use

Not creation, repair, ownership recovery or arbitrary child deletion. Hosted teardown: hosted-cleanup-unsupported.

Inputs and discovery order

Use request/session/records, then exact Azure readback. Ambiguous names need one focused question; no subscription inventory/repeated intake. No approval for planning.

InputWhy neededRequired?Discovery orderSafe defaultIf missing or unansweredReconfirmation trigger
TargetScopeYesRequest/session/recordsNoneSelect exactlyScope
Owner/recordsProofYesTrusted auditNoneBlockEvidence
BoundsComplete readsYesExplicit/default20 pages/500 objectsBlock at limitBounds
ConsentAuthorityBefore writeUnchanged envelopeUnapprovedNo writePlan/state

Owner metadata is neither ownership proof nor RBAC. Validate record bindings, not authenticity: retain original approvals/results and original successful call records. Never invent provenance or treat equivalent GET as create evidence. Existing/reused/updated/foreign resources stay unowned. Readiness isn't index content/ownership. Require original child versions, not guesses.

Decisions

  • KB: delete its definition only; retain sources, generated objects and consumers. Retrieval stops; consumers are not detached.

  • KS: the existing executor deletes only the source. The service cascades to its exact generated index (File), or index, indexer, skillset and datasource (Blob/ADLS). Show those names before approval. Retain local/Storage originals, accounts, containers, models, services/grants. Uploaded File copies and indexed content are deleted.

  • Before KS cleanup, enumerate every page of KBs in that Search service. References block: separately plan/delete an owned KB first; never detach outside-plan KBs. Native source in-use rejection remains a final guard. Enumerate scoped knowledge sources, indexers and skillsets to detect shared children; compare exact child definitions/ETags with original snapshots. Unknown consumers, missing objects, denied/partial inventories, or changed incarnations block.

  • Prompt: delete the connection, optionally preceded by one selected run-created version. Preserve containers, other versions, KB, models/grants. Deletion removes that version's tool binding; it never edits tools on a retained version. Require SDK ≥2.4, unshared state and complete paged agent/toolbox inventories, all versions including drafts, with exact version GETs. Only the selected version may consume it. Hosted/workflow/external definitions, unknown tools/skills/policies block. Sharing outside this project blocks: project agent inventory cannot prove external consumer absence. isSharedToAll: false alone is not proof.

Proposed plan

python helpers/cleanup_plan.py --plan request.json

Closed request: schema_version: "1.0", nonempty owner, exact target, creation_input_file, creation_receipt_file. Relative paths resolve beside the request. Use original producer outputs, not hand-built response JSON.

Before the original creation, retain proof with:

python helpers/search_reconcile.py --input approved-kb.json --cleanup-receipt-dir "<absolute-private-directory>"

The same flag applies to approved file_source.py and prompt_connect.py invocations under helpers/. Use an existing private user-owned directory outside the skill; validate paths/permissions without ACL changes. From cleanup_receipts, select the target's verified receipt. acknowledged is diagnostic, not authority. Immutable receipts contain filtered hashes/IDs/versions, never CU keys, auth/cookies or credentialized bodies. The keyless-Blob callback's privacy restriction is unchanged. Verified proof requires native create acknowledgement plus matching original readback. Reuse/update, recovery, missing identities/ETags or failed child readback block; later GETs cannot repair proof. Post-write failures are partial; retain errors/receipts.

Original Blob checkpoints from blob_source.py --receipt-dir also work with creation_result_file binding the checkpoint digest. ACK/recovery-only evidence cannot prove original child versions. Never recreate resources for cleanup proof.

Optional inventory_limits: closed integer max_pages/max_resources, defaults 20/500, maxima 100/5000 per collection; total Prompt versions also bounded. Connection-only agent_version + agent_creation_receipt_file select one version; name comes from the same creation input. Never select automatically.

Closed target:

  • Search: type: "knowledge-base" or "knowledge-source", endpoint, name, api_version (2026-04-01 or 2026-08-01-preview).

  • Prompt: type: "prompt-agent-version", project_resource_id, project_endpoint, name, exact numeric version.

  • Connection: type: "project-connection", same project identity, name.

  • Hosted: only type: "hosted"; blocked.

Initial receipts authorize only their version; native ID/time/definition are guarded. Retain the container.

Confirmation

Save only execution_input as JSON. Review exact delete/retain/ordering, then change only approval.confirmed from false to true. Never recalculate hashes. plan.cleanup_approved: true labels a destructive proposal: it is not consent while envelope approval is false.

Mutation

Executors: helpers/search_reconcile.py --input approved-cleanup.json or helpers/prompt_cleanup.py --input approved-cleanup.json. No combined creation/cleanup approval. Planners never delete, detach, provision, change roles, invoke retrieval/models, or auto-approve.

Closed dependency_guard snapshots and targets are revalidated immediately before destruction. For connection+version, check protected state before writing, delete/ verify the version, then rescan consumers before conditional connection DELETE. Stop on failure; report writes/remaining resources. Never strip guards or handcraft unguarded legacy envelopes.

Verification

ETag, fingerprint, identity, definition, sharing, inventory or child drift needs new planning/approval. These are fresh observations, not an atomic dependency lock; avoid concurrent administration. No force-delete or retry around a native dependency rejection. After source absence, GET each exact child to verify the cascade; remaining/unreadable children produce a failure, never child DELETE.

Failure and partial completion

Denied isn't absent. A definitive target 404 returns already-absent, no execution input and no new ownership; never authorize a future same-name replacement. Missing referenced/generated objects or incomplete pagination block. Unsupported enumeration (including drafts) names the missing operation; never substitute a filtered or partial list. Execution preserves blocked/partial; never advance after failed verification or delete a reused consumer.

Cleanup

No resources created; no recursive cleanup. Hosted teardown and arbitrary external consumer discovery remain unsupported.

Return contract

Exit 0: planned/already-absent, not cleanup completion. Exit 2: no-write blocked with first failure and retained scope. planned returns exact closed-schema execution_input, plan_fingerprint, executor, and delete/retain/blocked/ordering in approval_summary.

References

Authorities: failure/conflict/uncertainty only. Source cascade/in-use, paged KB inventory, paged agents and draft versions.

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