Generated banner for Declarative Agent Developer
Generated logo for Declarative Agent Developer

Declarative Agent Developer

MicrosoftOfficialPublished by Microsoft

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

From the author

Create, build, deploy, and localize declarative agents for M365 Copilot and Teams. USE THIS SKILL for ANY task involving a declarative agent — including localization, scaffolding, editing manifests, adding capabilities, and deploying. Localization requires tokenized manifests and language files that only this skill knows how to produce. Triggers: "create agent", "create a declarative agent", "new declarative agent", "scaffold an agent", "new agent project", "add a capability", "add a plugin", "configure my agent", "deploy my agent", "fix my agent manifest", "edit my agent", "localize my agent", "add localization", "translate my agent", "multi-language agent", "add an API plugin", "add an MCP plugin", "add OAuth to my plugin", "review instructions", "improve instructions", "fix my instructions"
— the description by Microsoft

AutoGineer summary

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

The declarative-agent-developer skill provides a structured workflow for managing the lifecycle of M365 Copilot and Teams declarative agents. It utilizes the M365 Agent Toolkit (ATK) CLI to handle project scaffolding, manifest management, API plugin integration, and deployment. The skill enforces strict workspace validation, requiring specific project structures before allowing modifications, and provides standardized protocols for error handling, localization, and authentication configuration.

What it does

  • Scaffolds new declarative agent projects using the ATK CLI.
  • Manages and validates declarativeAgent.json manifests.
  • Integrates API plugins and MCP servers into existing agent projects.
  • Configures OAuth authentication for secure plugin communication.
  • Handles localization of agent manifests and language files.
  • Deploys agents to local environments for testing and validation.

When to use it

  • When creating a new declarative agent project for M365 Copilot or Teams.
  • When adding new capabilities, API plugins, or MCP servers to an existing agent.
  • When updating agent instructions or conversation starters.
  • When localizing an agent for multiple languages.
  • When troubleshooting or fixing errors in an agent manifest.

Advantages

  • Ensures consistent project structure through mandatory workspace checks.
  • Automates complex tasks like API plugin registration and OAuth setup.
  • Provides a clear, step-by-step protocol for error detection and resolution.
  • Facilitates standardized deployment and testing workflows.
  • Maintains schema compatibility by checking version requirements before feature implementation.

Usage examples

“Create a new declarative agent project.”
The agent will initialize a new project structure, including the necessary manifest files, provided the workspace is empty and valid for agent development.
“Add an API plugin to my agent using this OpenAPI spec URL.”
The agent will use the ATK CLI to integrate the specified API, map the requested operations, and prompt for necessary metadata updates.
“Localize my agent into French.”
The agent will generate the required tokenized manifests and language files to support French localization.
“Deploy my agent to the local environment.”
The agent will run the provisioning command and provide the M365 test link for the deployed agent.

Install

  1. Download the skill as a ZIP:

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

    mkdir -p .agents/skills && unzip declarative-agent-developer.zip -d .agents/skills

Documentation by Microsoft

M365 Agent Developer

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.

⛔ Workspace Check — MANDATORY FIRST STEP

Before doing ANYTHING, check the workspace files to fingerprint the project:

  1. Run npx -y --package @microsoft/m365agentstoolkit-cli atk --version to confirm ATK CLI is installed. If not found → Stop. Tell the user to install ATK.

  2. Check for m365agents.yml or teamsApp.yml at the project root.

  3. Check for appPackage/declarativeAgent.json.

  4. Check for non-agent indicators (package.json with express/react/next, src/index.js, app.py, etc.)

Then follow the decision gate:

ConditionGateAction
Non-agent project files, no appPackage/RejectText-only response. No files, no commands.
No manifest, user wants to edit/deployRejectText-only response. Explain manifest is missing.
No manifest, user wants new projectScaffold→ Scaffolding Workflow
Manifest exists with errorsFixDetect → Inform → Ask (see below). Do NOT deploy.
Valid project, user reports behavior issuesReview→ Instruction Review — run the full 5-phase review workflow
Valid agent projectEdit→ Editing Workflow

Detailed gate rules, examples, and anti-patterns: Workspace Gates

🚫 HARD REJECTION RULES — No Exceptions

