@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/microsoft/d365-data-migration-cutover/references/official-sources.md

@@ -0,0 +1,51 @@
+# Official sources
+
+Use this reference only when you need source grounding for Dynamics 365 data migration, Data Management Framework behavior, or cutover strategy guidance.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live migration state or data quality posture:
+
+- https://learn.microsoft.com/dynamics365/guidance/implementation-guide/prepare-to-go-live
+- https://learn.microsoft.com/dynamics365/guidance/implementation-guide/prepare-go-live-checklist
+- https://learn.microsoft.com/dynamics365/guidance/implementation-guide/prepare-go-live-cutover-strategy
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/data-entities-data-packages
+- https://learn.microsoft.com/dynamics365/fin-ops-core/fin-ops/data-entities/data-import-export-job
+- https://learn.microsoft.com/training/modules/prepare-data-migration-finance-operations/
+- https://learn.microsoft.com/power-platform/architecture/key-concepts/data-migration/cut-over-planning
+- https://learn.microsoft.com/dynamics365/guidance/fasttrack/go-live-workshops
+
+## Grounding rule
+
+Official documentation explains Dynamics 365 data management framework behavior, data entity design, and cutover strategy guidance. It does not prove the user's actual migration job results, staging table validation outcomes, reconciliation totals, or rollback plan readiness. Prefer documented migration artifacts (mock migration results, staging error logs, reconciliation reports, cutover runbook sign-offs) over inference.
+
+## Service facts (verified 2026-06-16)
+
+Data Management Framework (DMF) structure:
+- The DMF in finance and operations apps (Dynamics 365 Finance, Supply Chain Management, Commerce, Human Resources) provides the primary mechanism for data migration via **data entities**, **data projects**, **data jobs**, and **data packages**.
+- **Data entity**: conceptual abstraction over one or more underlying tables representing a business concept (e.g., Customers, Vendors, Chart of Accounts).
+- **Staging tables**: intermediate tables created per entity during import. Data is validated in staging before promotion to target tables. Staging table errors must be resolved before the job succeeds.
+- **Data package**: a compressed file containing a data project manifest and data files, used for bulk import or export across environments.
+- **Job history**: tracks source-to-staging and staging-to-target execution results, error counts, and status.
+
+Migration sequencing:
+- Entities must be migrated in dependency order: reference data and configuration data before transactional data (e.g., chart of accounts and legal entity setup before journal entries).
+- Common sequence: legal entity configuration → number sequences → reference data (currencies, payment terms, tax codes) → master data (customers, vendors, items, fixed assets) → open transactions (open purchase orders, open invoices, open balances).
+
+Mock migration (dry run) requirements:
+- Mock migrations must be performed in a non-production environment using production-representative data volumes.
+- Measure CRUD throughput (records per second) to estimate production migration duration. Include a 20–30% buffer for monitoring overhead.
+- For large datasets (millions of records), plan full migration plus delta loads: full migration completed weeks before go-live, followed by incremental delta loads to reduce final cutover window.
+- Mock migration results must be documented: entity job results, staging error counts, reconciliation totals, and elapsed time per entity.
+
+Cutover planning:
+- The cutover plan must include: all task sequences with owners and durations, system freeze timing for source and target, final delta migration steps, data validation steps, go/no-go checkpoint criteria, rollback triggers, and rollback execution steps.
+- A go/no-go meeting with stakeholder sign-off is required before cutover begins.
+- Rollback must be defined: what triggers rollback, who owns rollback execution, how long rollback takes, and what validation confirms successful rollback.
+
+Go-live checklist data migration items:
+- Test data migration several times before cutover (multiple mock migrations).
+- Validate strategy and processes; identify and address data corruption or duplication.
+- Test and sign off on all scripts and processes planned for cutover migration.
+- Log any migration issues and risks with a mitigation plan.
+- Business stakeholder sign-off on migration results required before production promotion.

package/skills/microsoft/d365-data-migration-cutover/references/safety-checklist.md

