Update to Hive Axyl

{
  "description": "Investigate one individual user's activity history and latest state. This covers CS inquiry checks,\nreport verification, and confirmation of a specific user's purchases or logins. Identifying the user\nto investigate is also part of this skill's job.\nFollow the common rules of axyl-analytics-common as a prerequisite.\n\nTRIGGER when:\n- The user asks to check a specific user's activity, history, or state\n- Verifying \"what this user actually did\" based on a CS inquiry or report\n- Selecting and investigating one user matching a condition such as whale, dormant, or new\n\nDO NOT TRIGGER when:\n- Breaking a metric down by dimension (OS/country/market) → axyl-drill-down-metrics\n- Determining whether a metric is anomalous → axyl-detect-anomaly\n- The goal is to define and save a segment → axyl-create-segment\n- Dozens of users or more must be handled in a batch (this skill investigates one user at a time)\n",
  "included_files": [
    {
      "relative_path": "references/activity_investigation.md",
      "size_in_bytes": 5234
    },
    {
      "relative_path": "references/cross_check_settings.md",
      "size_in_bytes": 2390
    },
    {
      "relative_path": "references/user_id_sources.md",
      "size_in_bytes": 5820
    }
  ],
  "name": "axyl-inspect-user",
  "skill_md_contents": "---\nname: axyl-inspect-user\nmetadata:\n  version: \"1.0.0\"\ndescription: |\n  Investigate one individual user's activity history and latest state. This covers CS inquiry checks,\n  report verification, and confirmation of a specific user's purchases or logins. Identifying the user\n  to investigate is also part of this skill's job.\n  Follow the common rules of axyl-analytics-common as a prerequisite.\n\n  TRIGGER when:\n  - The user asks to check a specific user's activity, history, or state\n  - Verifying \"what this user actually did\" based on a CS inquiry or report\n  - Selecting and investigating one user matching a condition such as whale, dormant, or new\n\n  DO NOT TRIGGER when:\n  - Breaking a metric down by dimension (OS/country/market) → axyl-drill-down-metrics\n  - Determining whether a metric is anomalous → axyl-detect-anomaly\n  - The goal is to define and save a segment → axyl-create-segment\n  - Dozens of users or more must be handled in a batch (this skill investigates one user at a time)\n---\n\n# axyl-inspect-user\n\n> **CRITICAL — Read the common rules in [axyl-analytics-common](../axyl-analytics-common/SKILL.md) first.**\n> **CRITICAL — Use only company_cd, org_idx, and appid_group values confirmed through PROJECT_ID_GATE and organization access validation.**\n> **CRITICAL — Obtain the user ID only from the user or a USER_ID_GATE lookup result. Never guess or invent it (NO_GUESSING).**\n> **CRITICAL — Call `check_user_exists` first in every investigation. If `exists=false`, do not interpret that as no activity; recheck the user ID and project.**\n> **CRITICAL — User activity tracking is a raw log without metric aggregation rules. Do not present activity-history counts as metric values.**\n> **CRITICAL — Creating segments, snapshots, or user groups is a write operation. Check existing assets first and do not create them without WRITE_APPROVAL.**\n\n---\n\n## Tools\n\n- **User validation:** `check_user_exists`\n- **Activity investigation:** `get_user_activity_summary` / `list_user_activities` / `get_user_recent_info`\n- **Investigation target discovery:** `list_user_groups` / `get_user_group` / `preview_chart_rank`\n- **Target group creation when needed:** `regist_user_group` — irreversible write requiring WRITE_APPROVAL\n- **Metric-setting cross-check:** `list_except_users` / `list_metric_filters` / `list_start_dates`\n\nFor detailed arguments, returns, and permission scopes, use the direct tool-reference links in\n[axyl-analytics-common](../axyl-analytics-common/SKILL.md).\n`axyl-create-segment` handles any segment and snapshot creation required before `regist_user_group`.\n\n## Reference Documents\n\n- [Obtaining a user ID](references/user_id_sources.md) — the four USER_ID_GATE paths, actual calls, and candidate presentation format\n- [Investigating activity history](references/activity_investigation.md) — narrowing from summary to detail and handling pagination\n- [Cross-checking metric settings](references/cross_check_settings.md) — correcting conclusions when raw activity and aggregated metrics differ\n\n---\n\n## Workflow\n\n### Prerequisite — Common Rules\n\nPROJECT_ID_GATE, WRITE_APPROVAL, and NO_GUESSING from axyl-analytics-common apply. Pass the same confirmed\n`company_cd`, `org_idx`, and `appid_group` values to every user-investigation tool. This workflow identifies\none user and verifies facts; distinguish it from chart or segment analysis that finds patterns across users.\n\n### Phase 0 — Classify the Request\n\n```\nA. The user ID is known                         → user-supplied ID path in Phase 1\nB. One user matching a condition must be found → existing-group or ranking path in Phase 1\nC. The goal is a multi-user distribution/pattern → axyl-drill-down-metrics or axyl-detect-anomaly\nD. The goal is to define or save a segment      → axyl-create-segment\n```\n\nDo not ask again when the investigation purpose and period are already available. If no period was provided,\nnarrow it using available context such as the inquiry or report time. Ask the user when there is no reasonable\nbasis for choosing a period.\n\n### Phase 1 — Confirm the Project and Investigation Target\n\n```\nStep 1-1. PROJECT_ID_GATE\n  → confirm company_cd / org_idx / appid_group in the same project scope\n\nStep 1-2. USER_ID_GATE\n  ├─ User supplied an ID        → use that value as given\n  ├─ Existing condition group   → list_user_groups → get_user_group\n  ├─ Arbitrary metric criterion → ORG_WORKSPACE_GATE (workspace_idx), then query candidates with the\n  │                               userId dimension in preview_chart_rank\n  └─ Existing paths cannot solve it\n                               → propose segment, snapshot, and group creation; wait for approval ⛔\n\nStep 1-3. If several candidates remain, present no more than five with identifying evidence\n          and wait for the user's selection ⛔\n\nStep 1-4. check_user_exists\n  ├─ exists=true  → Phase 2\n  └─ exists=false → do not query activity; recheck the user ID and project\n```\n\nFollow [Obtaining a user ID](references/user_id_sources.md) for path priority and calls. Never select a candidate\non the user's behalf. Creating a new segment, snapshot, and group is expensive and leaves persisted assets, so\npropose that path only when an existing group or ranking cannot satisfy the request.\n\n### Phase 2 — Narrow the Activity Range\n\n```\nStep 2-1. get_user_activity_summary\n  → check totals for the entire period and counts by date\n  → select dates relevant to the inquiry or with concentrated activity\n\nStep 2-2. list_user_activities\n  → query only the selected dates or range\n  → inspect only the activities and properties needed for the conclusion instead of expanding the full history\n\nStep 2-3. get_user_recent_info (when needed)\n  → check the latest classification, cumulative purchases, server, and country from the per-date snapshot\n```\n\nFollow [Investigating activity history](references/activity_investigation.md) for detailed lookup and pagination.\nDo not exhaust an unrelated broad history. After narrowing to the smallest supported date range, continue the pages needed\nto answer a targeted event/property question; if the search stops before `has_more=false`, report it as incomplete and do\nnot conclude that the target is absent.\n\n### Phase 3 — Cross-check Metric Settings and Conclude\n\nMetric-excluded users, metric filters, and metric start dates do not apply to user activity tracking. When activity\nhistory and a metric differ, follow [Cross-checking metric settings](references/cross_check_settings.md) and verify:\n\n| Check | Tool |\n|---|---|\n| Is this user registered as excluded from metrics? | `list_except_users` |\n| Is the server or app used by this user filtered out? | `list_metric_filters` |\n| Did the activity occur before the metric start date? | `list_start_dates` |\n\nIf one applies, explain the difference as configured aggregation behavior. If none is confirmed, do not declare\ndata loss or a bug; report confirmed facts separately from remaining uncertainty.\n\nInclude the investigation target and period, confirmed activity and latest state, whether metric settings were\ncross-checked, and the basis of the evidence. `activity_date_time` reflects the user's timezone, while\n`properties.dateTime` is UTC. Since their dates can differ, use `activity_date_time` when explaining times unless\nthere is a specific reason not to.\n\n---\n\n## Full Chain\n\n```\n[Classify request]\n→ PROJECT_ID_GATE → USER_ID_GATE\n   ├─ Supplied ID             → check_user_exists\n   ├─ Existing user group     → list_user_groups → get_user_group → user selection ⛔\n   ├─ Arbitrary metric rank   → preview_chart_rank → user selection ⛔\n   └─ Existing paths fail     → propose creation scope → WRITE_APPROVAL before each write ⛔\n                               → axyl-create-segment → regist_user_group\n→ check_user_exists\n   ├─ exists=false → stop and recheck the ID and project\n   └─ exists=true  → get_user_activity_summary\n                    → narrow the range and call list_user_activities\n                    → [when needed] get_user_recent_info\n                    → [when metrics differ] cross-check settings\n                    → report evidence and uncertainty separately\n```\n\n---\n\n## Prohibited Actions ❌\n\n| Situation | Prohibited | Correct action |\n|------|----------|-----------|\n| No user ID | Invent or guess one | Find candidates through an existing group or ranking in USER_ID_GATE and wait for user selection |\n| Several candidates | Pick one automatically or present a long list | Present no more than five candidates with identifying evidence |\n| `exists=false` | Conclude that there is no activity | Explain that the ID or project may be wrong and recheck |\n| Multiple-user investigation | Query users one by one | Use `preview_chart_rank`, a segment, or an analysis skill |\n| Detailed activity lookup | Query the whole period and every page from the start | Use per-date summary counts to narrow the range first |\n| Presenting results | Dump raw activity history or nested properties | Summarize only the facts and evidence relevant to the investigation purpose |\n| Metric mismatch | Immediately conclude data loss or a bug | Cross-check excluded users, filters, start dates, and time boundaries first |\n| Activity counts | Present them as metric values | State that they are based on raw activity history |\n| Investigation assets | Create a segment, snapshot, or group without checking existing groups | Prefer existing assets and obtain approval before each write |\n\n---\n\n## Exception Handling\n\n| Situation | Response |\n|---|---|\n| User does not exist in the confirmed project | Stop activity lookup and ask the user to check for a typo or an ID from another project |\n| No existing user group matches the condition | Check whether an arbitrary metric ranking can solve it; only then propose creating a segment, snapshot, and group |\n| User-ranking result is too large | Narrow the period and filters. Do not assume `rank_limit` reduces response rows |\n| Activity summary is empty | Do not conclude that the user does not exist. Recheck `check_user_exists`, the period, project, and time boundary |\n| Detailed activity is too large | Narrow the date and event range from the summary; ask the user to choose a range when the needed scope is unclear |\n| Latest property value is `-` | Report it as not collected, not as zero or absent |\n| Activity and metric disagree | Cross-check settings and time boundaries; leave the cause unconfirmed when it cannot be established |\n| Not connected to the Hive Axyl MCP server (first install, never signed in), or the sign-in session expired | Apply MCP_CONNECTION_GATE in axyl-analytics-common. Cannot retry without user action |\n"
}