Finding things
Questions and the answer base
Get cited answers from your project's code and knowledge, search what was asked before, and curate the guidance future answers should use.
“how does our rate limiting work?”
A grounded answer with the project sources it used.
“what's our process for rotating the signing key?”
The relevant runbook or decision, cited.
“why do we have two auth paths?”
The recorded reasoning when it exists, or an honest gap.
You ask the project question. The assistant takes responsibility for joining the relevant evidence and exposing the source trail; ContextStream keeps the different evidence types available and scoped. You do not have to tell it which index to query first.
What comes back
An answer with its sources — the decisions, documents, code, and sessions it drew from. You can check the working.
The distinction from a general chat answer is that this one is grounded in your workspace. It doesn't know how rate limiting usually works; it knows how yours does, or says it can't find out.
When to reach for it
Onboarding. A new person can ask "how does deployment work here" and get your answer, not a generic one.
The thirty-second rule. If you've been hunting for something for half a minute, ask. It's faster.
Before asking a colleague. Often the answer is already recorded, and a citation beats an interruption.
The most useful part is the citations
An uncited answer you can't verify is a guess with confidence. The sources tell you whether it's reading a decision from last month or inferring from code comments — and whether it's worth trusting for what you're about to do.
Ask the assistant to explain an answer when the source trail or confidence is not clear. The explanation should identify which claims came from which records and where the available evidence stopped.
A question that joins the evidence
A new engineer asks:
why does webhook delivery retry with backoff, and what should I check before
changing it?A strong answer can join several sources without flattening them:
- the current decision explains why capped exponential backoff with jitter won over immediate or fixed-delay retries;
- the sender and its tests show the behavior that actually ships;
- a lesson warns that the provider mock once omitted the
429path; - the runbook gives the safe verification and rollback procedure.
The answer should cite each source next to the claim it supports. If the code now retries five times but the decision still says three, that disagreement is a finding—not something to smooth over. Verify current source, then update or supersede the stale knowledge record.
If no decision exists, the honest answer is “the code does this, but I could not find recorded reasoning.” Once a person confirms the reason, save it as a decision. If the same question appears every onboarding cycle, turn the confirmed answer into a focused FAQ or point the answer base at the full runbook.
Search what was asked before
Questions are retained with their workspace, optional project, session, tags, and asker when known. Before repeating a project-shaped question, your assistant can search prior questions and answers.
That history is useful in two ways:
- a repeated question can reuse a cited answer instead of starting over;
- a cluster of repeated questions shows where the project needs a runbook, glossary entry, or better onboarding material.
Question history is not a substitute for current source. If the prior answer depended on code or a document that changed, follow its citations and verify the present state.
Build the answer base
You can deliberately save five kinds of compact project knowledge:
| Kind | Use it for |
|---|---|
| Guidance | The preferred way to handle a recurring project situation |
| Guardrail | A boundary the assistant should not cross |
| Frequently asked question | A reusable answer to a question people keep asking |
| Runbook answer | A compact operational answer used by project Q&A |
| Caveat | An exception, edge case, or warning that changes an otherwise-correct answer |
These items can be listed, read, updated, or deleted as the project changes. They complement documents and runbooks: the answer base holds compact material intended for question answering, while a document is a versioned page someone may read from beginning to end.
When the operating procedure needs prerequisites, ordered steps, verification, and rollback guidance, write a full runbook and let the answer base point to it rather than compressing away the safety detail.
Improve future answers
Rate an answer as useful, neutral, or unhelpful. Feedback helps later retrieval weight what actually answered the question.
Do not use a positive rating to bless an uncited claim. Correct or retire the underlying answer-base item, decision, or document when the problem is stale source material.
When it says it doesn't know
Take it seriously. It means the answer isn't recorded anywhere — which is itself useful information, and usually the moment to write it down once you've found out.
If it doesn't work
The answer is thin. Nothing recorded on the subject. Ask a person, then record what you learn.
It cited something out of date. Documents don't expire on their own. Update or delete the stale one, then rate the old answer accordingly.
It answered generically. The workspace has little in it yet, the managed instructions are stale, or you're scoped to the wrong project. Ask "what project am I in?" and check Instruction files.
The same question keeps coming back. Save a focused FAQ, piece of guidance, guardrail, caveat, or full document instead of relying on one old transcript.
An answer has sources but I still don't trust it. Ask for an explanation of the source trail, then inspect the cited decision, document, or code.