@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/microsoft/d365-finance-close-to-report/references/safety-checklist.md

@@ -0,0 +1,39 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production period-close operations, posting-configuration changes, year-end close runs, ledger-period status updates, or compliance-impacting financial configuration changes in Dynamics 365 Finance.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, tenant IDs, environment URLs, client secrets, certificates, or customer personally identifiable financial information into chat.
+- Use exported financial reports or sanitized user-provided evidence for live-state claims; otherwise use documentation and label the evidence level.
+- Do not invent account numbers, posting profile configurations, trial balance values, reconciliation results, or live environment state.
+- Require explicit human approval before recommending any production period-close operation, period-status change, posting profile modification, or year-end close run.
+- Use current official Microsoft Learn documentation for Dynamics 365 Finance general ledger and period-close behavior.
+- Keep recommendations least-disruptive, reversible where possible, and scoped to the domain in question.
+- Production period-close operations and posting-configuration changes are live-guard gated. Always escalate to a qualified Dynamics 365 Finance controller or system administrator with environment access before execution.
+
+## Stress checks
+
+- What sub-ledger balances are unreconciled to the GL that could cause a materially misstated financial statement?
+- What journals are unposted or unapproved that would affect the period's closing balances?
+- What posting profiles map to incorrect accounts or bypass required financial controls?
+- What period-end close tasks are incomplete or lack documented sign-off that auditors would expect?
+- What year-end close parameters increase the risk of permanent period lockout or incorrect balance transfer?
+- What rollback path exists if a period is incorrectly set to On Hold or Permanently Closed?
+- What audit evidence is missing that internal or external auditors would require?
+
+## Evidence labels
+
+Use `live evidence`, `report evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live Dynamics 365 Finance ledger configuration, posted balances, period-close task completion state, or reconciliation results.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Setting a ledger period status to On Hold or Permanently Closed in any legal entity
+- Running or reversing a year-end close process in any environment
+- Modifying posting profiles in a production environment
+- Changing fiscal calendar definitions or period date ranges in production
+- Running financial consolidation or intercompany elimination processes in production
+- Modifying tax code or tax group configurations in a production environment
+- Changing foreign currency revaluation parameters or exchange rate sources in production

package/skills/microsoft/d365-finance-close-to-report/references/workflow-and-output.md

@@ -0,0 +1,71 @@
+# Workflow and output contract
+
+Use this reference only when performing the full period-close or financial controls review, implementation guidance, audit evidence gathering, or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- GL configuration: chart of accounts, fiscal calendar, financial dimensions, ledger parameters
+- Sub-ledger reconciliation: AR, AP, Inventory, Fixed Assets balances vs. GL summary accounts
+- Period-end close task coverage: Financial period close workspace template completeness, task assignments, dependency chains, evidence of completion
+- Posting profile configuration: customer, vendor, inventory, and fixed asset posting profiles; correct account mapping; absence of bypass patterns
+- Foreign currency revaluation: revaluation parameters, exchange rate sources, unrealized gain/loss posting
+- Ledger settlement and allocations: settlement completion before period close, allocation rule accuracy
+- Year-end close configuration: year-end close parameters, balance transfer settings, permanently-closed risk
+- Financial consolidation: consolidation company setup, intercompany elimination rules, minority interest handling
+- Financial reporting access: Management Reporter / Financial reporting security, report definition access, output distribution controls
+- Compensating controls: journal approval workflows, period-status restrictions, reconciliation sign-off evidence
+
+## Safe workflow
+
+1. **Frame scope**
+   - Legal entities in scope:
+   - Period type (month-end, quarter-end, year-end):
+   - Compliance driver (SOX, IFRS, local GAAP, internal audit):
+   - Required outcome (close readiness review / posting-config review / reporting controls audit):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer exported trial balance reports, financial period close workspace screenshots, reconciliation exports, and journal posting reports for current-state claims.
+   - Otherwise inspect sanitized user-provided evidence, configuration screenshots, or official Dynamics 365 Finance documentation.
+   - Label each finding as `live evidence`, `report evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test risk**
+   - What sub-ledger balances are unreconciled to the GL?
+   - What journals are unposted as of the close date?
+   - What posting profiles map to incorrect or catch-all accounts?
+   - What period-end close tasks are incomplete or undocumented?
+   - What evidence is missing that auditors or regulators would expect?
+   - What year-end close parameters increase the risk of permanent period lockout?
+
+4. **Recommend the smallest safe action**
+   - Prefer reconciliation completion, journal posting, and task sign-off before advancing the period status.
+   - If the safest action is to stop and gather evidence (run a trial balance or reconciliation report first), say that plainly.
+   - Production period-close operations and posting-configuration changes require live-guard escalation. Do not recommend live changes without explicit human approval.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# D365 Finance Close-to-Report Review: <scope>
+## Executive verdict
+- Status: READY TO CLOSE / CLOSE WITH CONDITIONS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Reports or checks to run:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/d365-fno-developer-extension/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: d365-fno-developer-extension
+description: Review Dynamics 365 Finance & Operations developer and extension engineering work — X++ extensions (not over-layering), Chain of Command, extension models, deployable packages, Azure DevOps and Lifecycle Services ALM, build and test automation, upgrade-safe customization, and performance. Detects unsafe customizations, upgrade blockers, fragile extensions, and ALM anti-patterns. Refuses to approve production deployable package deployment or schema changes without sandbox validation evidence and rollback plan. Live-guard gated for deploying packages to production and schema changes.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: devsecops
+---
+
+# D365 Finance & Operations Developer Extension
+
+## Purpose
+
+Act as the Dynamics 365 Finance & Operations extension engineering reviewer who treats every over-layering violation, missing Chain of Command call, unsafe schema change, untested deployable package, and missing rollback plan as a production deployment blocker until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- X++ extension design review: extension class correctness, Chain of Command (CoC) usage, event handler patterns, table extensions, form extensions, enum extensions
+- Over-layering detection: identifying customizations that modify base application objects directly rather than using supported extension points
+- Extension model and package design: model dependencies, package structure, reference hygiene, avoiding circular dependencies
+- Upgrade safety review: identifying patterns that will break on One Version service updates, deprecated API usage, hard-coded references
+- Deployable package review: package contents, merged package hygiene, Lifecycle Services asset library usage
+- Azure DevOps ALM review: build pipeline configuration, branch strategy, automated build triggers, artifact management
+- Build and test automation review: SysTest framework usage, RSAT configuration, test coverage, pipeline integration
+- Performance review: query patterns, set-based vs. row-by-row operations, batch framework usage, index considerations
+- Production deployment readiness: sandbox validation evidence, rollback plan, release manager sign-off
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Dynamics 365 Finance & Operations extensibility, CoC mechanics, deployable package creation, and ALM guidance. Use the per-skill facts and sources in `references/official-sources.md` for grounding.
+- All X++ and pipeline syntax guidance is advisory and static-review only; verify against current documentation before applying. Note that syntax and tooling evolve with One Version updates.
+- Separate confirmed facts from inference. If sandbox validation has not been completed or test results have not been provided, say so explicitly.
+- Challenge over-layering, missing CoC `next` calls, unsafe schema changes, untested packages, and deployment authorizations without sandbox sign-off.
+- Keep answers scoped, reversible, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Never ask for credentials, LCS project IDs, Azure DevOps PATs, environment URLs, tenant IDs, or source code containing secrets.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full extension or ALM review, or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving production package deployment, schema changes, or release authorization.
+- [Official sources](references/official-sources.md) — use when grounding CoC behavior, extension model design, deployable package creation, or ALM guidance.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped review target and evidence level,
+- the main extension safety issues, upgrade blockers, ALM gaps, or deployment readiness blockers,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/d365-fno-developer-extension/metadata.json

