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

docs/workflows.md

Workflow Scenarios

Message-native workflow patterns for Teams bots. These scenarios demonstrate how collaborative business workflows can be initiated, executed, persisted, queried, and displayed entirely within the message surface — no external tools or navigation required.

Each scenario follows the same five-element lifecycle:

ElementWhat It DoesTeams API
TriggerHow the workflow startsBot commands, message extensions, node-cron, Graph change notifications
StateWhere records liveSharePoint Lists via Graph API (or Dataverse for enterprise)
LogicHow decisions executeBot state machine, Action.Execute handlers, escalation timers
IntelligenceHow AI is layered over stateAzure OpenAI function calling for NL queries over list data
VisibilityHow records stay in-channelAdaptive Cards with Action.Execute → in-place refresh

All scenarios are implementable today with a standard Teams bot. No new platform features required.

Example implementation: examples/message-native-workflow/ — Daily Standup with all five pillars.

Experts: The teams/workflow.* and bridge/workflow.composable-platform-ts.md experts provide implementation guidance for each pillar.


Scenario 1: Daily Standup

Audience: SMB teams, engineering teams, any recurring check-in cadence.

User Flow
  1. Bot posts a standup prompt card at 9 AM (scheduled trigger) or on /standup (command trigger)

  2. Each team member fills in yesterday / today / blockers in the card's input fields

  3. On submit, Action.Execute replaces the prompt with a completed record card in-place

  4. Record persisted to SharePoint List with thread link

  5. Manager types "show blockers" or "summarize last week" — AI queries the list and renders results

Five Elements
ElementImplementation
Triggernode-cron scheduled at STANDUP_CRON + /standup bot command
StateSharePoint List: Respondent, Date, Yesterday, Today, Blockers, HasBlockers, ThreadActivityId
LogicCard form submission → record creation. Edit/save state machine via Action.Execute
IntelligencequeryStandups(date?, respondent?), queryBlockers(currentOnly?), summarizeStandups(date)
VisibilityPrompt card → record card (in-place). Summary card. Blockers card with per-person breakdown
Key Cards
  • Standup prompt — Input.Text fields for yesterday/today/blockers + Submit button

  • Record card — FactSet showing the response + Edit button

  • Summary card — response count, blocker count, respondent list

  • Blockers card — ColumnSet list of all current blockers by person

Why It Validates the Vision

Exercises structured input (form), durable state (list), in-place updates (Action.Execute), and NL retrieval (AI function calling). This is FHL Option A from the source document.


Scenario 2: Time-Off Requests (PTO)

Audience: SMB, any team with leave management.

User Flow
  1. Employee types /pto 2024-03-15 to 2024-03-22 or uses the "New PTO Request" compose extension

  2. Bot creates a PTO record card in the thread with request details + Approve/Reject buttons

  3. Manager sees the card with refresh.userIds showing action buttons only to them

  4. Manager clicks Approve — card refreshes in-place to show "Approved by [Manager]" (read-only)

  5. Employee receives a proactive notification in the thread

  6. Anyone in the channel can type "show PTO for March" — AI queries and renders results

Five Elements
ElementImplementation
TriggerBot command (/pto START to END), message extension action (form with date pickers)
StateSharePoint List: Requester, StartDate, EndDate, HoursRequested, Status, ApprovedBy, ThreadActivityId
LogicSingle-approver routing. Manager lookup via GET /users/{id}/manager. Escalation timer (48h)
IntelligencequeryPtoRequests(status?, requester?, month?) — "Who has PTO next week?", "Show pending requests"
VisibilityRequest card (pending, with Approve/Reject) → Approved card (read-only). PTO list card for queries
Approval Routing
PatternBehavior
SingleOne approver (direct manager), one decision
SequentialManager → Director. Director only sees the card after manager approves
Parallel-allHR + Manager must both approve
Role-Specific Card Views

The refresh property on the Adaptive Card targets refresh.userIds = the current approver's AAD ID. The approver sees Approve/Reject buttons. Everyone else sees a read-only status card. When the approver acts, the card refreshes for all viewers.


Scenario 3: Equipment / Asset Reservation

Audience: SMB operations, facilities, shared resource management.

