Generated banner for Teams App Developer
Generated logo for Teams App Developer

Teams App Developer

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Tool integration
  • Software development
  • MIT
  • Medium risk

From the author

Builds, tests, and deploys Microsoft 365 apps and agents for Teams and Copilot. Includes sub-skills for project creation, local testing, cloud deployment, troubleshooting, and Slack-to-Teams migration. USE FOR: Teams agent, bot, tab, message extension, Declarative Agents, Custom Engine Agents, local testing, Agents Playground, Azure resource provision, remote deployment, Slack to Teams migration, cross-platform bot development, Block Kit to Adaptive Cards conversion. DO NOT USE FOR: general web development, non-bot/non-Teams projects.
— the description by Microsoft

AutoGineer summary

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

The teams-app-developer skill provides a structured framework for managing the lifecycle of Microsoft 365 agents and Teams applications. It leverages the ATK CLI to handle project scaffolding, local testing via the Agents Playground, cloud provisioning on Azure, and troubleshooting. The skill includes specialized guidance for migrating Slack bots to Teams, including converting Block Kit UI to Adaptive Cards, and provides access to an extensive library of micro-expert documentation for cross-platform development.

What it does

  • Scaffolds new Microsoft 365 agents and Teams applications from templates.
  • Facilitates local testing using the Agents Playground or Teams-specific environments.
  • Automates Azure resource provisioning and cloud deployment workflows.
  • Provides diagnostic procedures for common authentication and configuration errors.
  • Supports migration of Slack bots to the Teams platform.
  • Manages project configuration and environment variables for ATK-based projects.

When to use it

  • When starting a new Teams app, bot, or Declarative Agent project.
  • When you need to test an agent locally before deploying to the cloud.
  • When migrating existing Slack bots to the Microsoft Teams ecosystem.
  • When troubleshooting deployment or authentication issues in a Teams project.
  • When you need to provision Azure infrastructure for a Teams application.

Advantages

  • Streamlines the development lifecycle with standardized CLI commands.
  • Reduces development time by offering a local testing playground.
  • Provides expert-level guidance for complex cross-platform migrations.
  • Ensures consistent configuration management across development environments.
  • Includes robust error-handling protocols for common platform-specific pitfalls.

Usage examples

“Create a new Teams bot project using the default template.”
The agent will initialize a new project folder, configure the necessary YAML files, and guide you through the initial setup using the ATK CLI.
“How do I migrate my Slack bot to Microsoft Teams?”
The agent will initiate the slack-to-teams workflow, providing access to cross-platform bridging experts and guidance on converting UI components.
“My Teams bot is returning a 401 error, how do I fix it?”
The agent will trigger the troubleshooting workflow, checking your environment variables, tunnel status, and authentication configuration.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/microsoft/teams-app-developer/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip teams-app-developer.zip -d .agents/skills

Documentation by Microsoft

Microsoft 365 Agents Toolkit Skill

Build Microsoft 365 agents and Teams apps using the ATK CLI.

AI Behavior Guidelines

  1. Testing Strategy: Recommend Agents Playground first (faster, no M365 needed). Use Teams workflow only if user explicitly requests it.

  2. Environment Variables: NEVER hardcode secrets or make up placeholder values. Always ask users for real values.

  3. Error Handling: Read error messages carefully. Check env/.env.local, .localConfigs, and atk auth list. Common pitfalls:

    • AADSTS7000229 → aadApp/create missing generateServicePrincipal: true in YAML — add it and re-provision

    • Missing TENANT_ID in .localConfigs → SDK uses wrong token authority → 401 from Bot Connector

    • 401 persists after auth fix → devtunnel URL may be blacklisted — create a fresh tunnel

    • See troubleshoot/troubleshoot.md for full diagnostic steps

  4. Long-Running Commands — WAIT for completion:

    • atk new, atk provision, atk deploy can take several minutes

    • Always wait for completion before running the next step (timeout 120000ms+)

  5. Local Service Startup — Hangs terminal (expected):

    • npm run dev, npm start, python app.py, devtunnel host, etc. will hang — the process keeps running indefinitely

    • ALWAYS run as a background process (isBackground=true) — NEVER use isBackground=false for these commands

    • Do NOT wait for it to "finish" — verify startup by checking output for "listening on port" or tunnel URL

    • If errors appear, read logs, diagnose, fix, restart

    • Use a NEW terminal to launch Agents Playground or open Teams sideloading URL

  6. Monitor App Logs: Periodically check background terminal output for runtime errors. If the app crashes, read the error, fix the root cause, and restart.

  7. Telemetry Tagging: Before running any atk CLI commands, set the session environment variable so all CLI invocations are tagged as skill-initiated:

    export ATK_CLI_SKILL=true

    Run this once at the start of the session. All subsequent atk commands in the same terminal will inherit it.

