{"id":20717,"plugin_id":"plugins_6aa698dc64588191b48664000f8522de","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:16:26.930Z","digest":"040779278311846b8d29b48ae0bbf1ec97ed806caebdf492b82eef84461e6643","against":null,"payload":{"description":"Use when diagnosing ERP or CRM performance, integration failures, tenant isolation, reporting or customization risks using scoped evidence and explicit vendor-coverage gaps.","included_files":[],"name":"erp-crm-advisor","skill_md_contents":"---\nname: erp-crm-advisor\ndescription: Use when diagnosing ERP or CRM performance, integration failures, tenant isolation, reporting or customization risks using scoped evidence and explicit vendor-coverage gaps.\n---\n\n# ERP / CRM Advisor\n\nUse when the user asks about ERP/CRM bottlenecks, vendor-specific data semantics,\nintegration failures, upgrades, reports, duplicate postings or tenant/company leakage.\nCodex performs the interpretation; no separate LLM API key is required.\n\nResolve the plugin root two directories above this file. Read\n`ERP_CRM_ANALYSIS.md` and `runtime/erp-crm-catalog.json` relative to that root.\nInvoke its absolute `runtime/runTool.js` path; use JSON via stdin (`-`) for inputs.\nInstall missing dependencies with `npm ci` in the plugin root.\n\n1. Run `erp_crm_vendor_catalog` with `{}`. Select an exact product profile; do not\n   equate Dataverse with Finance and Operations or Business Central, or SAP ECC\n   with S/4HANA. Obtain product release, instance ID, environment and deployment.\n2. Run `erp_crm_evidence_plan` with the selected `product`. Identify installed\n   modules, customizations and affected business processes. Separate application\n   execution from database, API and reporting costs.\n3. Inspect authorized, redacted exports and traces using available read-only\n   tools. Do not invent credentials, assume native SaaS connectors, or send SOQL,\n   SuiteQL, ABAP or HANA syntax to the SQL Server/PostgreSQL adapter.\n   Use `erp_crm_import_diagnostics` for supported exports. For Dataverse traces or\n   Salesforce query plans, use `erp_crm_collect_api` only with a configured\n   provider URL, matching system ID, access token and explicit API version.\n   A collector implementation is not proof that the customer's tenant was tested.\n4. Build evidence bundles with matching context, trace references and actual\n   observation timestamps. Populate supported numeric diagnostics from exports.\n   For qualitative observations, assess the relevant code/configuration with an\n   explanation tied to a trace or file reference; use `manual_review` for your\n   interpretation. Never convert absent evidence into `false`, and never pretend\n   a user assertion is a live measurement. Preserve provenance in the answer.\n5. Run `erp_crm_risk_analyzer`. Explain prioritized findings, business impact,\n   evidence, owner and next verification step. Include unresolved/conflicting\n   checks and coverage of this finite catalog. Check the cited manufacturer\n   guidance against the actual release before making product-specific claims.\n6. For an optimization claim, run `benchmark_evidence_compare` on comparable,\n   timestamped samples with case IDs, result hashes and row counts. Reject faster\n   results with semantic differences or errors. Explain sampling and uncertainty;\n   do not replace measured benchmarks with estimated advisor scores.\n   Also run `workload_regression_guard` with the same runs to detect individual\n   cases hidden by aggregate gains. Its defaults are a 10 percent per-case budget\n   and a 1 ms noise floor; set these from the workload requirements. Repeat flagged\n   cases under controlled load. A flag is not statistical proof or apply approval.\n   Supply `caseBudgets` when the process owner provides absolute deadlines:\n   `[{\"caseId\":\"case-0\",\"businessProcess\":\"Order posting\",\"maxDurationMs\":100}]`.\n   Review existing as well as newly breached budgets. Unassessed cases are not\n   evidence of business-SLO compliance. Preserve the returned policyHash with the\n   benchmark inputHash so threshold changes remain distinguishable.\n\nReview order-to-cash, procure-to-pay, period close and reporting where applicable:\ncompany keys, document/line grain, status transitions, currencies/units, effective\ndates, soft deletes, replication freshness and retry idempotency. Use control\ntotals from the business owner; a faster query that changes business meaning is\nnot an optimization.\n\nRun `business_reconciliation_compare` for business control exports before accepting\nan optimization. Both `before` and `after` require the full ERP scope, matching\n`period`, `snapshotHash` and `definitionHash` (SHA256), distinct `exportId`, fresh\n`capturedAt`, and nonempty `controls`. Each control has `companyId`, `currency`,\n`unit`, `metric`, `amount` as an exact decimal string, and integer `rowCount`.\nUse an explicitly agreed unit/currency label for nonmonetary metrics. Never invent\nhashes, totals or counts. Missing groups are not zero. A matched result proves only\nthe supplied aggregate controls, not row-level equivalence; retain result-hash checks.\n\nAnalysis tools do not execute corrections. Do not modify vendor-managed tables,\nindexes, permissions or production application data as part of this workflow.\nPrepare supported remediation and before/after verification for authorized work.\nNo result establishes exhaustive coverage, vendor certification or compliance.\n\n## Persistent advisory cases\n\nUse `advisory_case` for a tracked engagement. Every call requires `systemId`,\n`environment`, `product`, and `productVersion`. Create with `action: create` and\n`objective`; later calls need `caseId` and mutations need `expectedRevision` from\nthe last read. Follow this sequence:\n\n- `diagnose`: `hypothesis`, `evidenceRefs` (references are not attested facts).\n- `propose`: `change`, `rollback`, `testPlan`, `workloadId`, `customizationHash`\n  (SHA256 of the agreed customization inventory), and `businessContract` with\n  `definitionHash`, `period`, `deployment`, and `groups`. Each group has `companyId`,\n  `currency`, `unit`, `metric`. All expected groups must be agreed before approval;\n  do not derive the expected set solely from a potentially incomplete candidate.\n- `approve_test`: matching `proposalHash`, `reviewer`, `approvalRef`, `approvedAt`\n  (timestamp within seven days) from an actual\n  user approval. Never invent approval. This records a statement, not authenticated\n  authorization, and executes nothing.\n- `verify`, then `follow_up`: matching `proposalHash`, `measurements` for\n  `repeated_benchmark_review`, and `businessControls` for `business_reconciliation_compare`.\n  Control scope, period, definition and exact group set must match the approved\n  contract; `snapshotHash` must equal the benchmark `datasetHash`. Follow-up controls\n  must be newer. Missing controls cannot be waived by passing performance results.\n  Measurements must not predate the recorded test approval.\n  Each run must include the full case scope. Follow-up must use newer measurements,\n  the same workload and thresholds. A verified state means evidence was assessed,\n  not that an improvement succeeded; inspect its decision.\n- `close`: `outcome` (`confirmed`, `false_positive`, `inconclusive`), `corrected`\n  boolean, `reviewer`, `note`. Confirmation requires technical and business checks\n  to pass at both stages. Old proposals without contracts require a new case.\n\nUse `read` to resume, and `quality_report` to aggregate reviewed cases within the\nexact same scope/version. Neither reviews nor local storage authenticate a tenant;\nuse separate OS-protected state directories for different trust boundaries.\n\nUse `find_confirmed` with `workloadId` and `customizationHash` for up to ten relevant\nconfirmed cases. Search is limited to the latest 1000 cases in the exact scope;\nlegacy cases without business checks are excluded. Returned cases are examples\nfor review, not automatic optimization instructions.\n\nOptional `causalEvidence` on `diagnose` is validated by `causal_evidence_review`:\n`events` contain the four case-scope fields, `id`, `traceId`, `layer` (application,\nintegration, database), `startedAt`, `durationMs`, `evidenceRef`. `hypotheses` contain\n`id`, `claim`, `supportRefs`, `refuteRefs`. References must resolve; stale or wrong-scope\nevents are rejected. Report contradictions and unresolved alternatives explicitly.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}