@tplog/pi-zendy 0.2.17 → 0.3.1

package/skills/helm-watchdog/SKILL.md

@@ -1,146 +0,0 @@
----
-name: helm-watchdog
-description: "Query Dify Helm chart metadata — values.yaml, container images, validation results, and version info. Use when analyzing Helm-level configuration for a specific Dify Enterprise version."
----
-
-# Dify Helm Watchdog Skill
-
-Query the dify-helm-watchdog **HTTP API** to inspect Helm chart data for any cached Dify version.
-
-**IMPORTANT: This is a REST API, not a CLI tool. There is no `helm-watchdog` binary. Use `curl` to call the endpoints below.**
-
-## Quick Reference — Copy-Paste Commands
-
-```bash
-# Get values.yaml for a version
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/3.8.0/values"
-
-# Get version metadata (chart version → app version mapping)
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/3.8.0" | jq .
-
-# List all container images with their paths and tags
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/3.8.0/images" | jq '.[] | {path, tag}'
-
-# Find a specific component's image (e.g., plugin-connector)
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/3.8.0/images" | jq '.[] | select(.path | test("plugin-connector"))'
-
-# Check image validation status
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/3.8.0/images?validate=true" | jq '.[] | {path, tag, status}'
-
-# Get latest version number
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/latest?versionOnly=true"
-```
-
-### Images API response structure
-
-The `/images` endpoint returns a JSON array. Each element has these fields:
-```json
-{
-  "path": "langgenius/dify-api",        // image repository path
-  "tag": "7a1f0e32...",                 // image tag
-  "registry": "docker.io",             // registry (may be absent)
-  "valuesPath": "api.image"            // location in values.yaml
-}
-```
-
-Key: the field is `.path`, not `.name` or `.repository`.
-
-## When to Use
-
-- Looking up `values.yaml` for a specific Dify chart version
-- Checking what container images a chart version uses
-- Finding the latest chart version
-- Validating chart image availability
-- Answering customer questions about Helm configuration, default values, or image tags
-
-## When NOT to Use
-
-- Modifying chart values or deploying — this is read-only
-- Anything outside the Helm chart layer (application code, runtime behavior)
-
-## Base URL
-
-```
-https://dify-helm-watchdog.vercel.app/api/v1
-```
-
-## API Endpoints
-
-### List cached versions
-
-```bash
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions" | jq .
-```
-
-### Get latest version
-
-```bash
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/latest"
-# Plain text version number only:
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/latest?versionOnly=true"
-```
-
-### Get version metadata
-
-```bash
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/3.8.0" | jq .
-```
-
-Returns chart version, app version, creation date, and asset URLs.
-
-### Get values.yaml
-
-```bash
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/3.8.0/values"
-```
-
-Returns the full `values.yaml` for the requested chart version. This is the most commonly used endpoint — use it to check default configuration, environment variables, image tags, and feature flags.
-
-### Get container images
-
-```bash
-# JSON output
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/3.8.0/images" | jq .
-# With validation status
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/3.8.0/images?validate=true" | jq .
-```
-
-Lists all container image references from the chart's values. Useful for answering questions about image tags (`latest` vs pinned), base images, and vulnerability scoping.
-
-### Get validation results
-
-```bash
-# All validations
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/3.8.0/validation" | jq .
-# Only missing images
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/versions/3.8.0/validation?status=MISSING" | jq .
-```
-
-### Inspect cache metadata
-
-```bash
-curl -s "https://dify-helm-watchdog.vercel.app/api/v1/cache" | jq .
-```
-
-## Practical Guidance
-
-1. **Start with version metadata** to confirm the chart version exists and get the app version mapping (e.g., chart 3.8.0 → app 1.12.0).
-2. **Use values.yaml** to answer configuration questions — most customer inquiries about Helm settings can be resolved here.
-3. **Use images** endpoint when the question is about container images, tags, or vulnerability scope.
-4. When a customer reports an issue on a specific version, always pull the values.yaml for **that exact version** — defaults change between releases.
-5. Output is JSON unless otherwise noted (values endpoint returns raw YAML).
-
-## Version Mapping
-
-Chart versions map to Dify app versions. Common mappings:
-- Chart 3.8.0 → App 1.12.0
-- Chart 3.7.5 → App 1.11.4
-
-Use the version metadata endpoint to confirm the mapping for any version.
-
-## Notes for the Agent
-
-- All endpoints are public and read-only, no authentication needed for GET requests.
-- Use `curl -s` and pipe to `jq` for readable output.
-- The values.yaml can be large — if you only need a specific section, pipe through `grep` or use `yq` if available.
-- When comparing versions, pull values for both and diff them.

