القائمة
Use when an AX 2009 issue starts as a business symptom or support error and you need a standard-first troubleshooting cause tree that can escalate to customization and XPO analysis when needed.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when analyzing X++ AX 2009 profiler traces, code stack traces, or execution paths to identify performance bottlenecks — repeated call chains, quadratic loops, expensive constructor+calc combos, excessive tax/totals recalculation, or deep framework cascades.
Use when reviewing X++ or general ERP source code for architectural weaknesses, design gaps, fragile sequencing, responsibility mismatches, technical debt, or structural risks — not just syntax or performance issues.
Use when given any X++ AX 2009 artifact — stack trace, method, class, form XPO, posting code, or table — and you need a full structured multi-skill analysis applied automatically based on artifact type.
Use when proposing X++ AX 2009 code fixes for identified performance bottlenecks or behavioral bugs — minimal, production-safe changes that preserve business logic and fit ERP team review standards.
Use for all XppAI AX 2009 tasks as the canonical core baseline (architecture, language, lifecycle, hard constraints, and evidence labels).
Use when deep AX 2009 analysis is required (performance, posting, totals/tax, framework patterns, customization safety, and architecture judgment).
| name | xppai-support |
| description | Use when an AX 2009 issue starts as a business symptom or support error and you need a standard-first troubleshooting cause tree that can escalate to customization and XPO analysis when needed. |
REQUIRED BACKGROUND: Load xppai-init before applying this skill.
Use this skill when the user reports functional or operational AX 2009 support issues before providing code artifacts. Start from the standard AX 2009 process, narrow the likely causes, ask the next best support questions, and escalate to customization analysis only when evidence points there.
Restate the issue in AX 2009 terms. Separate the reported symptom from the root cause. Do not claim certainty when the prompt only provides the error message or business complaint.
Identify the most likely standard area involved, such as sales posting, inventory availability, reservation, inventory dimensions, tax, posting setup, number sequence, or permissions. Explain why that area is the most likely starting point.
List standard AX 2009 causes first. For each branch include:
Use the evidence labels Confirmed, Likely, Hypothesis, or Unknown.
Prefer checks a consultant, key user, or support analyst can perform without code first. Keep the tree narrow enough that the next action is obvious.
Ask whether the failing flow has customization, integration, modified validation, posting hooks, or custom reservation logic.
If customization is confirmed or likely:
.xpo.Do not assume customization first. Treat it as a branch that must be confirmed.
End with one concrete next action. That can be either:
Possible standard branches include:
InventTrans is out of sync with the expected process stateAfter listing the standard branches, ask whether posting, reservation, or inventory validation has been customized.
Use web search only when AX 2009 standard-process details are genuinely uncertain and local evidence is not enough. Keep general process knowledge separate from customer-specific evidence.