ATK CLI Setup

atk --version  # Must be > 1.1.5-beta

If ATK is not found or version is too old:

npm i -g @microsoft/m365agentstoolkit-cli@beta

CLI Global Options

OptionMeaningRecommendation
-iInteractive modeAlways use -i false in automation to avoid hanging
-fProject folderDefault to be current directory, used when specifying a custom folder. When scaffolding a new project, this is the parent folder where the project folder will be created under.
-hCommand helpUse atk <command> -h for quick syntax checks

Sub-Skills

Sub-SkillWhen to UseReference
create-projectScaffold new project from template, choose template, atk newcreate-project/create-project.md
test-playgroundTest locally with Agents Playground, agentsplayground, quick testingtest-playground/test-playground.md
test-teamsRun on Teams, devtunnel, sideload, Teams testing, test in Copilottest-teams/test-teams.md
provision-deployProvision Azure resources, deploy to cloud, atk provision, atk deployprovision-deploy/provision-deploy.md
troubleshootFix errors, 401, port conflicts, YAML errors, stale botstroubleshoot/troubleshoot.md
slack-to-teamsMigrate Slack bot to Teams, cross-platform bridging, Block Kit to Adaptive Cardsslack-to-teams/SKILL.md

MANDATORY: Before executing any workflow, read the corresponding sub-skill document.

Shared References

  • manifest-and-yaml.md — Project files, YAML config, env vars, .localConfigs flow

  • commands.md — ATK CLI commands: package, validate, share, collaborate

  • templates.md — Complete template catalog with language support

  • experts/ — 100+ micro-expert files: Teams SDK, Slack SDK, cross-platform bridging, deploy, AI models, security, language conversion

  • docs/ — Platform comparison guides: UI, messaging, identity, infrastructure, feature gaps

Workflow Chains

Match user intent to the smallest valid workflow.

User IntentWorkflow (read in order)
Build new app from scratchcreate-project → test-playground
Test existing project locallytest-playground (recommended) or test-teams
Deploy to Azureprovision-deploy
Fix broken bottroubleshoot → re-test
Migrate Slack bot to Teamsslack-to-teams

MANDATORY: Before executing any slack-to-teams workflow, read slack-to-teams/SKILL.md first. The sub-skill contains a routed expert system with 100+ micro-expert files for cross-platform bot development.

ATK Project Context Resolution

Resolve config values only when missing. If a value is already known in the session, reuse it.

Step 1: Detect ATK Project

If m365agentstoolkit*.yml exists in the current folder, treat it as an ATK project and parse configuration.

Step 2: Resolve Common Configuration

Resolve variables referenced in m365agentstoolkit*.yml. Common variables: AZURE_OPENAI_API_KEY AZURE_OPENAI_ENDPOINT AZURE_OPENAI_DEPLOYMENT_NAME

Step 3: Collect Missing Values

If required values are missing, ask the user for only the missing ones.

Refer to manifest-and-yaml.md for full config-file details.

Files

experts/update-experts.md

update-experts

purpose

Scan the .experts/ directory tree, detect expert files that were added or removed since the index files were last updated, and reconcile every index.md to match the actual file system.