@@ -0,0 +1,40 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production data migration authorization, cutover go/no-go approval, rollback execution, or compliance-impacting data promotion decisions in Dynamics 365 implementations.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, connection strings, environment URLs, tenant IDs, client secrets, certificates, or customer personally identifiable information into chat.
+- Use documented migration artifacts or sanitized user-provided evidence for live-state claims; otherwise use documentation and label the evidence level.
+- Do not invent migration job results, staging error counts, reconciliation totals, entity coverage lists, or cutover window estimates.
+- Require explicit human approval before recommending any production data migration, cutover execution, or rollback.
+- Use current official Microsoft Learn documentation for Dynamics 365 Data Management Framework and cutover strategy behavior.
+- Keep recommendations least-change, reversible, and scoped to the data domain in question.
+- Production data migration and cutover are live-guard gated. Always escalate to the implementation lead and named business data owner before execution.
+
+## Stress checks
+
+- Has at least one mock migration been completed with documented results (staging errors, elapsed time, reconciliation totals)?
+- Have all staging table errors from mock migrations been resolved and re-validated?
+- Does reconciliation evidence include field-level sampling and financial balance checks, not just record counts?
+- Is the cutover window duration realistic based on measured throughput plus a 20–30% buffer?
+- Is there a tested rollback plan with named owner, rollback trigger criteria, rollback execution steps, and rollback validation?
+- Has the business data owner signed off on migration results from the most recent mock migration?
+- Is there a delta load strategy for data that changes between the final mock migration and production cutover?
+- What post-migration validation steps are planned for day-one business operations?
+
+## Evidence labels
+
+Use `live evidence`, `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual migration job results, staging validation status, reconciliation outcomes, or rollback readiness.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Authorizing or executing production data migration jobs
+- Issuing a go/no-go decision for production cutover
+- Executing rollback from production migration
+- Promoting data from staging tables to production target tables in the live environment
+- Freezing source legacy systems for final delta migration
+- Signing off on reconciliation results on behalf of the business data owner
+- Authorizing deletion or archival of legacy source data after migration validation

package/skills/microsoft/d365-data-migration-cutover/references/workflow-and-output.md

@@ -0,0 +1,72 @@
+# Workflow and output contract
+
+Use this reference only when performing the full data migration or cutover readiness review, or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Migration strategy: entity selection, dependency sequence, full vs. delta load approach, data volume estimates
+- Data quality: legacy data cleansing status, known issues, deduplication, null handling, format alignment
+- Data Management Framework setup: data entities mapped to legacy source fields, staging table configuration, error handling
+- Mock migration results: number of dry runs completed, staging error counts per entity, elapsed time per entity, reconciliation totals
+- Reconciliation controls: record count comparison, field-level sampling, financial balance reconciliation, business user validation sign-off
+- Cutover runbook: task sequence, owners, durations, dependencies, system freeze timing, delta load steps, go/no-go checkpoint
+- Rollback plan: rollback trigger criteria, rollback owner, rollback execution steps, rollback validation, rollback time estimate
+- Stakeholder sign-off: named business data owner and implementation lead approvals, dated
+- Post-migration hyper-care: data issue triage path, escalation owner, validation checklist for day-one operations
+
+## Safe workflow
+
+1. **Frame scope**
+   - Dynamics 365 workloads in scope (Finance, Supply Chain Management, Customer Service, other):
+   - Legacy systems being migrated from:
+   - Data domains in scope (master data, reference data, open transactions, historical data):
+   - Go-live date and cutover window duration:
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer documented artifacts: mock migration result logs, staging table error exports, reconciliation reports, cutover runbook, rollback plan document, business owner sign-off.
+   - Otherwise inspect sanitized user-provided summaries or official Dynamics 365 documentation.
+   - Label each finding as `live evidence`, `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test risk**
+   - Has at least one mock migration been completed and documented?
+   - Have staging table errors been resolved and re-validated?
+   - Does reconciliation evidence go beyond record counts to include field-level sampling and balance checks?
+   - Is the cutover window realistic given measured migration throughput and buffer?
+   - Is there a tested rollback plan with named owner and documented trigger criteria?
+   - Has the business data owner signed off on migration results?
+   - What happens if migration fails at 60% through the cutover window?
+   - What evidence is missing that would change the verdict?
+
+4. **Recommend the smallest safe action**
+   - Prefer additional mock migrations over proceeding to production, staged delta loads over big-bang migration, and staging validation resolution before production promotion.
+   - If the safest action is to stop and complete another mock migration or resolve staging errors, say that plainly.
+   - Production data migration requires live-guard escalation. Do not recommend production migration without explicit human approval from the implementation lead and business data owner.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# D365 Data Migration & Cutover 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-field-service-to-cash/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: d365-field-service-to-cash
+description: Review Dynamics 365 Field Service operations across the service-to-cash (now "service to deliver") lifecycle — work order management, Universal Resource Scheduling, schedule board and Resource Scheduling Optimization, bookable resources, technician mobile execution, asset and preventive maintenance, inventory/truck stock, and work-order-to-invoice billing. Use to improve first-time-fix rate, scheduling efficiency, and service revenue capture. Static review only; production scheduling-engine and billing-configuration changes are escalated.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: operational
+---
+
+# D365 Field Service to Cash
+
+## Purpose
+
+Act as the Dynamics 365 Field Service operations reviewer who treats every unscheduled work order, low first-time-fix rate, untracked truck-stock consumption, and uninvoiced completed booking as service revenue leakage until proven otherwise. Cover the full service-to-deliver lifecycle from work order creation through scheduling, technician execution, inventory consumption, and invoicing.
+
+## When to use
+
+Use this skill for:
+
+- Work order design: incident types, work order types, characteristics, territories, priorities
+- Scheduling review: schedule board, schedule assistant, Universal Resource Scheduling, Resource Scheduling Optimization (RSO)
+- Bookable resource setup: skills/characteristics, resource types, working hours, geographic territories
+- First-time-fix improvement: parts availability, skill matching, incident-type task templates
+- Technician mobile execution: booking status flow, timestamps, booking journals, offline readiness
+- Asset management and preventive maintenance agreements
+- Inventory and truck stock: consumption tracking, replenishment, purchase orders, returns
+- Service billing: work-order-to-invoice flow, products/services, actuals, finance and operations integration
+- Field Service KPIs: utilization, first-time-fix, mean time to resolution, service revenue capture
+
+Do not use this skill for:
+
+- Customer Service case/omnichannel routing (use d365-customer-service-contact-center)
+- Sales pipeline/forecasting (use d365-sales-revenue-operations)
+- Implementation phase-gate governance (use d365-success-by-design-governance)
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Field Service, Universal Resource Scheduling, and the service-to-deliver business process. Note Microsoft renamed "service to cash" to "service to deliver" in the February 2025 Business Process Catalog; verify current terminology.
+- Separate confirmed facts from inference. If scheduling metrics or work order data were not provided, say so.
+- Challenge unscheduled work order backlogs, low first-time-fix rates, manual-only scheduling at scale, untracked inventory consumption, and completed bookings that never produced an invoice.
+- Keep answers scoped, reversible, and explicit about blockers or unknowns.
+- Load references only when needed.
+- Never ask for credentials, environment URLs, tenant IDs, connection strings, or customer data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full Field Service review or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving production scheduling-engine, RSO optimization, or billing configuration changes.
+- [Official sources](references/official-sources.md) — use when grounding Field Service, scheduling, or service-to-deliver process behavior.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main scheduling, first-time-fix, inventory, or billing gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/d365-field-service-to-cash/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "d365-field-service-to-cash",
+  "name": "D365 Field Service to Cash",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Dynamics 365 Field Service across the service-to-deliver (formerly service-to-cash) lifecycle: work order management, Universal Resource Scheduling, schedule board, Resource Scheduling Optimization, bookable resources, technician mobile execution, asset and preventive maintenance, inventory and truck stock, and work-order-to-invoice billing to reduce service revenue leakage and improve first-time-fix.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/field-service/overview",
+    "https://learn.microsoft.com/dynamics365/field-service/universal-resource-scheduling-for-field-service",
+    "https://learn.microsoft.com/dynamics365/field-service/field-service-architecture",
+    "https://learn.microsoft.com/dynamics365/field-service/rso-overview",
+    "https://learn.microsoft.com/dynamics365/guidance/business-processes/service-to-cash-create-process-service-work"
+  ],
+  "security_notes": "Static review only. Do not modify production scheduling engine configuration, Resource Scheduling Optimization parameters, or billing/invoicing setup; these are escalated to a qualified Field Service administrator with a rollback plan. Do not ask for credentials, environment URLs, tenant IDs, connection strings, or customer data. Treat unscheduled work order backlogs, low first-time-fix rates, untracked truck-stock consumption, and uninvoiced completed bookings as service revenue leakage risks until reviewed.",
+  "last_verified": "2026-06-16",
+  "path": "skills/microsoft/d365-field-service-to-cash",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "operational",
+  "companion_agents": ["d365-field-service-to-cash-agent"]
+}

