What a desk is

A desk turns a channel into a drop-box for the whole company — the canonical example is bug triage: anyone types a plain sentence, a session picks it up under the channel’s standing instruction and files a GitHub issue.

1. Admin, in the channel: /sparkyard share, with nothing after it. A form opens with three fields — name the desk, pick what job it does, and add anything else it should know. The job you pick is its type, and choosing one shows you the words that desk will be given about itself, which ship with Sparkyard and which you never have to write.

   Or do the whole thing in one line, if you already know what you want:

   /sparkyard share bugs as bug File everything in acme/api with repro steps and severity, and reply with the link.

2. Admin, same channel — give the desk Claude, either way:

   • API key (recommended): /sparkyard secret ANTHROPIC_API_KEY with an organisation key from console.anthropic.com — metered, built for many users. Skippable if the workspace already has an org-wide key (/sparkyard org-key); desks fall back to it automatically.
   • Subscription account: /sparkyard connect claude in the channel signs a Claude account into the desk — the full sign-in ceremony, sealed desk-level, taking precedence over any org key.
   • Another vendor: /sparkyard connect chatgpt or gemini seals that vendor’s API key to the desk; /sparkyard connect copilot uses the desk’s GitHub identity. /sparkyard connect with no argument lists all four and says which the desk has.

Terms warning on the subscription route

A personal Claude subscription is licensed for one person, and a desk serves many — signing a personal account into a desk is account sharing under Anthropic’s terms. Use that route only with an account approved for shared or automation use; for everything else, the API-key route is the commercial, many-users path Anthropic’s terms are built for.

The desk’s GitHub identity needs no setup — it uses the deployment’s App automatically, and its installation is discovered per tenant from GitHub itself. Only when the App is installed in several orgs does the admin disambiguate with /sparkyard secret GITHUB_INSTALLATION_ID.

In a bound channel: every top-level message starts a task (no mention needed), anyone in the workspace may post — no per-person approval, because a desk carries only its own credentials — and replies from anyone continue the thread. New desks mint GitHub tokens scoped to issues only: they can file and comment on issues and cannot read or push code, enforced by GitHub itself.

How people talk to it

They type a sentence. That is the whole interface — there is nothing to learn, no mention, no command, no form. Somebody who has never opened the repository can report a bug:

Ana the export button on the reports page does nothing for me since this morning

The desk picks that up as a task and answers in a thread under her message:

Sparkyard Before I file this — which report were you on, and does the button do nothing at all or show an error? Roughly what time it started would help too, so I can line it up against this morning’s deploys.

Anyone can reply in that thread, not only the person who started it:

Ana the weekly summary one. nothing happens at all, no error. around 9?

Sparkyard Filed as acme/api#812 — “Export silently no-ops on the weekly summary report”. Severity: medium — one report type, no data loss, and the CSV download still works as a way round it. Repro steps and the 09:00 window are in the issue, with the two deploys that landed inside it.

Three things in that exchange are the desk’s job description showing through, and each comes from a different place. Asking for the missing details in one message rather than a question at a time, and not making Ana read a stack trace, come from the bug type. Filing in acme/api with severity, and replying with the link, come from the standing instruction the admin typed. What actually happened — an export button, this morning — is Ana’s sentence.

Note

An illustration, not a transcript: what the desk says is generated, so the wording will differ. What is exact is the shape — a sentence in, a thread under it, replies from anyone continuing it.

Who the desk thinks it is

Two things decide that, and they are set together when you bind the channel — in the form, or in one line:

/sparkyard share                                        the form
/sparkyard share <desk> [as <type>] [standing instruction…]     the same thing, typed

• The type is the job — bug, ci, support, review, oncall, or general for a desk that is only ever what you say it is. Each one selects a persona that ships with Sparkyard: a few paragraphs telling the desk who it is and what it cares about. You do not write those words or keep them anywhere; naming the type is the whole of it. They are printed in full, so you can read what you are choosing, under Desk types.
• The instruction is the part you write: whatever else this particular desk needs to know — which repository, who to escalate to, what never to touch. It goes in underneath the persona.

Together they are the desk’s standing context, and it opens every turn the desk runs — a message somebody typed, a scheduled task, and a red build at two in the morning. That last one matters: the desk that answers while everyone is asleep is the same desk you described.

To change either of them later, run /sparkyard share again. In an already-bound channel it says what the channel is bound to now and offers an Edit button, which reopens the form with the type and the instruction already filled in — so changing the type does not mean retyping your paragraph from memory. /sparkyard unshare undoes the binding entirely.

as always means a type — in the typed version

This one is about the one-line command only; the form has no grammar to trip over, which is most of why it exists.

Because a typo like as devops would otherwise bind a desk with no persona at all — and you would not find out until you read a disappointing answer at 02:00 — the word as immediately after the desk name is always read as “a type follows”. If your standing instruction genuinely begins with the word “as”, put a type in front of it: /sparkyard share bugs as general As soon as a report arrives, …

A desk that answers on its own

A desk does not have to wait to be spoken to. Give it a webhook and it answers a failed CI build by itself — reading the failing job, saying what broke, and (if you turn that on) opening a pull request with the fix. See CI desk.