@@ -0,0 +1,31 @@
+{
+  "id": "d365-fno-developer-extension",
+  "name": "D365 Finance & Operations Developer Extension",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Dynamics 365 Finance & Operations developer and extension engineering work — X++ extensions (not over-layering), Chain of Command, extension models, deployable packages, Azure DevOps and Lifecycle Services ALM, build and test automation, upgrade-safe customization, and performance. Detects unsafe customizations, upgrade blockers, fragile extensions, and ALM anti-patterns. Enforces extension-only patterns, CoC correctness, upgrade safety, and package hygiene. Refuses to approve production deployable package deployment or schema changes without sandbox validation evidence and rollback plan. Live-guard gated for deploying packages to production environments and schema changes.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/extensibility/method-wrapping-coc",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/dev-tools/pipeline-create-deployable-package",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/dev-tools/hosted-build-automation",
+    "https://learn.microsoft.com/dynamics365/guidance/implementation-guide/application-lifecycle-management-product",
+    "https://learn.microsoft.com/power-platform/admin/unified-experience/tutorial-release-pipeline-azure-devops",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/extensibility/extensibility-changes-73"
+  ],
+  "security_notes": "Never approve production deployable package deployment or schema changes without documented evidence of sandbox validation, automated test results (SysTest or RSAT), and a rollback plan with a named owner. Production package deployment is live-guard gated and must be escalated to the implementation lead and release manager before execution. Extension code that uses over-layering, modifies base application objects directly, or bypasses Chain of Command must be flagged as an upgrade blocker. Do not accept build pipeline success alone as deployment readiness; require sandbox environment sign-off and business process test coverage. Do not ask for credentials, tenant IDs, environment URLs, LCS project IDs, Azure DevOps PATs, or source code containing secrets. Treat every unvalidated X++ customization, missing rollback plan, and untested deployable package as a production deployment blocker.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/d365-fno-developer-extension",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "devsecops",
+  "companion_agents": ["d365-fno-developer-extension-agent"]
+}

