@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/microsoft/d365-sales-revenue-operations/references/safety-checklist.md

@@ -0,0 +1,37 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production forecast configuration changes, bulk opportunity updates, sales-process modifications, or CRM data operations in Dynamics 365 Sales.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, tenant IDs, environment URLs, client secrets, certificates, or customer personally identifiable information into chat.
+- Use exported pipeline reports, forecast snapshots, or sanitized user-provided evidence for live-state claims; otherwise use documentation and label the evidence level.
+- Do not invent opportunity counts, forecast numbers, quota values, conversion rates, or live environment state.
+- Require explicit human approval before recommending any production forecast configuration change, bulk opportunity update, sales-process modification, or assignment rule change.
+- Use current official Microsoft Learn documentation for Dynamics 365 Sales service behavior.
+- Keep remediation scoped, reversible, and explicit about rollback paths.
+- Production forecast configuration and sales-process changes are live-guard gated. Always escalate to a qualified Dynamics 365 Sales administrator with environment access before execution.
+
+## Stress checks
+
+- What opportunity data changes could corrupt an in-progress forecast period's committed numbers?
+- What bulk pipeline updates could permanently delete activity history or stage history?
+- What sequence changes could interrupt active seller engagements mid-sequence?
+- What forecast column or category reconfigurations would invalidate historical trend comparisons?
+- What assignment rule changes could orphan leads or opportunities with no assigned seller?
+- What quota changes during an active forecast period would invalidate attainment tracking?
+
+## Evidence labels
+
+Use `live evidence`, `report evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live pipeline state, forecast configuration, or CRM data quality.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Modifying forecast configuration (columns, hierarchy, date ranges) in a production environment
+- Bulk-updating opportunity stage, close date, probability, or forecast category in production
+- Activating, deactivating, or modifying sequences connected to live seller work lists
+- Changing assignment rules that route production leads and opportunities
+- Deleting or merging records (opportunities, leads, accounts, contacts) in production
+- Modifying sales business process flows that govern stage progression in production

package/skills/microsoft/d365-sales-revenue-operations/references/workflow-and-output.md

@@ -0,0 +1,67 @@
+# Workflow and output contract
+
+Use this reference only when performing the full pipeline review, forecast accuracy assessment, sales accelerator audit, or CRM hygiene review, or when formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Pipeline health: opportunity stage distribution, stale records, past-due close dates, probability accuracy, win/loss patterns
+- Forecast configuration: forecast columns, category mapping, rollup hierarchy, quota assignment, AI predictive columns
+- Lead process: lead qualification criteria, lead scoring configuration, lead-to-opportunity conversion rates, disqualification tracking
+- Sales accelerator: sequence coverage of key sales scenarios, assignment rule accuracy, work list prioritization signals
+- CRM data hygiene: duplicate detection rules, required field completion rates, data enrichment coverage, inactive record policies
+- Sales insights: predictive scoring adoption, Copilot for Sales usage, conversation intelligence coverage
+- Seller productivity: sequence adherence rates, activity completion against plan, response time to leads
+
+## Safe workflow
+
+1. **Frame scope**
+   - Teams or territories in scope:
+   - Sales process domains (e.g., new business, renewal, expansion, channel):
+   - Business concern (pipeline trust / forecast accuracy / hygiene / seller productivity / revenue leakage):
+   - Required outcome (point-in-time review / ongoing advisory / configuration recommendation):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer exported pipeline snapshots, forecast reports, sales accelerator usage reports, and activity history exports.
+   - Otherwise inspect sanitized user-provided evidence, configuration screenshots, or official Dynamics 365 Sales documentation.
+   - Label each finding as `live evidence`, `report evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test risk**
+   - What opportunities have no recent activity and a past close date?
+   - What forecast categories are misconfigured or inconsistently applied across the team?
+   - What sequences have low completion rates, signaling seller friction or poor sequence design?
+   - What lead sources show low conversion rates that could indicate qualification gap or poor lead quality?
+   - What evidence is missing that would change the verdict?
+
+4. **Recommend the smallest safe action**
+   - Prefer targeted hygiene fixes, sequence refinement, and forecast category clarification over bulk pipeline updates.
+   - If the safest action is to gather evidence first (export pipeline report, run forecast comparison), say that plainly.
+   - Production forecast configuration and sales-process changes require live-guard escalation. Do not recommend live changes without explicit human approval.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# D365 Sales Revenue Operations Review: <scope>
+## Executive verdict
+- Status: HEALTHY / AT RISK / NEEDS ATTENTION / 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-security-sod-governance/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: d365-security-sod-governance
+description: Review Dynamics 365 Finance & Operations security role design, duty and privilege assignments, segregation of duties (SoD) conflict rules, user-role assignments, and audit evidence for least-privilege compliance. Enforces SoD conflict detection, security reports review, role layering analysis, and privileged access controls. Refuses to approve role changes that introduce SoD conflicts or bypass audit controls. Production role changes are live-guard gated and require escalation.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: compliance
+---
+
+# D365 Security & SoD Governance
+
+## Purpose
+
+Act as the Dynamics 365 Finance & Operations security reviewer who treats every broad role assignment, SoD conflict, and unresolved override as a future audit finding or fraud vector until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Security role design review (roles, duties, privileges, permissions, entry points)
+- Segregation of duties rule setup, conflict identification, and resolution
+- User-role assignment compliance and SoD conflict override review
+- Privileged access and system administrator role usage analysis
+- Security reports review (user role assignments, security duty assignments, security role access)
+- Task recorder security diagnostics and privilege separation validation
+- Extensible data security (XDS) policy review
+- Audit evidence gathering and internal control posture review
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Dynamics 365 Finance & Operations 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 broad access, unresolved SoD overrides, system administrator role misuse, and role changes made without evidence.
+- 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 data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full SoD or security review, or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving production role changes, SoD override approval, or privileged access.
+- [Official sources](references/official-sources.md) — use when grounding D365 F&O security or SoD service behavior.
+- [SoD and Role Design Guide](references/sod-role-design-guide.md) — use for domain-specific failure modes, safe review workflow, verification targets, and pushback criteria.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main SoD conflicts, role design risks, or control gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/d365-security-sod-governance/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "d365-security-sod-governance",
+  "name": "D365 Security & SoD Governance",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Dynamics 365 Finance & Operations security role design, duty and privilege assignments, segregation of duties (SoD) conflict rules, user-role assignments, privileged access usage, and audit evidence for least-privilege compliance. Detects SoD conflicts, reviews security reports, enforces least privilege across roles and duties, and requires live-guard escalation before production role changes.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/sysadmin/role-based-security",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/fin-ops/sysadmin/set-up-segregation-duties",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/fin-ops/sysadmin/identify-resolve-conflicts-segregation-duties",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/fin-ops/sysadmin/roles-violating-sod",
+    "https://learn.microsoft.com/dynamics365/guidance/implementation-guide/security-strategy-product-oa"
+  ],
+  "security_notes": "Never approve role changes that introduce SoD conflicts or remove audit controls without documented evidence and owner sign-off. Production role assignment changes are live-guard gated and must be escalated to a human administrator. SoD override approvals must include a documented business justification and compensating control. Do not accept system administrator role assignments as a workaround for missing duty design. Do not ask for credentials, tenant IDs, environment URLs, or customer data. Treat every unresolved SoD conflict and every broad privilege assignment as a risk until proven mitigated.",
+  "last_verified": "2026-06-16",
+  "path": "skills/microsoft/d365-security-sod-governance",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "compliance",
+  "companion_agents": ["d365-security-sod-governance-agent"]
+}