These rules override ALL other instructions. If any of these apply, you MUST stop immediately.

  1. NEVER create declarativeAgent.json yourself. If the manifest is missing and the user asked to edit/modify/deploy, respond with text only: explain the manifest is missing, suggest npx -y --package @microsoft/m365agentstoolkit-cli atk new or starting from scratch. Do NOT create the file, do NOT create appPackage/, do NOT "help" by scaffolding implicitly.

  2. NEVER create files in a non-agent project. If the workspace is an Express/React/Django/etc. app without appPackage/, your response must be text-only. Do NOT create any files, do NOT run any commands.

  3. NEVER deploy when errors exist. If the agent manifest has errors, STOP. Do NOT run npx -y --package @microsoft/m365agentstoolkit-cli atk provision — not "to test", not "to demonstrate the error", not "to see what happens". Report the errors and ask the user how to proceed.

🔍 Detect → Inform → Ask (Error-Handling Protocol)

When you encounter ANY problem (missing files, malformed JSON, validation errors, incompatible features), you MUST follow this sequence in order:

  1. Detect — Identify the specific problem. For JSON issues, attempt to parse the file and report syntax errors. For missing fields, check the manifest against the Schema.

  2. Inform — Tell the user BEFORE taking any action. Describe exactly what is wrong ("declarativeAgent.json has malformed JSON: missing comma on line 12, unclosed array on line 18").

  3. Ask — Wait for the user's response before making changes. Do NOT silently fix, auto-correct, or work around the problem.

This protocol applies to:

  • Missing declarativeAgent.json → Detect (file not found) → Inform ("no manifest found") → Ask ("would you like to create a new agent?")

  • Malformed JSON → Detect (parse errors) → Inform (list specific syntax issues) → Ask ("should I fix these syntax errors?")

  • Validation errors → Detect (parse and check manifest) → Inform (list all errors) → Ask ("how would you like to fix these?")

  • Version incompatibility → Detect (feature requires newer version) → Inform ("this feature requires v1.6, your agent is v1.4") → Ask ("should I upgrade?")


Phase Routing

ScenarioWorkflow Reference
Creating a NEW project from scratchScaffolding Workflow
Working with existing .json manifestsEditing Workflow
Adding an API pluginAPI Plugins
Adding an MCP serverMCP Plugin
Adding OAuth to an MCP or API pluginAuthentication
Reviewing or improving existing agent instructionsInstruction Review
User reports agent gives generic/wrong answersInstruction Review
Localizing an agent into multiple languagesLocalization
Adding a new language to an already-localized agentLocalization
Writing agent instructionsConversation Design

ATK CLI Setup

Before running any ATK commands, check if the ATK CLI is available by running npx -y --package @microsoft/m365agentstoolkit-cli atk --version. If not found, STOP and tell the user — do NOT attempt to install it yourself.

All commands use the npx -y --package @microsoft/m365agentstoolkit-cli atk prefix (e.g., npx -y --package @microsoft/m365agentstoolkit-cli atk provision --env local).


Critical Rules

1. Deploy After EVERY Edit

After ANY change to files in appPackage/, you MUST deploy and show the test link before responding:

npx -y --package @microsoft/m365agentstoolkit-cli atk provision --env local --interactive false

Then read M365_TITLE_ID from env/.env.local and ALWAYS present the review UX:

✅ Agent deployed successfully!

🚀 Test Your Agent in M365 Copilot:
🔗 https://m365.cloud.microsoft/chat/?titleId={M365_TITLE_ID}

⛔ Never respond without this link. If you deployed, the test link MUST appear in your response. This is not optional — it is how the user tests their agent.

  • If the manifest has errors → STOP. Fix errors. Do NOT deploy.

  • Exception: user explicitly asks you not to deploy

2. Never Invent Content or Create Missing Files
  • Do NOT invent placeholder names, descriptions, or instructions

  • Do NOT create declarativeAgent.json or appPackage/ if they don't exist — this is a REJECT scenario, not a "help by creating" scenario

  • If required fields are missing, report the gaps, and ASK the user

  • If JSON is malformed, follow Detect → Inform → Ask: parse the file first, tell the user what's broken, then ask before fixing. Use surgical edits (not rewrites)

  • ⛔ NEVER set placeholder values for environment variables that are populated by automation (e.g., <PREFIX>_MCP_AUTH_ID, TEAMS_APP_ID). Leave them empty (VAR_NAME=). Placeholders will be treated as real values and will NOT be overwritten by provisioning.

3. Schema Version Compatibility