package/skills/source-check/SKILL.md

@@ -1,143 +0,0 @@
----
-name: source-check
-description: "Clone and analyze Dify source code to investigate customer issues. Knows the repo map: enterprise backend/frontend, open-source core, plugin daemon, sandbox. Human-triggered only."
----
-
-# Dify Source Analysis Skill
-
-Clone the correct Dify repository and analyze source code to investigate customer issues.
-
-## When to Use
-
-- The user explicitly asks to look at the source code
-- A question cannot be answered from Helm chart values alone
-
-## When NOT to Use
-
-- Do NOT proactively decide to clone source code — wait for the user to ask
-- Do NOT use for questions answerable from values.yaml or documentation
-
-## Repository Map
-
-**First, determine which repo to clone based on the problem area:**
-
-**Clone destination:** always clone under `"$ZENDY_SRC_DIR"` (set by the `source-cleanup`
-extension at session start). The extension will wipe the whole directory when the
-session ends, so anything inside is guaranteed to be cleaned up — even if you forget.
-If for some reason `$ZENDY_SRC_DIR` is not set, fall back to `/tmp` but tell the user.
-
-| Problem area | Repo | Access | Language | Clone command |
-|---|---|---|---|---|
-| SSO, token, session, SCIM, license, audit, branding, MFA, password policy | `langgenius/dify-enterprise` | private | Go | `git clone --depth 1 --branch <tag> git@github.com:langgenius/dify-enterprise.git "$ZENDY_SRC_DIR/dify-enterprise-<tag>"` |
-| Enterprise Dashboard UI, admin console frontend | `langgenius/dify-enterprise-frontend` | private | TypeScript | `git clone --depth 1 --branch <tag> git@github.com:langgenius/dify-enterprise-frontend.git "$ZENDY_SRC_DIR/dify-enterprise-frontend-<tag>"` |
-| API, workflow, knowledge base, model provider, RAG, chat | `langgenius/dify` | public | Python | `git clone --depth 1 --branch <tag> git@github.com:langgenius/dify.git "$ZENDY_SRC_DIR/dify-<tag>"` |
-| Plugin runtime, plugin execution | `langgenius/dify-plugin-daemon` | public | Go/Python | `git clone --depth 1 --branch <tag> git@github.com:langgenius/dify-plugin-daemon.git "$ZENDY_SRC_DIR/dify-plugin-daemon-<tag>"` |
-| Code sandbox execution | `langgenius/dify-sandbox` | public | Go | `git clone --depth 1 --branch <tag> git@github.com:langgenius/dify-sandbox.git "$ZENDY_SRC_DIR/dify-sandbox-<tag>"` |
-
-Enterprise repos also contain these components (all in dify-enterprise):
-- **gateway** — enterprise API gateway (`cmd/gateway/`, `pkg/gateway/`)
-- **plugin-connector** — plugin pod orchestration on K8s (`cmd/plugin-connector/`, `pkg/connector/`)
-- **plugin-manager** — enterprise plugin management (`cmd/plugin-manager/`, `pkg/plugin-manager/`)
-- **plugin-crd** — K8s CRD controller for plugins (`cmd/plugin-crd/`, `pkg/plugincrd/`)
-- **audit** — audit logging (`cmd/audit/`, `pkg/audit/`)
-
-## Version Mapping
-
-Customer's Dify version → correct git tag:
-
-1. Get chart version from Zendesk ticket fields (e.g., `3.8.0`)
-2. Use helm-watchdog to get the image tags from values.yaml:
-   - `enterprise.image.tag` → tag for `dify-enterprise` and `dify-enterprise-frontend` (e.g., `0.15.0`)
-   - `api.image.tag` → tag for `dify` (usually a commit hash, e.g., `7a1f0e32...`)
-   - `pluginDaemon.image.tag` → tag for `dify-plugin-daemon`
-   - `sandbox.image.tag` → tag for `dify-sandbox`
-
-## dify-enterprise Directory Structure (Go)
-
-```
-cmd/                              # Entry points (one per component)
-├── enterprise/                   # Main enterprise backend
-├── gateway/                      # API gateway
-├── audit/                        # Audit service
-├── plugin-connector/             # Plugin K8s orchestrator
-├── plugin-manager/               # Plugin manager
-├── plugin-crd/                   # K8s CRD controller
-└── plugin-shader/                # Plugin image builder
-
-pkg/
-├── enterprise/
-│   └── service/                  # Core business logic
-│       ├── console-sso.go        # Console SSO login (SAML/OIDC/OAuth2)
-│       ├── web-sso.go            # WebApp SSO login
-│       ├── dashboard-sso.go      # Dashboard SSO
-│       ├── cookie.go             # Cookie/session management
-│       ├── ssoconfig.go          # SSO configuration
-│       ├── member.go             # User/member management
-│       ├── license.go            # License validation
-│       ├── mfa.go                # Multi-factor auth
-│       ├── password-policy.go    # Password policy
-│       ├── scim.go               # SCIM provisioning
-│       ├── scim-users.go         # SCIM user sync
-│       ├── scim-groups.go        # SCIM group sync
-│       ├── branding.go           # Custom branding
-│       ├── workspace.go          # Workspace management
-│       ├── admin-*.go            # Admin operations
-│       └── webapp.go             # WebApp config
-├── sysconf/
-│   ├── keys.go                   # Configuration key definitions
-│   └── values.go                 # Default values
-├── auth/                         # Authentication
-├── connector/                    # Plugin connector logic
-├── gateway/                      # Gateway logic
-├── plugin/                       # Plugin management
-├── plugin-manager/               # Plugin manager logic
-├── plugincrd/                    # K8s CRD logic
-├── audit/                        # Audit logic
-├── kube/                         # Kubernetes utilities
-└── data/                         # Data layer
-
-ts/                               # TypeScript code
-├── connector/                    # Plugin connector frontend
-├── enterprise_client/            # Enterprise API client
-└── dify/                         # Dify integrations
-```
-
-## dify (open-source) Directory Structure (Python)
-
-```
-api/                              # Backend API (Flask)
-├── controllers/                  # HTTP handlers
-├── core/
-│   ├── workflow/                 # Workflow engine
-│   ├── rag/                      # RAG pipeline
-│   ├── model_runtime/            # Model provider integrations
-│   ├── app/                      # App orchestration
-│   └── tools/                    # Built-in tools
-├── services/                     # Business logic
-├── models/                       # Database models
-└── configs/                      # Configuration
-
-web/                              # Frontend (Next.js / TypeScript)
-├── app/                          # Pages
-├── components/                   # UI components
-└── service/                      # API client
-```
-
-## Analysis Approach
-
-1. **grep first** — find relevant files by keyword (feature name, config key, error message)
-2. **Read identified files** — understand the logic
-3. **Trace the flow** — API endpoint → handler → service → data layer
-4. **Compare** with the customer's reported behavior
-5. **Conclude** — bug, misconfiguration, or expected behavior
-
-## Rules
-
-- Always shallow clone (`--depth 1`) for speed
-- State confidence level: "confirmed from code" vs "inferred from structure"
-- Read-only — never modify source code
-- Clone into `"$ZENDY_SRC_DIR"`. The `source-cleanup` extension wipes this directory
-  on session shutdown, so manual `rm -rf` after analysis is no longer required.
-  If the user asks for immediate cleanup mid-session, use the `/cleanup-src` slash
-  command (wipes `/tmp/dify-*` and orphan session dirs).
-- If clone fails (permission denied), tell the user to configure SSH keys