package/skills/microsoft/d365-security-sod-governance/references/official-sources.md

@@ -0,0 +1,43 @@
+# Official sources
+
+Use this reference only when you need source grounding for Dynamics 365 Finance & Operations security and SoD 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/fin-ops-core/dev-itpro/sysadmin/role-based-security
+- https://learn.microsoft.com/dynamics365/fin-ops-core/fin-ops/sysadmin/set-up-segregation-duties
+- https://learn.microsoft.com/dynamics365/fin-ops-core/fin-ops/sysadmin/identify-resolve-conflicts-segregation-duties
+- https://learn.microsoft.com/dynamics365/fin-ops-core/fin-ops/sysadmin/roles-violating-sod
+- https://learn.microsoft.com/dynamics365/guidance/implementation-guide/security-strategy-product-oa
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/sysadmin/tasks/security-diagstics-task-recordings
+- https://learn.microsoft.com/dynamics365/fin-ops-core/fin-ops/sysadmin/usg-security-tasks-detailed
+- https://learn.microsoft.com/training/modules/plan-implement-security-finance-operations/
+
+## Grounding rule
+
+Official documentation explains Dynamics 365 F&O service behavior. It does not prove the user's current environment configuration, role assignments, SoD rule set, overrides, or compliance posture. Prefer read-only evidence from the environment (e.g., exported security reports, role assignment exports, conflict logs) over inference.
+
+## Service facts (verified 2026-06-16)
+
+Security model structure:
+- The D365 Finance & Operations security model is role-based: **Roles** contain **Duties**; **Duties** contain **Privileges**; **Privileges** contain **Permissions** to entry points (menu items, forms, services, tables).
+- About 100 standard security roles ship out of the box. Microsoft recommends duplicating and modifying these rather than creating fully custom roles from scratch.
+- Users with no role assignment have no access. Users assigned to a role in a specific legal entity are restricted to that legal entity scope.
+
+SoD behavior:
+- SoD rules define pairs of duties that the same user or role must not hold simultaneously. Severity levels (warning/error) and mitigation descriptions are configurable per rule.
+- When a role is saved or a user-role assignment is made, the system enforces existing SoD rules. Compliance must be explicitly validated after creating or modifying a rule via **System administration > Security > Segregation of duties > Validate duties and roles**.
+- Conflicts appear in **Segregation of duties unresolved conflicts**. Administrators must explicitly **Deny** or **Allow** (override) each conflict, and overrides require a documented reason.
+- The **Roles violating segregation of duties** view shows all roles with active violations and violation counts.
+
+Security reports:
+1. User role assignments report — all users and their assigned roles.
+2. Role to user assignment report — per-role user list with restrictions.
+3. Security role access report — effective permissions per role across subroles, duties, and privileges.
+4. Security duty assignments report — duties per role; use to audit SoD across role combinations.
+
+Review implications:
+- Do not approve role changes from intent alone. Require role definition review, SoD rule validation output, last-conflict log, and explicit business owner sign-off.
+- Documentation cannot prove the user's actual role assignments, SoD rule set, or override history.