Before adding ANY feature, read the version field in declarativeAgent.json and check the Schema feature matrix. If the feature isn't supported in that version, refuse and offer to upgrade.

Key version gates:

  • sensitivity_label, worker_agents, EmbeddedKnowledge → v1.6 only

  • Meetings → v1.5+

  • ScenarioModels, behavior_overrides, disclaimer → v1.4+

  • Dataverse, TeamsMessages, Email, People → v1.3+

4. Use npx -y --package @microsoft/m365agentstoolkit-cli atk add action for API Plugins — NEVER Create Plugin Files Manually

You are forbidden from manually creating ai-plugin.json, OpenAPI specs, adaptive cards, or editing the actions array. Use the CLI:

# ⛔ Always list ALL operations in a single call — NEVER run separate calls per operation
npx -y --package @microsoft/m365agentstoolkit-cli atk add action --api-plugin-type api-spec --openapi-spec-location URL --api-operation "GET /path,POST /path,PATCH /path/{id},DELETE /path/{id}" -i false

Run a single npx -y --package @microsoft/m365agentstoolkit-cli atk add action call per OpenAPI spec, listing all operations as a comma-separated list in --api-operation. Never run separate npx -y --package @microsoft/m365agentstoolkit-cli atk add action calls for different operations from the same spec — this creates multiple plugins instead of one. If npx -y --package @microsoft/m365agentstoolkit-cli atk add action fails, report the error; do NOT fall back to manual creation.

Exception: MCP servers are not supported by npx -y --package @microsoft/m365agentstoolkit-cli atk add action. Use the MCP Plugin workflow instead.

5. MCP Server Integration

When the user mentions an MCP server URL, follow the MCP Plugin workflow. You MUST discover tools via the MCP protocol handshake (initialize → notifications/initialized → tools/list) — NEVER fabricate tool names/descriptions. For authenticated MCP servers, follow the authentication guide to configure OAuth.

6. Always Update Instructions & Starters After Changes

Adding a capability or plugin without updating instructions is incomplete. After ANY change:

  1. Update instructions to describe the new/changed functionality — every data source should have clear intent coverage (WHEN and WHY to use it) per the Instruction Review quality bar. Built-in capabilities don't need exact names; actions/plugins should be named.

  2. Do NOT list tool names, descriptions, or parameters in instructions — these are already in the plugin metadata (ai-plugin.json, MCP manifests, capability config). Instructions should contain decision logic only: WHEN to use each tool, chaining rules, and failure handling.

  3. Stay within the 8,000-character instruction limit — if close to the limit, cut tool descriptions first

  4. Add at least 1 conversation starter per added capability/plugin

  5. Remove starters that reference removed capabilities

  6. Run the Diagnostic Checklist against the updated instructions to verify quality

7. App Name Requirement

Always update the app name and description to something meaningful. Never leave defaults like "My Agent".


References

Shared
  • Authentication — OAuth discovery, credentials, oauth/register lifecycle, OAuthPluginVault

  • Best Practices — Security, performance, testing, compliance

  • Conversation Design — Authoring instructions and conversation starters from scratch

  • Instruction Review — Auditing, diagnosing, and improving existing instructions; anti-pattern detection; before/after rewrites

  • Deployment — ATK CLI workflows, environments, CI/CD

  • Localization — Multi-language support, tokenized manifests, language files

  • Workspace Gates — Detailed gate rules, examples, anti-patterns

Scaffolding
JSON Development
  • Editing Workflow — Step-by-step JSON development instructions

  • Schema — Official JSON schema for agent manifests

  • API Plugins — OpenAPI integration for JSON agents

  • MCP Plugin — MCP server integration with RemoteMCPServer, OAuth, response semantics, logo handling

  • Examples — JSON manifest examples

Files

references/editing-workflow.md

JSON Development Workflow

This document provides step-by-step instructions for developing M365 Copilot agents using JSON manifest files.

Prerequisites

  • Project must be scaffolded first (use scaffolding workflow if needed)

  • Project contains m365agents.yml at the root

  • Project uses JSON manifest files (.json)


✅ APP NAME & DESCRIPTION REQUIREMENT ✅

When developing an agent, you MUST ALWAYS update the app name and description in manifest.json to something meaningful and descriptive that reflects the agent's purpose. Never leave default/placeholder names like "My Agent" or generic descriptions.