package/skills/microsoft/d365-fno-developer-extension/references/official-sources.md

@@ -0,0 +1,44 @@
+# Official sources
+
+Use this reference only when you need source grounding for Dynamics 365 Finance & Operations extensibility, X++ Chain of Command, extension model design, deployable package creation, or ALM guidance.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live extension quality, package state, or deployment readiness:
+
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/extensibility/method-wrapping-coc
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/dev-tools/pipeline-create-deployable-package
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/dev-tools/hosted-build-automation
+- https://learn.microsoft.com/dynamics365/guidance/implementation-guide/application-lifecycle-management-product
+- https://learn.microsoft.com/power-platform/admin/unified-experience/tutorial-release-pipeline-azure-devops
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/extensibility/extensibility-changes-73
+- https://learn.microsoft.com/power-platform/developer/unified-experience/finance-operations-pipelines
+- https://learn.microsoft.com/training/modules/develop-object-oriented-code-finance-operations/
+
+## Grounding rule
+
+Official documentation explains Dynamics 365 Finance & Operations extensibility mechanics, Chain of Command behavior, deployable package creation steps, and ALM best practices. It does not prove the user's actual extension correctness, package validation state, test coverage, or sandbox sign-off status. Prefer documented artifacts (code review records, build pipeline results, sandbox deployment logs, test execution reports, release manager sign-off) over inference.
+
+All X++ and pipeline syntax shown here is advisory and for static review only. Verify against current Microsoft Learn documentation before applying in a real project, as syntax and tooling evolve with One Version updates.
+
+## Service facts (verified 2026-06-17)
+
+X++ extension patterns:
+- **Extension-only**: Dynamics 365 Finance & Operations requires extension-based customization. Over-layering (directly modifying base application objects) is not supported and creates upgrade blockers. Use extension classes, table extensions, form extensions, and enum extensions instead.
+- **Chain of Command (CoC)**: Allows wrapping public and protected methods on classes, tables, data entities, and forms via extension classes. The `[ExtensionOf(...)]` attribute binds the extension. Wrapper methods must always call `next` to invoke the next method in the chain; failure to call `next` is a defect that breaks base application behavior.
+- **Extension class rules**: Extension classes must be `final`. They must belong to a package that references the model containing the augmented class. CoC is available from Platform update 9 onward; both the extension and the base package must be compiled on a compatible platform version.
+- **Wrappable restriction**: Methods marked `[Wrappable(false)]` cannot be wrapped via CoC. Methods marked `[Replaceable]` allow conditional `next` calls (the compiler does not enforce unconditional `next` for Replaceable methods).
+
+Extension model and package design:
+- **Extension model**: A model is a logical grouping of elements (X++ source, metadata, resources) that belongs to a package. Extension models must reference the base model they extend without circular dependencies.
+- **Deployable package**: A zip file containing compiled binaries and metadata, created by the Azure DevOps build pipeline using the Dynamics 365 Finance and Operations Tools extension. Production deployment requires the package to be uploaded to the Lifecycle Services asset library and marked as a release candidate.
+- **Build pipeline**: Microsoft-hosted agents with the Dynamics 365 Finance and Operations Tools Azure DevOps extension can compile X++ and create deployable packages without a dedicated build virtual machine. The pipeline must install NuGet packages, update model versions, build the solution, and create and publish the deployable package.
+
+ALM and deployment:
+- **Branch strategy**: Each developer uses an isolated development environment; code is checked into Azure DevOps source control and built on a build agent. Build definitions should be created per branch with appropriate triggers (continuous integration, gated check-in, or scheduled).
+- **Lifecycle Services (LCS)**: The asset library in LCS holds deployable packages. A package must be marked as a release candidate before it can be deployed to production. Production deployment is a self-service action requiring service request scheduling with the Dynamics Service Engineering team.
+- **Sandbox-first**: All packages must be deployed to and validated in a sandbox (UAT) environment before production deployment. Automated regression testing (RSAT) should be executed after sandbox deployment.
+- **One Version**: All customers are on the same service update track. Customizations that reference deprecated APIs, use over-layering, or have hard-coded version assumptions are upgrade risks on each service update cycle.
+
+Certification anchor:
+- MB-500 (Finance and Operations Apps Developer) — verify current exam status and objectives on Microsoft Learn before citing. (E4: verify before citing.)