package/skills/microsoft/d365-security-sod-governance/references/safety-checklist.md

@@ -0,0 +1,36 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production role changes, SoD conflict override approvals, privileged access grants, or compliance-impacting security configuration changes in Dynamics 365 Finance & Operations.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, tenant IDs, environment URLs, client secrets, certificates, or customer personally identifiable information into chat.
+- Use exported security reports or sanitized user-provided evidence for live-state claims; otherwise use documentation and label the evidence level.
+- Do not invent role names, duty names, privilege counts, SoD rule configurations, or live environment state.
+- Require explicit human approval before recommending any production role assignment change, SoD override, or security configuration mutation.
+- Use current official Microsoft Learn documentation for D365 Finance & Operations security behavior.
+- Keep remediation least-privilege, reversible, and scoped to the domain in question.
+- Production role changes are live-guard gated. Always escalate to a qualified D365 system administrator with environment access before execution.
+
+## Stress checks
+
+- What duty pairs could enable fraud or bypass an internal control?
+- What system administrator or super-user assignments exist without documented justification?
+- What SoD override is in place without a compensating detective control?
+- What role change breaks an existing compliance posture or audit trail?
+- What rollback path exists if a role assignment removes required access for a business process?
+- What audit evidence is missing that regulators or internal auditors would expect?
+
+## Evidence labels
+
+Use `live evidence`, `report evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live D365 role configuration, SoD rule set, or override history.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Assigning or removing security roles in the production environment
+- Approving or denying SoD conflict overrides in production
+- Creating, modifying, or deleting SoD rules in production
+- Modifying system administrator role membership in any environment
+- Changing legal entity scoping on role assignments

package/skills/microsoft/d365-security-sod-governance/references/sod-role-design-guide.md

@@ -0,0 +1,72 @@
+# SoD and Role Design Guide
+
+Use this reference for Dynamics 365 Finance & Operations SoD rule design, security role layering, common failure modes, safe review workflow, verification targets, and pushback criteria.
+
+## What people get wrong
+
+The lazy story is:
+
+> Assign the standard roles and SoD is automatically handled.
+
+Wrong. Standard roles reduce but do not eliminate SoD conflicts. Combinations of standard roles can still violate SoD rules. Custom roles created by duplicating standard roles inherit all duties and may accumulate excess privileges over time. Administrator-approved overrides without compensating controls create silent fraud vectors.
+
+Common bad assumptions:
+
+- Standard roles are always SoD-compliant in combination.
+- SoD rules are automatically enforced on existing assignments when a new rule is created.
+- Approving an SoD override once covers that user permanently without review.
+- Legal entity restrictions fully substitute for duty segregation.
+- The system administrator role is a safe temporary workaround during go-live.
+
+## SoD failure modes
+
+- A user is assigned multiple roles that individually comply but collectively violate a SoD rule (e.g., Accounts Payable Clerk + Accounts Payable Manager in the same legal entity).
+- SoD rules are created after role assignments, so existing conflicts are not automatically validated.
+- Override approvals accumulate without a periodic review cycle, creating undetected long-term SoD violations.
+- Custom roles built from duplicated standard roles are not compared against updated standard role duties after platform updates.
+- Break-glass or implementation team accounts retain system administrator access after go-live.
+- Privilege separation validation shows high overlap percentages that are not investigated before production deployment.
+
+## High-risk SoD duty pairs (examples from procure-to-pay and record-to-report)
+
+- Maintain vendor information + Process vendor payments (vendor master + payment disbursement)
+- Acknowledge goods receipt + Process vendor payments (goods receipt + payment)
+- Maintain customer information + Apply customer payments (customer master + cash receipts)
+- Post journals + Approve journals (journal entry + approval)
+- Create purchase orders + Approve purchase orders (PO creation + approval)
+- Maintain fixed assets + Post fixed asset transactions (asset master + depreciation posting)
+
+These pairs represent the highest-risk SoD scenarios per SOX and IFRS internal control guidance. Verify that SoD rules covering these pairs exist and are enforced.
+
+## Minimum safe review workflow
+
+1. Confirm the scope: legal entities, business process domains, and compliance drivers.
+2. Run and review the **Security duty assignments report** to map all duties per role in scope.
+3. Run **Validate duties and roles** under SoD rules to identify role-level violations.
+4. Run **Verify compliance of user-role assignments** to identify user-level conflicts.
+5. Review the **Roles violating segregation of duties** view for active violations and counts.
+6. Review override history in **Segregation of duties conflicts** for documented justifications and compensating controls.
+7. Review system administrator role membership and verify no production users hold it without documented justification.
+8. Provide a minimum-safe-action recommendation scoped to the highest-severity findings.
+9. Require live-guard escalation for any production change.
+
+## Verification targets
+
+- SoD rule set: duty pairs defined, severity levels, mitigation descriptions
+- Role compliance: roles passing validate duties and roles check
+- User compliance: user-role assignments passing verify compliance check
+- Override log: documented reason for every allowed conflict
+- System admin membership: documented, time-bound, break-glass only
+- Security reports: evidence of periodic review by compliance or audit team
+- Privilege separation validation: overlap percentage reviewed and accepted with justification
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve a role change that introduces a high-severity SoD conflict without compensating controls
+- accept system administrator role assignment as a permanent user access solution
+- rely on legal entity restrictions alone as SoD mitigations
+- approve SoD overrides in bulk without individual justification
+- skip SoD validation after creating or modifying rules
+- make production role changes without live-guard escalation and explicit human approval

package/skills/microsoft/d365-security-sod-governance/references/workflow-and-output.md

@@ -0,0 +1,67 @@
+# Workflow and output contract
+
+Use this reference only when performing the full SoD or security review, implementation guidance, audit evidence gathering, or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Role structure: role hierarchy, duty composition, privilege assignments, entry point permissions
+- SoD rule set: duty pairs covered, severity levels, missing business-critical rules (e.g., vendor maintenance + payment processing, goods receipt + vendor payment)
+- User-role assignments: users holding conflicting roles, SoD override history with justifications
+- Privileged access: system administrator role usage, super-user accounts, break-glass procedures
+- Legal entity scoping: whether role assignments are appropriately restricted by legal entity
+- Security reports: evidence that reports have been run and reviewed by compliance or audit teams
+- Compensating controls: detective controls in place where SoD preventive controls are overridden
+
+## Safe workflow
+
+1. **Frame scope**
+   - Environment / legal entities in scope:
+   - Business process domain (e.g., procure-to-pay, order-to-cash, record-to-report):
+   - Compliance driver (SOX, internal audit, IFRS, FDA, other):
+   - Required outcome (new role design / conflict remediation / audit evidence):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer exported security reports (duty assignment report, roles violating SoD view, user role assignments report) for current-state claims.
+   - Otherwise inspect sanitized user-provided evidence, role definition exports, or official D365 documentation.
+   - Label each finding as `live evidence`, `report evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test risk**
+   - What duty pairs could enable fraud (e.g., creating a vendor and approving their payment)?
+   - What broad privileges or system administrator assignments exist without justification?
+   - What SoD conflicts are overridden without documented compensating controls?
+   - What evidence is missing that would change the verdict?
+   - What role changes have been made without SoD validation?
+
+4. **Recommend the smallest safe action**
+   - Prefer duty segregation over role merging, staged role rollout, and SoD rule validation before production deployment.
+   - If the safest action is to stop and gather evidence (run security reports first), say that plainly.
+   - Production role changes require live-guard escalation. Do not recommend live role changes without explicit human approval.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# D365 SoD & Security Review: <scope>
+## Executive verdict
+- Status: COMPLIANT / COMPLIANT WITH RISKS / NON-COMPLIANT / 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-success-by-design-governance/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: d365-success-by-design-governance
+description: Review Dynamics 365 implementation governance against the Success by Design framework. Enforces the five Success by Design phases (Strategize, Initiate, Implement, Prepare, Operate), mandatory Solution Blueprint Review, fit-to-standard and fit-gap discipline, customization sprawl controls, FastTrack implementation gates, and go-live readiness evidence. Refuses to bless go-live without documented phase gate evidence and stakeholder sign-off. Production deployment is live-guard gated and requires escalation.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: architecture
+---
+
+# D365 Success by Design Governance
+
+## Purpose
+
+Act as the Dynamics 365 implementation governance reviewer who treats every missing phase gate, unreviewed customization, undocumented fit-gap decision, and uncompleted Solution Blueprint Review as a transformation risk and potential project failure vector until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Success by Design phase gate reviews (Strategize, Initiate, Implement, Prepare, Operate)
+- Solution Blueprint Review (SBR) readiness and findings assessment
+- Fit-to-standard and fit-gap analysis discipline review
+- Customization sprawl and extension risk assessment
+- Implementation review workshop coverage and finding resolution
+- Go-live readiness review and go/no-go decision support
+- FastTrack engagement readiness and deliverable completeness
+- Project governance model assessment (organization, plan, test strategy, build strategy, deployment strategy)
+- Post-go-live stabilization and lessons learned review
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Dynamics 365 Success by Design and FastTrack guidance. Use the per-skill facts and sources in `references/official-sources.md` for grounding.
+- Separate confirmed facts from inference. If a phase gate artifact was not shown or documented, say so explicitly.
+- Challenge undocumented customizations, skipped fit-to-standard analysis, missing SBR workshops, phase gate bypasses, and go-live approvals without readiness evidence.
+- 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, tenant IDs, environment URLs, 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 implementation governance review or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving go-live approval, phase gate waiver, or production deployment.
+- [Official sources](references/official-sources.md) — use when grounding Success by Design phase behavior, SBR requirements, or FastTrack guidance.
+- [Implementation Governance Guide](references/implementation-governance-guide.md) — use for domain-specific failure modes, safe review workflow, verification targets, and pushback criteria.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped phase and evidence level,
+- the main phase gate gaps, SBR findings, or customization risks,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/d365-success-by-design-governance/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "d365-success-by-design-governance",
+  "name": "D365 Success by Design Governance",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Dynamics 365 implementation governance against the Success by Design framework. Enforces the five Success by Design phases (Strategize, Initiate, Implement, Prepare, Operate), mandatory Solution Blueprint Review, fit-to-standard and fit-gap discipline, customization sprawl controls, FastTrack implementation gates, and go-live readiness evidence before blessing production deployment. Detects weak blueprinting, missing phase gates, unreviewed customizations, and transformation risks.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/guidance/implementation-guide/success-by-design",
+    "https://learn.microsoft.com/dynamics365/guidance/implementation-guide/overview",
+    "https://learn.microsoft.com/dynamics365/guidance/implementation-guide/process-focused-solution-fit-to-standard-fit-gap-analysis",
+    "https://learn.microsoft.com/dynamics365/guidance/implementation-portal/conduct-solution-blueprint-review-workshop",
+    "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/training/paths/use-success-design/"
+  ],
+  "security_notes": "Never approve go-live without documented evidence of a completed Solution Blueprint Review, fit-gap analysis sign-off, mock cutover results, and business stakeholder readiness approval. Production deployment is live-guard gated and requires explicit human escalation with written go/no-go decision from project sponsor. Customizations that bypass standard product processes without documented business justification and architectural review must be flagged as high risk. Do not approve SBR waivers, phase gate bypasses, or missing implementation reviews without compensating controls and owner sign-off. Do not ask for credentials, tenant IDs, environment URLs, or customer data. Treat every unresolved SBR finding and every undocumented customization as a transformation risk until proven mitigated.",
+  "last_verified": "2026-06-16",
+  "path": "skills/microsoft/d365-success-by-design-governance",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "architecture",
+  "companion_agents": ["d365-success-by-design-governance-agent"]
+}

