Azure App Onboard Prereq
MicrosoftOfficialCreated by Microsoft
- Skill
- Review and audit
- Software development
- MIT
- Low risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
The azure-app-onboard-prereq skill performs a comprehensive, read-only assessment of a repository to determine if it is prepared for deployment to Azure. It operates as the initial phase of the Azure onboarding pipeline, identifying potential blockers such as unsupported frameworks, incompatible dependencies, or missing configurations. By performing static analysis rather than executing build or test commands, it ensures a safe evaluation of the codebase. The skill generates a structured readiness report and identifies necessary remediations, ensuring that only viable applications proceed to the infrastructure planning and deployment stages.
What it does
- Scans repositories to detect project components, language stacks, and infrastructure requirements.
- Performs static analysis of build manifests to identify missing dependencies or configuration errors.
- Checks for compatibility with Azure services and identifies non-Azure cloud SDKs that require migration.
- Generates a readiness report with per-component verdicts (PASS/WARN/FAIL).
- Validates the presence of necessary configuration files for deployment.
- Enforces a strict read-only policy, prohibiting build, install, or test command execution.
When to use it
- Before starting infrastructure planning or deployment for an existing application.
- When you need to verify if your current codebase is compatible with Azure.
- To identify specific blockers or missing dependencies preventing a successful deployment.
- When you want to assess the health of your build configuration without running the build process.
Advantages
- Ensures deployment readiness without executing potentially unsafe build or test commands.
- Provides clear, actionable feedback on what needs to be fixed before proceeding.
- Integrates seamlessly into the broader Azure onboarding pipeline.
- Reduces deployment failures by catching configuration and dependency issues early.
Usage examples
- “Is my app ready to deploy to Azure?”
- The agent scans the repository, evaluates the build configuration and dependencies, and provides a readiness report with specific findings or blockers.
- “What is blocking my deployment to Azure?”
- The agent identifies missing dependencies, incompatible frameworks, or non-Azure cloud SDKs that must be addressed before deployment can proceed.
- “Scan my repo for Azure deployment issues.”
- The agent performs a static analysis of the codebase and reports on build health, completeness, and any required configuration changes.
- “Are my dependencies compatible with Azure?”
- The agent checks the project manifest against known Azure requirements and flags any problematic or unsupported packages.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/microsoft/azure-app-onboard-prereq/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip azure-app-onboard-prereq.zip -d .agents/skills
Documentation by Microsoft
Azure App Onboard Prereq — Repository Evaluation
Evaluate a user's repository for build health, app completeness, and Azure deployment feasibility — before infrastructure planning. Produces per-component verdicts (PASS/WARN/FAIL) consumed by downstream phases.
Orchestrator relationship: Called by
azure-app-onboardat Step 3, or standalone for code readiness checks. When called by orchestrator, return control toazure-app-onboardafter writing artifacts — do NOT invoke downstream phases directly.
Phase 1 of 4 in AppOnboard pipeline. Session: .copilot-azure/sessions/{session-id}/. Reads context.json. Writes components[], repo{}, detectedInfra[]. Produces prereq-output.json. Schema: prereq-schemas.ts — PrereqOutput, BuildRequirements. Direct entry supported.
When NOT to Use
| Signal | Redirect |
|---|---|
| Validate infrastructure (Bicep/TF/azure.yaml) | azure-validate |
| Generate IaC | azure-prepare |
| End-to-end idea-to-production | azure-app-onboard |
Run azd up or deploy | azure-deploy |
Rules
⛔ ABSOLUTE PROHIBITION —
npm install,npm test,npx jest,pytest, and ALL install/build/test commands are NEVER allowed. Under NO circumstances may you runnpm install,npm test,npx jest,pip install,pytest,dotnet build,dotnet restore,dotnet test,go mod download,cargo build, or ANY package-manager install, build, or test command during the prereq phase. Do NOT run test suites to verify code — check for test config files statically instead. The prereq phase is read-only evaluation + static-only verification. ONLY exception — two sanctioned contexts, both consent-gated: (a) code the agent modified during migration/remediation (see remediation-protocol.md step 6), or (b) code the agent wrote from scratch on the zero-code path (see zero-code-path.md). In either case, install/build/test runs ONLY via the user-confirmed build-validation gate (build-check.md Step 3), after the user answers that specific per-command consent prompt. General prior consent never counts.
⛔ Full pipeline (Steps 1–8), no exceptions. All prompts → Step 1 directly. Answer specific questions AS PART OF findings (Step 5), not before.
⛔ No sub-agents for evaluation. 3-axis evaluation is inline. Exception: zero-code-path scaffolding (Step 2).
Code/destructive modifications require
ask_user. Max 3 questions before results. Direct entry: don't repeat orchestrator's intent questions.
MCP Tools
| Tool | Purpose |
|---|---|
mcp_azure_mcp_get_azure_bestpractices | Validate detected stack patterns against Azure best practices |
mcp_azure_mcp_extension_cli_install | Check/install required CLI tools (az, azd, func) |
Workflow
Step 1: Session Check
Orchestrator entry: Session exists — read context.json, proceed to Step 2.
Direct entry: Check .copilot-azure/sessions/active-session.json:
Exists → ⛔ read session-protocol.md for resume/fresh gate. Do NOT proceed until user answers.
Missing → create session: generate UUID,
New-Item -ItemType Directory -Path ".copilot-azure/sessions/{uuid}" -Force, writecontext.json+active-session.jsonviacreatetool.
Then: az account show → merge {id, name, tenantId} into context.json.azure. ⛔ Session MUST exist on disk before any scanning.
Step 2: Scan Workspace
Scan for project files. Detect components, repo{}, detectedInfra[], detectedServices[]. Classify Terraform providers. Check CLI availability. Stack detection conflicts: user explicit statement wins (write to context.json, mark scan as override); scan-only → confirm with user; multiple stacks → show all and ask (see component-mapping.md); no code → zero-code-path.md.
If no project files, no Dockerfile, AND no index.html → ⛔ read zero-code-path.md.
⛔ Cloud SDK early gate. Grep for
aws-sdk|@aws-sdk|boto3|google-cloud|@google-cloud|firebase. If functional deps found → read cloud-sdk-migration.md, thenask_user: "Redirect to Azure Cloud Migrate" (setrouteToSkill: "azure-cloud-migrate") · "Continue evaluation anyway" (finish readiness eval + SDK→Azure mapping, then STOP at Step 8 — no plan until the deps are swapped) · "Cancel".
Step 3: Per-Component Evaluation
| Sub-step | Action | Reference |
|---|---|---|
| 3.1 | Build check | ⛔ You MUST read build-check.md |
| 3.2 | Completeness check | ⛔ You MUST read completeness-check.md |
| 3.3 | Deployability check | ⛔ You MUST read deployability-check.md |
| 3.3a | Component mapping (conditional) | Read component-mapping.md ONLY IF >1 project manifest found (monorepo) |
Populate buildRequirements per component after evaluation. Verdict propagation, tier rules, and f1Viable aggregation are in readiness-gate.md and the individual check references.
Step 4: Write Artifacts + Readiness Gate
⛔ Verify context.json exists on disk. ⛔ You MUST read readiness-gate.md (verdicts, tiers, batch-then-approve, fast-track), then ⛔ You MUST read prereq-artifacts.md (write procedures, schemas).
Step 5: Present Findings
Per readiness-gate.md § Present Findings — show verdicts grouped by severity before proceeding.
Step 6: Remediation (conditional)
⛔ You MUST read remediation-protocol.md IF any ❌ FAIL verdict, 🔧 Recommended Fix, or ⚠️ WARN with fixPhase: "prereq" exists. Contains remediation loop, static verification, re-eval mandate, post-remediation artifact updates, and the build-validation consent gate. If all verdicts are ✅ PASS or ⚠️ WARN without fixPhase: "prereq", skip to Step 7.
Step 7: Write Final State
completedPhases already has "prereq" + currentPhase: null (from Step 4). Then:
⛔ Write
lastScanCommit. Rungit rev-parse HEADand store the full 40-character SHA ascontext.json.repo.lastScanCommit. Required — staleness guard in Step 1 compares to HEAD on resume to detect changes.
Step 8: Route
⛔ Mandatory — do NOT skip this step.
Routing fields: All routing writes
routeToSkillandrouteReasontocontext.json.
Post-remediation context: If Step 6 ran, lead the routing prompt with: "Remediation complete — {N} issues fixed, your app is now {overallHealth}."
⛔ Evaluate rows top to bottom — first match wins.
| # | Condition | Action |
|---|---|---|
| 1 | routeToSkill set (any entry) | ask_user: "Redirect to {routeToSkill}" / "Not now". ⛔ Pipeline stops — do NOT proceed to architecture planning. |
| 2 | cloudSdkFindings[] non-empty (user chose "Continue evaluation anyway") | Present the cloud-SDK → Azure swap mapping as 🔶 blockers, then ask_user with this exact prompt: "🔶 Cloud SDK migration required — these dependencies must be swapped before this app can deploy to Azure. (Redirect to azure-cloud-migrate / Stop — swap manually and re-run)" — Redirect sets routeToSkill: "azure-cloud-migrate", Stop halts. ⛔ Pipeline stops — do NOT proceed to architecture planning, and do NOT offer a "continue to prepare" option; the app can't deploy until the deps are swapped. |
| 3 | Orchestrator + no routeToSkill | Tell the user: "✅ Your app has been evaluated and is ready — let's plan your Azure deployment." Then invoke azure-app-onboard. ⛔ Do NOT stop, do NOT wait for user input, do NOT narrate internal handoffs. The user already consented to the full pipeline at scope triage. |
| 4 | Direct + ready/readyWithCaveats + no Azure infra | ask_user: "Deploy to Azure (full pipeline)" → invoke azure-app-onboard / "Not now" |
| 5 | Direct + ready/readyWithCaveats + existing Azure infra | ask_user: "Start fresh" → invoke azure-app-onboard / "Use existing infra" → invoke azure-prepare / "Not now" |
| 6 | Direct + blocked | Report blocker summary + "Fix and re-run." |
Severity tiers (🛑🔶❌🔧⚠️✅) are defined in readiness-gate.md.
Outputs
| Artifact | Location | Consumer |
|---|---|---|
| Session context | context.json → components[], repo{}, detectedInfra[], detectedServices[] | All downstream phases |
| Prereq output | prereq-output.json | prepare phase (via azure-app-onboard) |
| Readiness report | .copilot-azure/sessions/{uuid}/readiness-report.md | User (offline reference) |
Files
- ATTRIBUTION.mdAdded by AutoGineer1004 B
- LICENSELicence file added by AutoGineer1.1 KiB
- SKILL.md10.0 KiB
- references/build-check.md5.7 KiB
- references/cloud-sdk-migration.md2.2 KiB
- references/completeness-check.md4.4 KiB
- references/component-mapping.md4.6 KiB
- references/dependency-compatibility.md10.0 KiB
- references/deployability-check.md3.1 KiB
- references/prereq-artifacts.md2.3 KiB
- references/prereq-schemas.tsScript4.2 KiB
- references/readiness-gate.md5.4 KiB
- references/remediation-protocol.md3.6 KiB
- references/session-protocol.md7.4 KiB
- references/session-schemas.tsScript5.2 KiB
- references/subagent-starter-scaffold.md4.0 KiB
- references/subscription-resolution.md1.8 KiB
- references/zero-code-path.md3.6 KiB
references/session-protocol.md
Session Protocol — Step 1
All Prompts Are Actionable
⛔ ALL prompts that activate this skill are actionable — go directly to Step 1. Do NOT answer the user's question, give an overview of capabilities, or describe what AppOnboard can do before starting the pipeline. "Can Azure figure out my app?" and "Deploy my app" are the same action: Step 1 → Step 2 → scan. The user's phrasing (question vs command) does NOT change the workflow.
Session Check
Resolve active session via pointer file.
⛔ YOU MUST CREATE A SESSION BEFORE DOING ANY WORK — INCLUDING SCANNING
STOP — Do not answer the user's question, scan code, or plan architecture yet
CHECK — Read
.copilot-azure/sessions/active-session.json.
Pointer exists →
⛔ Read
session-schemas.tsto get the exact field names and types forAppOnboardContext,PrereqOutput, andPreparePlan. Do not guess field names. Then read the pointed-to session'scontext.json. Display: "Found session from [lastModifiedUtc] — {statusSummary}."⛔ MANDATORY
ask_userGATE — execute this step NOW, before ANY branching. Callask_user: "Resume this session or start fresh?" Do NOT auto-resume, do NOT skip ahead to the staleness check, do NOT present cached findings. Nothing else happens until the user answers. WHY: stale sessions from prior test runs cause the agent to silently reuse outdated results and skip PHASE.md reads. The staleness check alone cannot catch this — only the user knows whether the prior session is still relevant.Branch on user's answer (only after
ask_userreturns):
Resume → Staleness check (prereq skill only): If
completedPhasesincludes"prereq", rungit rev-parse HEADand compare tocontext.json.repo.lastScanCommit. If the commit is different ORlastScanCommitis missing → tell the user: "Repo has changed since last scan — re-running prereq." Proceed to SKILL.md Step 2 (skip session creation). If identical → present cached findings fromprereq-output.jsonand go to SKILL.md Step 8 (Route). Then ⛔ Read the PHASE.md for the NEXT phase (derive fromcompletedPhases). E.g., prereq done → readprepare/PHASE.md. Then continue from that phase.Start fresh → generate a new UUID via
[guid]::NewGuid().ToString(), create a new session folder, updateactive-session.jsonto point to the new session. Old session folder is never touched again.Pointer missing but session folders exist → list folders under
.copilot-azure/sessions/. If 1 folder: adopt it (read itscontext.json, writeactive-session.jsonpointing to it, show summary). If 2+: show a numbered list withstatusSummary+lastModifiedUtcfrom each, ask user to pick one or start fresh. Write pointer for the chosen session.No sessions at all → generate a UUID by running
[guid]::NewGuid().ToString()in the terminal. ⛔ You MUST generate the UUID via a terminal command — do NOT hardcode a placeholder likea1b2c3d4-e5f6-7890-abcd-ef1234567890. Create the session directory:New-Item -ItemType Directory -Path ".copilot-azure/sessions/{uuid}" -Force. Then write a minimalcontext.jsonusing thecreatetool — only these 3 fields are known immediately:{ "sessionId": "{uuid}", "createdUtc": "{ISO 8601 now}", "intent": { "userPrompt": "{user's first message verbatim}" } }. Writeactive-session.jsonwithactiveSessionId: {uuid}using thecreatetool.PRUNE — After resolving the active session, check remaining session folders. Delete any where
context.json.lastModifiedUtcis >7 days ago. Never delete the active session (the oneactive-session.jsonpoints to).VERIFY — Confirm
context.jsonexists and is valid JSON. If missing or malformed, halt and retry creation — do NOT continue to Step 2 without a verified session.CONFIRM — Begin your first response with: "Started session at
.copilot-azure/sessions/{uuid}/" (new) or "Resuming session from [date] — {statusSummary}" (existing)THEN proceed to Step 2
⛔ Ordering: session FIRST, scanning SECOND. If you scan the workspace or read project files before writing
context.json, you have violated the session-first rule. The session must exist before ANY code analysis.⛔ Shell fallback: If PowerShell/terminal hangs on first attempt (no output after 10s), use the
createtool directly for session directory and file writes. Do NOT retry shell commands more than once.⛔ Path scoping: ALL
createtool calls for session artifacts MUST target.copilot-azure/sessions/{active-session-id}/. Writing to any other session folder is forbidden.
CLI Availability
Call mcp_azure_mcp_extension_cli_install with cli-type: "az" to verify Azure CLI is available. If missing, surface installation instructions before proceeding. Downstream phases (prepare, deploy) require it. Fallback: skip if MCP tool unavailable.
Azure Login Gate
Azure login gate (mandatory): Run az account show --query "{id:id, name:name, tenantId:tenantId}" -o json with a 5-second timeout (PowerShell: Start-Process with -Wait or inline timeout; if command hangs beyond 5s, treat as failure). If it succeeds, merge subscriptionId, subscriptionName, tenantId into context.json.azure (use replace_string_in_file or rewrite the file — the minimal context.json from Step 1 sub-step 2 may not have the azure key yet).
⛔ If
az account showfails or hangs: ⛔ You MUST readsubscription-resolution.mdand follow its fallback procedure. Do NOT proceed to Step 2 without a resolved subscription. Do NOT leavecontext.json.azureempty and continue. Every downstream phase (prepare, scaffold validation, deploy) requires Azure auth — proceeding without it produces incomplete results.
User Identity Detection
User identity detection (for deployed-by tag): If az account show succeeded, also run az ad signed-in-user show --query displayName -o tsv (5-second timeout). Write the result to context.json.azure.userDisplayName. Fallback if az ad fails: use az account show --query user.name -o tsv (returns UPN/email). If both fail, leave empty — prepare phase will resolve. This value becomes the deployed-by tag on ALL resources — resolving it once here prevents inconsistent tag values across resources.
Subscription Detection Method
⛔
az account showis the ONLY subscription detection method in Step 1. Do NOT callmcp_azure_mcp_subscription_listhere — that tool returns ALL subscriptions across ALL tenants and causes a lengthy picker detour.az account showreturns the CLI's active subscription in <1 second. MCP subscription list is reserved for prepare Step 1 when the user explicitly wants a different subscription.
Artifact Locations
| Location | Artifacts |
|---|---|
.copilot-azure/sessions/{uuid}/ | context.json, prereq-output.json, prepare-plan.json, scaffold-manifest.json, deploy-result.json |
Phase-gated Reference Loading
⛔ Phase-gated reference loading. Do NOT pre-read reference files for downstream phases. Read each sub-skill's references only when entering that step. Scaffold references are irrelevant during deploy; prepare references are irrelevant during scaffold. Each sub-skill PHASE.md specifies its own required reads.
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, 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
- Created by
- Microsoft
- Publisher
- Microsoft (Official)
- Source
- microsoft/skills · .github/plugins/azure-skills/skills/azure-app-onboard-prereq · commit 0696600
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from .github/plugins/azure-skills/LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Also distributed in
- microsoft/azure-skills
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 azure-app-onboard-prereq.zip