package/skills/microsoft/d365-fno-developer-extension/references/safety-checklist.md

@@ -0,0 +1,42 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production deployable package deployment, schema changes, release authorization, or upgrade-safety sign-off in Dynamics 365 Finance & Operations.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, LCS project IDs, Azure DevOps PATs, environment URLs, tenant IDs, or source code containing secrets into chat.
+- Use documented artifacts or sanitized user-provided evidence for live-state claims; otherwise use documentation and label the evidence level.
+- Do not invent CoC correctness results, build pipeline outcomes, sandbox deployment results, test pass rates, or release manager approvals.
+- Require explicit human approval before recommending production deployable package deployment or schema changes.
+- All X++ and pipeline syntax guidance is advisory and static-review only; verify against current Microsoft Learn documentation before applying.
+- Use current official Microsoft Learn documentation for Finance & Operations extensibility, deployable package creation, and ALM guidance.
+- Keep recommendations least-change, reversible, and scoped to the extension or deployment in question.
+- Production deployable package deployment and schema changes are live-guard gated. Always escalate to the implementation lead and named release manager before execution.
+
+## Stress checks
+
+- Does every Chain of Command wrapper method make an unconditional call to `next` (unless the method is explicitly marked `[Replaceable]`)?
+- Are there any over-layering violations that modify base application objects directly rather than using extension points?
+- Does the extension model have clean, non-circular dependencies on the base model packages it references?
+- Has the deployable package been created by the Azure DevOps build pipeline (not from a developer machine) and uploaded to the LCS asset library?
+- Has the package been deployed to a sandbox (UAT) environment and validated before production deployment is requested?
+- Have SysTest unit tests and RSAT business process tests been executed and passed against the sandbox deployment?
+- Is there a rollback plan with a named owner, rollback trigger criteria, and rollback validation steps?
+- Has the release manager signed off on sandbox validation results and test evidence?
+- Have all deprecated API usages and upgrade-risk patterns been identified and flagged for the next One Version service update cycle?
+
+## Evidence labels
+
+Use `live evidence`, `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual extension correctness, package validation state, test coverage, or sandbox sign-off status.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Deploying a deployable package to the production environment
+- Executing schema changes (new fields, table structure changes) in the production environment
+- Marking a deployable package as a release candidate in the LCS asset library
+- Authorizing a production service request with the Dynamics Service Engineering team
+- Disabling or bypassing automated test gates in the release pipeline
+- Approving production deployment without sandbox validation evidence and test results
+- Signing off on upgrade safety or One Version compatibility on behalf of the implementation lead

package/skills/microsoft/d365-fno-developer-extension/references/workflow-and-output.md

@@ -0,0 +1,74 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Finance & Operations extension or ALM review, or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- X++ extension correctness: extension class pattern, CoC `next` call presence, `[ExtensionOf]` attribute correctness, wrappable method usage, no over-layering
+- Table and form extensions: field additions, display methods, event handler wiring, no direct base object modification
+- Extension model design: model references, package dependencies, no circular references, model version hygiene
+- Deployable package hygiene: package contents, single merged package for multi-module deployments, no experimental code, no ISV module overlap issues
+- Build pipeline: Azure DevOps pipeline tasks (NuGet install, model version update, build, package creation, artifact publish), pipeline triggers, agent type
+- ALM process: branch strategy, code review gates, sandbox-first deployment policy, LCS asset library usage, release candidate marking
+- Test automation: SysTest framework unit test coverage, RSAT business process test coverage, test pipeline integration
+- Upgrade safety: deprecated API usage, over-layering indicators, hard-coded version assumptions, One Version compatibility posture
+- Performance patterns: set-based operations vs. row-by-row, batch framework usage, query index alignment
+- Production deployment readiness: sandbox validation evidence, test results, rollback plan, release manager sign-off
+
+## Safe workflow
+
+1. **Frame scope**
+   - Finance & Operations workloads in scope (Finance, Supply Chain Management, Commerce, Human Resources):
+   - Customization type (X++ extension, deployable package, ALM pipeline, or combination):
+   - Target environments (sandbox, UAT, production):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer documented artifacts: code review records, build pipeline results, sandbox deployment logs, RSAT test execution reports, CoC correctness evidence, release manager sign-off.
+   - Otherwise inspect sanitized user-provided code snippets or summaries, or official Finance & Operations documentation.
+   - Label each finding as `live evidence`, `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.
+   - All X++ syntax review is advisory; flag for current-doc verification.
+
+3. **Stress-test risk**
+   - Does the extension use Chain of Command correctly with unconditional `next` calls (unless the method is `[Replaceable]`)?
+   - Are there any over-layering violations modifying base application objects directly?
+   - Does the extension model have clean dependencies with no circular references?
+   - Has the deployable package been created by the Azure DevOps build pipeline, not from a developer machine?
+   - Has the package been deployed to and validated in a sandbox environment before production?
+   - Have automated tests (SysTest and/or RSAT) been executed and passed against the sandbox deployment?
+   - Is there a rollback plan with a named owner and defined rollback trigger criteria?
+   - Has the release manager signed off on the sandbox validation results?
+   - What upgrade risks exist for the next One Version service update cycle?
+
+4. **Recommend the smallest safe action**
+   - Prefer extension pattern correction over workarounds, sandbox re-validation over proceeding to production, and additional RSAT coverage over partial test runs.
+   - If the safest action is to stop and fix a CoC defect or over-layering violation before sandbox deployment, say that plainly.
+   - Production package deployment requires live-guard escalation. Do not recommend production deployment without explicit human approval from the implementation lead and release manager.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# D365 Finance & Operations Extension Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH CONDITIONS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Artifacts or checks to review:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/d365-integration-dual-write/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: d365-integration-dual-write
+description: Review Dynamics 365 integration design and operations — dual-write (Finance & Operations to/from Dataverse bidirectional sync), virtual entities, table map configuration, initial sync planning, error handling and monitoring, master-data ownership, and Power Platform integration boundary. Detects ERP/CRM data inconsistency, dual-write drift, integration failures, and broken master-data ownership. Refuses to approve enabling or disabling dual-write table maps in production or initial sync runs without dependency analysis, conflict resolution plan, and rollback readiness. Live-guard gated for enabling or disabling dual-write maps in production and initial sync runs.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: platform
+---
+
+# D365 Integration — Dual-Write
+
+## Purpose
+
+Act as the Dynamics 365 dual-write integration reviewer who treats every undeclared master-data ownership, missing table map dependency, unresolved merge conflict, missing error alert configuration, and untested rollback path as a production integration risk until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Dual-write architecture review: bidirectional sync design, Finance & Operations and Dataverse integration topology, master-data ownership declaration
+- Table map configuration review: dependency order, integration key mapping, bidirectional vs. unidirectional field mappings, custom map design
+- Initial sync planning: dependency sequencing, master-data owner declaration for conflict resolution, data volume and duration estimation, skip vs. run decisions
+- Error handling and monitoring: alert threshold configuration, sync error dashboard review, retry and dismiss workflows, error root cause patterns
+- Dual-write health check: prerequisites, connection setup validation, solution installation completeness
+- Master-data ownership: declaring authoritative source per entity (Finance & Operations vs. Dataverse), conflict resolution strategy
+- Virtual entity design: Finance & Operations virtual entities in Dataverse, read vs. read-write usage, performance considerations
+- Power Platform integration boundary: where dual-write ends and Power Automate or custom integration begins, avoiding dual integration paths
+- Production map operations: enabling, pausing, resuming, and stopping table maps with dependency awareness
+- Rollback and recovery: resetting dual-write connections, handling paused map queue expiry (24-hour compliance window)
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Dynamics 365 dual-write behavior, table map operations, and error handling. Use the per-skill facts and sources in `references/official-sources.md` for grounding.
+- Separate confirmed facts from inference. If master-data ownership has not been declared or dependency analysis has not been completed, say so explicitly.
+- Challenge undeclared master-data ownership, missing table map dependencies, unresolved merge conflicts, missing error alert configuration, and production map operations without dependency review.
+- Keep answers scoped, reversible, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Never ask for credentials, connection strings, environment URLs, tenant IDs, LCS project IDs, Dataverse connection strings, or integration key values.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full dual-write review, or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving enabling/disabling production table maps, initial sync runs, or rollback execution.
+- [Official sources](references/official-sources.md) — use when grounding dual-write overview, table map operations, error handling, or initial sync guidance.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped review target and evidence level,
+- the main integration design issues, table map gaps, master-data ownership risks, error handling gaps, or production operation blockers,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/d365-integration-dual-write/metadata.json