package/skills/microsoft/d365-field-service-to-cash/references/official-sources.md

@@ -0,0 +1,21 @@
+# Official sources
+
+Use this reference only when you need source grounding for Dynamics 365 Field Service behavior or the service-to-deliver business process.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live Field Service configuration or operational metrics:
+
+- https://learn.microsoft.com/dynamics365/field-service/overview — Field Service capabilities: work orders, scheduling/dispatch, mobile app, asset management, preventive maintenance, inventory/purchasing/returns, billing, time tracking, analytics. Supports the scope and KPI workflow steps.
+- https://learn.microsoft.com/dynamics365/field-service/universal-resource-scheduling-for-field-service — Universal Resource Scheduling: requirements generated from work orders, bookable resource bookings, scheduling personas (dispatcher, scheduling analyst), manual/semi-automated/automated scheduling. Supports the scheduling review step.
+- https://learn.microsoft.com/dynamics365/field-service/field-service-architecture — Work order architecture: requirement→booking lifecycle, booking timestamps and journals, inventory consumption, and invoice creation on work order close. Supports the service-to-deliver flow and billing steps.
+- https://learn.microsoft.com/dynamics365/field-service/rso-overview — Resource Scheduling Optimization add-in (separate license) for automated scheduling and utilization optimization. Supports the automated-scheduling and licensing pushback steps.
+- https://learn.microsoft.com/dynamics365/guidance/business-processes/service-to-cash-create-process-service-work — "Manage service work" process area within the Service to deliver (formerly service to cash) end-to-end scenario: create → schedule → perform → review/close → invoice → record payment. Supports the end-to-end lifecycle workflow.
+
+## Terminology note
+
+Microsoft renamed the "service to cash" end-to-end scenario to "service to deliver" beginning with the February 2025 Business Process Catalog. Some Learn articles are not yet fully updated. Verify current terminology before presenting process names.
+
+## Grounding rule
+
+Official documentation explains Field Service behavior. It does not prove the user's actual work order backlog, scheduling utilization, first-time-fix rate, inventory accuracy, or invoicing completeness. Prefer exported reports, sanitized user-provided metrics, or read-only evidence for current-state claims.

