Dv Overview
Route Dataverse, Dynamics 365, and Power Platform requests to the right specialist skill and enforce workspace init before any CRM work.
Overview
dv-overview is an agent skill most often used in Build (also Ship security, Operate infra) that routes Dataverse and Power Platform work to the correct specialist skill and enforces connect initialization before any file
Install
npx skills add https://github.com/microsoft/dataverse-skills --skill dv-overviewWhat is this skill?
- Hard gate: verify `.env` and `scripts/auth.py` before any code; auto-run dv-connect when missing—no manual scaffolding
- Routes to dv-connect, dv-data, dv-metadata, dv-query, dv-solution, dv-admin, and dv-security by task triggers in each sk
- Cross-cutting rules: environment confirmation and pull-to-repo conventions shared by the whole Dataverse skill pack
- Non-duplicative routing defers per-task WHEN/DO NOT USE to specialist skills’ frontmatter
- Positions connect flow as the #1 failure preventer for broken auth and duplicate requirements files
- 7 named specialist skills in the routing index (connect, data, metadata, query, solution, admin, security)
Adoption & trust: 29 installs on skills.sh; 136 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You mentioned Dataverse or CRM but the agent might scaffold the wrong auth, skip environment checks, or open the wrong specialist skill for your task.
Who is it for?
Agents working across Microsoft Dataverse with the official multi-skill pack who need consistent init and task routing before data, metadata, or admin steps.
Skip if: One-off scripts with no Power Platform context, or tasks where a specialist skill is already explicit and the workspace is known to be initialized.
When should I use this skill?
User mentions Dataverse, Dynamics 365, Power Platform, or CRM and the agent must pick the right specialist skill.
What do I get? / Deliverables
The workspace is initialized via dv-connect when needed, cross-cutting rules are applied once, and the request is handed to the matching dv-* skill for the actual work.
- Correct specialist skill invocation
- Initialized `.env` and auth via dv-connect when required
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Dataverse work is integration-heavy; this meta skill is shelved in Build → integrations as the entry point before data, metadata, query, or admin tasks. The skill index and pull-to-repo rules apply across connect, schema, and solution tasks—all of which tie to platform integrations rather than a single UI or ship-only gate.
Where it fits
User asks to list tables in Dataverse and the agent runs init check then routes to dv-metadata or dv-query.
Custom API or plugin work starts with overview rules before dv-data changes.
Role or field-security question routes to dv-security after environment is confirmed.
Solution import or environment admin task routes to dv-admin or dv-solution.
How it compares
Use as the meta entry to a skill family, not as a replacement for dv-connect, dv-data, or dv-query task skills.
Common Questions / FAQ
Who is dv-overview for?
Solo builders and indie teams using Claude or similar agents against Dynamics 365, Dataverse, or Power Platform who rely on the microsoft/dataverse-skills pack.
When should I use dv-overview?
At the start of any Dataverse mention in Build integrations, before schema or query work; when Operate tasks need admin or security routing; and whenever you are unsure which dv-* skill applies.
Is dv-overview safe to install?
Treat it as documentation and routing logic in your repo; review the Security Audits panel on this Prism page and your org’s Power Platform policies before storing secrets in `.env`.
Workflow Chain
Then invoke: dv connect
SKILL.md
READMESKILL.md - Dv Overview
# Skill: Overview — What to Use and When This skill provides cross-cutting context that no individual skill owns: tool capabilities, UX principles, and the skill index. Per-task routing is handled by each skill's WHEN/DO NOT USE WHEN frontmatter triggers — not duplicated here. --- ## Hard Rules — Read These First These rules are non-negotiable. Violating any of them means the task is going off-rails. ### 0. Check Init State Before Anything Else Before writing ANY code or creating ANY files, check if the workspace is initialized: ```bash ls .env scripts/auth.py 2>/dev/null ``` - If BOTH exist: workspace is initialized. Proceed to the relevant task. - If EITHER is missing: **Automatically run the connect flow** (see the `dv-connect` skill). Do NOT ask the user whether to initialize — just do it. Do not create your own `.env`, `requirements.txt`, `.env.example`, or auth scripts. The `dv-connect` skill handles all of this. Do NOT create `requirements.txt`, `.env.example`, or scaffold files manually. The connect flow produces the correct file structure. Skipping it is the #1 cause of broken setups. ### 1. Python Only — No Exceptions All scripts, data operations, and automation MUST use **Python**. This plugin's entire toolchain — `scripts/auth.py`, the Dataverse SDK, all skill examples — is Python-based. **NEVER:** - Run `npm init`, `npm install`, or any Node.js/JavaScript tooling - Install packages via `npm`, `yarn`, or `pnpm` - Write scripts in JavaScript, TypeScript, PowerShell, or any language other than Python - Use `@azure/msal-node`, `@azure/identity`, or any Node.js Azure SDK - Import or reference `node_modules/` **ALWAYS:** - Use `pip install` for Python packages - Use `scripts/auth.py` for authentication tokens and credentials - Use the Python Dataverse SDK (`PowerPlatform-Dataverse-Client`) for data and schema operations - Use `azure-identity` (Python) for Azure credential flows If you find yourself about to run `npm` or create a `package.json`, STOP. You are going off-rails. Re-read Hard Rule 1 above. ### 2. MCP → SDK → Web API (in that order) **Before writing ANY code, ask: can MCP handle this?** If MCP tools are available in your tool list (`list_tables`, `describe_table`, `read_query`, `create_record`, etc.): - **Writes:** ≤10 records → use MCP directly. 10+ records → use Python SDK (`dv-data`). - **Reads:** Simple filter, small result set (no paging needed) → use MCP. Multi-page iteration, DataFrame loading, aggregation, or queries hitting SQL limits (DISTINCT, HAVING, subqueries) → use Python SDK (`dv-query`). Examples where MCP is sufficient: "how many accounts have 'jeff' in the name?", "show me the columns on the contact table", "create an account named Contoso." **If MCP can't handle it** (bulk operations, large reads, schema creation, multi-step workflows, analytics, or MCP tools aren't available), **use the Python SDK — not raw HTTP.** This is the most common mistake agents make. **SDK checklist — evaluate EVERY time you write a script:** - Creating/updating/deleting records? → `client.records.create()`, `.update()`, `.delete()` — see `dv-data` - Bulk record operations? → `client.records.create(table, [list_of_dicts])` — see `dv-data` - Querying or filtering records? → `client.records.get(table, select=[...], filter="...")` — see `dv-query` - Aggregation (top-N, sum, count by group, "most/least")? → Single-table: `$apply` server-side aggregation (raw Web API). Cross-table: `client.dataframe.get()` with `$select` + `pd.merge()` — see `dv-query`. Do NOT load all records without `$select` and aggregate in Pytho