NEVER use "(local)" suffix in app names. Always remove any "(local)" suffix from the app name.


🚨 CRITICAL DEPLOYMENT RULE 🚨

When making ANY edits to an agent — including instructions, conversation starters, capabilities, plugins, or any file in appPackage/ — you MUST ALWAYS deploy using npx -y --package @microsoft/m365agentstoolkit-cli atk provision --env local --interactive false before returning to the user. This applies to EVERY turn, not just the final turn. Never return to the user with undeployed changes.

You must NEVER:

  • Skip deploy because "it's just instructions" — deploy after every change

  • Tell the user to "run npx -y --package @microsoft/m365agentstoolkit-cli atk provision yourself" — YOU must run it

  • Deploy when validation found errors — not even "to test" or "to demonstrate"

  • Deploy "to show the user what happens" when there are errors — just report the errors

  • Run npx -y --package @microsoft/m365agentstoolkit-cli atk provision "for educational purposes" to demonstrate failure — errors = STOP, not a teaching moment

Only exception: The user explicitly asks you NOT to deploy. Only the user can opt out, never you.



💬 CONVERSATION STARTERS REQUIREMENT 💬

Every agent needs meaningful conversation starters that help users understand what the agent can do. Review the agent's capabilities and add/update conversation starters that showcase the agent's primary functions. Never leave an agent without conversation starters.


📝 ALWAYS UPDATE INSTRUCTIONS & STARTERS AFTER CHANGES — MANDATORY 📝

This is NOT optional. Adding a capability without updating instructions is incomplete work.

When you add, remove, or modify ANY capability or plugin, you MUST complete ALL of these steps before deploying:

  1. Update instructions — Add a section describing what the new capability/plugin enables. For removals, delete all references to the removed capability.

  2. Add conversation starters — Add at least 1 new conversation starter per added capability or plugin. Each starter should demonstrate the new functionality.

  3. Remove stale starters — Delete conversation starters that reference removed capabilities.

  4. Update description in manifest.json if the agent's purpose has expanded.

  5. Review existing instructions for stale references to removed capabilities.

This applies to EVERY edit operation: adding capabilities, removing capabilities, adding API plugins, adding MCP servers, modifying scoping, or any other manifest change.


Instructions

Step 1: Understand the Requirements

Action: Gather and analyze the agent requirements:

  • Identify the agent's primary purpose and target users

  • Determine required data sources (M365 services, external APIs)

  • List necessary actions the agent must perform

  • Identify security and compliance requirements

Step 2: Design the Agent Architecture

Action: Create a comprehensive architectural design:

  • Select deployment model (personal or shared)

  • Choose appropriate M365 capabilities with scoping

  • Design API plugin integrations if needed

  • Plan authentication and authorization strategy

  • Design conversation flow and instructions

Step 3: Edit JSON Manifest Files

⚠️ PRE-EDIT CHECK — Before making ANY edits, do ALL of these:

  1. Check for malformed JSON: Read declarativeAgent.json and verify it parses correctly. If it has syntax errors (missing commas, unclosed brackets, trailing commas, etc.):

    • STOP — do NOT proceed with your edit

    • INFORM the user: list every syntax issue with line numbers

    • ASK the user if you should fix the syntax errors first

    • Only after the user confirms, fix with surgical edits, then re-read the file

    • Then continue with the user's original request as a separate step

  2. Check the schema version: Read the "version" field in declarativeAgent.json (e.g., "v1.4", "v1.6"). For EVERY feature you plan to add, verify it exists in that version using the feature matrix. If a requested feature requires a newer version → STOP. Tell the user. Offer to upgrade the version first.

  3. Run a proactive instruction review (if the edit touches instructions or capabilities): Before modifying instructions or adding/removing capabilities, run Instruction Review Phase 1 (Inventory), Phase 2 (Comprehension Check), and Phase 3 (Diagnose) against the current instructions. This catches existing problems before you add to them. For Phase 2, use the brief confirmation shortcut ("I see this agent is designed to [purpose]…") since this is a proactive check. If the review finds high-severity issues (C1, C3, C11, D1-D8), inform the user and offer to fix them as part of the current edit.

⛔ NEVER invent placeholder values. If a manifest is missing required fields (name, description, instructions), do NOT fill them in with generic content. Ask the user to provide values. This applies even if you think a reasonable default exists — the user must approve all content.