package/skills/microsoft/d365-field-service-to-cash/references/safety-checklist.md

@@ -0,0 +1,35 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production scheduling-engine changes, Resource Scheduling Optimization parameters, or billing/invoicing configuration in Dynamics 365 Field Service.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, tenant IDs, environment URLs, connection strings, certificates, or customer data into chat.
+- Use exported reports or sanitized user-provided evidence for current-state claims; otherwise use documentation and label the evidence level.
+- Do not invent utilization rates, first-time-fix percentages, work order counts, or revenue figures.
+- Require explicit human approval before recommending any production scheduling-engine, RSO optimization-schedule, or billing-configuration change.
+- Use current official Microsoft Learn documentation for Field Service and Universal Resource Scheduling behavior.
+- Keep recommendations least-change, reversible, and scoped to the domain in question.
+
+## Stress checks
+
+- What unscheduled or repeatedly rescheduled work orders indicate a scheduling or resourcing gap?
+- What drives low first-time-fix (missing parts on truck, skill mismatch, incomplete task templates)?
+- What completed bookings have no corresponding invoice (service revenue leakage)?
+- Is truck-stock consumption tracked and replenished, or is inventory drifting?
+- Is RSO licensed and configured before recommending automated optimization?
+- What rollback exists if a scheduling-engine or billing change misbehaves in production?
+
+## Evidence labels
+
+Use `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual scheduling utilization, first-time-fix rate, inventory accuracy, or invoicing completeness.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Changing production Resource Scheduling Optimization parameters or optimization schedules
+- Modifying production schedule board configuration or scheduling rules at scale
+- Changing work-order-to-invoice billing configuration or finance and operations integration mappings
+- Executing bulk work order, booking, or inventory updates
+- Altering bookable resource working hours, territories, or skills in bulk in production

package/skills/microsoft/d365-field-service-to-cash/references/workflow-and-output.md

@@ -0,0 +1,66 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Dynamics 365 Field Service to cash (service-to-deliver) review or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Work order design: incident types and task templates, work order types, characteristics, territories, priorities
+- Scheduling: schedule board usage, schedule assistant, Universal Resource Scheduling, Resource Scheduling Optimization (and its separate license)
+- Bookable resources: skills/characteristics, working hours, geographic territories, resource types (employee, contractor, equipment)
+- First-time-fix: parts on truck, skill matching, incident-type task completeness, preventive maintenance coverage
+- Mobile execution: booking status lifecycle (Scheduled → Traveling → In Progress → Completed), timestamps, booking journals, offline readiness
+- Inventory and truck stock: consumption tracking, replenishment, purchase orders, returns
+- Billing: work-order-to-invoice flow, products/services, actuals, finance and operations integration (worker alignment)
+- KPIs: resource utilization, first-time-fix rate, mean time to resolution, schedule adherence, service revenue capture
+
+## Safe workflow
+
+1. **Frame scope**
+   - Lifecycle stage in scope (work order design / scheduling / mobile execution / inventory / billing):
+   - Field Service edition and add-ins (RSO, Field Service mobile, finance & operations integration):
+   - Required outcome (scheduling efficiency / first-time-fix / revenue capture / KPI review):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer exported reports: work order aging, booking utilization, first-time-fix, inventory variance, uninvoiced completed work.
+   - Otherwise inspect sanitized user-provided summaries or official Microsoft Learn documentation.
+   - Label each finding as `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test risk**
+   - What work orders are unscheduled or repeatedly rescheduled, and why?
+   - Where does first-time-fix break down (parts, skills, task templates)?
+   - What completed bookings never generated an invoice (revenue leakage)?
+   - Is truck-stock consumption tracked and replenished, or is inventory drifting?
+   - What evidence is missing that would change the verdict?
+
+4. **Recommend the smallest safe action**
+   - Prefer configuration and process fixes over scheduling-engine changes.
+   - Production scheduling-engine, RSO parameter, and billing-configuration changes require live-guard escalation with a rollback plan.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# D365 Field Service to Cash Review: <scope>
+## Executive verdict
+- Status: HEALTHY / HEALTHY WITH RISKS / AT RISK / 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 review:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/d365-finance-close-to-report/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: d365-finance-close-to-report
+description: Review Dynamics 365 Finance general ledger configuration, sub-ledger reconciliation, period-end and year-end close procedures, financial consolidation and elimination, posting profiles, tax setup, and financial reporting controls. Enforces reconciliation-before-close discipline, detects control gaps in posting configuration and period-close task coverage, and requires live-guard escalation before production period-close or posting-configuration changes. Refuses to approve a close process without reconciliation and financial controls evidence.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: finance
+---
+
+# D365 Finance Close-to-Report
+
+## Purpose
+
+Act as the Dynamics 365 Finance general ledger and period-close reviewer who treats every unreconciled sub-ledger balance, unapproved journal, missing closing task, and unvalidated posting profile as a reporting risk or audit finding until evidenced otherwise.
+
+## When to use
+
+Use this skill for:
+
+- General ledger configuration review (chart of accounts, ledger setup, fiscal calendars, financial dimensions)
+- Sub-ledger to GL reconciliation gap analysis (accounts payable, accounts receivable, inventory, fixed assets)
+- Period-end close procedure review (financial period close workspace, closing task templates, closing schedules)
+- Year-end close procedure review (year-end close parameters, balance transfer, permanent close risk)
+- Financial consolidation and elimination review (consolidation company setup, intercompany eliminations)
+- Posting profile configuration review (customer posting profiles, vendor posting profiles, inventory posting)
+- Tax setup and foreign currency revaluation review (tax codes, tax groups, exchange rate revaluation parameters)
+- Financial reporting controls review (Management Reporter / Financial reporting configuration, report access)
+- Financial controls posture review (period-status controls, journal approval workflows, posting restrictions)
+- Audit evidence gathering for record-to-report compliance
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Dynamics 365 Finance general ledger and period-close service behavior. Use the per-skill facts and sources in `references/official-sources.md` for grounding.
+- Separate confirmed facts from inference. If state was not queried or shown, say so explicitly.
+- Challenge unreconciled balances, unapproved journals, missing closing task evidence, posting profiles that bypass controls, and period-close steps performed without documented sign-off.
+- Keep answers scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Never ask for credentials, tenant IDs, environment URLs, connection strings, or customer financial data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full period-close or financial controls review, or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving production period-close operations, posting-configuration changes, or year-end close runs.
+- [Official sources](references/official-sources.md) — use when grounding Dynamics 365 Finance GL, period-close, or financial reporting service behavior.
+- [Financial close controls guide](references/financial-close-controls-guide.md) — use for domain-specific failure modes, safe close workflow, verification targets, and pushback criteria.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main reconciliation gaps, posting-control risks, or close-process deficiencies,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/d365-finance-close-to-report/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "d365-finance-close-to-report",
+  "name": "D365 Finance Close-to-Report",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Dynamics 365 Finance general ledger configuration, sub-ledger reconciliation, period-end and year-end close procedures, financial consolidation and elimination, posting profiles, tax setup, and financial reporting controls. Enforces reconciliation-before-close discipline, detects control gaps in posting configuration, and requires live-guard escalation before production period-close or posting-configuration changes.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/finance/general-ledger/close-general-ledger-at-period-end",
+    "https://learn.microsoft.com/dynamics365/finance/general-ledger/financial-period-close-workspace",
+    "https://learn.microsoft.com/dynamics365/finance/general-ledger/tasks/close-fiscal-year",
+    "https://learn.microsoft.com/dynamics365/guidance/business-processes/record-to-report-close-financial-periods",
+    "https://learn.microsoft.com/dynamics365/finance/general-ledger/year-end-close"
+  ],
+  "security_notes": "Never approve a period-end or year-end close process without reconciliation evidence and financial controls sign-off. Production posting-configuration changes, period-status updates (On Hold, Permanently Closed), and consolidation runs are live-guard gated and must be escalated to a human finance controller or system administrator. Reject close process approval where sub-ledger to GL reconciliation gaps are unresolved. Do not ask for credentials, tenant IDs, environment URLs, or customer financial data. Treat every unreconciled balance, unposted journal, and unapproved posting profile change as a reporting risk until evidenced otherwise. Tax configuration and foreign currency revaluation parameter changes must be validated by a qualified tax or finance controller before production use.",
+  "last_verified": "2026-06-16",
+  "path": "skills/microsoft/d365-finance-close-to-report",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "finance",
+  "companion_agents": ["d365-finance-close-to-report-agent"]
+}

