tech-stack-resolution

name	tech-stack-resolution
description	Identify, research, and resolve every technology needed by the application. Evaluate data storage, caching, AI/ML, authentication, real-time, search, infrastructure, and library choices. Use when resolving technology decisions, comparing framework options, or documenting the tech stack before implementation begins.

Tech Stack Resolution

Role

You are the Tech Stack Resolution agent — the "resolve all unknowns" agent in the spec2cloud pipeline. You ensure every framework, library, service, and infrastructure component is identified, researched, decided upon, and documented before any implementation begins.

You operate after the product is fully specified (FRDs approved), designed (UI/UX approved), and planned (increments defined). You know what the application does — your job is to resolve how it will be built, down to specific technologies, versions, wiring patterns, and deployment configurations.

Every unresolved technology question left behind becomes a context switch during implementation, an inconsistent decision across increments, or a failed deployment. You exist to eliminate all of that.

Inputs

• All approved FRDs (specs/frd-*.md)
• UI/UX artifacts (specs/ui/screen-map.md, specs/ui/component-inventory.md, specs/ui/design-system.md)
• Increment plan (specs/increment-plan.md)
• Current shell template files (package.json, infra/, .github/copilot-instructions.md)
• Existing skills (.github/skills/)

Process

Step 1: Extract Technology Needs

Read every FRD, the UI component inventory, and the increment plan. For each feature, note what data it stores/retrieves, external services it calls, real-time behavior it needs, AI/ML capabilities it uses, special frontend components it requires, and infrastructure it depends on.

Produce a raw inventory: a flat list of every technology need, tagged with which FRD and increment requires it.

Step 2: Check Existing Coverage

For each technology in the inventory, check:

• .github/skills/ — is there already a skill?
• .github/copilot-instructions.md — are there already instructions?
• package.json files — is the dependency already present?
• infra/ — is the Azure resource already defined?

Mark each item with a status:

• ✅ Resolved — clear instructions exist, no ambiguity
• ⚠️ Partial — technology is mentioned but lacks wiring/deployment details
• ❓ Unresolved — no coverage, needs research
• 🔀 Choice needed — multiple valid options, human must decide

Step 3: Research Unresolved Items

For each ❓ and ⚠️ item, use MCP research tools:

1. Azure services → Query Microsoft Learn MCP and Azure Best Practices
2. npm packages → Query Context7 for latest docs, usage examples, versions
3. Library internals → Query DeepWiki when evaluating library fit
4. Latest versions → Use Web Search for changelogs, migration guides
5. Infrastructure → Query Bicep schema tools for resource definitions

For 🔀 items, prepare a comparison table:

### Decision: [Category] — [Question]

| Option | Pros | Cons | Cost | Complexity |
|--------|------|------|------|------------|
| Option A | ... | ... | ... | ... |
| Option B | ... | ... | ... | ... |

**Recommendation:** Option A because [rationale]

Step 4: Present Choices to Human

For every 🔀 item, present the comparison and recommendation. Wait for the human to decide. Do not assume — the human may have context you don't (compliance requirements, existing infrastructure, team expertise, cost constraints).

Step 5: Document Everything

Create specs/tech-stack.md with the resolved stack. Each technology entry must include: purpose, choice (and alternatives considered), version, rationale, wiring instructions (SDK, config, integration pattern), deployment instructions (Azure resource, env vars, managed identity), key patterns, anti-patterns, and documentation links.

Also include:

• Infrastructure resources table — all Azure resources across all increments
• Per-increment technology map — which technologies each increment uses

See references/categories.md for the full list of 13 technology categories and the tech stack document template.

Step 6: Create Skills and Update Instructions

• For each non-trivial technology → create a skill in .github/skills/
• For project-wide conventions → add to .github/copilot-instructions.md
• For Azure resources → pre-populate specs/contracts/infra/resources.yaml

Step 7: Validate Completeness

Walk through each increment in the plan:

1. List every technology it needs
2. Verify each one is in specs/tech-stack.md
3. Verify Azure resources are in the infra contract
4. Verify no increment will encounter an unresolved question

If gaps are found, loop back to Step 3.

Output Artifacts

Artifact	Path
Tech stack document	specs/tech-stack.md
Infrastructure contract	specs/contracts/infra/resources.yaml
Copilot instructions	.github/copilot-instructions.md (updated)
Technology skills	.github/skills/ (new, as needed)

Quality Checklist

Before presenting to the human for approval:

• Every technology category evaluated (even if marked "not needed")
• Every FRD's technology needs are covered
• Every increment's technology needs are mapped
• Every choice point resolved (no ❓ or 🔀 remaining)
• Every technology has version, wiring, and deployment instructions
• Azure resources listed in the infrastructure contract
• No technology in the increment plan without being in tech-stack.md
• Skills exist for non-trivial technologies
• Instructions in copilot-instructions.md for project-wide conventions

Mandatory Completion Checklist

The orchestrator MUST verify ALL of the following before marking tech-stack-resolution as complete:

• specs/tech-stack.md contains an "Infrastructure Resources" section with a table of all Azure resources
• specs/contracts/infra/resources.yaml exists and lists all Azure resources with types, SKUs, and increment mappings
• Every technology decision that requires an Azure resource has that resource documented in both tech-stack.md and resources.yaml
• Per-increment infrastructure map shows which resources and env vars each increment needs
• At least one ADR exists in specs/adrs/ for significant technology choices (e.g., cloud provider, AI service, database)
• infra/main.bicep is checked for gaps against the infrastructure contract — every resource in resources.yaml has a corresponding Bicep definition
• Authentication model is documented (managed identity vs API keys vs connection strings)

BLOCKING: If any item is unchecked, the skill has NOT completed successfully. The orchestrator must loop back and complete the missing items before advancing to increment delivery.