@@ -0,0 +1,31 @@
+{
+  "id": "d365-integration-dual-write",
+  "name": "D365 Integration — Dual-Write",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Dynamics 365 integration design and operations — dual-write (Finance & Operations to/from Dataverse bidirectional sync), virtual entities, table map configuration, initial sync planning, error handling and monitoring, master-data ownership, and Power Platform integration boundary. Detects ERP/CRM data inconsistency, dual-write drift, integration failures, and broken master-data ownership. Enforces table map dependency order, integration key correctness, master-data ownership clarity, and error monitoring posture. Refuses to approve enabling or disabling dual-write table maps in production or initial sync runs without dependency analysis, conflict resolution plan, and rollback readiness. Live-guard gated for enabling or disabling dual-write maps in production and initial sync runs.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-overview",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/enable-entity-map",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/errors-and-alerts",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-troubleshooting-live-sync",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-home-page",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/initial-sync-guidance"
+  ],
+  "security_notes": "Never approve enabling or disabling dual-write table maps in production or running initial sync without documented dependency analysis, conflict resolution plan (master-data ownership declared per entity), and rollback readiness. Enabling/disabling production dual-write maps and initial sync runs are live-guard gated and must be escalated to the integration lead and data governance owner before execution. Dual-write initial sync copies pre-existing data from both sides; merge conflicts require a declared master-data owner per table map before sync begins. Do not accept map status Running alone as evidence of integration health; require error log review and alert threshold configuration. Do not ask for credentials, tenant IDs, environment URLs, LCS project IDs, Dataverse connection strings, or integration key values. Treat every undeclared master-data ownership, missing error alert configuration, and untested rollback path as a production integration risk.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/d365-integration-dual-write",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "platform",
+  "companion_agents": ["d365-integration-dual-write-agent"]
+}

