Coding Agents
Scitor has no proprietary API to learn, no SDK to install, and no CLI to download. Tickets are GitHub Issues or Discussions, actions are comments, and configuration is a file in your repository.
That means any agent that can run gh can already run your support desk. This guide covers the conventions it needs to know.
Tip
Rather than paste this page into your agent, install the skill — it loads these conventions automatically:
npx skills add scitorapp/agent-skills
The mental model
| You want to… | The agent does… |
|---|---|
| Read the ticket queue | gh issue list (or a GraphQL query for Discussions) |
| Read one ticket | gh issue view <n> --comments |
| Reply to the customer | Post a comment starting with /send |
| Triage | Post a comment with /priority, /assign, /sla |
| Change configuration | Edit .github/scitor.yaml and commit |
Everything an agent does is an ordinary GitHub action, so it inherits GitHub’s audit trail: every reply your agent sends is a comment with an author and a timestamp, visible to your whole team.
Prerequisites
- The GitHub CLI installed and authenticated (
gh auth login) - Write access to the support repository — see Team Management
- A private support repository (see the warning below)
Use a private repository
Scitor runs any slash command posted to your support repository. On a public repository, that means anyone with a GitHub account can post a comment containing /send and cause a reply to be emailed to your customer.
Keep your support repository private. This is the recommended setup for every Scitor installation, and it is what limits command access to the collaborators you have deliberately invited.
Reading tickets
Issue-based repositories
# The open queue, newest first
gh issue list --repo acme/support --state open --limit 20
# Only tickets Scitor flagged as urgent and negative
gh issue list --repo acme/support --label "priority:urgent" --label "sentiment:negative"
# One ticket, with the full conversation
gh issue view 482 --repo acme/support --comments
Listing vs searching
gh search issues does work on a private repository when you are authenticated as a user with access to it. But search runs against an index, so a ticket that arrived moments ago may not be findable yet.
Use gh issue list for “what is in the queue right now” — it reads the repository directly and is always current. Use gh search issues for “have we seen this before”.
Discussion-based repositories
If your integration_type is discussion, tickets are GitHub Discussions, which the gh issue commands do not cover. Use GraphQL:
gh api graphql -f query='
query($owner: String!, $repo: String!) {
repository(owner: $owner, name: $repo) {
discussions(first: 20, orderBy: {field: UPDATED_AT, direction: DESC}) {
nodes { number title url createdAt labels(first: 10) { nodes { name } } }
}
}
}' -F owner=acme -F repo=support
Not sure which mode you are in? Check the integration key in your .github/scitor.yaml.
Replying to customers
A reply is a comment whose body starts with /send. The text below the command becomes the email:
gh issue comment 482 --repo acme/support --body '/send
Hi Dana,
Thanks for flagging this. The export now includes the archived records —
please try again and let us know if anything still looks off.
Best,
Acme Support'
Use /sendall instead to reply to everyone on the original thread, not just the sender. See Slash Commands for the full reference.
Keep a human in the loop at first
A good starting pattern is to have the agent post its proposed reply as an ordinary comment (no /send), let a person read it, and send it themselves. Move to agent-sent replies once you trust the output on your own tickets.
Letting agents act automatically
Comments posted by bot accounts — github-actions[bot], your own GitHub App, a CI agent — are honoured, as long as the comment contains a slash command. A bot comment with no command is ignored.
This is what makes GitHub Agentic Workflows work, and the same rule applies to any automation you build. Two consequences worth knowing:
- Scitor’s own bot (
scitor-customerops[bot]) is always ignored, so an automated reply can never trigger another one. - Inbound customer emails are posted by that same bot, so a customer cannot inject a command by typing
/sendinto an email.
Giving agents your documentation
Every Scitor-hosted knowledge base publishes machine-readable copies of itself, so an agent can answer from your documentation instead of guessing:
| File | What it is |
|---|---|
/llms.txt |
An index of every page, following the llmstxt.org convention |
/llms-full.txt |
Every page’s content concatenated into one file |
/<page>.md |
The raw markdown behind any page — add .md to its URL |
For Scitor’s own docs, that is:
curl https://support.scitor.io/llms.txt
curl https://support.scitor.io/features/commands.md
Point your agent at your own knowledge base the same way — swap in your docs domain.
Info
These files are generated on each docs build and require a custom domain to be configured, since the index needs absolute URLs. If your knowledge base predates this feature, run /docs build in your repository to regenerate it.
Working with configuration
.github/scitor.yaml is the whole configuration surface, so an agent can change routing, SLAs, or the knowledge base by editing one file and opening a pull request:
gh pr create --repo acme/support \
--title "Route billing tickets to the finance team" \
--body "Adds a routing rule for billing-category tickets."
The scitor.yaml reference documents every key, and Examples has complete working configurations worth giving an agent as a starting point.
Which agents work
Anything that can run shell commands and read SKILL.md files: Claude Code, Codex, Cursor, Copilot, Devin, Gemini, OpenCode, and others. Nothing in this guide is agent-specific — it is gh and Markdown all the way down.
Related
- Slash Commands — the complete command reference
- GitHub Agentic Workflows — AI automation that runs inside GitHub Actions
- Team Management — who gets access to your support repository
Was this article helpful?