VibeConfigStarterKit

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.

Use when interacting with a Dynamics 365 Finance & Operations environment through the Dynamics 365 ERP MCP server — i.e. whenever a `data_*`, `form_*`, or `api_*` MCP tool call is planned. Covers tool selection hierarchy, naming conventions, OData/SQL querying, form navigation, action invocation, prerequisites (feature flag, allowed clients, version requirements), and the dynamic-vs-static server distinction. Read BEFORE the first tool call of any deployment, validation, or data-exploration task.

⚠️ SUB-AGENT ONLY — never invoke from main context. Invoked by `module-fanout` from `d365-config-builder`. Builds ALL configuration artefacts for ONE D365 F&O module during Phase 1.2. The worker reads the assigned module's `.md` knowledge file and existing DMF template, derives field values from its scoped requirements, produces the updated DMF JSON, per-entity CSV data files, parameter-settings markdown, and a per-module config summary — then returns the standard fan-out output contract (see `schemas/fan-out-contract.schema.json`). Stays in its OWN context window so the orchestrator never sees module-level detail.

⚠️ SUB-AGENT ONLY — never invoke from main context. Invoked by `module-fanout` from `d365-deployment`. Deploys ONE D365 F&O module to a live environment during Phase 2.1. The worker pre-checks upstream state, walks the module's deployment plan (data entities → form config → actions) using the Dynamics 365 ERP MCP server (`data_*` → `form_*` → `api_*`), validates the deployed state, logs failures via `reinforcement-learning`, and returns the standard fan-out output contract (see `schemas/fan-out-contract.schema.json`). Pairs MANDATORILY with the `fo-mcp-server` skill — every MCP tool call must follow those rules.

Use whenever a phase skill needs to perform repetitive per-module work across multiple D365 F&O modules (config building in Phase 1.2, deployment in Phase 2.1, validation in Phase 2.2). Defines the sub-agent dispatch pattern, the input/output contract every worker must honour, the parallelization rules (parallel within DMF `ExecutionUnit`, sequential across), the wave/batch sequencing for DMF order (010 → 650), result aggregation, and failure-handling/retry semantics. Pairs each module-level call with the appropriate worker skill (`module-config-worker`, `module-deployment-worker`, `module-validation-worker`).

⚠️ SUB-AGENT ONLY — never invoke from main context. Invoked by `module-fanout` from `d365-validation-testing`. Executes the E2E test scenarios touching ONE module's process slice during Phase 2.2. Drives every assigned scenario through the D365 F&O MCP server start-to-finish, captures pass/fail per step, runs the localized fix-loop (fix source → request re-deploy via orchestrator → re-test), logs failures, and returns the standard fan-out output contract (see `schemas/fan-out-contract.schema.json`). Pairs MANDATORILY with `fo-mcp-server` and `reinforcement-learning`.

Top-level dispatcher for the D365 F&O implementation lifecycle. Use FIRST on any new user request — it classifies the request (Phase 1 analysis, Phase 1 config, Phase 2 deployment, Phase 2 testing, Phase 3 docs, troubleshooting), checks prerequisite gates (e.g. Phase 1 approval before Phase 2), picks the right phase skill, and manages hand-offs between phases. Drives the `module-fanout` skill when a phase needs per-module parallelism. Keeps the main agent's context lean by delegating heavy work to sub-agents instead of loading everything inline.

Use whenever a challenge, error, workaround, or non-obvious discovery is encountered during ANY phase of D365 F&O work. Captures the issue in `ChallengeJournal/challenge_journal.json`, classifies it (Rule / Discovery / Gap / Sequence), routes the insight to the correct destination (module `.md` file, DMF template, or process catalogue), and verifies the update so the next similar challenge is resolved faster. Also: ALWAYS query the journal BEFORE risky operations to apply known preventive measures.