@raishin/vanguard-frontier-agentic 2.10.0 → 2.11.0

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.

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