Using Q from Slack

The simplest way to use Q is to mention it in Slack. Ask the question in the thread where the work is happening, include the links or context Q should use, and say what kind of output you want.

That is the human version.

The system version is slightly more interesting: the Q you meet in ordinary team channels is the observer sandbox. It is allowed to do real work, but it is not allowed to become the control plane for its own runtime. You should not need that sentence for every request, but it explains why some things work immediately and others get turned into a draft or routed to an operator.

Start with the thread

Slack is noisy. Q should not make it noisier.

When you ask Q for something, the best shape is:

1. mention Q
2. keep the request in the relevant thread
3. say the outcome you want
4. include links, repo names, docs, screenshots, or prior decisions
5. say whether Q should act, draft, or only recommend

That request gives Q a surface, a scope, and a stopping point. It is much better than “capture this” or “fix this.”

What Q can do from team channels

In the observer sandbox, Q can do useful work directly:

• summarize a thread or pull out decisions and open questions
• search shared knowledge in doc-vault and Cairns
• inspect trusted repos available to the sandbox
• use git and GitHub CLI authentication for normal repo work
• draft issues, PR descriptions, plans, docs, and status updates
• run sandbox-local checks, builds, and searches
• work on Cairns articles end to end when the request is clear and low-risk
• use Notion and Google Workspace within the boundaries described below

The important phrase is from the sandbox. Q can operate on the working surfaces it has been given. It cannot use an ordinary team channel to change the gateway, rewrite channel routing, manage crons, restart host services, or alter the rules under which Q runs.

What Q will usually draft instead

Some work is safe to discuss but risky to perform immediately. In those cases, the best answer is usually a draft.

Ask for a draft when the work involves:

• sending or replying to email
• posting as Q outside the current thread
• creating or updating shared docs with sensitive material
• widening Drive or Notion access
• filing public-facing GitHub issues from incomplete context
• summarizing material that may not belong in the current channel

Drafts are not a weaker result. They are often the right collaboration surface: everyone can see the intended action before the action happens.

How Q uses shared tools

Q has real integrations, but each integration has its own trust model.

GitHub work happens through Q’s own authenticated CLI context inside the sandbox. That lets Q inspect repos, prepare changes, draft issues, and work through pull-request-shaped tasks without borrowing a human’s browser session.

Notion work happens through Q’s Notion integration. Q can read pages and data sources shared with the integration and create new pages in approved locations such as Q’s Home. Existing-page or database updates should be drafted for review or handled through an explicitly approved operator path. Notion is a collaboration surface, not an excuse to paste confidential material into a broad Slack channel.

Google Workspace work happens through Q’s Redshifted account. Q can receive mail, have calendar events, and work with docs and Drive files it has access to. The observer path is policy-gated: outbound mail, mailbox mutation, broad Drive upload/share/file mutation, Docs write, and Calendar event mutation are blocked from ordinary observer use until the broker model is ready.

What Q remembers

Q should feel like one teammate, but it does not keep one undifferentiated shared brain. The current design keeps memory shaped to where the work happened and uses shared documents for facts that should survive across contexts.

The practical version:

• if it belongs to a project or policy, put it in a shared doc
• if it belongs in canonical operational truth, put it in doc-vault
• if it belongs in explanatory team knowledge, make or update a Cairns article
• if it is private or operator-only, do not expect it to leak into a public channel

That is a feature, not a bug. Q can be one teammate without every conversation inheriting every private memory.

How to ask better

Here are requests Q can usually handle well:

• “@Q summarize this thread and list decisions, risks, and next actions.”
• “@Q inspect the repo and tell me where this behavior lives.”
• “@Q draft a Notion page in Q’s Home from these notes.”
• “@Q turn this into a GitHub issue, but do not file it yet.”
• “@Q check whether this Cairns article is stale against the source docs.”
• “@Q make a short Slack update I can post to the team.”

Here are requests that need more care:

• “Send this email.”
• “Share this doc with everyone.”
• “Read whatever Q can see and summarize it here.”
• “Change Q’s config.”
• “Restart Q.”

The pattern is simple: the more a request affects other people, access, availability, or private context, the more likely Q should draft or route rather than act immediately.

What to do when Q says no

Q should not dead-end you. If a request is outside the observer sandbox’s authority, Q should explain the boundary and give you a path forward: draft the work, move it to the right private/operator surface, or ask an authorized operator to relay it.

That is not Q being precious. It is the same thing a good teammate does when you ask them to make a decision in a room where the right people are not present.

1. Mention Q in the thread where the work lives. Give context, desired output, and whether Q should act or draft.
2. The observer sandbox can do real work. Repo inspection, drafting, research, builds, GitHub, Cairns, Notion, and read-oriented GWS workflows are all useful from Slack.
3. Tool access is not blanket authority. Sends, shares, permission changes, host operations, and sensitive reads need stricter handling.
4. Drafts are the collaboration default for risky actions. A draft lets the team review intent before Q changes the world.

• Which recurring Slack requests should become examples in this guide?
• Where do we want Q to create default long-form drafts: Notion, doc-vault, or Cairns?
• Which Google Workspace actions should eventually move from "draft only" into broker-approved direct action?

1. What Q Can Help With — The capability map that follows this usage guide.
2. The Only Locked Door — The architecture behind the observer sandbox boundary.
3. Three Memories, One Q — The memory model behind Q's continuity rules.