Channel Defaults and Instructions

Set defaults with workspace, personal, and agent instructions

Channel Defaults and Instructions

Nobody wants to name the same project in every request. Quickly handles that with standing instructions rather than a mapping table: you write down how your team works once, and it applies to every request from then on.

The Three Layers

Instructions are applied in order, from broadest to most specific.

Workspace instructions apply to everyone. An Admin sets them in Settings > General. This is where conventions belong: which tracker you use, which project is the default, naming rules, the tone of generated documents, anything that would otherwise be repeated by every person in every request.

Personal instructions apply only to you, and are set in Settings > My Settings. Use them for preferences rather than policy: how terse you want replies, which project you personally work in, your timezone.

Agent instructions apply to a single agent. Each agent carries a purpose that describes its role, and can carry per-tool instructions keyed to a tool pattern, for example telling every linear_* tool to add a security label. Agents are configured in Workforce, opened from the agents rail in Chat.

Writing Useful Workspace Instructions

Be concrete and state the rule rather than the preference:

Our issue tracker is Jira. Unless a project is named, create issues in OPS.
Bugs get the "triage" label until someone accepts them.
Postmortems go in the ENG space and always include impact, timeline,
root cause, and action items.

Instructions are injected into the agent's context on every request, so keep them short and durable. Anything that changes weekly belongs in the request itself, not here.

Overriding a Default

Naming something in the request always wins over the standing instruction:

@Quickly create a bug in MOBILE about the Safari login crash

That creates the issue in MOBILE even when workspace instructions default to OPS. Instructions set the fallback; they do not lock anything.

Per-Channel Behavior

Quickly does not hold a per-Slack-channel configuration table. What differs between channels is the conversation itself: Quickly reads the thread it is replying in, so an incident channel and a sales channel naturally produce different work from the same phrasing.

Where you want genuinely different behavior per surface, use a dedicated agent. Agents have their own purpose, tool instructions, and knowledge, and can be invited into a channel so that mentioning them there routes the work to that configuration.

Checking What Applied

If a request lands somewhere unexpected, open Action Logs and read the tool call. It shows exactly which project, space, or record was used, which is the fastest way to tell whether an instruction was too vague or simply overridden by the request.

Related