From copilot-studio
Edits existing TaskDialog actions in Copilot Studio agents. Supports connector actions and MCP server actions. Modifies inputs, outputs, descriptions, connection mode, and properties.
npx claudepluginhub microsoft/skills-for-copilot-studio --plugin copilot-studioThis skill is limited to using the following tools:
Edit an existing action (`kind: TaskDialog`) in a Copilot Studio agent. Supports both regular connector actions (`InvokeConnectorTaskAction`) and MCP server actions (`InvokeExternalAgentTaskAction`). Uses connector definitions to understand the full operation schema (inputs, outputs, types) and action templates as structural reference.
Enforces C++ Core Guidelines for writing, reviewing, and refactoring modern C++ code (C++17+), promoting RAII, immutability, type safety, and idiomatic practices.
Provides patterns for shared UI in Compose Multiplatform across Android, iOS, Desktop, and Web: state management with ViewModels/StateFlow, navigation, theming, and performance.
Implements Playwright E2E testing patterns: Page Object Model, test organization, configuration, reporters, artifacts, and CI/CD integration for stable suites.
Edit an existing action (kind: TaskDialog) in a Copilot Studio agent. Supports both regular connector actions (InvokeConnectorTaskAction) and MCP server actions (InvokeExternalAgentTaskAction). Uses connector definitions to understand the full operation schema (inputs, outputs, types) and action templates as structural reference.
Help the user find the right connector and operation before they go to the UI. Use the connector lookup tool. Important: The connector lookup script only covers a subset of connectors (run list to see which ones). If the user's requested connector is not in the list, tell the user they need to find and add the connector action entirely through the Copilot Studio portal, then ask them to pull again the files locally. Once pulled, /copilot-studio:edit-action can still be used to customize the YAML.
When the connector IS available, use the lookup tool to help the user before they go to the UI:
node ${CLAUDE_SKILL_DIR}/../../scripts/connector-lookup.bundle.js list # List connectors
node ${CLAUDE_SKILL_DIR}/../../scripts/connector-lookup.bundle.js operations <connector> # List operations
node ${CLAUDE_SKILL_DIR}/../../scripts/connector-lookup.bundle.js operation <connector> <opId> # Full input/output details
node ${CLAUDE_SKILL_DIR}/../../scripts/connector-lookup.bundle.js search <keyword> # Search operations
Use schema lookup for structural properties:
node ${CLAUDE_SKILL_DIR}/../../scripts/schema-lookup.bundle.js summary TaskDialog
node ${CLAUDE_SKILL_DIR}/../../scripts/schema-lookup.bundle.js summary InvokeConnectorTaskAction
node ${CLAUDE_SKILL_DIR}/../../scripts/schema-lookup.bundle.js summary InvokeExternalAgentTaskAction
node ${CLAUDE_SKILL_DIR}/../../scripts/schema-lookup.bundle.js summary ModelContextProtocolMetadata
Auto-discover the agent directory:
Glob: **/agent.mcs.yml
If multiple agents found, ask which one.
Find the action file to edit:
Glob: <agent-dir>/actions/*.mcs.yml
Read the action file. If the user's request is ambiguous and multiple actions exist, list them and ask which one.
Identify the connector and operation:
action.operationId and the connector API name from connectionreferences.mcs.ymlnode ${CLAUDE_SKILL_DIR}/../../scripts/connector-lookup.bundle.js operation <connector> <operationId>
shared_sharepointonline), read the SharePoint-specific reference before making any edits:
Read: ${CLAUDE_SKILL_DIR}/sharepoint-actions.md
This covers OData filter syntax, the critical "'$filter'" quoting pattern, which inputs should be Manual vs Automatic, and dynamic output handling.Determine the action type from the YAML:
action.kind is InvokeConnectorTaskAction → regular connector actionaction.kind is InvokeExternalAgentTaskAction → MCP server actionRead the appropriate template for structural reference:
Read: ${CLAUDE_SKILL_DIR}/../../templates/actions/connector-action.mcs.yml
Read: ${CLAUDE_SKILL_DIR}/../../templates/actions/mcp-action.mcs.yml
Use this alongside the connector-lookup output from step 3 to understand the YAML structure and available inputs/outputs.
Make the requested edits using the Edit tool. Common modifications:
Update description on AutomaticTaskInput entries to improve how the orchestrator fills them:
inputs:
- kind: AutomaticTaskInput
propertyName: body
description: The email body content in HTML format # <-- edit this
Cross-reference the connector definition to see all available input properties. Add new ones or remove unnecessary ones:
# Add a new input from the connector definition
- kind: AutomaticTaskInput
propertyName: importance
description: The importance level of the email (Low, Normal, High)
AutomaticTaskInput: The orchestrator fills this dynamically based on the conversationManualTaskInput: A hardcoded value (string only)# Change from automatic to manual (hardcode a value)
- kind: ManualTaskInput
propertyName: timeZone
value: "(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna"
Add or remove output properties. Cross-reference the connector definition for available outputs:
outputs:
- propertyName: id
description: The unique ID of the created item
These control how the orchestrator understands and routes to this action:
modelDisplayName: Send a Teams message
modelDescription: Posts a message to a Teams chat or channel on behalf of the user
action:
connectionProperties:
mode: Invoker # or Maker
Maker: Uses the developer's credentials (shared connection)Invoker: Each end user authenticates with their own credentialsMCP actions (InvokeExternalAgentTaskAction with ModelContextProtocolMetadata) have a simpler structure than connector actions. The MCP protocol handles tool discovery, so there are no explicit inputs/outputs.
Safe to edit:
modelDisplayName: Microsoft Learn Docs MCP Server # display name for the orchestrator
modelDescription: MCP Server to search Microsoft Learn content # routing description
action:
connectionProperties:
mode: Invoker # or Maker
MCP actions may also have ManualTaskInput entries for passing context to the MCP server (e.g., user identity as a header):
inputs:
- kind: ManualTaskInput
propertyName: userid
value: =System.User.Email
This is fine — ManualTaskInput with Power Fx expressions can pass user context. But do NOT add AutomaticTaskInput entries — MCP handles tool parameter discovery dynamically.
Do NOT edit on MCP actions:
action.operationDetails.operationId — identifies the MCP operationaction.connectionReference — links to the authenticated connectionAutomaticTaskInput entries — MCP handles tool discovery dynamicallymodelDescription — keep it on a single line; multi-line descriptions have been reported to break MCP tool registration after push (see #91)Validate the edited file:
node ${CLAUDE_SKILL_DIR}/../../scripts/schema-lookup.bundle.js validate <action-file-path>
Inform the user about next steps:
action.operationId (connector) or action.operationDetails.operationId (MCP) — this identifies which operation runs. Changing it breaks the action.action.connectionReference — this links to the authenticated connection. Changing it breaks the action.connector-lookup operation to verify exact property names.connector-lookup operation to see available output properties.AutomaticTaskInput entries — the MCP protocol handles tool parameter discovery dynamically. ManualTaskInput entries are OK for passing context (e.g., user identity via Power Fx expressions like =System.User.Email).