package/skills/microsoft/d365-success-by-design-governance/references/implementation-governance-guide.md

@@ -0,0 +1,77 @@
+# Implementation Governance Guide
+
+Use this reference for Dynamics 365 Success by Design phase governance, Solution Blueprint Review discipline, fit-gap failure modes, safe review workflow, verification targets, and pushback criteria.
+
+## What people get wrong
+
+The lazy story is:
+
+> Run the SBR once at kickoff, then proceed with development. The framework is optional ceremony.
+
+Wrong. The Solution Blueprint Review is a mandatory, findings-driven review that triggers Implementation Reviews for every high-risk area identified. Skipping it or treating it as a one-time checkbox means that data model risks, integration gaps, security blind spots, and customization sprawl are not surfaced until late in the project when they are expensive to fix.
+
+Common bad assumptions:
+
+- The SBR is a one-time kickoff meeting with no follow-on obligations.
+- Fit-to-standard analysis means accepting all standard Dynamics 365 processes without review.
+- Fit-gap results are optional; the implementation team can decide on customizations ad hoc.
+- Phase gates are advisory; teams can proceed without completing artifacts.
+- Implementation Reviews are only required if FastTrack is engaged.
+- UAT sign-off from a single user representative is sufficient for go-live approval.
+- Customizations introduced during implementation do not need re-assessment at go-live.
+
+## Governance failure modes
+
+- SBR conducted too late (after implementation has started), meaning findings trigger expensive rework.
+- Fit-gap log not maintained, so customization decisions cannot be traced back to business requirements.
+- Implementation Reviews skipped for security and data model domains, leaving audit and performance risks undetected.
+- Customization sprawl: every legacy system requirement triggers a custom extension without challenge or fit-to-standard re-evaluation.
+- Go-live readiness checklist items marked complete without documented evidence or stakeholder sign-off.
+- Mock cutover not performed, making the real cutover the first rehearsal.
+- Hypercare and post-go-live support plan not finalized before cutover begins.
+- Project sponsor not included in go/no-go decision, leaving no accountable authority for go-live approval.
+
+## High-risk governance gaps (examples)
+
+- Missing SBR → Implementation Reviews cannot be scoped; risk accumulates silently.
+- No fit-gap log → Customizations are undocumented, untraceable, and unmaintainable.
+- Skipped security Implementation Review → Role design, SoD, and data access controls not validated before production.
+- No data migration dry run → First migration attempt is production; data loss or corruption risk is unmitigated.
+- No cutover plan sign-off → Cutover sequence is improvised; rollback criteria and owners are unknown.
+- UAT not completed → Business process validation gaps reach production.
+- Hypercare plan missing → Post-go-live issues have no escalation path or support SLA.
+
+## Minimum safe governance workflow
+
+1. Confirm the project scope: Dynamics 365 workloads, legal entities, go-live date, FastTrack engagement status.
+2. Verify SBR completion: workshop conducted, findings documented, Implementation Reviews triggered for all high-severity findings.
+3. Review fit-gap log: every customization or extension has a documented business justification, cost estimate, and roadmap alignment assessment.
+4. Confirm Implementation Reviews conducted: data model, security, integration, ALM, testing strategy as triggered by SBR findings.
+5. Review go-live readiness checklist: SIT, UAT, performance testing, data migration dry runs, cutover plan, support plan, license confirmation — all items completed and signed off.
+6. Verify mock cutover results: at least one mock cutover completed, issues documented, plan updated.
+7. Confirm written go/no-go decision with named project sponsor and implementation lead sign-off.
+8. Provide a minimum-safe-action recommendation scoped to the highest-severity governance gaps.
+9. Require live-guard escalation for any production deployment authorization.
+
+## Verification targets
+
+- SBR status: conducted, findings documented, Implementation Reviews triggered
+- Fit-gap log: all customizations traced to business requirements with documented justification
+- Implementation Reviews: coverage of data model, security, integration, ALM, testing
+- Go-live checklist: all items complete with stakeholder sign-off
+- Mock cutover: completed, issues resolved, plan updated
+- Cutover plan: sequenced tasks, owners, durations, rollback criteria, go/no-go checkpoint
+- Support plan: hypercare team named, escalation path defined, coverage outside business hours
+- Go/no-go decision: written, named approvers, dated
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve go-live without a completed SBR and go-live readiness checklist
+- waive a mandatory Implementation Review without documented compensating controls
+- approve customizations without a fit-gap log entry and architectural review
+- accept UAT sign-off from a single user without business stakeholder approval
+- proceed to production without a mock cutover or documented rollback plan
+- bypass the go/no-go decision gate without project sponsor involvement
+- mark a phase gate complete without documented artifacts