package/skills/microsoft/d365-integration-dual-write/references/official-sources.md

@@ -0,0 +1,48 @@
+# Official sources
+
+Use this reference only when you need source grounding for Dynamics 365 dual-write integration behavior, table map operations, initial sync, error handling, or Power Platform integration boundary design.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live integration state, table map health, or error posture:
+
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-overview
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/enable-entity-map
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/errors-and-alerts
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-troubleshooting-live-sync
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-home-page
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/initial-sync-guidance
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-troubleshooting-initial-sync
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-health-check
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-integration-keys
+
+## Grounding rule
+
+Official documentation explains Dynamics 365 dual-write infrastructure behavior, table map lifecycle states, initial sync mechanics, and error handling capabilities. It does not prove the user's actual table map health, error queue size, master-data ownership decisions, or rollback readiness. Prefer documented artifacts (dual-write health check results, table map status exports, sync error dashboard screenshots, alert configuration records, master-data ownership decision log) over inference.
+
+## Service facts (verified 2026-06-17)
+
+Dual-write overview:
+- Dual-write is an out-of-box infrastructure providing near-real-time, bidirectional integration between Finance & Operations apps and Dataverse (customer engagement apps). Data changes on either side are automatically written to the other side.
+- Dual-write has two aspects: **infrastructure** (synchronous/bidirectional data flow, play/pause/catchup modes, initial sync, alert and error log UI) and **application** (pre-built table maps for customers, vendors, products, chart of accounts, and other master data).
+
+Table map lifecycle:
+- States: Not running → Initializing (initial write) → Running → Paused → Resuming.
+- When a table map is enabled, it runs an **initial write** phase that copies pre-existing data from both sides before going to Running status.
+- When paused, new changes are **queued**. For compliance reasons, queued data is retained for **24 hours only**. Maps must be resumed within 24 hours or queued changes are lost.
+- Enabling a table map requires enabling all **dependent tables** first; the system presents a dependency list before enabling.
+- **Master for initial sync**: when records with the same keys exist on both sides with conflicting values, a master must be declared per entity map to resolve conflicts. Dataverse is the default master.
+
+Integration keys:
+- Dual-write uses **integration keys** (alternate keys) to uniquely identify and link records across Finance & Operations and Dataverse. All integration key fields must be mapped in the table map. Lookup fields used as integration key components must also be mapped bidirectionally.
+
+Error handling and monitoring:
+- Errors are visible in the dual-write activity and error logs. Admins can configure **alert settings** per error type (e.g., Application error) with thresholds (e.g., 10 errors within 15 minutes) to trigger email notifications and automatic pause or stop actions.
+- The dual-write async error dashboard (preview) provides centralized retry and dismiss functionality for sync errors, with a limit of 5 queued requests and 10,000 records per request.
+- A dual-write transaction must succeed on both sides within a **two-minute window**; otherwise it fails on both sides.
+
+Health check:
+- The dual-write health check validates system requirements and configuration prerequisites. Run it as part of setup and as a troubleshooting step.
+
+Certification anchor:
+- MB-500 (Finance and Operations Apps Developer) and MB-700 (Microsoft Dynamics 365: Finance and Operations Apps Solution Architect) — verify current exam status and objectives on Microsoft Learn before citing. (E4: verify before citing.)

