Foundry Agentic Loop

GitHubOfficialFirst committed by vieiraaeDistributed by GitHub

Skill
Workflow
Software development
MIT
Low risk
Has scripts

From the author

Build agentic solutions on Microsoft Foundry, GitHub and Azure: hosted agents, toolbox tools and skills, Foundry IQ grounding and a React/FastAPI app. Three modes: rapid prototyping in an existing Foundry project; spec-driven development (SDD), where the foundry-agentic-loop-workflow runs Specify, Implement, Verify and Deploy to create the Foundry project and deploy with azd, or one phase runs alone; and Improve, which refines this skill and the workflow from past runs. Use for Agentic Loop requests and canvas actions, or end-to-end agent solutions from architecture to Azure deployment. Not for isolated Azure administration or unrelated UI edits.

— the description by vieiraae

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

foundry-agentic-loop provides a structured framework for developing agentic applications. It supports two primary modes: rapid prototyping for existing projects and Spec-Driven Development (SDD) for new projects requiring full Azure deployment pipelines. The skill manages the lifecycle of agents, toolbox tools, Foundry IQ grounding, and web application components, ensuring consistent architecture, security, and observability across the development process.

What it does

Orchestrates end-to-end agentic solution development from architecture to Azure deployment.
Provides a Spec-Driven Development workflow covering Specify, Implement, Verify, and Deploy phases.
Supports rapid prototyping for existing Foundry projects.
Manages Foundry hosted agents, toolbox tools, and Foundry IQ grounding configurations.
Automates deployment of React/FastAPI applications to Azure Container Apps.
Enforces security best practices through managed identities and least-privilege RBAC.

When to use it

When building new agentic solutions on Microsoft Foundry that require a structured development lifecycle.
When you need to deploy agentic applications to Azure using standardized pipelines.
When prototyping agentic features within an existing Foundry project.
When you need to integrate Foundry IQ grounding or custom toolbox tools into an agent.

Advantages

Ensures architectural consistency through a contract-first development approach.
Automates complex deployment tasks using azd and Bicep infrastructure layers.
Provides built-in observability via OpenTelemetry and Application Insights integration.
Maintains project history and lessons learned to improve future development cycles.
Reduces manual configuration errors by enforcing standardized workspace structures.

Usage examples

“Start a new agentic project using the SDD workflow.”: The agent initializes the SDD workflow, creates the necessary project structure, and begins the Specify phase to define the project requirements.
“Deploy my current Foundry project to Azure.”: The agent validates the current configuration, runs the deployment pipeline, and reports the status of the Azure Container Apps deployment.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/github/foundry-agentic-loop/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip foundry-agentic-loop.zip -d .agents/skills

Documentation by vieiraae

Foundry Agentic Loop

Coordinate the solution and use microsoft-foundry for platform operations. Explicit user choices override defaults. Reuse known context, ask only for missing decisions, read only the references a step needs, and report decisions, blockers and endpoints concisely.

Bootstrap (once per session)

Foundry skill. If microsoft-foundry is unavailable, ask, then install it (copilot plugin install azure@awesome-copilot, or gh skill install microsoft/azure-skills microsoft-foundry --agent github-copilot --scope project) and reload skills.
Canvas and workflow. This plugin ships foundry-agentic-loop-canvas and foundry-agentic-loop-workflow, listed as foundry-agentic-loop:<name> or <name>. Call extensions_manage with operation: "list". Never install extensions from a URL and never edit Copilot settings files. If one is listed under neither name, tell the user which is missing and that it ships with the plugin, then ask before running copilot plugin install foundry-agentic-loop@awesome-copilot; after they approve, call extensions_reload once. If one is disabled, tell the user to re-enable it in their extension settings and continue in a new session: running sessions keep it disabled, even after a reload. If one failed, inspect it and report its log. Without the canvas, continue in Chat; without the workflow, SDD cannot start, so offer rapid prototyping.
Canvas. When work starts from Chat, open it once: open_canvas with canvasId: "foundry-agentic-loop-canvas", instanceId: "foundry-agentic-loop" and input: { mode }. Prompts that begin [Agentic Loop canvas action] come from the canvas; follow their target, approval and resume instructions literally.

