Use as a HARD GATE at the start of Phase 1.1 (and any time new files arrive in `Requirements/`) to validate that every source document can actually be read and that the extracted content is sufficient. Detects encrypted/password-protected files, corrupt files, scanned-image PDFs that need OCR, empty or suspiciously short extractions, unsupported formats, and macro-enabled Office files. Produces `Documentation/source-document-validation.json` (machine-readable) and `Documentation/source-document-validation.md` (human-readable). If ANY document is classified as `blocker`, Phase 1.1 (`d365-requirements-analysis`) MUST NOT proceed — surface the blocker list to the user and request unencrypted/readable replacements before continuing.
Use after the requirement profile is complete to translate requirements into deployable configuration files (DMF JSON templates, CSV data files, parameter-settings markdown), produce the cross-module rollout plan and end-to-end test plan, validate completeness, and run the Phase 1 approval gate. Covers Phase 1 Steps 1.2 → 1.5 of the D365 F&O implementation lifecycle. Source files produced here are the AUTHORITATIVE source of truth for everything that gets deployed in Phase 2.
Use at the start of a new D365 F&O project, or when requirements change, to ingest raw requirement documents from the `Requirements/` folder, classify each requirement (Standard Config, Data Migration, Parameter Setting, Workflow, Integration, Gap, Clarification), map every requirement to the correct module/entity/feature, and produce `Documentation/requirement-profile.md` and `Documentation/requirement-matrix.json`. This is Phase 1 Step 1.1 of the implementation lifecycle.
Use after deployment to validate the F&O environment by executing every end-to-end business-process test scenario from `Documentation/test-scenarios.json` start-to-finish (Source-to-Pay, Order-to-Cash, Record-to-Report, etc.). Drives the fix-loop — when a test fails, fix the SOURCE configuration file, re-deploy via the `d365-deployment` skill, then re-test. This is Phase 2 Step 2.2 of the implementation lifecycle. Pair with `fo-mcp-server` and `reinforcement-learning`.
NON-NEGOTIABLE compliance gate for any project that configures D365 Finance modules (General Ledger, AP, AR, Fixed Assets, Cash & Bank, Tax, Budgeting, Project Accounting, Expense). Captures the customer's applicable accounting and regulatory frameworks (US GAAP, IFRS, local GAAPs, SOX, ASC 606 / IFRS 15, ASC 842 / IFRS 16, SAF-T, GoBD, MTD-VAT, ESG/CSRD, etc.) at Phase 1.1, and validates the proposed AND deployed configuration against them at Phase 1.4 (config validation), Phase 1.5 (approval gate), and Phase 2.2 (E2E testing). If any check has `result = fail` and `severity = blocker`, the project STOPS — Phase 1.5 cannot pass and Phase 2.1 must not start. Produces `Documentation/compliance-validation.json` and `Documentation/compliance-validation.md`.
Use after Phase 2 validation passes to generate the Phase 3 HTML deliverable suite under `Documentation/html/`. Produces seven single-file HTML documents — two narrative reports (`rollout-report.html`, `environment-config.html`) plus five interactive dashboards (`test-results.html`, `challenge-journal.html`, `process-catalogue.html`, `dependency-graph.html`, `run-state.html`). All seven are self-contained — embedded CSS/JS, no external network calls, professional styling, interactive elements (collapsible sections, search/filter, diagrams). Pull data exclusively from Phase 1 / Phase 2 artefacts and from the canonical JSON files under `Modules/`, `ChallengeJournal/`, `Documentation/` — never invent.
Use after the Phase 1 approval gate passes to deploy configuration to a Dynamics 365 F&O environment via the Dynamics 365 ERP MCP server. Walks each module in DMF dependency order (010 → 650) through pre-deployment checks, data-entity deployment (Priority 1 — `data_*` tools), form-based deployment (Priority 2 — `form_*` tools), post-deployment actions (Priority 3 — `api_*` tools), and per-module validation. This is Phase 2 Step 2.1. ALWAYS pair with the `fo-mcp-server` skill (which holds the operational rules for every MCP tool call) and the `reinforcement-learning` skill (for failure logging).
Use when you need a file path. Provides the keyword router and DMF dependency rules so any task can find the right module knowledge file (`.md`), DMF template (`.json`), or supporting artefact. The full 47-module index and end-to-end process matrix live in the sidecar `module-index.md` — load that ONLY when you need exhaustive lookups. Do NOT load this skill speculatively; only when a path is unknown.