Action: Configure the agent using JSON manifest files:

  • Edit declarativeAgent.json to define agent properties

  • Configure capabilities with appropriate scoping

  • Set up API plugin integrations using npx -y --package @microsoft/m365agentstoolkit-cli atk add action (NEVER manually create plugin files)

  • Write clear instructions and conversation starters

  • Ensure proper JSON syntax and schema compliance

After ALL edits, immediately run:

npx -y --package @microsoft/m365agentstoolkit-cli atk provision --env local --interactive false

This command is part of the edit — not a separate optional step. Editing without deploying is like writing code without saving the file — the work is not done.

⛔ API Plugin Rule — HARD RULE, NO EXCEPTIONS: To add an API plugin, you MUST use npx -y --package @microsoft/m365agentstoolkit-cli atk add action — one command per OpenAPI spec with ALL operations included in a single call. Never run separate npx -y --package @microsoft/m365agentstoolkit-cli atk add action calls for different operations from the same spec — this creates multiple plugins instead of one. You are FORBIDDEN from manually creating ai-plugin.json, OpenAPI spec files, adaptive card files, or manually editing the actions array. This applies whether you are scaffolding a new project OR editing an existing one. If the workspace already has an agent and the user says "add an API plugin", you STILL must use npx -y --package @microsoft/m365agentstoolkit-cli atk add action. If npx -y --package @microsoft/m365agentstoolkit-cli atk add action fails, report the error — do NOT fall back to manual file creation. Manual plugin file creation = automatic eval failure.

# ✅ The ONLY way to add an API plugin — ALL operations in ONE call:
npx -y --package @microsoft/m365agentstoolkit-cli atk add action --api-plugin-type api-spec --openapi-spec-location <URL> --api-operation "GET /path,POST /path,PATCH /path/{id},DELETE /path/{id}" -i false

After adding a plugin with npx -y --package @microsoft/m365agentstoolkit-cli atk add action, you MUST complete ALL of these — skipping any step is an eval failure:

🔌 POST-PLUGIN MANDATORY STEPS (do ALL of these, in order):

  1. Customize ai-plugin.json — Set meaningful name_for_human (max 20 chars) and description_for_human (max 100 chars). Set a descriptive description_for_model on each function. NEVER leave defaults.

  2. Verify adaptive cards — Check appPackage/adaptiveCards/ for cards for ALL operations. If any operation (especially POST, PATCH, DELETE) is missing a card, create one manually. Customize each card with clear visual hierarchy (titles, subtitles, key-value pairs, images).

  3. Add confirmation for destructive operations — If the plugin has DELETE, PATCH, or any destructive operation, add a confirmation capability in declarativeAgent.json so users are prompted before the action executes.

  4. Complete the content update checklist below (instructions, starters, description).

After ANY capability or plugin change (add, remove, modify), complete this checklist:

  1. ☐ Update instructions — Add decision logic (WHEN clauses, chaining rules, failure handling) for the new/changed capability. For removals, delete all references. Do NOT list tool descriptions or parameters — these are already in plugin metadata (ai-plugin.json, MCP manifests, capability config). Instructions should contain decision logic only.

  2. ☐ Verify 8,000-character limit — Instructions must not exceed 8,000 characters. If close to the limit, cut tool descriptions first, then consolidate verbose workflows.

  3. ☐ Run instruction quality audit — Run the Diagnostic Checklist against the updated instructions. Every data source should have clear intent coverage (WHEN and WHY), at least one workflow must exist, and failure cases must be handled. Built-in capabilities don't need exact names; actions/plugins should be named. If any check fails, fix it before deploying.

  4. ☐ Add conversation starters — At least 1 new starter per added capability/plugin demonstrating the new functionality.

  5. ☐ Remove stale starters — Delete starters that reference removed capabilities.

  6. ☐ Update manifest.json description if the agent's purpose has expanded.

  7. ☐ Review existing instructions for stale references to removed capabilities.

This checklist is NOT optional. Adding a capability without updating instructions and starters is incomplete work.

⚠️ Instruction quality matters as much as JSON correctness. Output-focused instructions (tone, format, style only) are a known failure pattern — they cause agents to give generic answers and ignore configured capabilities. Listing tool descriptions and parameters in instructions wastes the 8,000-character budget — this metadata is already available to the orchestrator. See Instruction Review for the anti-pattern catalog and before/after rewrites.

