Using it
What to say once it's connected
State the outcome in ordinary language while your assistant chooses the relevant project context and permitted next steps.
There are no commands to learn. You ask in English and your assistant decides what to reach for. The examples below are not a script you must memorize. They show the outcomes and boundaries that give an assistant room to investigate without making it guess what success means.
Start with the outcome
This is enough to begin a substantial task:
Fix the sign-outs after sleep. Preserve the public auth API, follow our current
retry policy, and stop before deployment. Show me the evidence and verification.You do not also need to say “search for the refresh coordinator, read the retry decision, check lessons, find the auth runbook, inspect open tasks.” A properly configured assistant can choose those relevant sources itself. ContextStream supplies the scoped project evidence and continuity; the assistant decides how to use it inside the task and permissions you gave it.
Add detail where judgment matters: the desired outcome, what must not change, how to verify it, and where the assistant must stop. The agent partnership guide explains that division of work.
Looking things up
“where do we handle expired tokens?”
Files and lines, from the index — no repository crawl first.
“what did we decide about retries?”
The decision, when it was made, and what it replaced.
“why is this module structured this way?”
The reasoning if it was captured — silence if it wasn't.
“what were we working on last week?”
Captured exchanges and snapshots, including ones from your other configured assistants.
“have we hit this error before?”
Past sessions and lessons that mention it.
Writing things down
“remember we're using Postgres, not MySQL”
Saved as durable project context.
“we decided to drop the legacy client — record that”
A decision, with the reasoning attached.
“lesson: never edit a shipped migration”
A lesson that resurfaces when it's relevant.
“save a runbook for restoring the database”
A durable project procedure you can reuse yourself or share with authorized collaborators.
“make a plan for the billing migration”
A structured plan with linked tasks, acceptance criteria, and a clear next step.
Picking up where you left off
Start a session with any of these and your assistant orients itself before doing anything:
- "what were we working on?"
- "pick up where we left off"
- "what's still open on the billing work?"
Work through a risky change
You can guide a complete investigation in ordinary language:
- “Before changing token refresh, show me the decisions and lessons about auth retries.”
- “Where is refresh implemented, and what calls it?”
- “What would break if its return type changed?”
- “Show me the auth-refresh sequence diagram and rotation runbook.”
- “Make a plan with verification and rollback, then let me review it before saving.”
- “Record why we chose one shared refresh request.”
- “We are stopping with the clock-skew test failing; save the exact state for tomorrow.”
Each sentence asks a different question. The assistant can join the evidence, but it should not use source lines as a substitute for a decision or a plan as a substitute for a runbook.
Work beyond source code
“find the screenshot that contains the 30-second timeout”
The indexed image and its extracted match.
“where in the architecture recording do they explain the retry queue?”
The relevant timestamped media result, ready to clip.
“save a sequence diagram of sign-in, refresh, and retry”
An editable diagram kept with the project.
“write the key-rotation runbook with failure branches and rollback”
A maintained procedure, not a generic checklist.
“remind me on August 5 to start the rotation and link the runbook”
A dated prompt with enough lead time and context.
“open a sev2 for the login failures”
An incident with severity, affected services, timeline, and status.
“make our auth-change preflight reusable”
A skill that can match future auth work and be previewed before it runs.
Track and share
“create a capsule for this so I can send it to Sam”
A scoped, revocable link to the current context.
“handoff the remaining auth review to Maya”
A transfer with scope, current state, open questions, next steps, and evidence.
“what tickets are open?”
Your workspace's tickets, filtered.
“file a bug for the timeout we just found”
A ticket, with the context of what you were doing.
“what risks and reviews are still open for the release?”
The active structured records, not a guess from chat history.
What doesn't reach the memory
Vague appeals. "Use best practices" does not identify a particular project rule or boundary; "follow the error-handling convention we agreed" does.
Assuming it re-reads everything. It grounds each turn in what's relevant rather than dumping the whole workspace into the conversation. You normally state the outcome and let it choose. For a high-risk change or an audit, “check the auth decisions first” is a useful explicit requirement, not a routine retrieval command you must repeat.
Expecting the code index to answer why. "Where is X" is the code. "Why is X like this" is the history. Ask them differently and you get better answers to both.
If it doesn't work
It answers from general knowledge instead of the project. The instruction file is missing or stale. See Instruction files.
It says it has no memory of something you discussed. Discussion isn't a decision. Say "remember that…" for the things that matter.
Lookups are slow. The first ones after connecting can be, while indexing finishes.