package/skills/zendesk-cli/SKILL.md

@@ -1,37 +0,0 @@
----
-name: zendesk-cli
-description: "Zendesk ticket lookup via the zcli CLI. Provides ticket metadata, comment threads, and search — all as JSON."
----
-
-# zendesk-cli
-
-`zcli` is a Zendesk CLI that outputs JSON. Use it to fetch tickets, comments, and search results.
-
-## Quick start
-
-Discover all commands and options:
-
-```bash
-zcli --help
-zcli <command> --help
-```
-
-## Install (if missing)
-
-```bash
-npm install -g @tplog/zendesk-cli
-zcli configure
-```
-
-## Key behaviors the agent must know
-
-- **`zcli <email>` is assignee lookup, not requester.** This is the most common mistake.
-- **`zcli follower <email>`** is a separate command — don't try to filter assignee results manually.
-- **Output is already JSON.** No `--json` flag needed. Summarize directly from stdout.
-- **When summarizing a ticket, always parallel-call both:**
-  ```bash
-  zcli <id>            # ticket metadata
-  zcli comments <id>   # comment thread
-  ```
-  Ticket metadata alone is not enough for a complete summary.
-- **Errors are also JSON on stdout** with non-zero exit code. Check stdout, not just stderr.

package/skills/zendesk-kg/SKILL.md