User Flow
  1. Employee types /book Projector Room-A tomorrow 2pm-4pm

  2. Bot checks for conflicts by querying the list for overlapping reservations

  3. If available, bot creates the booking and posts a confirmation card

  4. If conflict detected, bot posts a card showing the conflict and suggesting alternatives

  5. Late-return alert: if the booking end time passes without a return confirmation, bot sends a reminder

  6. Manager types "show all bookings this week" — AI renders a calendar-style summary

Five Elements
ElementImplementation
TriggerBot command (/book ITEM LOCATION DATE TIME), message extension search for availability lookup
StateSharePoint List: Item, Location, BookedBy, StartTime, EndTime, Status (Active/Returned/Overdue), ThreadActivityId
LogicConflict detection via $filter on overlapping date ranges. Return confirmation via Action.Execute. Overdue timer → proactive reminder
IntelligencequeryEquipmentBookings(item?, status?, dateRange?) — "Is the projector available Friday?", "Show overdue items"
VisibilityBooking confirmation card. Conflict card with alternatives. Overdue alert card. Weekly summary card
Conflict Detection Query
fields/Item eq 'Projector' and fields/Location eq 'Room-A'
  and fields/StartTime lt '2024-03-16T16:00:00Z'
  and fields/EndTime gt '2024-03-16T14:00:00Z'
  and fields/Status eq 'Active'

If results > 0, there's a conflict. The bot renders the conflicting bookings and suggests the next available slot.


Scenario 4: Account Health Monitoring (CRM)

Audience: Sales teams, account managers, customer success.

User Flow
  1. Weekly scheduled prompt posts to the sales channel: "Time for account health check-ins"

  2. Each account owner fills in: Account name, health status (Green/Yellow/Red), notes, next meeting date

  3. Responses aggregate into a durable account health list

  4. Stale accounts flagged: if no update in 30 days, bot sends a dormant account alert

  5. Before a meeting, manager types "summarize Acme Corp" — AI pulls the last 4 check-ins and renders a trend card

Five Elements
ElementImplementation
TriggerWeekly cron schedule. Dormant-account check (daily timer queries for last-update > 30 days)
StateSharePoint List: AccountName, Owner, HealthStatus (Green/Yellow/Red), Notes, NextMeeting, LastUpdated
LogicStaleness detection: daily timer queries fields/LastUpdated lt '{30-days-ago}'. Proactive alert to owner
IntelligencequeryAccountHealth(account?, status?, owner?) — "Show all red accounts", "Summarize Acme Corp history"
VisibilityCheck-in prompt card. Account status card (color-coded). Dormant account alert. Trend summary card
Trend Analysis

The AI function returns the last N check-ins for an account. The LLM summarizes:

"Acme Corp: 4 check-ins over the last month. Trend: Yellow → Yellow → Red → Red. Key issue: delayed contract renewal (first flagged March 1). Next meeting: March 15."

This is the "intelligence layered over structured state" pattern — the primary differentiation opportunity called out in the source document.


Scenario 5: Frontline Break Management

Audience: Frontline workers, call centers (e.g., T-Mobile scenario from source document).

User Flow
  1. Agent changes presence to "Away" (auto-detected via Graph presence subscription)

  2. Bot removes agent from call queue and starts break timer

  3. At 15 minutes, bot sends a reminder card to the agent and their manager

  4. At 20 minutes, bot escalates — posts an alert card in the manager channel

  5. Agent changes presence to "Available" — bot re-adds to queue, records break duration

  6. Manager types "who is on break?" or "average break duration today" — AI queries and responds

Five Elements
ElementImplementation
TriggerGraph change notification subscription on /communications/presences/{userId}
StateSharePoint List: EmployeeName, BreakStart, BreakEnd, DurationMinutes, Status (Active/Ended/Escalated)
LogicTimer-based escalation (15 min reminder, 20 min escalate). Call queue add/remove via Teams admin APIs. Break record created on "Away", updated on "Available"
IntelligencequeryBreakStatus(currentOnly?) — "Who is on break right now?", "Average break duration this week"
VisibilityBreak started card (in manager channel). Reminder card (to agent). Escalation alert card. Break summary card
Why This Is Teams-Native

This scenario depends on three capabilities Slack cannot replicate:

