{"skill":{"slug":"alibabacloud-pai-rec-diagnosis","displayName":"Alibabacloud Pai Rec Diagnosis","summary":"Alibaba Cloud PAI-Rec Engine Diagnostic and Configuration Validation Skill. Use for diagnosing PAI-Rec engine interface issues and validating engine configur...","description":"---\nname: alibabacloud-pai-rec-diagnosis\ndescription: |\n  Alibaba Cloud PAI-Rec Engine Diagnostic and Configuration Validation Skill.\n  Use for diagnosing PAI-Rec engine interface issues and validating engine configurations.\n  Triggers: \"PAI-Rec\", \"engine diagnosis\", \"engine config validation\", \"pairec\", \"recommendation engine\".\n---\n\n# PAI-Rec Engine Diagnosis and Configuration Validation\n\nThis skill provides comprehensive diagnostic and validation capabilities for Alibaba Cloud PAI-Rec (Programmable Recommendation System) engines, including interface troubleshooting and configuration analysis.\n\n## Scenario Description\n\nPAI-Rec is Alibaba Cloud's programmable recommendation system that provides intelligent recommendation capabilities. This skill helps users:\n\n1. **Diagnose PAI-Rec Engine Interface Issues**: When engine API returns errors or unexpected results, trace the request through EAS service logs and engine configurations to identify root causes.\n\n2. **Validate Engine Configurations**: Analyze engine configuration files for potential issues, inconsistencies, or misconfigurations before deployment.\n\n**Architecture**: PAI-EAS Service + PAI-Rec Engine + Engine Configuration Management\n\n### Key Components\n- **PAI-EAS Service**: Elastic Algorithm Service hosting the recommendation engine\n- **PAI-Rec Engine**: The recommendation engine processing requests\n- **Engine Configuration**: Configuration files defining engine behavior\n- **Service Logs**: EAS service logs containing request traces\n\n---\n\n## Installation\n\n**Pre-check: Aliyun CLI >= 3.3.3 required**\n> Run `aliyun version` to verify >= 3.3.3. If not installed or version too low,\n> run `curl -fsSL https://aliyuncli.alicdn.com/setup.sh | bash` to install/update,\n> or see `references/cli-installation-guide.md` for installation instructions.\n\n**Pre-check: Aliyun CLI plugin update required**\n> [MUST] run `aliyun configure set --auto-plugin-install true` to enable automatic plugin installation.\n> [MUST] run `aliyun plugin update` to ensure that any existing plugins are always up-to-date.\n\n---\n\n## Authentication\n\n> **Pre-check: Alibaba Cloud Credentials Required**\n>\n> **Security Rules:**\n> - **NEVER** read, echo, or print AK/SK values (e.g., `echo $ALIBABA_CLOUD_ACCESS_KEY_ID` is FORBIDDEN)\n> - **NEVER** ask the user to input AK/SK directly in the conversation or command line\n> - **NEVER** use `aliyun configure set` with literal credential values\n> - **ONLY** use `aliyun configure list` to check credential status\n>\n> ```bash\n> aliyun configure list\n> ```\n> Check the output for a valid profile (AK, STS, or OAuth identity).\n>\n> **If no valid profile exists, STOP here.**\n> 1. Obtain credentials from [Alibaba Cloud Console](https://ram.console.aliyun.com/manage/ak)\n> 2. Configure credentials **outside of this session** (via `aliyun configure` in terminal or environment variables in shell profile)\n> 3. Return and re-run after `aliyun configure list` shows a valid profile\n\n---\n\n## RAM Policy\n\n> **[MUST] Permission Failure Handling:** When any command or API call fails due to permission errors at any point during execution, follow this process:\n> 1. Read `references/ram-policies.md` to get the full list of permissions required by this SKILL\n> 2. Use `ram-permission-diagnose` skill to guide the user through requesting the necessary permissions\n> 3. Pause and wait until the user confirms that the required permissions have been granted\n\nFor detailed RAM policies required by this skill, see [references/ram-policies.md](references/ram-policies.md).\n\n---\n\n## Parameter Confirmation\n\n> **IMPORTANT: Parameter Confirmation** — Before executing any command or API call,\n> ALL user-customizable parameters (e.g., RegionId, service names, instance IDs,\n> environment names, config names, etc.) MUST be confirmed with the user.\n> Do NOT assume or use default values without explicit user approval.\n\n### Required Parameters\n\n| Parameter Name | Required/Optional | Description | Default Value |\n|----------------|-------------------|-------------|---------------|\n| `service-name` | Required | PAI-EAS service name | N/A |\n| `cluster-id` | Required | EAS cluster/region ID | N/A |\n| `instance-id` | Required | PAI-Rec instance ID | N/A |\n| `request-id` | Required (for diagnosis) | Request ID from engine API response | N/A |\n| `config-name` | Optional | Engine configuration name | N/A |\n| `environment` | Optional | Engine environment (Prod/Pre) | N/A |\n| `engine-config-id` | Optional | Specific engine config version ID | N/A |\n| `region` | Optional | Alibaba Cloud region | N/A |\n\n---\n\n## Observability (MUST follow for every aliyun command)\n\nUpon loading this skill, generate a random session ID (32-char lowercase hex string) once for the entire session. Use it as `{session-id}` below.\n\n**Rule: Every `aliyun` CLI command that calls a cloud API MUST include the `--user-agent` flag.**\nLocal utility commands (e.g. `configure`, `plugin`, `version`) do not support this flag and should be excluded.\n\n```\n--user-agent AlibabaCloud-Agent-Skills/alibabacloud-pai-rec-diagnosis/{session-id}\n```\n\nExample (assuming session-id is `a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6`):\n```bash\naliyun eas describe-service --cluster-id cn-hangzhou --service-name my_service --user-agent AlibabaCloud-Agent-Skills/alibabacloud-pai-rec-diagnosis/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6\n```\n\nDo not skip, alter the format, or omit `--user-agent` on any `aliyun` API command invocation.\n\n---\n\n## Core Workflow\n\n> **[MUST] Allocate a per-session work directory** — All transient artifacts\n> (raw config dumps, log dumps, sanitized output) MUST be written under a unique\n> per-session directory to avoid concurrent overwrite between parallel skill\n> invocations. Run the following at the start of the workflow, before any\n> artifact-producing CLI invocation, and reuse `$WORKDIR` for the whole session.\n> Pass the full template as a positional arg (works on both BSD/macOS and\n> GNU/Linux `mktemp`); do NOT use `-t prefix`, which falls back to `$TMPDIR`\n> (e.g. `/var/folders` on macOS) and may even fail under sandboxed shells.\n> ```bash\n> export WORKDIR=$(mktemp -d /tmp/pairec-diag-XXXXXX)\n> ```\n> All file paths shown below (`$WORKDIR/engine_configs_list.json`, etc.) live\n> inside this directory and MUST NOT be replaced with hard-coded `/tmp/...` paths.\n\n> **[MUST] Use ONLY the workflows defined below.** Do NOT invent additional\n> steps (e.g. instance resource checks, network probes) or substitute manual\n> analysis for a defined workflow step.\n\n### Workflow 1: PAI-Rec Engine Interface Diagnosis\n\nThis workflow helps diagnose issues when a PAI-Rec engine API returns errors or unexpected results.\n\n**Input Example:**\n```\nService Name: embedding_recall\nAPI Response:\n{\n    \"code\": 299,\n    \"msg\": \"items size not enough\",\n    \"request_id\": \"941b4e14-d1c5-489f-a184-b2b17f8b4fdb\",\n    \"size\": 0,\n    \"experiment_id\": \"\",\n    \"items\": []\n}\n```\n\n#### Step 1: Retrieve EAS Service Information\n\nGet the service details to find the EAS service ID and configuration:\n\n```bash\naliyun eas describe-service \\\n  --cluster-id <cluster-id> \\\n  --service-name <service-name>\n```\n\n**What to extract:**\n- `Resource`: EAS service resource ID (e.g., `eas-r-1v4qb1yan3qmnjwxqe`)\n- `ServiceConfig.envs`: Environment variables containing:\n  - `REGION`: The region\n  - `INSTANCE_ID`: PAI-Rec instance ID\n  - `CONFIG_NAME`: Engine configuration name\n  - `PAIREC_ENVIRONMENT`: Environment (product/prepub)\n\n#### Step 2: Extract Request ID from API Response\n\nParse the API response JSON to get the `request_id` field. This will be used to search service logs.\n\n#### Step 3: Query EAS Service Logs\n\nUse the request ID as the **sole** filter to search service logs. Do NOT pass `--start-time` / `--end-time` when searching PAI-Rec business logs:\n\n```bash\naliyun eas describe-service-log \\\n  --cluster-id <cluster-id> \\\n  --service-name <service-name> \\\n  --keyword <request-id> \\\n  --page-size 500\n```\n\n**[CRITICAL] `--keyword <request-id>` is MANDATORY — local post-processing is FORBIDDEN:**\n- You MUST pass `--keyword <request-id>` (server-side filter, exact case-sensitive match on the full `request_id`). The API returns only log lines matching the keyword.\n- You MUST NOT omit `--keyword` and then filter locally (e.g., piping through `head`, `grep`, `python3`, `jq`, or any script).\n- You MUST NOT make multiple `describe-service-log` calls without `--keyword` hoping to find relevant lines by scanning the full log stream.\n- If a call with `--keyword` returns empty results, report that no matching logs were found — do NOT fall back to fetching unfiltered logs.\n- `--page-size` 500 captures the entire trace in a single page; matched entries for one request are usually < 30.\n\n> **❌ WRONG** (fetches ALL logs, filters locally — FORBIDDEN):\n> ```bash\n> aliyun eas describe-service-log --cluster-id cn-beijing --service-name embedding_recall | head -300\n> aliyun eas describe-service-log --cluster-id cn-beijing --service-name embedding_recall | grep \"request_id\"\n> ```\n>\n> **✅ RIGHT** (server-side keyword filter — REQUIRED):\n> ```bash\n> aliyun eas describe-service-log --cluster-id cn-beijing --service-name embedding_recall --keyword 0c6cbd91-5618-4705-8e08-9126bf4600f7 --page-size 500\n> ```\n\n**[CRITICAL] Time range silently drops business logs:**\n- With `--keyword` only (no time range), the CLI returns the full PAI-Rec application trace (`controller.go` / `feed.go` / `recall.go` / `rank_service.go` etc.) matching the request_id.\n- Adding `--start-time` / `--end-time` — even when the window covers the real timestamp — silently drops business logs and returns only infrastructure noise (`/bin/sh` heartbeats, `502 Bad Gateway` retries, `postgres.go dbstat`).\n- Use time ranges only for broad scans WITHOUT `--keyword`, in `yyyy-MM-dd HH:mm:ss` UTC format (no `T` / no `Z`); ISO-8601 forms like `2025-04-28T00:00:00Z` are rejected with `InvalidParameter`.\n\n#### Step 4: List Engine Configurations\n\nMap the environment and list matching configurations:\n\n**Environment Mapping:**\n- `product` → `Prod`\n- `prepub` → `Pre`\n\n```bash\naliyun pairecservice list-engine-configs \\\n  --instance-id <instance-id> \\\n  --environment <Prod|Pre> \\\n  --status Released \\\n  --name <config-name> > \"$WORKDIR/engine_configs_list.json\" 2>&1\n```\n\n**[MUST] Always pass `--name <config-name>` for server-side filtering:**\n`<config-name>` is already known from Step 1 (`ServiceConfig.envs.CONFIG_NAME`); forward it as `--name`. Omitting it returns the entire instance's config inventory (often hundreds of unrelated entries), forces client-side filtering, wastes tokens, and risks hitting CLI default pagination so the target row is silently dropped. `--name` is an exact-match filter on the server; do NOT substitute with `grep` / `jq select` post-processing. The same rule applies to every `list-engine-configs` invocation in this skill (Workflow 2 Step 1 included).\n\n**What to extract:**\n- Find the configuration with `Status: Released`\n- Get `EngineConfigId` and `Version`\n\n#### Step 5: Get Engine Configuration Details\n\n```bash\naliyun pairecservice get-engine-config \\\n  --instance-id <instance-id> \\\n  --engine-config-id <engine-config-id> > \"$WORKDIR/raw_engine_config.json\" 2>&1\n```\n\n**[MUST] Sanitize before display** — Config may contain plaintext passwords or\naccess keys. Always pipe through the sanitizer before printing to terminal;\nonly sanitized output (with credentials replaced by `***REDACTED***`) should\nappear there. The raw file at `$WORKDIR/raw_engine_config.json` can be passed\ndirectly to `scripts/validate.py` (which does not print credential values).\n\n```bash\npython3 scripts/sanitize_config.py \"$WORKDIR/raw_engine_config.json\"\n```\n\n**What to extract:**\n- `ConfigValue`: The actual engine configuration (JSON/YAML)\n\n#### Step 5.5 (Optional): Static Config Sanity Check\n\nRun `scripts/validate.py` against the retrieved `ConfigValue` to rule out structural /\nreference errors. See [references/config-validation.md](references/config-validation.md).\n\n```bash\nprintf '%s' \"$CONFIG_VALUE\" | python3 scripts/validate.py --stdin\n```\n\n**When to run:** when logs point at a config element or when diagnosing the config for the first time.\n**When to skip:** when logs show a non-config root cause (missing `scene_id`, upstream 5xx).\n**[MUST NOT]** Do not replace or duplicate `validate.py` (same restriction as Workflow 2 § Step 3).\n**[MUST] Scoping rule:** findings enter the final diagnosis ONLY when tied to log evidence for the current `request_id`.\n\n#### Step 5a (Conditional): Retrieve Experiment Configuration\n\n**Condition:** `experiment_id` in the API response is non-empty (e.g., `\"ER14_L21_L26#EG21_L38#EG38#E44_GL36_GL37\"`).\n\n**Parse:** Extract `EG{id}` (experiment group) and `E{id}` (experiment) numeric IDs from the string. Ignore `ER`, `L`, `GL` prefixes — they carry no config.\n\n```bash\n# For each EG{id}:\naliyun pairecservice get-experiment-group \\\n  --instance-id <instance-id> \\\n  --experiment-group-id <id> > \"$WORKDIR/experiment_group_<id>.json\" 2>&1\n# For each E{id}:\naliyun pairecservice get-experiment \\\n  --instance-id <instance-id> \\\n  --experiment-id <id> > \"$WORKDIR/experiment_<id>.json\" 2>&1\n```\n\n**What to extract:** The `Config` field — contains override parameters (e.g., `default.RecallNames`, `rankconf`, `filterNames`, `default.SortNames`) that supersede the base engine config.\n\n**Override priority (low → high):** Base Engine Config < ExperimentGroup.Config < Experiment.Config. Apply in Step 6 to understand actual runtime behavior.\n\n**Validate experiment configs** against the base config (reference existence check):\n\n```bash\npython3 scripts/validate.py \"$WORKDIR/raw_engine_config.json\" \\\n  --experiment-config \"$WORKDIR/experiment_group_<id>.json\" \\\n  --experiment-config \"$WORKDIR/experiment_<id>.json\"\n```\n\n#### Step 6: Comprehensive Analysis\n\nAnalyze the following components together:\n1. **API Response**: Error code, message, and returned data\n2. **Service Logs**: Trace logs for the request_id showing processing flow\n3. **Engine Configuration**: Settings that may affect the behavior\n4. **Experiment Overrides** (if `experiment_id` non-empty): Effective config = base config with experiment parameters applied on top\n\n**Common Issues to Check:**\n- Configuration mismatches (e.g., recall settings, filtering rules)\n- Experiment overrides (e.g., experiment changed `RecallNames` / `rankconf` from base config)\n- Resource limitations (e.g., insufficient items, timeout settings)\n- Data source issues (e.g., table access, feature availability)\n- Environment inconsistencies (e.g., prod config in prepub environment)\n\n**[MUST] Evidence-only reporting rule:**\n\nThe final diagnosis delivered to the user MUST be grounded strictly in what the EAS service logs and the engine configuration directly show. Apply the following constraints:\n\n- **Report only what is observed.** Quote the exact log line (file:line, level, message) and the exact config fragment that proves each claim.\n- **State the direct causal chain** from log evidence to the API response, and stop there.\n- **Do NOT add** any of the following unless the user explicitly asks:\n  - Speculative root causes not visible in logs/config (e.g., \"client probably sent wrong X\")\n  - Fix recommendations or remediation steps\n  - Conditional \"if X then Y\" scenarios\n  - Tangential best-practice advice (security, fallback design, naming, etc.)\n  - Guesses about upstream systems, client code, or data sources not covered by the logs/config\n- **If the evidence is insufficient** to reach a conclusion, state explicitly what additional data (specific log lines, other config versions, other environments) is needed, instead of guessing.\n- **Recommendations are opt-in only.** Provide fixes/suggestions only when the user explicitly requests them in a follow-up.\n\n---\n\n### Workflow 2: PAI-Rec Engine Configuration Validation\n\nThis workflow validates engine configurations for potential issues.\n\n**Input:** Configuration name and environment (Prod/Pre)\n\n#### Step 1: List Configuration Versions\n\nIf user doesn't provide `engine-config-id`, list available versions:\n\n```bash\naliyun pairecservice list-engine-configs \\\n  --instance-id <instance-id> \\\n  --environment <Prod|Pre> \\\n  --name <config-name>\n```\n\n**Display to user:**\n- `Version`: Version number\n- `Status`: Configuration status (Released/Draft/Archived)\n- `GmtCreateTime`: Creation timestamp\n- `EngineConfigId`: Version ID\n\nAsk user to select a version or provide the `engine-config-id`.\n\n#### Step 2: Retrieve Configuration Details\n\n```bash\naliyun pairecservice get-engine-config \\\n  --instance-id <instance-id> \\\n  --engine-config-id <engine-config-id> > \"$WORKDIR/raw_engine_config.json\" 2>&1\n```\n\n**[MUST] Sanitize before display** — Always sanitize before printing to terminal:\n\n```bash\npython3 scripts/sanitize_config.py \"$WORKDIR/raw_engine_config.json\"\n```\n\n#### Step 3: Run Schema + Rule Validation\n\n**[MUST]** Feed the extracted `ConfigValue` JSON into `scripts/validate.py`. The script\nenforces JSON Schema (`references/schema.json`) + reference-consistency rules and exits\nwith status 0 on pass, 1 on failure.\n\n```bash\n# From a saved JSON file (recommended)\npython3 scripts/validate.py \"$WORKDIR/raw_engine_config.json\"\n# Or pipe ConfigValue directly via stdin\nprintf '%s' \"$CONFIG_VALUE\" | python3 scripts/validate.py --stdin\n```\n\nRequires `jsonschema` (`pip install jsonschema`); if missing the script falls back to\nrule-only validation without Schema checks.\n\n**[MUST NOT] Do not replace or duplicate `validate.py`:**\n- Do NOT skip it; do NOT hand-write equivalent checks in Python / jq / grep / any other tool — the script is the authoritative validator.\n- Do NOT re-implement, re-check, or \"double-confirm\" any rule after the script has run; trust its output verbatim, including a clean `0 error(s), 0 warning(s)` run.\n- If the script cannot run (missing Python, dependency issue, etc.), fix the environment and re-run — do NOT fall back to manual checking.\n- Inspections OUTSIDE the script's scope are still allowed (see Step 4).\n\n**What the script checks (summary):**\n\n1. **Structure** — JSON well-formedness, required fields, types (`RecallConfs`,\n   `FilterConfs`, `SortConfs`, `AlgoConfs`, `SceneConfs`, `RankConf`,\n   `FeatureConfs`, `UserFeatureConfs`, `DebugConfs`, `FeatureLogConfs`,\n   `CallBackConfs`, `PipelineConfs`, etc.)\n2. **Enum values** — `RecallType` / `FilterType` / `SortType` /\n   `DebugConfs.OutputType` / `GeneralRankConfs.ActionConfs[].ActionType`\n3. **Reference consistency** — `SceneConfs.RecallNames` → `RecallConfs`;\n   `FilterNames` → `FilterConfs`; `SortNames` → `SortConfs`;\n   `RankConf.RankAlgoList` → `AlgoConfs`; any `DaoConf.AdapterType` +\n   `*Name` → the corresponding `*Confs` (Hologres / Redis / MySQL / TableStore /\n   FeatureStore / …)\n4. **Business rules**\n   - `User2ItemExposureFilter` with `WriteLog=true` + FeatureStore adapter: must set\n     `TimeInterval > 0`\n   - `PriorityAdjustCountFilter` in `accumulator` mode: `Count` must be strictly\n     increasing (use `Type=\"fix\"` for independent per-recall caps)\n   - `PipelineConfs.*.Name` must be globally unique\n   - `DebugConfs.Rate` must be an integer in `[0, 100]`\n5. **Duplicate name detection** within `RecallConfs`, `FilterConfs`, `SortConfs`,\n   `AlgoConfs`\n\nDetailed usage, exit codes, example outputs and the full rule list live in\n[references/config-validation.md](references/config-validation.md).\n\n#### Step 4: Evidence-Grounded Report\n\n**[MUST] Required first line of the report:** Quote `validate.py`'s stdout\nverbatim — either `Validation passed: configuration is well-formed` or\n`Validation finished: N error(s), M warning(s)`. A report missing this\nexact line is INVALID; restart from Step 3.\n\n**Manual inspection is allowed only** for concerns out of scope of\n`validate.py`: env / region / model-signature mismatches, cross-version diffs,\nnaming collisions between `RankScore` variables and model output fields, and\nroot-cause reading of any `[WARNING]` the script itself asks a human to judge.\nDo NOT add findings the script did not report unless you can tie them to one\nof these out-of-scope concerns.\n\n**Report structure:**\n\n- ✅ Checks passed — quote `validate.py`'s `0 error(s), 0 warning(s)` line\n- ⚠️  Warnings — copy each `[WARNING] <path>: <message>` from the script,\n  plus any out-of-scope inconsistency from manual inspection\n- ❌ Errors — copy each `[ERROR] <path>: <message>` from the script\n- Missing-evidence notes — ONLY when ≥1 ⚠️ warning is listed: state what extra data would upgrade that warning into a confirmed error. With 0 warnings, OMIT this section; do NOT fill it with generic out-of-scope disclaimers (cross-version diff, remote connectivity, region/endpoint consistency) — those are volunteered best-practice advice forbidden by the evidence-only rule.\n\nDo not add speculative fixes or best-practice tangents; suggestions are provided\nonly when the user explicitly asks for them.\n\n---\n\n## Success Verification Method\n\nFor detailed verification steps, see [references/verification-method.md](references/verification-method.md).\n\n**Quick Verification:**\n\n1. **For Diagnosis Workflow:**\n   - Service information retrieved successfully\n   - Logs found containing the request_id\n   - Configuration loaded correctly\n   - Root cause identified\n\n2. **For Validation Workflow:**\n   - Configuration retrieved successfully\n   - All validation checks executed\n   - Issues clearly reported\n   - Recommendations provided (if applicable)\n\n---\n\n## Cleanup\n\nThis skill performs read-only Alibaba Cloud API calls (no remote resources are\ncreated). Transient artifacts go to a per-session local `$WORKDIR` under `/tmp`\n(see Core Workflow preamble). The skill does NOT delete `$WORKDIR` automatically\n— the OS-level temp policy reclaims it (macOS reaps `/tmp` periodically; most\nLinux distros reap on reboot or via `systemd-tmpfiles`). To free disk space\nsooner, manually run `rm -rf /tmp/pairec-diag-*` outside the workflow.\n\n---\n\n## Best Practices\n\n1. **Log queries — keyword only, no time range, no local filtering**: For request-level diagnosis, pass `--keyword <request_id>` to `aliyun eas describe-service-log` and leave `--start-time` / `--end-time` unset. NEVER omit `--keyword` and post-process locally (e.g., `| head`, `| grep`, `| python3`) — this defeats server-side filtering, wastes tokens, and may miss logs beyond the first page. Combining keyword with a time range filters out business logs due to a CLI quirk (see Workflow 1, Step 3). Only use time ranges for broad non-request scans, and only with the `yyyy-MM-dd HH:mm:ss` UTC format (no `T` / no `Z`).\n2. **Trust `validate.py`**: For Workflow 2, treat `scripts/validate.py` as the single source of truth for the rules in its catalogue. Do NOT skip it and hand-write checks, and do NOT re-validate its rules manually after a clean run. Manual inspection is reserved for concerns out of its scope (env / region / model signature, cross-version diffs, `RankScore` vs model output naming).\n3. **Environment awareness**: Always verify that configurations match the target environment (Prod vs Pre); compare against a known-good version when issues persist.\n4. **Log retention**: EAS service logs are retained for limited periods; diagnose issues promptly after occurrence.\n5. **Evidence-only conclusions**: Ground every statement on a specific log line or config fragment. Follow the systematic workflow rather than jumping to conclusions from error messages alone. Do not speculate, do not propose fixes, and do not volunteer best-practice advice unless the user explicitly asks. If the evidence is insufficient, say what is missing rather than inferring.\n\n---\n\n## Reference Links\n\n| Reference Document | Description |\n|--------------------|-------------|\n| [RAM Policies](references/ram-policies.md) | Required RAM permissions for PAI-Rec and EAS APIs |\n| [Related Commands](references/related-commands.md) | Complete CLI command reference |\n| [Verification Method](references/verification-method.md) | Detailed verification procedures |\n| [CLI Installation Guide](references/cli-installation-guide.md) | Alibaba Cloud CLI installation instructions |\n| [Configuration Examples](references/configuration-examples.md) | Sample engine configurations and common patterns |\n| [Config Validation](references/config-validation.md) | `scripts/validate.py` usage, exit codes, rule catalogue |\n| [Troubleshooting Guide](references/troubleshooting-guide.md) | Common issues and solutions |\n| [Config Sanitization](scripts/sanitize_config.py) | Credential redaction before LLM analysis |\n","tags":{"latest":"0.0.3"},"stats":{"comments":0,"downloads":528,"installsAllTime":20,"installsCurrent":0,"stars":0,"versions":3},"createdAt":1778234795432,"updatedAt":1781681030720},"latestVersion":{"version":"0.0.3","createdAt":1781681030720,"changelog":"alibabacloud-pai-rec-diagnosis 0.0.3\n\n- Enforces that every `aliyun` API command must include a unique session-based `--user-agent` for observability.\n- Removes SKILL.md requirements for enabling or disabling \"AI-Mode\" in the workflow.\n- Clarifies that only published workflows may be used (e.g., forbids ad-hoc instance resource checks).\n- Updates documentation and references to reflect new verification steps and compliance requirements.\n- Removes the deprecated file `skill-card.md`.","license":"MIT-0"},"metadata":null,"owner":{"handle":"sdk-team","userId":"s173swjet2yrebzqrp6hjkvmy583mxef","displayName":"alibabacloud-skills-team","image":"https://avatars.githubusercontent.com/u/49941014?v=4"},"moderation":null}