@@ -1,120 +0,0 @@
----
-name: zendesk-kg
-description: "Search the Zendesk Knowledge Graph via the `zendesk-kg` CLI. Hybrid (vector + fulltext) retrieval over historical tickets — use for cross-ticket / semantic lookups that go beyond `zcli` single-ticket fetch."
----
-
-# zendesk-kg
-
-`zendesk-kg` is a CLI for the Zendesk Knowledge Graph retrieval API. It performs **hybrid search (vector + fulltext) with Reciprocal Rank Fusion** over an index of historical Dify Enterprise support tickets — each ticket pre-summarized into `quickSummary` / `issueSummary` / `solutionSummary`. Use it when you need to find **similar past issues, related conversations, or aggregated knowledge** that a single-ticket lookup can't surface.
-
-## When to use this skill
-
-- The user is investigating a recurring symptom and you want to find **other tickets that show the same pattern**
-- You need cross-ticket evidence ("has anyone else hit this?") to support a hypothesis
-- You want to retrieve related KB-style ticket summaries before drafting a reply
-
-## When NOT to use
-
-- The user gave you a specific ticket ID — use `zcli <id>` + `zcli comments <id>`. zendesk-kg returns curated *summaries*, not the raw ticket / comment thread.
-- The question is answerable from Helm chart values or source code — use `helm-watchdog` or `source-check` first.
-
-## Quick start
-
-```bash
-zendesk-kg --help
-zendesk-kg search --help     # has the most options worth knowing
-```
-
-## Install (if missing)
-
-The standard `zendy` install handles this automatically. To install manually:
-
-```bash
-curl -fsSL https://raw.githubusercontent.com/sorphwer/zendesk-kg-cli-release/main/install.sh | sh
-zendesk-kg init   # paste your RETRIEVER_API_KEY
-```
-
-Config lives in `~/.zendesk-kg/.env` (`RETRIEVER_API_KEY`, `RETRIEVER_API_URL`).
-
-## Core commands
-
-| Command | Purpose |
-|---|---|
-| `zendesk-kg search "<query>" [flags]` | Hybrid search. Natural-language query. |
-| `zendesk-kg stats` | Show current index size / coverage. |
-| `zendesk-kg health` | Check API connectivity. **Currently unreliable — see Caveats below.** |
-| `zendesk-kg init` | Re-enter API key / URL. Setup only. |
-| `zendesk-kg set-env output json` | Set default output format. |
-| `zendesk-kg update` | Self-update the CLI binary. Don't run proactively. |
-
-## `search` flags worth knowing
-
-```
--k, --top-k INTEGER     Number of results to return (1-20, default 5)
--s, --order-by TEXT     rrfScore | createdAt | priority
--o, --output FORMAT     table | json | text
-    --priority TEXT     Filter: high / normal / low / urgent
--v, --version TEXT      Filter by Dify version mentioned in the ticket
-    --created-after DATE
-    --use-llm           LLM-formatted summary instead of raw JSON
-```
-
-For agent automation always use `-o json`. `table` is for humans, `text` is for terminal browsing.
-
-## Output format (real shape, not pseudocode)
-
-`search -o json` returns:
-
-```json
-{
-  "results": [
-    {
-      "ticketId": "765",
-      "subject": "<original ticket subject, often non-English>",
-      "status": "closed | open | pending | ...",
-      "priority": "low | normal | high | urgent",
-      "quickSummary": "1-2 sentence summary in English",
-      "issueSummary": "Multi-paragraph: Environment / Symptoms / User Questions / Timeline",
-      "solutionSummary": "Multi-paragraph: Analysis / Actions / Recommendations / Resolution",
-      "createdAt": "YYYY-MM-DD HH:MM:SS",
-      "handledBy": ["agent_name", ...],
-      "versions": ["3.8.0", ...],
-      "keywords": ["sso", "oidc", ...],
-      "referenceUrls": [...],
-      "channels": { ... }
-    },
-    ...
-  ]
-}
-```
-
-**Always surface `ticketId`, `quickSummary`, and `solutionSummary`** when reporting back to the user. The FDE will follow up on the ticket via `zcli <ticketId>` for full context. Don't dump the whole JSON.
-
-## Behavioral rules the agent must follow
-
-- **Use natural-language queries.** Describe the symptom in the user's words; the graph handles semantics. Don't manually OR a bunch of keywords.
-- **Cite ticket IDs.** When summarizing for the user, always include the ticket IDs the synthesis is drawn from — the FDE will want to read the originals.
-- **`search` returns curated summaries, not raw tickets.** For raw comment threads, follow up with `zcli <id>` + `zcli comments <id>`.
-- **Filter when you can.** If the user mentioned a Dify version (`-v 3.8.0`) or priority (`--priority high`), use the flag — don't filter post-hoc on the JSON.
-- **Don't assume coverage.** The KG is indexed over a snapshot, not live Zendesk. Empty result ≠ proof nothing exists. Fall back to `zcli search` for live data.
-- **Don't run `update` without explicit user request.** Self-update mutates the binary on disk.
-
-## Typical retrieval flow
-
-```bash
-# 1. Cast a wide semantic net for context (most-relevant first by default)
-zendesk-kg search "users intermittently logged out after SSO with MFA enabled" -k 5 -o json
-
-# 2. Inspect the most relevant ticket end-to-end via zcli
-zcli <ticketId>
-zcli comments <ticketId>
-
-# 3. Cross-check Helm config / source as needed
-# (helm-watchdog, source-check skills)
-```
-
-## Caveats
-
-- **`health` and `stats` may report `Redirecting...` / `unreachable` even when `search` works.** As of zendesk-kg 0.1.2 / retriever backend v0.1, those endpoints sit behind a 302 redirect to a login page while `/search` is API-key-authenticated directly. **Don't gate retries on `health`** — if `search` failed and you want to diagnose, retry `search` itself or surface the error verbatim to the user. Treat `health: ok` as a real signal, but `health: unreachable` as inconclusive.
-- **Errors come back in the JSON body, not via exit code.** All commands tend to exit 0 even when the API rejects the request. Always parse `stdout` for `"error"` / `"status": "unreachable"` instead of relying on `$?`.
-- **Index is a snapshot.** The catalog won't include tickets that opened today; for fresh tickets use `zcli search`.