whatevertr

Whatevertr POC Zendesk API — Development skill for Claude Code

Development community

Claude Skill que entrega dados em planilha no formato tidy — sem células mescladas, Excel Table, datas ISO e aba Schema legível por máquina.

How to install Whatevertr POC Zendesk API

This entry records only its repository, not the path inside it, so there is no exact command to give. Open whatevertr/whatevertr-poc-zendesk-api and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Whatevertr POC Zendesk API does

Claude Skill que entrega dados em planilha no formato tidy — sem células mescladas, Excel Table, datas ISO e aba Schema legível por máquina. Navegável por humano e por IA. Parte do NUD | Constellation Method. CC-BY-4.0.

Alternatives in Development

  • North Star Metric — Define North Star Metric and input metrics constellation 7.8k ★
  • Sellersprite Rpa Skills — 基于浏览器 RPA + 数据分析的项目,覆盖 sellersprite.com(亚马逊卖家精灵) 30 ★
  • Capturar — Captura una tarea o goal en formato canónico 1 ★

README

🇧🇷 [Leia em português](README.pt-BR.md)

PoC — Validating Service-Desk Architecture Premises via the Zendesk API

Nine test suites run entirely through the REST API on a disposable trial instance, proving, before any official build, that the platform sustains a redesigned support architecture: collapsed groups, a three-level taxonomy (group → category → sub-category), SLA anchored on field values, and multi-ticket journey measurement.

🌐 **Language note:** this README is in English; the detailed docs under `docs/` are currently in Portuguese. Translations welcome — open a PR.

What this proves

**9 test suites · 13 verdicts · validated exclusively via REST API · fully auditable request/response history.**

  • A unified ticket form with conditional fields, including the real limit of native conditionality (it toggles fields, not dropdown options) and the viable pattern around it.
  • SLA policies driven by custom field values, in business hours, with the three operational requirements nobody mentions upfront: end-user requester, ticket priority set, and the metric-events endpoint lagging by hours.
  • Group-based routing fired on creation, the negative test (changing the reason does not reroute), and a corrective trigger that reverts invalid moves in the same update.
  • The core premise: end-to-end journey SLA is analytically computable from the platform's native trail, for linear chains and parallel trees alike (critical path vs. total effort), linked by a lookup field.
  • Customer experience: one visible ticket number (the shell), internal stages invisible in the portal, and the exact leak risk, proven, not assumed.
  • One CSAT survey per journey (never per stage), answered programmatically through OAuth impersonation and joined with the composed SLA in a one-row-per-journey report.
  • Legacy migration: only solve is blocked by an empty required field (enforced by the API too, not just the UI), native bulk backfill via jobs, and the sequence that migrates