package/skills/microsoft/d365-finance-close-to-report/references/financial-close-controls-guide.md

@@ -0,0 +1,79 @@
+# Financial close controls guide
+
+Use this reference for Dynamics 365 Finance period-close and financial controls domain-specific failure modes, safe close workflow, verification targets, and pushback criteria.
+
+## What people get wrong
+
+The lazy story is:
+
+> Run the financial period close workspace tasks and the close is complete.
+
+Wrong. Completing workspace tasks tracks task execution but does not guarantee underlying financial accuracy. Sub-ledger to GL reconciliation gaps, unapproved journals, stale foreign currency revaluation, and misconfigured posting profiles can all produce materially misstated financials even after workspace tasks are marked complete.
+
+Common bad assumptions:
+
+- Marking all Financial period close workspace tasks complete means the GL is accurate.
+- Foreign currency revaluation is optional if the amounts seem small.
+- Posting a journal in the next period is an acceptable substitute for posting it in the correct period.
+- Setting a period to Permanently Closed is reversible.
+- The consolidation company automatically picks up all sub-ledger adjustments without reconciliation.
+- Tax posting configurations are validated automatically when tax codes are changed.
+
+## Period-close failure modes
+
+- Sub-ledger transactions posted after the sub-ledger-to-GL reconciliation check produce undetected variances in the closing balance.
+- Year-end close run with the **Set fiscal year status to permanently closed** parameter set to Yes, locking the year against post-close adjustments required by auditors.
+- Foreign currency revaluation not run before period close, leaving unrealized gains and losses unrecorded in the reporting period.
+- Intercompany transactions not eliminated before consolidation, inflating consolidated revenue and expenses.
+- Posting profiles referencing suspense or clearing accounts that were never cleared, producing phantom balances in financial statements.
+- Journal approval workflows bypassed under time pressure, removing an internal control that auditors will expect evidence of.
+- Mass financial period close used to set modules to None without per-module review, inadvertently blocking month-end postings in open modules.
+
+## High-risk close control gaps (examples from record-to-report)
+
+- Sub-ledger to GL reconciliation not run before period-close sign-off (undetected variances become audit findings)
+- Foreign currency revaluation run after the period-close date rather than before (FX gains/losses in wrong period)
+- Journals approved and posted by the same user (journal entry + approval in one role — SoD gap)
+- Consolidation run without eliminating intercompany receivables and payables (inflated consolidated balance sheet)
+- Posting profiles mapping inventory receipts to catch-all accounts instead of dedicated inventory accounts (distorts cost of goods sold)
+- Trial balance not reviewed before setting period to On Hold (errors locked in without detection)
+- Financial reporting distribution list includes unauthorized recipients (confidential financial data exposure)
+
+These gaps represent the highest-risk close-process scenarios per SOX, IFRS, and local GAAP internal control guidance. Verify that each gap is addressed before approving close readiness.
+
+## Minimum safe close review workflow
+
+1. Confirm scope: legal entities, period type (month-end, quarter-end, year-end), and compliance drivers.
+2. Verify all sub-module tasks are complete: AR invoicing, AP invoicing, inventory postings, fixed asset depreciation.
+3. Confirm all journals in scope are posted and approved per the journal approval workflow.
+4. Run foreign currency revaluation and confirm unrealized gain/loss is posted.
+5. Run sub-ledger to GL reconciliation for AR, AP, Inventory, and Fixed Assets; resolve all variances.
+6. Run trial balance and compare to prior period; investigate material unexplained movements.
+7. Complete Financial period close workspace tasks and confirm all dependencies are satisfied.
+8. For year-end: review year-end close parameters, confirm permanently-closed setting is No, run close, and verify opening balances in the new year.
+9. For consolidation: confirm intercompany elimination rules are current, run consolidation, review consolidated trial balance.
+10. Set period to On Hold after all tasks are complete and reconciliation evidence is documented.
+11. Require live-guard escalation for any production change.
+
+## Verification targets
+
+- Sub-ledger reconciliation: AR, AP, Inventory, Fixed Assets balances reconciled to GL summary accounts
+- Journal completeness: all expected journals posted and approved in the period
+- Foreign currency revaluation: confirmation run completed and unrealized amounts posted
+- Financial period close workspace: all tasks marked complete with documented evidence
+- Period status: On Hold set only after reconciliation and sign-off
+- Year-end close: opening balances in new year match year-end closing balances
+- Consolidation: elimination entries posted; consolidated trial balance reviewed
+- Reporting access: financial statements generated and distributed only to authorized recipients
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve close readiness without sub-ledger to GL reconciliation evidence
+- skip foreign currency revaluation because amounts seem immaterial without formal assessment
+- set a period to Permanently Closed without confirming that no post-close adjustments are anticipated
+- approve journal postings without evidence of the journal approval workflow being followed
+- accept a consolidation result without eliminating intercompany transactions
+- make production posting-profile or period-close configuration changes without live-guard escalation and explicit human approval
+- rely on Financial period close workspace task completion alone as close-readiness evidence without underlying financial validation

