PR #2190 Analysis: azure-bya vs Existing Skills — Integration Map Verdict: Hybrid — Keep BYA orchestrator + prereq as new skills, merge the rest into existing What BYA Genuinely Adds (Not Present Today) 1. Source Code Prereq Scanning (azure-bya-prereq) — NEW SKILL
Evaluates code readiness before any IaC work: build health, completeness, dependency compat
Read-only static analysis (explicitly forbids npm install/test)
PASS/WARN/FAIL verdicts with severity-tiered readiness gate
Cloud SDK swap detection (AWS/GCP → Azure SDK inline swaps)
Nothing in azure-prepare/validate/deploy does this today
2. Orchestrated Pipeline with Session State — NEW CAPABILITY
Resumable sessions via .copilot-azure/sessions/{id}/context.json
Phase lifecycle state machine (prereq → prepare → scaffold → deploy)
JSON artifact handoff between phases (prereq-output.json, prepare-plan.json, etc.)
Today's pipeline has no session persistence or resume capability
3. Two-Pass Intent Gathering — NEW CAPABILITY
Pass 1: Quick probe with workspace scan (≤6 questions)
Pass 2: Refine after prereq scan results inform the questions
Today's azure-prepare asks requirements once, linearly
4. Dual Approval Gates — ENHANCED
Scaffold gate (before IaC generation) separate from deploy gate
Today has only one implicit gate (plan approval before execution)
5. Adversarial Self-Review (4-Layer) — NEW CAPABILITY
L1: Security, L2: Pattern validation, L3: Hallucination detection (Bicep diagnostics), L4: WAF
Delegated to sub-agent with structured checklist
Today's azure-validate does recipe-based checks but not this adversarial model
6. Deploy Healing Loop with Taxonomy — ENHANCED
Structured error classification: IAC_ERROR, INFRA_TRANSIENT, ENVIRONMENT_BLOCKING
Healing trace with counter (ask user after 3 attempts, then every 5)
Audit logging (deploy-audit.log)
Orphan resource group tracking in handoff
Today's azure-deploy has error recovery per recipe but not this systematic approach
7. Integrated Cost Estimation — ENHANCED
Pricing API calls before deployment with approval gate display
Quota validation via az rest (pre-deploy, not post-failure)
Today this is partially in azure-prepare (deferred) and azure-cost (separate skill)
8. Health Check False-Positive Detection — ENHANCED
App Service default page detection (avoids marking placeholder as "healthy")
Per-service health signal patterns
Today's verify step is simpler HTTP check
What's Duplicated (Same Function, Different Implementation)
BYA Component
Existing Equivalent
Duplication Level
prepare/service-mapping.md
azure-prepare/architecture.md
~80% same
prepare/sku-matrix.md
azure-prepare/requirements.md
~70% same
prepare/naming-patterns.md
azure-prepare/generate.md
~60% same
scaffold/bicep-patterns.md
azure-prepare/services/* (Bicep refs)
~90% same
scaffold/terraform-patterns.md
azure-prepare/recipe-selection.md
~70% same
scaffold/bicep-app-service.md
azure-prepare/services/app-service/*
~85% same
scaffold/bicep-container-apps.md
azure-prepare/services/container-apps/*
~85% same
deploy/preflight-checks.md
azure-deploy/pre-deploy-checklist.md
~75% same
deploy/code-deployment-*.md
azure-deploy/recipes/*
~70% same
deploy/deploy-safety.md
azure-deploy/global-rules.md
~50% overlap
Keep as Separate Skills (2):
azure-byaazure-bya-prereq
Merge into Existing Skills (3 sub-skills → 3 existing): azure-bya/prepare → merge into azure-prepare
Add: pricing API integration, quota pre-validation via az rest, SKU-aware region selection
Add: two-pass intent gathering pattern
Keep: existing plan-template.md artifact format (.azure/deployment-plan.md)
Drop: duplicate service-mapping, naming, architecture references
azure-bya/scaffold → merge into azure-prepare Phase 2
Add: adversarial self-review (L1-L4) as new Phase 2 step before handoff to azure-validate
Add: self-healing validation loop (max 3 attempts)
Keep: existing IaC generation references (services/*)
Drop: duplicate bicep-patterns, terraform-patterns, bicep-app-service, bicep-container-apps
azure-bya/deploy → merge into azure-deploy
Add: error classification taxonomy (IAC_ERROR, INFRA_TRANSIENT, ENVIRONMENT_BLOCKING)
Add: healing loop with counter + user checkpoints
Add: deploy-audit.log
Add: health check false-positive detection
Add: orphan RG tracking in handoff
Keep: existing recipe-based execution
Drop: duplicate preflight checks, code-deployment references
CURRENT PROPOSED (POST-MERGE)
─────── ─────────────────────
┌─────────────────────┐
│ azure-bya │ ← NEW orchestrator
│ (idea-to-production) │
└──────┬───────────────┘
│
┌──────▼───────────────┐
│ azure-bya-prereq │ ← NEW skill
│ (source code eval) │
└──────┬───────────────┘
│
┌──────────────┐ ┌──────▼───────────────┐
│azure-prepare │ ──────────► │ azure-prepare │
│ │ │ + pricing/quota │
│ │ │ + two-pass intent │
│ │ │ + self-review (L1-L4) │
└──────┬───────┘ └──────┬───────────────┘
│ │
┌──────▼───────┐ ┌──────▼───────────────┐
│azure-validate│ ──────────► │ azure-validate │
│ │ │ (unchanged) │
└──────┬───────┘ └──────┬───────────────┘
│ │
┌──────▼───────┐ ┌──────▼───────────────┐
│azure-deploy │ ──────────► │ azure-deploy │
│ │ │ + error taxonomy │
│ │ │ + healing loop │
│ │ │ + audit log │
│ │ │ + health FP detection │
└──────────────┘ └──────────────────────┘
Routing Rules (Post-Merge)
User Intent
Routes To
"I have an idea, build it" / "what services do I need"
azure-bya → prereq → azure-prepare → validate → deploy
"deploy my existing app" / "create Bicep"
azure-prepare → azure-validate → azure-deploy (unchanged)
"is my code ready for Azure"
azure-bya-prereq (standalone)
"run azd up" / "ship it"
azure-deploy (unchanged)
"validate my infra"
azure-validate (unchanged)
Risk if Kept Fully Separate
~60-70% reference file duplication = maintenance nightmare (Bicep patterns, service mappings, etc.)
Divergent IaC guidance between BYA scaffold and azure-prepare services/* references
Users get different quality depending on which path they hit
Token budget blow-up from duplicated skill descriptions in the plugin manifest
Three-PR Comparison: #2190 (azure-bya) vs #1992 (azure-project-plan) vs #2163 (azure-local)
PR
Skill(s)
Purpose
Target Scenario
#2190 azure-bya + azure-bya-prereq
End-to-end orchestrator: idea → prereq → plan → scaffold → deploy
Cloud-native apps on App Service, Container Apps, Functions, SWA
#1992 azure-project-plan
Pre-code project planning: gather requirements → write .azure/project-plan.md → hand off to scaffold
New projects that don't exist yet
#2163 azure-local
Azure Local / Azure Stack HCI planning, deployment, operations, troubleshooting
On-premises hybrid infrastructure (Azure Local, Arc, HCI)
Capability
azure-prepare (existing)
azure-bya (#2190)
azure-project-plan (#1992)
azure-local (#2163)
Requirements gathering Phase 1 Steps 1-3
Two-pass intent gathering
Full requirements collection via askQuestions
Intake questions (topology, connectivity, identity)
Architecture/service mapping Phase 1 Step 5
prepare sub-skill service-mapping.md
Architecture decisions in plan template
N/A (hardware-based, not service selection)
IaC generation Phase 2 Step 3 (Bicep/TF)
scaffold sub-skill (Bicep/TF)
❌ No — hands off to scaffold
❌ No — references ARM templates/portal
Validation Hands off to azure-validate
Built-in L1-L4 self-review
❌ No
Checkpoint only
Deployment execution Hands off to azure-deploy
deploy sub-skill (az deployment)
❌ No
Guides deployment choices, no execution
Cost estimation ❌ Deferred
✅ Pricing API + quota pre-check
❌ No
❌ No
Source code readiness ❌ No
✅ azure-bya-prereq
❌ No
❌ No
Session persistence ❌ No (.azure/deployment-plan.md only)
✅ .copilot-azure/sessions/ + JSON
❌ No (.azure/project-plan.md only)
❌ No
Plan artifact .azure/deployment-plan.mdprepare-plan.json.azure/project-plan.mdNone (doc-guided)
Where They Overlap Each Other #2190 (BYA) vs #1992 (project-plan) HIGH overlap in intent gathering and planning.
Both collect requirements before any code/IaC exists
Both target "I have an idea, help me build it" scenarios
BYA does this as Step 2+4 (intent gathering), project-plan does this as its entire purpose
Key difference: project-plan stops at the plan and hands off to a scaffold skill; BYA goes all the way to deploymentRecommendation: project-plan is essentially BYA Steps 1-6 minus the prereq scan. If BYA lands, project-plan is redundant for cloud-native scenarios
#2190 (BYA) vs #2163 (azure-local) LOW overlap. Completely different target:
BYA targets cloud PaaS (App Service, Container Apps, Functions, SWA)
azure-local targets on-premises hybrid infrastructure (Azure Stack HCI, Arc VMs, SDN)
azure-local doesn't generate IaC or execute deployments — it guides users to docs
No routing conflict — trigger phrases are entirely distinct
Recommendation: azure-local is independent and can coexist cleanly
#1992 (project-plan) vs #2163 (azure-local) NO overlap. Completely different scope:
project-plan is for greenfield cloud app design
azure-local is for on-premises HCI infrastructure
All Three vs Existing (azure-prepare/validate/deploy)
Existing Skill
#2190 BYA
#1992 project-plan
#2163 azure-local
azure-prepare 70-80% functional overlap
40% overlap (planning only)
~5% (different domain)
azure-validate 50% overlap (built-in self-review)
No overlap
No overlap
azure-deploy 70% overlap (deploy sub-skill)
No overlap
No overlap
PR #2163 (azure-local) — ✅ CLEAN NEW SKILL
No merge needed. Entirely different domain (on-prem HCI vs cloud PaaS)No trigger conflicts with existing skills
Self-contained with its own workflow docs, safety rules, resource types
Ship independently. No concerns.
PR #1992 (azure-project-plan) — ⚠️ LIKELY REDUNDANT IF BYA LANDS
If BYA (#2190) ships, project-plan is a subset of BYA Steps 1-6
If BYA does NOT ship, project-plan fills a real gap: pre-code planning that azure-prepare doesn't do well today
The artifact formats differ (.azure/project-plan.md vs BYA's prepare-plan.json) but the content is the same: architecture decisions, service selection, constraints
Recommendation:
If BYA ships → close project-plan or fold its requirement-gathering into BYA's intent-gathering
If BYA doesn't ship → project-plan is valuable as a lightweight front-end to azure-prepare
PR #2190 (azure-bya) — ⚠️ MOST VALUE BUT MOST DUPLICATION
Brings genuinely new capabilities (prereq scanning, cost estimation, self-review, healing loops)
But reimplements ~70% of azure-prepare and azure-deploy as parallel sub-skills
Recommendation (unchanged from prior analysis):
Keep azure-bya orchestrator + azure-bya-prereq as new skills
Merge BYA's novel enhancements into existing azure-prepare and azure-deploy
Have BYA orchestrator call existing skills instead of parallel sub-skills
Proposed Unified Architecture (All Three PRs) ┌──────────────────────┐
│ azure-project-plan │ (only if BYA doesn't ship)
│ "I have an idea" │
└──────┬───────────────┘
│ (writes .azure/project-plan.md)
▼
┌────────────────┐ ┌──────────────────────┐
│ azure-bya │──────────────►│ azure-bya-prereq │
│ (orchestrator) │ │ (source code eval) │
│ "idea to prod" │ └──────┬───────────────┘
└──────┬─────────┘ │
│ ▼
│ ┌──────────────────────┐
└────────────────────────►│ azure-prepare │ ← enhanced with:
│ │ + pricing/quota
│ │ + self-review L1-L4
│ │ + two-pass intent
└──────┬───────────────┘
│
┌──────▼───────────────┐
│ azure-validate │ (unchanged)
└──────┬───────────────┘
│
┌──────▼───────────────┐
│ azure-deploy │ ← enhanced with:
│ │ + error taxonomy
│ │ + healing loop
│ │ + audit log
└──────────────────────┘
┌──────────────────┐
│ azure-local │ ← independent, no overlap
│ (on-prem HCI) │
└──────────────────┘
