If you spend your day inside Claude Code, Codex, or Cursor, you’ve probably noticed the same thing we did: your coding agent is already good at working in GitHub. It reads issues, writes comments, opens pull requests. So when your support tickets are GitHub Issues too, the agent doesn’t need a new integration to help with them — it needs to know your conventions.

That’s the whole idea behind Scitor’s agent skill. No SDK, no MCP server, no API key to wire up. If your agent can run gh, it can already read your queue and reply to customers. The skill just teaches it what /send means, which labels are Scitor’s, and where your routing rules live.

This post is a practical walkthrough of what that looks like day to day — and, just as importantly, where we think a person still needs to read before something goes out.

Install it once

npx skills add scitorapp/agent-skills

That’s it. It works the same way across Claude Code, Codex, Cursor, Copilot, Devin, Gemini, and OpenCode, because there’s nothing agent-specific about it — it’s a description of gh commands and Markdown conventions, not a proprietary client.

What it looks like in practice

Ask it to triage. Scitor already labels incoming tickets with sentiment, priority, and category. Your agent can filter on those the same way you would:

gh issue list --repo acme/support \
  --label "sentiment:negative" \
  --label "priority:urgent"

Ask Claude Code “what’s in the urgent queue right now” and it runs some version of this, then summarizes what it finds — which customers, how long they’ve been waiting, whether anyone’s replied yet.

Ask it to draft a reply. A Scitor reply is a GitHub comment that starts with /send; everything below it becomes the email the customer receives.

gh issue comment 482 --repo acme/support --body '/send

Hi Dana — the export now includes archived
records. Please try again.

Acme Support'

This is the part worth being deliberate about. Ask your agent to draft a reply and it will have actually read the ticket, your docs, and possibly the relevant code — often a better first draft than starting from a blank box. But “draft” is the operative word. Read it before it goes out. Customers can tell when a reply doesn’t quite land, and an agent that’s confidently wrong is still confidently wrong. Scitor doesn’t auto-send anything the skill types — the comment sits there like any other comment until someone (agent or human) adds /send, so there’s a natural pause to actually look at it.

Ask it to handle the busywork. Priority, assignment, follow-ups — these are all slash commands, so they’re easy for an agent to fire off correctly and easy for you to double-check afterward in the issue history:

/priority urgent
/assign @dana
/followup 2d Check the customer confirmed

Ask it to change your config. Routing rules, SLAs, and auto-replies live in .github/scitor.yaml. An agent proposing a change to that file opens a pull request, same as it would for application code — you review it the same way, in the same place.

A realistic example

Say you start your morning with: “Claude, what came in overnight and does anything need me right now?”

A reasonable agent response: it lists three new tickets, flags one as sentiment:negative from a customer who’s emailed twice before, drafts a reply to the straightforward one referencing your docs, and tells you the negative one probably needs your judgment rather than its draft. You read the draft, tweak a sentence, send it. You handle the escalation yourself. Two minutes instead of fifteen — but nothing left your inbox without a person having seen it.

That division of labor is the point. The agent is good at the parts that are mostly retrieval and pattern-matching: finding the ticket, finding the doc, assembling a first pass. It’s not the part that decides whether “the export now includes archived records” is actually true, or whether an annoyed customer needs a different tone than your default template. That judgment stays with your team.

Why this doesn’t need a special integration

There’s no Scitor API the agent is calling. It’s gh and Markdown, which means:

Nothing to trust beyond what you already trust. You’re not granting a third-party agent tool access to a new system — it’s using the same GitHub permissions your team already has.
Everything is auditable. An agent’s reply is a comment with an author and a timestamp, sitting in the same issue thread as everything else. If something looks off, git blame-style scrutiny works exactly like it does for code.
It keeps working as the tools change. We’re not maintaining a Claude-specific client and a separate Codex plugin and a Cursor extension. When a new coding agent shows up next year, if it can run gh, it can already do this.

Your docs are agent-readable too

The same shift is happening on the customer side. People increasingly ask a question with an agent open rather than a search bar. If you’re running a Scitor-hosted knowledge base, it already publishes /llms.txt and /llms-full.txt — machine-readable copies of your docs, so a customer’s agent can answer from what you’ve actually written instead of guessing. You can see it live at support.scitor.io/llms.txt. No extra work required on your end.

When you want the agent working without you

Everything above assumes a person is driving — you’re asking Claude Code to look something up or draft something, and you’re the one who hits send. If you want agents doing this continuously, on their own, without someone opening a chat window every morning, that’s a different setup: agentic workflows running inside GitHub Actions on a schedule — triaging new tickets, drafting replies, flagging frustrated customers — with the same full audit trail. Worth a look once the manual version above feels routine.

Get started. Install the skill with npx skills add scitorapp/agent-skills, or read the full guide for agents. If you haven’t set up Scitor yet, it’s on the GitHub Marketplace and takes about five minutes.

Running Your Support Queue from Claude Code