Plugin check: Run node "${PLUGIN_ROOT}/scripts/check-version.js" - if it outputs a message, show it to the user before proceeding.

📋 Shared instructions: shared-instructions.md — read first.

Add Data Source

Entry routing: use the shared App feature entry points preflight before the workflow below.

Invocation scope: follow Data-source invocation scope before any project read or the workflow below. Resolve the absolute app root before reading memory-bank. Routing selects a data workflow, not implementation approval or a full-app integration workflow.

Router skill that understands the user's goal and connects them to the right data source — without requiring them to know Power Platform terminology.

Workflow

Check Memory Bank

Check for memory-bank.md per shared-instructions.md.

Understand the Goal

1. If $ARGUMENTS is provided or the caller already specified what's needed, use it directly and skip the question below.
2. Otherwise, ask the user what they want their app to do — not which connector to use. Focus on the end goal. Example questions:
   • "What kind of data does your app need to work with?"
   • "What should your app be able to do? (e.g., search company info, manage tasks, send messages)"
3. Based on their answer, recommend the best approach and explain why it's the right fit. The user shouldn't need to know the difference between Dataverse, SharePoint, or other connectors — that's our job.

Route to the Right Skill

Telemetry checkpoint: route_data_source_request

Note: Dedicated skills for Teams, Excel, OneDrive, Office 365, and Azure DevOps are planned for v1. Until then, /add-connector handles all of them — it covers every connector the platform supports and generates the same src/generated/ service layer.

Important routing rules:

• Forward the absolute working_dir, current request, owner/phase/scope, supplied answers, and --plan-only or planning-phase status unchanged on every handoff. Standalone calls use the selected leaf's own approval and verification gates; a saved plan or router choice is not consent to mutate.
• For refreshes, forward the exact registered identity, --refresh, --data-source-name, proposal-only status, and current approved scope to the matching leaf. Never convert a refresh into an add or request a new connection. Conflicting add/refresh/remove scopes return to the owner for separate calls.
• For removals, forward the approved identities and scope unchanged to the matching leaf's removal branch; never turn "remove this source" into an add command. Use data-source-removal.md.
• When the user wants to perform actions (send an email, post a Teams message, create a file), route to /add-connector with the connector name as the argument (e.g., /add-connector office365, /add-connector teams).
• For a cloud-flow binding request, report BLOCKED: cloud-flow integration is not supported and return without discovery or mutation. Do not route it through a connector or Dataverse workflow.
• When the user wants to invoke a Dataverse action/function/API rather than table CRUD, route to /add-connector and tell it to use $PA app find-dataverse-api --search '<operation-name>' --json; then stop and explain that this plugin only adds Dataverse table CRUD.
• When the user wants to store or query structured business data with custom schema, route to /add-dataverse.

4. If the approved scope includes multiple capabilities, invoke each skill in sequence and return the combined results to the user or current owner. Do not independently expand a connector request into schema or screen changes.

When the User Isn't Sure

If the user describes a vague goal (e.g., "I need data for my app"), guide them:

1. Ask what their app does and who uses it
2. Ask what data they need to display or interact with
3. Recommend the simplest approach that meets their needs
4. Explain the recommendation in plain language (avoid jargon like "connector", "Dataverse", "tabular data source" unless the user uses those terms first)