rules

  1. Scan the full directory tree first. Walk every folder under .experts/ and collect all .md files. Separate them into three categories: index files (index.md), utility files (root-level system files like builder.md, analyzer.md, fallback.md, update-experts.md), and expert files (everything else that isn't prefixed with _).

  2. Build the expected inventory from the file system. For each domain folder (tools/, languages/, languages/{lang}/, .project/), list every expert .md file present on disk (excluding index.md). This is the source of truth.

  3. Build the registered inventory from each index file. Parse each domain's index.md to extract: (a) the ## file inventory list and (b) expert filenames referenced in Read: or → Read directives within ## task clusters. This is what the routing system currently knows about.

  4. Diff the two inventories per domain. Identify: (a) New experts — files on disk not in the index, (b) Removed experts — files in the index not on disk, (c) Orphaned references — Read: directives pointing to files that don't exist.

  5. For each new expert, read the file to extract routing metadata. Open the new expert file and extract: the # title line, the ## purpose line, trigger phrases from ## instructions, and any When: signal words. This metadata is needed to write the index entry.

  6. Update domain index.md files for new experts. For each new expert: (a) Add a task cluster entry under ## task clusters with a When: line derived from the expert's trigger phrases and a → Read directive pointing to the file. (b) Add the filename to ## file inventory in alphabetical order.

  7. Update domain index.md files for removed experts. For each removed expert: (a) Delete its task cluster entry from ## task clusters. (b) Remove the filename from ## file inventory. (c) Remove any Depends on: references to it from other clusters.

  8. Update the root index.md for signal word changes. After updating domain indexes, check if new experts introduced signal words not already present in the root index.md routing rules for that domain. Add them. Similarly, remove signal words that only belonged to a now-deleted expert.

  9. Update the root index.md utilities section. If a new root-level utility file was added (not inside a domain folder), add it to ## utilities with a → Read directive, signals line, and one-line description. If a utility was removed, delete its entry.

  10. Handle language sub-domains. Languages have a two-level structure: languages/index.md routes to languages/{lang}/index.md, which routes to individual expert files. New language folders need entries in languages/index.md. New expert files within a language folder need entries in that language's index.md.

  11. Detect new domain folders. If a folder exists under .experts/ that contains an index.md but has no routing entry in the root index.md, flag it as a new domain and add a routing entry with signals derived from its index.md purpose and task clusters.

  12. Detect orphaned domain folders. If the root index.md references a domain folder that doesn't exist on disk, remove the routing entry and warn the developer.

  13. Never modify expert files themselves. This utility only touches index.md files. Expert content, rules, patterns, and instructions are never altered.

  14. Report all changes. After updating, output a structured summary showing: files scanned, new experts wired, removed experts unwired, signal words added/removed, and any warnings (orphaned references, missing metadata).

workflow

phase 1 — scan
  1. List all folders under .experts/ recursively.

  2. For each folder, list all .md files.

  3. Categorize every file: index, utility, or expert.

  4. Build the file-system inventory: { domain → [expert files] }.

phase 2 — parse indexes
  1. Read every index.md file found in phase 1.

  2. Extract registered experts from ## file inventory and Read: / → Read directives.

  3. Build the index inventory: { domain → [registered files] }.

phase 3 — diff
  1. For each domain, compute:

    • added = filesystem - index

    • removed = index - filesystem

    • orphaned_refs = Read directives pointing to missing files

  2. For root-level files, compare against ## utilities in the root index.md.

phase 4 — gather metadata for new experts
  1. For each file in added, read the expert file.

  2. Extract: title, purpose, trigger phrases from ## instructions, signal words.

  3. If the expert lacks ## instructions or trigger phrases, derive signal words from the title and purpose.

phase 5 — update indexes
  1. Apply additions and removals to each domain index.md:

    • Add/remove task cluster entries.

    • Add/remove file inventory entries.

    • Clean up Depends on: / Cross-domain deps: references to removed files.

  2. Apply signal word changes to root index.md routing rules.

  3. Apply utility additions/removals to root index.md ## utilities section.

phase 6 — report

Output a structured summary:

## Update Report

### Scanned
- Domains: {count}
- Expert files: {count}
- Index files: {count}

### Changes
#### New experts wired
- {domain}/index.md ← {filename} (signals: {words})

#### Removed experts unwired
- {domain}/index.md → {filename} removed

#### Signal words updated
- Root index.md: added {words} to {domain} signals
- Root index.md: removed {words} from {domain} signals

#### Utilities updated
- Root index.md: added {filename} to utilities
- Root index.md: removed {filename} from utilities

### Warnings
- {any orphaned references, missing metadata, etc.}

### No changes needed
- {domains where filesystem matches index}

patterns

Parsing file inventory from an index
# File inventory formats to recognize:

# Pipe-delimited (tools/index.md style):
# git.md | json-yaml.md | prompt-engineer.md
→ Split on ` | `, strip backticks

# Backtick-delimited (languages/typescript/index.md style):
# `idioms.md` | `patterns.md` | `pitfalls.md` | `type-system.md`
→ Split on ` | `, strip backticks

# Comment placeholder (.project/index.md style):
# <!-- empty — populated by analyzer.md + builder.md -->
→ Empty list
Parsing Read directives from task clusters
# Single-file directive (tools style):
# → Read `.experts/tools/git.md`
→ Extract path, derive filename: git.md

# Multi-file directive (language sub-domain style):
# Read:
# - `idioms.md`
# - `patterns.md`
→ Extract each filename from bullet list

# Domain-level directive (root index.md style):
# → Read `.experts/languages/index.md`
→ This points to an index, not an expert — skip when inventorying experts
Deriving signal words from an expert file
# Priority order for extracting signals:

1. ## instructions → "Trigger phrases:" line
   → Parse the comma-separated quoted phrases

2. ## interview → question text
   → Extract domain-specific keywords

3. ## purpose → one-line description
   → Extract nouns and noun phrases

4. # title → filename stem
   → Use as a last-resort signal word

pitfalls

  • Confusing index files with expert files. Every domain has an index.md that is a router, not an expert. Never add index.md to a file inventory or create a task cluster pointing to an index within its own domain.

  • Missing the two-level language structure. languages/index.md routes to languages/{lang}/index.md, which routes to expert files. A new file in languages/python/ must update languages/python/index.md, not languages/index.md directly. A new language folder must update languages/index.md.

  • Overwriting hand-crafted cluster descriptions. When adding a new expert to an existing index, don't rewrite the existing task clusters. Only add the new entry and update the file inventory.

  • Duplicating signal words in root index. Before adding signal words to a domain's entry in the root index.md, check that those words don't already appear in another domain's signals. Duplicate signals cause ambiguous routing.

  • Forgetting locked files. *.locked.md files are valid experts that should appear in indexes. Don't skip them during scanning — they route identically to unlocked files.

  • Treating _prefixed.md files as experts. Files starting with _ are system/template files, not routable experts. Exclude them from inventory and index updates.

instructions

Use this expert when the developer wants to synchronize the routing indexes with the actual expert files on disk. This is the maintenance counterpart to builder.md — the builder creates experts, this utility ensures the routing system reflects what exists.

Trigger phrases: "update experts," "sync indexes," "update index," "refresh routing," "fix index files," "new experts not routed," "clean up indexes," "reconcile experts."

Pair with: builder.md (run update-experts after bulk expert creation to wire everything at once). Pair with: analyzer.md (run update-experts after the analyzer recommends and creates project experts).

research

Deep Research prompt:

"Write a meta-expert for maintaining a modular AI expert routing system's index files. Cover: recursive directory scanning to discover expert files, parsing index.md files to extract registered file inventories and Read directives, diffing filesystem state against index state, extracting routing metadata (signal words, trigger phrases) from expert files, updating multi-level index hierarchies (root router, domain routers, sub-domain routers), handling additions and removals symmetrically, managing signal word propagation from domain indexes to root index, reporting changes in a structured format, and common maintenance pitfalls (index/expert confusion, two-level language routing, locked files, underscore-prefixed system files, duplicate signal words across domains)."

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 an API key, Needs Python, Needs Node.js

Security

What our scanner noticed· Medium risk

  • Possible data-exfiltration endpoints
  • Instructions that use the network
  • Downloads piped into a shell

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

Published by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills · .github/plugins/microsoft-365-agents-toolkit/skills/teams-app-developer · commit 0696600
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download teams-app-developer.zip