CapabilityTeamsSlack
Presence change subscriptionsGraph /communications/presencesNot available
Shift schedule integrationShifts APINot available
Call queue managementTeams admin APIs + GraphNot available
Technical Requirements
  • Graph subscription for presence requires Presence.Read.All application permission and encrypted rich notifications (public/private key pair for notification decryption)

  • Presence subscriptions expire in 60 minutes — aggressive renewal required (55-minute interval)

  • Webhook must respond in 3 seconds — process notifications asynchronously

  • In-memory timers don't survive restarts — use Azure Durable Functions or a Redis-backed job queue for production


Scenario 6: Incident Response

Audience: IT operations, DevOps, on-call teams.

User Flow
  1. On-call engineer types /incident P1 Production database connection pool exhausted

  2. Bot creates an incident record, posts a structured incident card, and creates a dedicated incident thread

  3. Bot proactively notifies the on-call rotation (looked up from a Shifts schedule or list)

  4. Team members post updates in the thread — bot captures tagged updates (/update Database restarted, monitoring)

  5. Engineer types /resolve — bot closes the incident, calculates MTTR, and posts a resolution summary

  6. Post-incident: manager types "show P1 incidents this month" — AI generates a summary with MTTR trends

Five Elements
ElementImplementation
Trigger/incident PRIORITY DESCRIPTION bot command
StateSharePoint List: IncidentId, Priority (P1-P4), Description, Status (Open/Investigating/Resolved), AssignedTo, CreatedAt, ResolvedAt, MTTR, Updates[]
LogicAuto-assign from on-call rotation. Status transitions: Open → Investigating → Resolved. MTTR calculation on resolve. Thread-based update capture
IntelligencequeryIncidents(priority?, status?, dateRange?) — "Show open incidents", "MTTR trend for P1s this quarter"
VisibilityIncident card (color-coded by priority). Update timeline in thread. Resolution summary card with MTTR

Composable Platform Pattern

All six scenarios follow the same lifecycle. The composable platform approach (see bridge/workflow.composable-platform-ts.md) defines workflows as configuration:

interface WorkflowDefinition {
  id: string;                   // "pto", "standup", "equipment"
  commandPrefix: string;        // "/pto", "/standup", "/book"
  columns: ColumnDefinition[];  // SharePoint List schema
  statusField: string;          // Which column tracks lifecycle
  routing?: RoutingConfig;      // Approval chain config
  cards: CardTemplates;         // Active, completed, list, form
  queryDescription: string;     // AI function calling description
  filterableColumns: string[];  // Columns exposed to NL queries
}

A single workflow engine registers handlers from definitions. New workflows require a new WorkflowDefinition object, not new handler code. Template workflows (standup, PTO, equipment) serve as reference implementations.

Scenario Comparison
ScenarioTrigger TypesApprovalState-DrivenNL QueriesCompetitive Edge
Daily StandupScheduled, commandNoNoBlockers, summariesStructured check-ins as durable records
PTO RequestsCommand, extensionYes (single/chain)NoStatus, date range, personApproval routing + NL retrieval
Equipment BookingCommand, searchNoNoAvailability, overdueConflict detection + alternatives
Account HealthScheduledNoTimer (staleness)Trends, status, ownerTrend analysis over time
Break ManagementPresence changeNoYes (presence)Current status, averagesTeams-only: presence + Shifts + call queues
Incident ResponseCommandNoNoPriority, MTTR, statusThread-based update capture + MTTR

Platform Comparison: Teams vs Slack

CapabilitySlackTeamsGap
In-channel workflow creationWorkflow Builder GUIPower Automate (external)Teams gap: no in-channel builder
Structured input formsOpenForm built-in functionAdaptive Card forms (bot) or task modulesParity
State persistenceDatastores (50K limit, Slack-hosted)SharePoint Lists (30M limit, tenant-owned)Teams advantage
Card interactivityBlock Kit (new message on action)Action.Execute (in-place refresh)Teams advantage
NL querying over stateNot built-inAI function calling + structured dataTeams advantage
Presence/Shifts triggersNot availableGraph subscriptionsTeams advantage
Call queue integrationNot availableTeams admin APIsTeams advantage
No-code authoringWorkflow BuilderPower AutomateSlack advantage (simpler UX)
Hosting modelSlack-hosted (Deno)Self-hosted or AzureTrade-off

The core thesis: if Teams unifies its existing primitives at the message layer (which a bot can do today), it moves beyond parity — especially for operational and frontline workflows where Slack lacks system-level integration.

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