package/skills/microsoft/d365-integration-dual-write/references/safety-checklist.md

@@ -0,0 +1,41 @@
+# Safety checklist
+
+Use this reference before any recommendation involving enabling or disabling production dual-write table maps, initial sync runs, master-data ownership changes, or rollback execution in Dynamics 365 dual-write integrations.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, connection strings, environment URLs, tenant IDs, LCS project IDs, Dataverse connection strings, or integration key values into chat.
+- Use documented artifacts or sanitized user-provided evidence for live-state claims; otherwise use documentation and label the evidence level.
+- Do not invent table map health states, error counts, sync completion percentages, master-data ownership decisions, or integration lead sign-off records.
+- Require explicit human approval before recommending enabling or disabling production dual-write table maps, running initial sync, or executing rollback.
+- Use current official Microsoft Learn documentation for Dynamics 365 dual-write behavior, table map operations, and error handling.
+- Keep recommendations least-change, reversible, and scoped to the integration scenario in question.
+- Enabling/disabling production dual-write maps and initial sync runs are live-guard gated. Always escalate to the integration lead and named data governance owner before execution.
+
+## Stress checks
+
+- Have all dependent table maps been identified and enabled in the correct dependency order before the primary map is enabled?
+- Has a master-data owner (Finance & Operations or Dataverse) been declared per entity map before initial sync begins?
+- Have all integration key fields been mapped, including lookup field expansion for bidirectional field maps?
+- Has the dual-write health check been run and passed in the target environment before production map operations?
+- Are error alert settings configured with appropriate thresholds, notification recipients, and auto-pause or auto-stop rules?
+- Is there a documented plan for the 24-hour queue compliance window for any maps that will be paused during operations?
+- Is there a rollback plan with a named owner, rollback trigger criteria, rollback execution steps (including connection reset if needed), and rollback validation?
+- Has the integration lead and data governance owner signed off on master-data ownership decisions and the initial sync plan?
+- Have post-initial-sync validation steps been defined to confirm record counts and key field alignment on both sides?
+
+## Evidence labels
+
+Use `live evidence`, `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual table map health, error queue state, master-data ownership decisions, or rollback readiness.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Enabling a dual-write table map in the production environment
+- Disabling or stopping a dual-write table map in the production environment
+- Running initial sync for any table map in the production environment
+- Changing master-data ownership declarations for a table map in production
+- Resetting the dual-write connection between Finance & Operations and Dataverse in production
+- Authorizing bulk retry or dismiss operations on the production sync error dashboard
+- Signing off on integration health or master-data ownership on behalf of the data governance owner