Docs · Working with Cedric
Ask well, once.
You do not need prompt engineering. You need the same clarity you would give a competent new colleague, and there are four things worth including.
- Write to Cedric the way you would brief a capable new hire: what you want, what it is for, and where the truth lives.
- The four things worth stating: the output, the source, the scope, and the audience.
- Vague asks do not fail, they come back generic. That is more expensive than failing, because you have to read it to find out.
- Correct it in the thread rather than rewriting your request. Corrections persist in the shared memory.
- If a task is going to run every week, get it right once by hand, then schedule the version that worked.
The bar is a new colleague, not a search engine
Most people write their first requests to Cedric as though it were a search box: three words, no context. It answers, because it can, and the answer is technically responsive and not very useful. Then they conclude the tool is mediocre.
The same three words given to a new hire on their first Monday would produce exactly the same result, for exactly the same reason. Neither of them knows which report you mean, what you plan to do with it, or that your fiscal year starts in April.
The fix is not a special syntax. It is one extra sentence of context, and the difference it makes is disproportionate.
The four things worth including
You will not need all four every time. Including two of them usually moves an answer from acceptable to right.
- 01
The output: what should exist when it is done
"Summarize the numbers" leaves the form open. "A one-page summary I can paste into the board deck" does not. Say whether you want a file, a message, a table, or a decision.
This is the highest-value one. Most disappointing answers are the right content in the wrong shape.
- 02
The source: where the truth lives
When two systems could answer the question, say which one wins. "Signups from the billing system, not analytics" removes an entire class of wrong answer, especially where the two disagree.
- 03
The scope: how far to go
Bound it in time, volume, or depth. "Last quarter", "the top ten by revenue", "a quick check rather than a deep dive". Without a bound, Cedric picks a reasonable one, and reasonable is not always yours.
- 04
The audience: who reads it
The same analysis for your CFO and for the engineering channel are different documents. Saying who it is for settles the tone, the length, and how much explaining is needed.
Before and after
The same intent, asked two ways. The right column is not longer by much.
| Vague ask | What comes back | Better ask |
|---|---|---|
| summarize the numbers | A generic overview of whatever it judged relevant | One page of last quarter's revenue by plan, from the billing system, for the board deck |
| look into the churn | An essay about churn, some of it about churn in general | Which accounts cancelled in March, why if the reason is recorded, and what they had in common |
| fix the build | A plausible guess at the most likely failure | The checkout PR is failing CI, find the cause and open a fix PR with a regression test |
| write the update | A competent, characterless status post | A short Friday update for the whole company on what shipped this week, from the merged PRs, warm but not breathless |
| check the invoices | A description of the invoices | Reconcile March invoices against the bank, flag anything that does not match, working file attached |
In practice
One sentence of context, a completely different answer.
Lucia Moreau9:14 AM
@Cedric pull last week's signups and chart them, from billing not analytics, for the Monday growth meeting. Weekly comparison, not cumulative.
CedricAPP9:15 AM
1,204 signups last week from billing records, up 18% on the week before. Chart is week-over-week for the last eight weeks so the trend is visible in the meeting. One note: analytics shows 1,318 for the same period, and the gap is almost entirely trials that never completed payment, which is why billing is the better source for this. Chart and underlying data attached.
Correct in the thread, do not start over
When an answer is not right, the instinct is to rewrite the whole request and ask again. Replying with the correction is better, and not only because it is faster. Corrections are how the shared memory learns your conventions.
"Use the fiscal year, ours starts in April." "Always exclude internal test accounts." "When I say the report I mean the growth one." Each of these, said once in a thread, stops being something you have to say. Because the memory is shared across the workspace, your colleague benefits from your correction without knowing you made it.
This is also the honest reason the first week feels different from the fourth. Cedric does not arrive knowing that your company calls it something unusual, or that one dashboard has been wrong since February. It learns that from being told.
Long tasks, and how to phrase them
For anything substantial, say what done looks like and let Cedric work rather than specifying each step. "Reconcile the invoices, flag mismatches, and give me a file I can check" is better than a numbered procedure, because the procedure is the part it is good at deriving.
The exception is when a step genuinely matters: an order of operations, a system that must be checked first, an approval that has to come before something else. State those explicitly and leave the rest open.
If it is going to recur, prove it once. Run the task by hand, correct it until the output is right, and only then ask for it on a schedule. Scheduling a task you have not verified means being wrong reliably, every week, at the same time.
Common mistakes worth avoiding
Asking for the moon in one message. Six unrelated jobs in one request produces six mediocre answers. Send them separately; they can run at the same time.
Assuming context it cannot see. "The usual report" works after the fourth time, not the first. Until then, say which one.
Not saying when the data is unreliable. If you know a dashboard has been broken since February, say so. Cedric can flag suspicious data but it cannot know your history with it.
Treating a hedge as a failure. When it says it is unsure, that is information, and it is more useful than a confident answer that turns out to be wrong in front of your board.
FAQ
No. Plain language in the channel is the whole interface. There is no syntax, no slash commands to memorise, and no prompt formula.
One or two sentences covers almost everything. If it is longer than a short paragraph, it is probably several tasks that would each be better asked separately.
Say that. "I want to understand why churn moved last month, I am not sure what would show that" is a perfectly good request, and it will come back with an approach for you to react to.
Yes. The workspace memory is shared, so conventions and corrections persist for everyone, not just the person who said them. You can browse and edit that memory from the dashboard.
Yes, and replying in the same thread is the best way, because it keeps the context of the first attempt and treats your reply as a refinement rather than a new job.
It says so, and where it can it explains what it would need (a tool connection, a permission, a decision from you) to get there.
Ready when you are
Try it with one real task.
Add Cedric where your team talks and give it something you would otherwise do yourself this afternoon.
$50 in free credits, no card needed.