Choose the mode

Signal	Mode
Root `AGENTS.md` has an Agentic Loop section	Its `mode`. Switch only when the user confirms, then rewrite the section
Canvas prompt or explicit choice	As stated
Existing Foundry project selected or named; fast prototype; no deployment pipeline needed	Rapid prototyping: rapid.md
Spec, new Foundry project, azd or IaC, CI-ready repo or full Azure deployment	SDD: sdd.md
Improve, learn from runs, or the canvas improve prompt	Improve: improve.md; measure changes with `node scripts/evals.mjs` (index, then run `--base <commit>`; exit 2 means evals are unavailable, so stop)
One named SDD phase, with no run active	Its guide (Specify, Implement, Verify or Deploy) with the SDD defaults

Otherwise ask once with the choices "Rapid prototyping (existing Foundry project)" and "SDD (new project, deployed with azd)".

Lock it in. Before any other workspace write (in the rapid preflight, or just before the SDD workflow starts), upsert the section from agents-md-rapid.md or agents-md-sdd.md into the root AGENTS.md: replace everything between its foundry-agentic-loop begin and end markers, or append it, keeping other content; then read it back. The section routes short commands such as deploy and locks the mode for Chat, the canvas and the workflow. Azure settings go only in .azure/deployment-plan.md, never in AGENTS.md. Improve mode never writes it.

Defaults

Agents: Foundry hosted agents exposing the Responses API, Python 3.13, code deployment. Create them through microsoft-foundry's foundry-agent/create/quick-start-hosted.md with the Basic sample, resolved through that skill, never a guessed URL. Use its advanced workflow only when quick-start cannot support a capability, keeping these defaults. Prompt agents only when requested.
Framework: the Copilot SDK for agents that use runtime skills (recipe, reference agent); Microsoft Agent Framework for basic agents and explicit workflows. If a workflow also needs skills, clarify. One framework per agent.
Models: rapid keeps the Basic sample's model deployment, or verifies and reuses a supplied one; SDD defaults to gpt-5.4-mini unless the spec needs otherwise. Run the joint placement preflight in foundry-models.md before creating resources. Never hard-code a replacement or silently duplicate a deployment.
Tools and knowledge: one governed Foundry toolbox for built-in tools, MCP connections and agent skills; agents use its endpoint, not hard-coded tool URLs. Private knowledge uses Foundry IQ through the toolbox, with citations for supported claims and a deterministic insufficient-evidence response; test both. Add Search only when needed. Reuse run skills the user names from the run catalog instead of regenerating them.
App: React + Vite, FastAPI and FastMCP (streamable HTTP) on Azure Container Apps. Rapid deploys with az containerapp up --name <app> --source <dir> --resource-group <rg> --environment <env>; SDD uses azd with a microsoft.foundry layer plus a Bicep (AVM) app layer, remoteBuild: true and one ACR pulled by managed identity. Add services from the reference architecture only when the solution needs them.
App access: decide it from the data. When everything the app shows is sample, synthetic or deliberately public, default to no end-user sign-in, even for staff users; services still authenticate with managed identities and need no anonymous-session or identity-verification workarounds. When it shows private, sensitive or user-specific data, ask for the access model before deploying and default to internal ingress or Entra sign-in; anonymous access needs explicit approval. With sign-in, the API pre-authorizes the SPA, the spec states how automated browser tests get a user token, and Implement proves that token path as soon as the app registrations exist.
Identity and safety: managed identities and least-privilege keyless RBAC (contract; preflight with check_rbac_preflight.py). Check management-plane, data-plane and role-assignment rights separately; subscription Owner does not grant Foundry data-plane roles. Plan roles for identities not yet created and verify actual principals after creation. No credentials in browser code or Git; Foundry guardrails on.
Observability: OpenTelemetry from the backend, agents, MCP servers and model calls into one Application Insights connected to the project (observability.md). Sensitive content capture stays off unless approved with redaction and retention controls.

Workspace files

