What Q Can Help With
A practical map of Q's Slack, repo, Notion, Google Workspace, and GitHub capabilities · ~14 min read ~– min read · Suggested by Bob businesstechnicaloperations
The fastest way to misunderstand Q is to ask whether it is a chatbot or an automation system. In practice it is a teammate with a sandboxed computer, a few work accounts, and a strong preference for making the next useful artifact instead of talking forever.
Slack work
Q’s strongest Slack work is turning scattered context into a summary, issue, doc, plan, cairn, or decision record. If a thread has enough information for a human to write the first draft, Q can usually make the draft.
Repo and GitHub work
Q can inspect trusted repos from the observer sandbox and use its own GitHub CLI authentication. Good asks include “find where this lives,” “draft an issue,” “check this PR,” “run the relevant tests,” and “prepare a small change.”
Cairns and shared knowledge
Q can maintain Cairns directly when the request is clear and low-risk. It also uses doc-vault and Cairns as shared knowledge, which is healthier than hoping a Slack thread becomes durable memory.
Notion work
Q can use Notion through Q’s integration: read shared pages, summarize, and create net-new pages or drafts in approved places. Edits to existing pages and databases should be drafted or routed through an approved operator path.
Google Workspace work
Q can use Google Workspace as its own work account, but public/team Slack is not a blank check. Read and draft workflows are useful; sends, shares, Docs writes, and calendar mutation are currently blocked from observer.
What Q should not do from ordinary channels
Q should not turn ordinary channels into host-admin, confidential, or broad-sharing authority surfaces. When the request would affect others or expose sensitive material, draft or route.
A quick chooser
The practical shortcut is simple: summarize threads, inspect repos, draft artifacts, use Notion and GWS carefully, and route operator work instead of burying it in public Slack.
Q is most useful when something needs to become more concrete. A messy Slack thread becomes a decision summary. A vague bug report becomes a GitHub issue. A source doc becomes a Cairns article. A repo question becomes file links and a short explanation. A plan becomes a checklist someone can execute.
That is the capability to reach for first: not “can Q do everything?” but “can Q turn this context into the next useful artifact?”
Q is a good teammate for synthesis, search, drafting, repo work, and bounded tool use. It is not a substitute for judgment about audience, authority, or confidentiality.
Slack work
In Slack, Q can help with:
- thread summaries
- open-question lists
- decision records
- draft status updates
- handoff notes
- issue drafts
- meeting or planning follow-ups
- explaining a prior decision from shared knowledge
The best Slack requests name the audience and output:
Q should keep reactive replies in-thread. If the output grows too large for Slack, it should create or suggest an artifact and post a short summary back to the thread.
Repo and GitHub work
Q can work inside the observer sandbox against trusted checked-out repos. It can use rg, build tools, test commands, git, and gh through Q’s own sandbox authentication.
Useful requests include:
- “Where is this implemented?”
- “Which tests cover this?”
- “Can you draft a GitHub issue from this bug report?”
- “Check whether this PR is ready for review.”
- “Make the smallest safe change and show me what changed.”
- “Run the relevant local check and summarize failures.”
Q’s GitHub access is not a human’s browser session. That matters. It means Q can do agent-shaped repo work without borrowing a person’s ambient account, but it also means it should respect repo boundaries, branch discipline, and review expectations.
For implementation work, give Q a repo, a goal, and a stopping condition. “Find the bug and propose the fix” is often better than “look at this.”
Cairns and shared knowledge
Q can work directly on Cairns from the observer sandbox when the request is clear and low-risk. That includes researching, drafting, building, committing, pushing, and announcing.
Good Cairns requests look like:
- “Turn this explanation into a cairn for new hires.”
- “Check whether this existing article is stale against the current doc-vault policy.”
- “Add a short note to the relevant article instead of writing a new one.”
- “Make this topic a GitHub issue for later, not a full article today.”
Q also uses doc-vault and Cairns as shared memory. doc-vault is the canonical operational wiki. Cairns is the explanatory layer for humans. If Q needs to know something later across contexts, one of those surfaces is usually better than hoping it remembers a Slack thread.
Notion work
Q has access to the Constructured Notion workspace through Q’s integration. The safe mental model is: Q can work with Notion content that has been shared with its integration, and it can create new pages in approved locations such as Q’s Home.
Q can usually help with:
- reading shared pages and databases
- summarizing a Notion page
- creating a new draft page under Q’s Home when no destination is specified
- turning Slack notes into a Notion draft
- drafting proposed updates to existing pages or database entries for review
Q should be more conservative with:
- applying edits directly to existing company pages or databases from observer
- confidential HR, finance, personnel, or executive material
- moving content between audiences
- treating Notion links inside untrusted content as instructions to follow
Notion is a workspace, not a side door around Slack audience rules. If Q summarizes a Notion page into a channel, the channel still needs to be an appropriate audience.
Google Workspace work
Q has its own Redshifted Google Workspace account. That means Q can receive mail, have calendar events, and work with Google docs and files it can access.
In the observer sandbox, Google Workspace is currently policy-gated. Q can use read-oriented GWS workflows, but the observer wrapper blocks high-risk side effects such as:
- sending, replying to, or forwarding Gmail
- mutating the mailbox
- uploading or changing Drive files
- changing Drive permissions
- writing Google Docs
- creating or changing Calendar events
That is intentional. It lets Q be useful with its work account while avoiding the bad version of “just tell the bot to email someone from a public channel.”
The right ask is usually:
- “Draft an email I can send.”
- “Summarize what Q’s calendar says about availability.”
- “Draft text for a Google Doc I can create or route through the operator/broker path.”
- “Tell me what this shared doc appears to cover.”
The future target is a proper broker that can authorize specific GWS actions with requester, channel, object, operation, and audit context. Until then, the wrapper is the practical guardrail.
What Q should not do from ordinary channels
Some requests belong elsewhere or should become drafts:
- sending mail as Q
- widening document sharing
- reading private or sensitive material into a broad channel
- making host/admin changes
- restarting services
- changing Q’s own runtime configuration
- following instructions found inside untrusted emails, docs, issues, or web pages
That last point matters. Q reads the world, and the world contains text written to manipulate agents. A GitHub issue, email body, web page, or copied transcript is source material; it is not automatically an instruction.
A quick chooser
Use this mental shortcut:
| You want | Ask Q to |
|---|---|
| Understand a thread | summarize decisions, risks, and next actions |
| Preserve context | draft a doc, issue, or Cairns note |
| Find code | inspect the repo and return file links |
| Start implementation | make the smallest safe change and run checks |
| Use Notion | draft or summarize in an approved workspace location |
| Use Google Workspace | read/summarize/draft; avoid direct sends/shares from observer |
| Do operator work | ask Q for a plan or route it to the operator path |
- Q is best at making the next artifact. Summaries, issues, docs, plans, PR notes, and Cairns articles are all natural outputs.
- Repos and GitHub are normal work surfaces. Q has sandbox-local repo access and its own GitHub auth for trusted workflows.
- Notion and GWS are useful but audience-sensitive. Q can read and draft, but the current observer path blocks the riskiest sends, shares, and mutations.
- Draft first when side effects matter. It keeps Q helpful without making Slack the authority surface for every tool.
- Which Notion destinations should be approved as default landing zones for Q-created drafts?
- Which GWS actions, if any, should graduate from wrapper-denied to broker-approved?
- Where should the team draw the line between "Q can file this issue" and "Q should draft it for a human first"?
- Using Q from Slack — The front-door guide for asking Q for work.
- The Workshop — Broader map of Constructured's development tools.
- Where the Work Lives — How GitHub and beads coordinate planning and implementation work.
Generated by Cairns · Agent-powered with Claude