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

helpers/private-artifacts.md

Private execution artifacts

Use private_artifacts.py before collecting resource-sensitive planning/receipt data. These commands touch local storage only: no Azure calls, billable queries, approval, login or mutation. Disclose local creation separately from any subsequent planner discovery or approved Azure mutation.

This is an operator-selected private directory, not an automatically managed workspace for all skill I/O. Only explicitly selected supported outputs/receipts go there. It does not relocate source documents, intercept every input/output, provide a full workflow journal or create an OS sandbox.

From the packaged helpers directory, replace placeholders with local paths:

python private_artifacts.py --create-directory <absolute-new-private-directory>
python private_artifacts.py --validate-directory <absolute-existing-private-directory>
python file_source.py --plan <request.json> --execution-output <absolute-new-private-file.json>

Use native absolute paths, such as C:\operator\session\private-receipts on Windows or /home/operator/session/private-receipts on POSIX. The parent must already exist. Creation makes one new leaf; it never fixes or overwrites an existing directory. Validation accepts only the current operator's private directory under the existing receipt policy. Use the returned directory as bootstrap receipt_dir or Blob --receipt-dir; no manual ACL commands. If blocked, select another safe parent/new leaf, not the session, home or repository directory itself. Never recursively change their permissions.

Artifact operations add local filesystem, ACL/ownership and handle checks, JSON serialization/hashing, integrity readback and flushes; work scales with path depth and artifact size, including inventories. They make no Azure/model calls. Planner discovery/inventory costs remain separate. No latency or “negligible overhead” claim is established by these correctness tests.

Output and approval

The optional --execution-output is supported only with --plan in File, Blob, KB, vector verification and bootstrap. It writes the exact unapproved execution input, not the result wrapper. Preserve null, empty object/array, Unicode, resource bindings and all plan metadata. Bytes are canonical JSON (sorted keys, ASCII escapes, compact) plus one newline; execution_artifact.sha256 hashes those bytes, while fingerprint is the existing sha256: plan digest. No implicit approval or executor invocation.

Stdout contains a compact artifact reference, both hashes, confirmed: false, bounded counts/execution-required flags and local/Azure side-effect distinctions—not inventories, source names, prerequisite references or per-file digests. Review the full private artifact before approval; a hash alone is not a customer-readable approval summary. Do not copy private JSON into normal logs or conversation. Output filenames/paths themselves appear in the reference; choose neutral names.

Legacy output without the flag is unchanged. Bootstrap still defaults to the existing schema-2 <receipt_dir>/<operation-id>.plan.json convention; explicit output selects its plan location but does not redirect its other operation receipts. Bootstrap reuse remains read-only and requires no execution.

After human approval, preserve the entire plan/fingerprint and change only approval.confirmed to true for schema-1 --input executors. For bootstrap, retain the unchanged schema-2 artifact and use its existing --apply ... --approve contract. These are separate consequential steps, not artifact validation. Never run an executor unapproved as a test. Existing immutable acknowledgement, conditional-write and receipt ownership semantics are unchanged.

Filesystem safety and recovery

Shared _bootstrap_io.py creates POSIX leaves at 0700 and files at 0600; Windows supplies an explicit protected owner/SYSTEM/Administrators DACL at creation, with inheritable private directory access. Windows chmod is not privacy. Existing directories must pass owner/DACL or owner/mode validation. Symlink/reparse ancestors, unsafe leaf names and installed-plugin destinations block. POSIX ancestors must be root/operator-owned and not group/world writable. Windows ancestor handles prevent rename/deletion substitution while writing; a readable inherited parent can safely contain a newly protected private leaf. Ancestor owners must be the operator, SYSTEM, Administrators or Windows' fixed TrustedInstaller principal. Nontrusted delete/delete-child, write-owner, write-DACL and generic-all grants block even when the selected leaf is private: otherwise another principal could replace the retained path after handles close. This does not relax the operator-owned private-leaf receipt policy.

Artifacts use exclusive private temporary creation, flushed file contents, integrity readback, no-replacement publication and final identity/link-count/bytes verification. POSIX publication flushes the directory; Windows renames the owned write-through handle without closing/reopening its temporary pathname. Existing files, directories, symlinks and hardlinks are never overwritten. Only an owned temporary inode can be removed on failure. Unsupported filesystems, unprovable ACLs or races block; no reported artifact success on failed persistence. Cleanup preserves the original persistence blocker and reports a sanitized outcome: removed, already absent, identity changed, inspection unavailable or removal unconfirmed. Changed/uninspectable entries are not deleted. Cleanup-only failures also block success; there is no unprotected fallback. An error after publication can leave the complete private destination: retain it for operator inspection and select a new filename, never overwrite it on retry. No guarantee against the operator, system administrator, compromised kernel or hardware ignoring flush semantics. Files remain private until the operator handles retention.

JSON output is finite, secret-field checked and bounded to 16 MiB. Individual planner/executor input limits still apply (notably bootstrap's 1 MiB); the helper does not expand those limits. Credentials, tokens and secret-bearing connection strings are forbidden; private query text stays inside the artifact.

Extension contract (future planners)

Prompt/connection/cleanup do not accept this optional flag. Add that wiring only in a separate integration after this facility merges. A planner may then import add_execution_output_argument(parser), validate_execution_output_mode(args) (before discovery), and emit_plan_result(result, args.execution_output, preserve_unapproved_input=...). Pass the original status: planned result and its closed schema-1 unapproved execution_input; retain the prior emitter's preservation setting for default compatibility. Call inside the CLI's HelperFailure boundary. retain_execution_input(document, absolute_path) supports existing schema-1/2 closed envelopes and returns only the reference. No planner may supply an approved envelope, bypass secret checks, invent consent, emit private summaries or invoke execution here. Add planner-specific exact-artifact and no-execution regressions.

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