File	Holds
`AGENTS.md` (root)	The mode lock and short-command routes; never Azure settings
`README.md` (rapid) or `docs/spec.md` (SDD, from the spec template)	The contract
`.azure/deployment-plan.md`	Every Azure setting, in both modes (template)
`.env` (Git-ignored)	What the canvas reads: `FOUNDRY_PROJECT` (full ARM ID, once validated or created), `LOCAL_FRONTEND` and `DEPLOYED_FRONTEND` (verified URLs only). Upsert, keep other keys and read back
`docs/LOOP.md`	Lessons (template)
`.agentic-loop/runs/<runId>.json`	SDD flight records, written by the workflow
`.devcontainer/devcontainer.json`	Optional dev container (asset)

Working rules

Contract first. Freeze service names, environment variables, protocols, endpoints, schemas, auth, streaming, errors and versions (implementation-contract.md) before parallel work.
Integration first. Pass the hosted integration checkpoint with a minimal agent before building full orchestration, UI or backend: always a model request, plus a toolbox skill load and a safe MCP call only when the architecture needs them. Record excluded capabilities as N/A with the reason, never as passed, and never add unused ones to satisfy the checkpoint.
Evidence, not signals. HTTP 200, exit 0 or active never pass alone; require terminal completion, schema-valid output, execution evidence and correlated traces. Fix with bounded diagnostics, not unchanged redeployments.
Wait by completion. Provisioning, deployments, role-assignment propagation and agent readiness end when their command or status check says so: run the command synchronously with a long initial wait, or poll its status every 30-60 s against a stated deadline. Never chain fixed sleeps; keep coding while Azure works.
Subagents. Before the checkpoint, parallelize only research and preflight. After it, give each worker a bounded goal, exclusive workspace-relative files or folders, skill references, verified context, the contract, acceptance checks and stop conditions. One owner (the coordinator, or the SDD phase lead) holds the contract and the shared files: azure.yaml, infra/, docs/, .env, .azure/, .agentic-loop/, AGENTS.md and the root lockfiles. Keep teams small, avoid recursive delegation, serialize shared Azure mutations and integrate centrally; worker success is not acceptance. Delegation grants no extra approval. Without subagents, work sequentially and say so.
Safety. Reuse resources; confirm billable, security or compliance changes; delete without approval only a resource this build created whose provisioning failed; never sign in for the user; never report an unverified deployment as successful.
Workspace boundary. Builds stay inside the workspace: read lessons only from its own docs/LOOP.md, scaffold from the Foundry samples and these references, and use code from other folders only when the user names them. Only improve mode reads past runs elsewhere.
Work IQ context. Only when the user or a canvas prompt asks for it, query the workiq MCP server before clarifying questions, fold in only the requirements that matter, cite each by source type and confirm them. Never copy confidential content, personal data or secrets into the workspace; if Work IQ is unavailable or needs consent, say so and continue without it.
Companions and SDKs. Verify installed SDK APIs against the latest stable release (or the newest stable one the build's package index serves, recording the gap) and lock versions before generating code; package sources beat stale guidance. Consult the build catalog only for needed capabilities; respect pins, ask before installs and route third-party skill defects upstream.

Lessons

Right after a fix is verified (the failing probe or an equivalent boundary check reruns successfully; an edit, commit or deployment alone is not resolution), upsert a lesson in the workspace's docs/LOOP.md from the template before unrelated work, then read it back. Keep user notes, update matching lessons instead of duplicating them, and never include secrets, raw .env values or payloads. The coordinator, or the SDD phase lead, owns writes; workers report evidence. Lessons never authorize skill edits or weaker gates; improve mode applies them with approval.

Files

ATTRIBUTION.mdAdded by AutoGineer873 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md12.1 KiB
assets/agents-md-rapid.md1.1 KiB
assets/agents-md-sdd.md1.4 KiB
assets/deployment-plan-template.md3.0 KiB
assets/devcontainer.json800 B
assets/loop-template.md1.3 KiB
assets/spec-template.md4.0 KiB
evals/evals.json94.0 KiB
evals/fixtures/improve-history/.agentic-loop/runs/wr_101.json2.4 KiB
evals/fixtures/improve-history/.agentic-loop/runs/wr_117.json2.4 KiB
evals/fixtures/improve-history/.agentic-loop/runs/wr_123.json1.6 KiB
evals/fixtures/improve-history/AGENTS.md1.4 KiB
evals/fixtures/improve-history/docs/LOOP.md2.0 KiB
evals/fixtures/rapid-locked/.azure/deployment-plan.md868 B
evals/fixtures/rapid-locked/.env207 B
evals/fixtures/rapid-locked/AGENTS.md1.2 KiB
evals/fixtures/rapid-locked/README.md1010 B
evals/fixtures/rapid-locked/gitignore41 B
evals/fixtures/sdd-deployed/.agentic-loop/runs/wr_88.json2.6 KiB
evals/fixtures/sdd-deployed/.azure/deployment-plan.md1.6 KiB
evals/fixtures/sdd-deployed/AGENTS.md1.4 KiB
evals/fixtures/sdd-deployed/docs/spec.md1.9 KiB
evals/fixtures/sdd-deployed/docs/verify.md374 B
evals/fixtures/sdd-paused/.agentic-loop/runs/wr_42.json2.9 KiB
evals/fixtures/sdd-paused/AGENTS.md1.4 KiB
evals/fixtures/sdd-paused/docs/LOOP.md371 B
evals/fixtures/sdd-paused/docs/spec.md1.9 KiB
evals/fixtures/sdd-paused/docs/verify.md322 B
evals/fixtures/sdd-paused/src/backend/routing.pyScript172 B
evals/fixtures/sdd-paused/tests/contract/test_routing.pyScript208 B
evals/fixtures/team-conventions/AGENTS.md224 B
references/azd-layout.md11.3 KiB
references/build-skills-catalog.md4.8 KiB
references/check_rbac_preflight.pyScript18.9 KiB
references/copilot-sdk-foundry.md16.6 KiB
references/copilot-sdk-with-toolbox.pyScript14.3 KiB
references/deploy.md4.4 KiB
references/foundry-hosted-agent.md6.0 KiB
references/foundry-iq-grounding.md6.8 KiB
references/foundry-models.md5.2 KiB
references/foundry-toolbox.md5.5 KiB
references/hosted-integration-checkpoint.md13.4 KiB
references/implement.md5.9 KiB
references/implementation-contract.md3.7 KiB
references/improve.md5.0 KiB
references/observability.md5.9 KiB
references/rapid.md8.9 KiB
references/rbac-contract.md9.9 KiB
references/rbac-preflight.md10.3 KiB
references/reference-architecture.md3.4 KiB
references/run-skills-catalog.md3.4 KiB
references/sdd.md11.1 KiB
references/specify.md4.4 KiB
references/verify.md5.3 KiB
scripts/evals.mjsScript22.0 KiB

references/rbac-preflight.md

RBAC pre-flight

Reference for the foundry-agentic-loop skill: the permission gate that runs before any provisioning in an agentic loop run, so missing role assignments are reported as one complete list before anything is created — never discovered one failure at a time, halfway through provisioning.

Why this exists. An agentic loop run hit RBAC failures on the subscription, then the resource group, then the Foundry project. Each surfaced mid-provisioning, after partial resources already existed, and each had to be chased separately: request a grant, re-run, hit the next one. The whole set of missing assignments was knowable up front. This step makes it knowable up front.

This step is deliberately self-contained — it needs only the caller identity and the scopes in play — so rapid prototyping, SDD Specify and Deploy preflights reuse it unchanged.

What it checks

The runtime matrix describes the solution's managed identities — principals that do not exist yet before provisioning. The pre-flight checks the other half of the contract: the deployer prerequisites, the rights the caller needs both to create the resources and to write every role assignment the generated Bicep will create.

Concretely:

Enumerate required assignments from the deployer-prerequisites table.
Resolve effective assignments for the caller at each scope in play — subscription, resource group, Foundry AI account, and Foundry project — including inherited and group-derived ones.
Diff required against effective, applying role equivalence (see below).
Report every gap at once as principal → scope → role, with a remediation block a subscription owner can run as-is.
Fail fast on any gap. Nothing has been provisioned at this point, so there is no partial state to unwind.

Scopes

Scope	Resolved from	Notes
Subscription	`AZURE_SUBSCRIPTION_ID` / `--subscription`	Checked when no existing resource group is in play: the run creates the group.
Resource group	`AZURE_RESOURCE_GROUP` / `--resource-group`	When the group exists, its rows replace the subscription rows; subscription grants still count through inheritance. A named group that does not exist yet falls back to the subscription rows.
Foundry AI account	`AZURE_AI_ACCOUNT_ID` / `--ai-account`	Pass when the run creates model deployments or other account resources in an existing account.
Foundry project	`AZURE_AI_PROJECT_ID` / `--ai-project`	Pass for every run against an existing project, such as rapid prototyping.

Greenfield SDD runs create the resource group, account and project, so only the subscription rows apply. Brownfield runs check the concrete scopes as well, which is where per-resource grants diverge from subscription-level ones.

Role equivalence

Roles are matched by built-in role definition ID, not display name. The Azure AI roles were renamed (Azure AI User → Foundry User, Azure AI Project Manager → Foundry Project Manager, Azure AI Account Owner → Foundry Account Owner, Azure AI Owner → Foundry Owner) and the old names no longer resolve in az role assignment create. Legacy names are still accepted in --from-file input. Custom roles are not evaluated: confirm them manually and record the exception.

A requirement is satisfied by an equivalent-or-broader assignment, so a fully-permissioned caller produces no findings rather than a wall of false positives:

Requirement	Satisfied by
Deploy resources (subscription or existing resource group)	Contributor, Owner
Write role assignments (same scope)	Role Based Access Control Administrator, Owner, User Access Administrator
Foundry account control plane	Foundry Account Owner, Foundry Owner, Owner, Contributor, Cognitive Services Contributor
Foundry project: agents, skills, toolboxes, connections	Foundry Project Manager, Foundry Owner, or Foundry User (or Cognitive Services User) plus an account control-plane role

Assignments inherited from a broader scope also satisfy a narrower one: subscription Contributor satisfies the resource-group Contributor requirement.

Control plane and data plane are separate. Owner, Contributor, Foundry Account Owner and Cognitive Services Contributor grant Microsoft.CognitiveServices/* actions but no dataActions, so on their own they cannot create agents, skills or toolboxes. Foundry User grants the dataActions but no write actions, so on its own it cannot create project connections. A subscription Owner therefore still needs Foundry User on the project: the gap that surfaced separately, after the subscription and resource-group ones had already been fixed.

Running it

# Reference check — copy references/check_rbac_preflight.py from the foundry-agentic-loop skill into ./scripts/
# SDD (greenfield): subscription only
python ./scripts/check_rbac_preflight.py --subscription "$AZURE_SUBSCRIPTION_ID"
# Rapid prototyping (existing project): add the group and project, and the account if the run creates deployments
python ./scripts/check_rbac_preflight.py --subscription "$AZURE_SUBSCRIPTION_ID" \
  --resource-group "$RESOURCE_GROUP" --ai-project "$FOUNDRY_PROJECT"

Live mode shells out to the Azure CLI — az ad signed-in-user show to resolve the caller, az group exists for a named resource group, then az role assignment list --assignee <id> --scope <scope> --include-inherited --include-groups per scope. No extra Python dependencies, and az is already present in any azd-driven run. Pass --assignee to check a principal other than the signed-in user (a service principal or CI identity).

--from-file <observed.json> replays a recorded set of assignments (or raw az role assignment list output) instead of calling Azure; raw output names no principal, so pass --assignee with it. Malformed input is an ERROR, never a PASS. Both the pass and the fail path can be exercised without a subscription.

Verdicts

Verdict	Exit code	Meaning
`PASS`	`0`	Every required assignment is satisfied. One summary line is printed (`--quiet` prints nothing) — a fully-permissioned run adds no noise to the loop's output.
`BLOCKED`	`2`	One or more required assignments are missing. The full list is printed. Do not start provisioning.
`ERROR`	`1`	The check could not be evaluated (no caller identity, `az` unavailable, CLI failure). Resolve it rather than skipping the gate.

BLOCKED is not a repair loop — unlike the hosted integration checkpoint, the loop cannot grant itself permissions. The correct response is to hand the report to someone who can, then re-run the pre-flight.

Report contract

Print every missing assignment, not the first one — being handed the complete set in one go is the entire point:

RBAC pre-flight: BLOCKED -- 2 required role assignments are missing.

  principal: [email protected] (b3f1...c2a9)

  MISSING  [email protected] -> /subscriptions/<sub-id>/resourceGroups/rg-app
           grant:   Role Based Access Control Administrator (f58310d9-a9f6-439a-9e8d-f62e7b41a168)
           accepts: Role Based Access Control Administrator | Owner | User Access Administrator
           why:     Microsoft.Authorization/roleAssignments/write - create the runtime matrix rows in the resource group
  MISSING  [email protected] -> /subscriptions/<sub-id>/resourceGroups/rg-app/providers/Microsoft.CognitiveServices/accounts/aif-app/projects/proj
           grant:   Foundry User (53ca6127-db72-4b80-b1b0-d745d6d5456d)
           accepts: Foundry Project Manager | Foundry Owner | Foundry User (or Cognitive Services User) plus Foundry Account Owner, Owner, Contributor or Cognitive Services Contributor
           why:     Create and publish hosted agents, skills, toolboxes (data plane) and project connections (control plane)

Ask a subscription owner to run (role definition IDs are stable across renames):

  az role assignment create --assignee "b3f1...c2a9" --role "f58310d9-a9f6-439a-9e8d-f62e7b41a168" --scope "/subscriptions/<sub-id>/resourceGroups/rg-app"
  az role assignment create --assignee "b3f1...c2a9" --role "53ca6127-db72-4b80-b1b0-d745d6d5456d" --scope "/subscriptions/<sub-id>/resourceGroups/rg-app/providers/Microsoft.CognitiveServices/accounts/aif-app/projects/proj"

reference: skills/foundry-agentic-loop/references/rbac-contract.md#deployer-prerequisites-pre-flight
No resources have been created. Re-run this check once the assignments are in place.

Keep all four parts — the principal, one MISSING block per gap naming scope, smallest grant and accepted alternatives, the ready-to-run remediation, and the statement that nothing was created. The grant is the smallest role that completes the requirement given what the caller already holds (Foundry User for a caller who already has Contributor in the example). The remediation block is what turns the report into a single request to a subscription owner instead of a conversation.

Where it sits in the loop

Run it before provisioning, after the target subscription/scopes are known and before any azd provision, resource creation, or Bicep deployment. Optionally wire the same script as a preprovision hook in azure.yaml so a direct azd up is gated too.

Record the verdict in ./.azure/deployment-plan.md, in both modes, so a later failure can be told apart from a permission gap that was accepted and worked around.

Reuse

The step depends only on the caller identity and the scopes in play, and touches no mode-specific state — so both agentic loop modes inherit it without extra wiring.

Source

Requirements and compatibility

Written for: GitHub Copilot

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 an MCP server, Needs Python, Needs Node.js

Security

What our scanner noticed· Low risk

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

First committed by

vieiraae

Publisher

GitHub (Official)

Distributed by

GitHub

Source

github/awesome-copilot · skills/foundry-agentic-loop · commit 797337f

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

Contributors

vieiraae

AutoGineer is not affiliated with or endorsed by vieiraae or GitHub.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download foundry-agentic-loop.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by vieiraae

Foundry Agentic Loop

Bootstrap (once per session)

Choose the mode

Defaults

Workspace files

Working rules

Lessons

Files

references/rbac-preflight.md

RBAC pre-flight

What it checks

Scopes

Role equivalence

Running it

Verdicts

Report contract

Where it sits in the loop

Reuse

Source

Requirements and compatibility

Security

Attribution and licence

Related skills

Implement Spec

MCP Builder

Schema

Postgresql Table Design

SQL Optimization Patterns

API Scaffolding Fastapi Pro

Download ZIP