Reference: schema.md for proper manifest structure Reference: api-plugins.md for adaptive card enhancement guidelines after adding a plugin

⚠️ IMPORTANT: After making any edits to JSON files, you MUST deploy the agent (Step 4) before returning to the user.

⛔ MANDATORY POST-EDIT CHECKPOINT — YOU ARE NOT DONE YET: After editing ANY file in appPackage/, you MUST deploy before responding to the user. Skipping this is an eval failure:

  • Deploy — Run npx -y --package @microsoft/m365agentstoolkit-cli atk provision --env local --interactive false. If you edited files but did not run this command, your work is incomplete. The only exception is if the user explicitly asked you not to deploy.

If you are about to respond to the user and you have NOT deployed, STOP and deploy now.

Step 4: Provision and Deploy

⛔ PRE-DEPLOY CHECK: Before running the command below, verify the JSON files are syntactically correct and have the required fields. If there are known errors → fix them first before deploying.

Action: Provision required Azure resources and register the agent:

npx -y --package @microsoft/m365agentstoolkit-cli atk provision --env local --interactive false

Result: Returns a test URL like https://m365.cloud.microsoft/chat/?titleId=T_abc123xyz

Note: JSON-based agents do not require a compilation step - changes are deployed directly.

✅ After successful provision, ALWAYS present the review UX with the test link:

Read M365_TITLE_ID from env/.env.local and output:

✅ Agent deployed successfully!

🚀 Test Your Agent in M365 Copilot:
🔗 https://m365.cloud.microsoft/chat/?titleId={M365_TITLE_ID}

⛔ Never respond without this link. If you deployed, the test link MUST appear in your response. This is not optional.

Then wait for the user's response.

Step 5: Test and Iterate

Action: Test the agent in Microsoft 365 Copilot:

  • Use the provisioned test URL

  • Test all conversation starters

  • Verify capability access and scoping

  • Test error handling and edge cases

  • Validate security controls

Step 6: Deploy to Environments

Action: Deploy to staging/production environments:

npx -y --package @microsoft/m365agentstoolkit-cli atk provision --env prod --interactive false

Reference: deployment.md for environment management and CI/CD patterns

Step 7: Package and Share

Action: Package and share the agent:

# Package the agent
npx -y --package @microsoft/m365agentstoolkit-cli atk provision --env dev --interactive false

# Share to tenant (for shared agents)
npx -y --package @microsoft/m365agentstoolkit-cli atk share --scope tenant --env dev

Critical Workflow Rules

Always Deploy After Edits

RULE: When making any changes to an agent (JSON manifest files, instructions, capabilities, API plugins), you MUST complete the following workflow before returning to the user:

  1. Provision/deploy the agent: npx -y --package @microsoft/m365agentstoolkit-cli atk provision --env local --interactive false

  2. Read M365_TITLE_ID from env/.env.local

  3. Present the review UX with the test link:

    ✅ Agent deployed successfully!
    
    🚀 Test Your Agent in M365 Copilot:
    🔗 https://m365.cloud.microsoft/chat/?titleId={M365_TITLE_ID}

⛔ Never respond without this link after deploying.

Always Clean Up Unused Files

RULE: Every time you work on an agent project, check for and remove unused or obsolete files:

  • TODO.md or planning files no longer needed

  • Old backup files (.bak, .old, .orig)

  • Unused JSON files not referenced anywhere

  • Stale environment files (.env.old, .env.backup)

  • Empty or placeholder files

  • Outdated manifest versions

  • Unused API plugin definitions


⛔ FINAL GATE — Before Responding to the User

STOP. Before writing your response to the user, verify ALL of the following:

  • [ ] I ran npx -y --package @microsoft/m365agentstoolkit-cli atk provision --env local --interactive false and it succeeded

  • [ ] I read M365_TITLE_ID from env/.env.local

  • [ ] I presented the review UX with the 🚀 Test Your Agent in M365 Copilot: link

If you cannot check ALL boxes, you are NOT done. Go back and complete the missing steps.

This checklist applies to EVERY turn — not just the last turn in a multi-turn conversation. Even if you "only edited instructions," you must deploy before responding.

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 MCP server, Needs Node.js

Security

What our scanner noticed· Low risk

  • Phrasing that asks for actions without confirmation
  • Instructions that use the network

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/declarative-agent-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 declarative-agent-developer.zip