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/downloadUnzip 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
helpers/file-upload-recovery.md
File upload continuation and partial batches
After partial File creation, retain the source. Never rerun creation, infer MI from redacted GET, or recover by recreation/deletion/reset/new roles. Generic File MI reuse/provenance guards remain unchanged.
Retain original evidence before creation
python helpers/file_source.py --input <original-approved.json> --cleanup-receipt-dir <private-receipts> --upload-receipt-dir <separate-private-empty-directory>Use the private directory helper; no automatic directory/ ACL changes. The required journal retains original approval/context, actual conditional source PUT ACK/request ID/ETag, exclusive pre-POST attempts and separate upload responses. Never edit/remove/reconstruct entries. Integrity isn't a service signature: retain exclusive control, no concurrent writers.
File CLI creation requires protected --cleanup-receipt-dir and
--upload-receipt-dir pre-write; separate directories, no guessed paths. Plan with
--execution-output <new-private-plan.json>; show reference/counts, not
hash-bearing envelopes. Plan JSON/library and non-File policies are unchanged.
Persistence failure stops requests. An attempt without result stays uncertain,
even if POST wasn't sent. Missing ACK/ETag cannot come from GET. Journals neither
replace cleanup provenance nor authorize deletion.
Without originals: retain source, file-upload-provenance-missing, not
"recreate required".
Supported upload-only plan
Closed request:
{"schema_version":"1.0","receipt_directory":"<absolute-original-private-directory>"}python helpers/file_upload.py --plan resume-request.json --execution-output <new-private-resume.json>
python helpers/file_upload.py --input <newly-approved-resume.json>Planning is read-only: an unapproved, closed version 1.0 resume-file-uploads
envelope binds original plan/creation ACK/journal digests, owner, exact
never-attempted ordinals and receipt directory;
cleanup_approved stays false. Review and newly approve these uploads. An empty
eligible list needs no mutation or execution; use the returned observation.
Never edit ordinals/hashes to authorize attempted files.
Execution validates the original unchanged approved corpus (paths, full hashes,
size, timestamps, mode, metadata), tenant/subscription/principal, source URL/API/
definition/ACK ETag, and applicable CU account/Search MI/role/network snapshots.
It neither acquires CU keys nor changes authentication. It invokes only existing
metadata GETs and direct File upload POSTs using the original Search identity;
no source PUT, source update, new role, indexer operation, deletion, KB or model call.
POST targets the original validated
/knowledgesources('<name>')/files?api-version=2026-08-01-preview&pageSize=200
multipart contract; approval/privacy gates apply.
Continuation excludes previously attempted files, including exhausted 429 retries, timeout/409/5xx and interrupted attempts. Only the original operation may retry its received File-upload 429 once, as below. An immediate or delayed empty inventory never proves in-flight termination for unknown outcomes. Positive exact file-ID/ marker/hash/size readback can prove completed ingestion, but never invents an upload ACK or source ownership. Drift blocks; never repair by write.
Bounded batching and truthful progress
File upload is synchronous: extraction, chunking, embedding, indexing and metadata
persistence finish before success. No File indexer, schedule or asynchronous status
polling. Each sequential POST has a 180-second processing/response allowance,
separate from the 60-second read budget; stricter approved outer deadlines win.
Timeout is not remote cancellation. Retain 200/201 ACKs without relisting source/
full inventory after every healthy file. One final bounded inventory checks the
batch; follow validated @odata.nextLink exactly, without rebuilding parameters.
A per-file 415 permits independent continuation. Auth/access, deadlines,
persistence, drift and unknown outcomes stop new uploads. Repeated 429, or later
429 after the operation's one retry opportunity, stops without more reads/sleeps.
Preserve prior confirmed files; never hammer the remaining corpus.
429 recovery supplies one server-respecting delay/read
opportunity, at most 30 seconds waiting/60 seconds per complete read sequence,
including all pages and response reads. Overlong delays stop, not shorten.
Journal-retained UTC backoff blocks resume planning/execution before any network;
fresh approval never waives it. file_batch.backoff reports waiting/unresolved/
elapsed. Legacy 429 without timing stays unresolved; no invented deadline.
--no-progress disables observations. Otherwise stderr emits counts, a waiting
event with the bounded HTTP-429 delay, and terminal state. During POST, an immediate
and then five-second content-free heartbeat reports ordinal/total/attempt, elapsed
time and already ingested count: "1/25 ingested; processing file 2/25". This observer
never makes requests. No within-file percentage, ETA, filenames or private content.
Increment completion only after ACK/metadata proof and required receipt persistence.
file_batch.files records bounded relative names/full hashes, upload state,
verification state and sanitized request IDs. Counts distinguish:
accepted (original 200/201 ACK), confirmed (exact file-ID/markers without
reported error), failed, pending (ACK but not confirmed),
unverified (uncertain attempt), and not_attempted.
Accepted overlaps verification counts; do not sum it with them.
ingested counts synchronous completion proved by valid ACK metadata or exact
completed-file readback. A status-only ACK is insufficient. Original ACK file IDs
remain binding even if its remaining metadata is incomplete. Failed readback stays
partial while preserving known prior ingestion; retrieval stays unverified.
File completion does not prove OCR quality or KB retrieval.
Report "24 ingested, one failed/unverified" only with this proof; otherwise distinguish accepted/pending. Preserve outcomes, not a blanket blocker. A subset handoff must disclose pending files may appear and subset isolation is not proven; any KB use still needs its existing separate approval. No automatic KB writes.
One documented queue-rejection retry
The official File guide identifies upload HTTP 429 as a full processing queue and recommends bounded parallelism/exponential backoff; Retry-After is not guaranteed. Only this File upload route permits one same-operation retry across the batch, not per file. No private throttle marker/error text is required. Honor valid Retry-After; missing/invalid metadata uses the diagnosed first backoff step of one second. Shared 30-second wait/60-second complete preflight limits apply. After waiting, revalidate unchanged source/corpus and one fresh bounded inventory. Positive proof avoids another POST; absence is not the retry authority: the received queue-rejection 429 is. Persist exclusive original/retry attempt and result records when journaling. Retry the original URL, token, multipart bytes/ boundary and approved payload; source creation happens once.
The MI canary's stricter one-upload approval forbids this retry. No PUT/DELETE/
update retry, new roles or auth substitution. Each upload creates a new file ID,
even for the same filename; no filename-idempotency key exists. Timeout/504/409/
5xx remain unknown, never replayable from empty inventory or elapsed time.
file-upload-retry-safety-unproven retains that blocker. Exhausted files stay
failed; continuation uploads only never-attempted files under fresh approval,
not another attempt at an exhausted file.
Authorities: failure/conflict/uncertainty only. File upload/troubleshooting.
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