@tplog/pi-zendy 0.3.7 → 0.3.8

package/README.md

@@ -12,6 +12,7 @@ zendy is a single pi extension that provides:
 
 - **LLM Tools** — Direct API access to Zendesk, Helm Watchdog, and Knowledge Graph. No external CLI dependencies.
 - **Slash Commands** — `/zendy-config` to set up credentials, `/zendy-status` to check connectivity.
+- **Skill** — a `zendy` skill (also `/skill:zendy`) that teaches the agent the ticket-analysis workflow, so "analyze ticket #1959" reliably uses the right tools in the right order.
 - **Session Safety** — Automatic workspace isolation and cleanup for source code analysis.
 
 Typical workflow:

package/dist/index.js

@@ -16,6 +16,10 @@ const PKG_ROOT = join(__dirname, "..");
 // This is the same file pi loads via the `pi.extensions` manifest field, so the
 // `zendy` launcher and `pi install` behave identically — no separate extraction step.
 const EXT_ZENDY = join(PKG_ROOT, "extensions", "zendy.ts");
+// Skill describing zendy and the ticket-analysis workflow. pi discovers it via
+// the pi.skills manifest field when installed as a package; the launcher passes
+// it explicitly so both load paths expose the same skill.
+const SKILL_ZENDY = join(PKG_ROOT, "skills", "zendy");
 function findPi() {
     try {
         return execFileSync("which", ["pi"], { encoding: "utf-8" }).trim();
@@ -83,6 +87,8 @@ async function main() {
     const args = [
         "--extension",
         EXT_ZENDY,
+        "--skill",
+        SKILL_ZENDY,
     ];
     // Pass through all user arguments
     args.push(...filteredArgs);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tplog/pi-zendy",
-  "version": "0.3.7",
+  "version": "0.3.8",
   "description": "Pi package for Dify Enterprise support ticket analysis",
   "repository": {
     "type": "git",
@@ -19,12 +19,16 @@
   "pi": {
     "extensions": [
       "./extensions/zendy.ts"
+    ],
+    "skills": [
+      "./skills"
     ]
   },
   "files": [
     "dist",
     "extensions",
-    "prompts"
+    "prompts",
+    "skills"
   ],
   "publishConfig": {
     "access": "public"

package/skills/zendy/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: zendy
+description: >
+  Dify Enterprise support ticket analysis using the zendy tools. Use whenever the
+  user mentions a Zendesk ticket number or asks to analyze, investigate, or reply to
+  a support ticket (e.g. "analyze ticket #1959", "分析工单", "工单分析", "チケットを調査"),
+  asks about a customer's Dify Helm chart values or version defaults, wants to find
+  similar historical tickets, or needs a customer reply drafted. Covers the full
+  workflow: fetch ticket → identify Dify version → check Helm values → search
+  similar tickets → draft reply in the ticket's language.
+---
+
+# zendy — Dify Enterprise Support Ticket Analysis
+
+zendy is a support-engineering harness for Dify Enterprise. It registers tools for
+Zendesk, the Dify Helm Watchdog, and a historical-ticket Knowledge Graph, so a
+support engineer can analyze a ticket end-to-end without leaving the terminal.
+
+## Tools
+
+| Tool | Use for |
+|------|---------|
+| `zendy_ticket_get` | Fetch one Zendesk ticket with comments, requester, assignee |
+| `zendy_ticket_search` | Search live Zendesk tickets (Zendesk search syntax) |
+| `zendy_whoami` | Verify which Zendesk account is authenticated |
+| `zendy_helm_get` | Dify Helm chart data by exact version: values.yaml, images, validation, latest |
+| `zendy_kg_search` | Semantic search over historical tickets; returns ticketIds |
+| `zendy_source_status` | Check the source-analysis workspace path and authorization rules |
+
+Use these tools for all data access. Do not use zcli, curl, or any external Zendesk
+CLI. If credentials are missing, tell the user to run `/zendy-config`; check
+connectivity with `/zendy-status`.
+
+## Ticket analysis workflow
+
+1. User gives a ticket number → `zendy_ticket_get` to pull ticket + comments.
+2. Identify the customer's exact Dify version from ticket fields or the thread.
+3. Pull the matching chart data with `zendy_helm_get` — always pass the exact
+   version. Defaults change between releases; never assume a config value from a
+   different version.
+4. Optionally `zendy_kg_search` for similar past tickets. Always cite the
+   `ticketId` values from results so the engineer can read the source tickets.
+   Empty results do not prove no similar issue exists.
+5. Synthesize findings and draft a reply.
+
+## Behavior rules
+
+- **Never guess.** Base conclusions on actual data — ticket fields, values.yaml,
+  knowledge-graph results. State clearly what is fact vs. inference.
+- **Don't recommend unverified solutions.** If something was not confirmed in
+  config or docs, say so explicitly.
+- **Reply drafts match the ticket language.** Detect the thread language
+  (Japanese, Chinese, or English) and draft in that language with appropriate
+  business tone.
+- **Source code analysis requires explicit user permission.** If config-level
+  analysis cannot settle the question, ask the user whether to check the source
+  (e.g. "需要我去源码确认吗？") — never clone without permission. Use
+  `zendy_source_status` to find the workspace.
+- **Inspect before filtering.** On the first call to an unfamiliar response shape,
+  look at the structure before writing filter expressions; never assume field names.