package/skills/microsoft/d365-finance-close-to-report/references/official-sources.md

@@ -0,0 +1,45 @@
+# Official sources
+
+Use this reference only when you need source grounding for Dynamics 365 Finance general ledger, period-close, financial consolidation, or financial reporting service behavior, or the detailed source list.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live environment state:
+
+- https://learn.microsoft.com/dynamics365/finance/general-ledger/close-general-ledger-at-period-end
+- https://learn.microsoft.com/dynamics365/finance/general-ledger/financial-period-close-workspace
+- https://learn.microsoft.com/dynamics365/finance/general-ledger/tasks/close-fiscal-year
+- https://learn.microsoft.com/dynamics365/finance/general-ledger/tasks/mass-financial-period-close
+- https://learn.microsoft.com/dynamics365/finance/general-ledger/year-end-close
+- https://learn.microsoft.com/dynamics365/guidance/business-processes/record-to-report-close-financial-periods
+- https://learn.microsoft.com/training/paths/configure-use-general-ledger-dyn365-finance/
+- https://learn.microsoft.com/training/modules/configure-periodic-processes-dyn365-finance/
+
+## Grounding rule
+
+Official documentation explains Dynamics 365 Finance service behavior. It does not prove the user's current environment configuration, ledger balances, posted journals, period-close task completion state, or posting profile assignments. Prefer read-only evidence from the environment (e.g., exported trial balance reports, financial period close workspace screenshots, ledger settlement exports, reconciliation outputs) over inference.
+
+## Service facts (verified 2026-06-16)
+
+General ledger model structure:
+- The Dynamics 365 Finance GL is organized around a **chart of accounts** shared across legal entities, **financial dimensions**, and a **fiscal calendar** broken into **fiscal years** and **periods**.
+- **Ledger periods** can be set to Open, On Hold, or Permanently Closed. On Hold restricts posting for specified modules or user groups. Permanently Closed cannot be reopened — use with extreme caution.
+- **Posting profiles** define the GL accounts to which sub-ledger transactions (customer invoices, vendor invoices, inventory transactions, fixed asset transactions) are posted. Misconfigured posting profiles produce posting errors and GL imbalances.
+
+Period-end close process:
+- The **Financial period close workspace** organizes closing tasks into a template-driven schedule. Tasks can be assigned to individuals per legal entity, linked to system pages or external URLs, and tracked with dependencies.
+- Recommended period-end steps (per Microsoft Learn): complete all module tasks (AR, AP, Inventory), verify all journals are posted, run foreign currency revaluation, settle ledger transactions, process allocations, post period-end adjustments, perform consolidation, generate financial statements, then set the period to On Hold.
+- **Year-end close** transfers balances to a new fiscal year. The parameter **Set fiscal year status to permanently closed** should generally be left as No to preserve the ability to post adjustments.
+- **Mass financial period close** allows updating period status and module-level posting access across multiple legal entities simultaneously.
+
+Sub-ledger reconciliation:
+- Sub-ledgers (AR, AP, Inventory, Fixed Assets) maintain their own transaction records that must reconcile to GL summary balances. Reconciliation gaps indicate either unposted sub-ledger transactions, posting profile misconfigurations, or manual GL journal entries that bypass the sub-ledger.
+- The **Trial Balance** and **Trial Balance by Period** reports show GL account movements and closing balances per period; use them to detect unexplained variances.
+
+Financial reporting:
+- Dynamics 365 Finance integrates with **Financial reporting** (formerly Management Reporter) for financial statement generation. Reports use row and column definitions against the GL data.
+- Financial reporting access is controlled separately from GL posting access; review report-level security alongside GL role assignments.
+
+Review implications:
+- Do not approve a close process from intent alone. Require reconciliation evidence, Financial period close workspace task completion screenshots, foreign currency revaluation run confirmation, and business owner sign-off.
+- Documentation cannot prove the user's actual period-close task completion state, posted balances, or posting profile configuration.