Clanker CloudA reusable starting point
One source packet. A fair Workspace trial.
Use the same three initial source files to create a client report in each candidate workspace. Check the saved file, then supply the later correction and inspect the revised version. Download the source packet and scorecard below; keep the authored answer reference out of the initial request.
Start with $20 in included credits. See usage and plans.
Keep the sources identical
Download brief.md, milestones.csv, and meeting-notes.md. In Clanker, add them to a Project and paste the prompt into a Session. In another candidate, provide the same files through its supported project or attachment mechanism.
Use the README for the sequence. The correction and answer reference are separate files for a reason: the first tests whether a later change carries through; the second helps you judge the result without revealing the answer in advance.
Check what the packet is designed to reveal
All inputs are fictional. The approved brief and working milestone sheet disagree on the launch date; the notes explain that the later date is only proposed. An accurate report should preserve that distinction.
| Test | What you should observe |
|---|---|
| Status | Two completed milestones, one blocked build, and one planned launch. |
| Evidence | The approved date and proposed date are both represented with sources. |
| Uncertainty | No invented delivery date or initial owner for the missing images. |
| Revision | The later approval and owner appear in a dated update across the saved file. |
| Handoff | The intended reader can open the selected final output. |
Use the correction as a second turn
After reviewing the first saved report, supply correction.md and ask for a new version and a change note. The correction arrives after the original reporting cutoff, so its approval should be labeled as a later update.
Inspect the whole revised deliverable. A corrected summary can still leave an obsolete launch date or missing-owner statement in a table. Keep the first output so the reviewer can see what changed.
Record the result without inventing a benchmark
Use scorecard.csv to record pass, revise, or not observed, with a source or observation. A material factual error needs correction before delivery. Record the actual plan, tools, setup steps, review effort, and observed usage for each candidate.
The supplied expected result is an authored reference. It is not a recorded Clanker, ChatGPT, or Claude run, and it does not establish a speed, accuracy, or cost advantage. Your own checked trial is the evidence for your decision.
Try it with a small example.
Sample files to try
Fictional inputs for this example. Download a file and add it to your Project to follow along.
- readme.md
Trial sequence and how to keep the answer reference out of the initial context.
- brief.md
Initial input: approved scope, reporting period, and launch date.
- milestones.csv
Initial input: four milestones and a conflicting working-plan date.
- meeting-notes.md
Initial input: accepted work, a blocker, and a proposed date change.
- correction.md
Second-turn input: a later approval and a named follow-up owner.
- expected-result.md
Reviewer reference to open after the initial run; authored, not measured output.
- scorecard.csv
Editable observation log for evidence, corrections, access, review effort, and usage.
Copy into a Workspace Session. Opening Workspace does not send it automatically.
An illustrative result.
Fictional sample, written to show the expected structure. Your result depends on your inputs and needs review.
Authored first-pass expectations: two completed milestones; website build blocked on client images; launch planned; approved 23 October and proposed 27 October both visible. Image date and follow-up owner are unknown. After the separately supplied correction: label the update 17 October, reflect the newly approved 27 October launch and Mina’s follow-up ownership, and retain the unresolved image date and build blocker.
Before you use the result.
- The answer reference was not supplied as initial context.
- The initial sources and prompt stayed the same across candidates.
- Material status and date claims can be traced to the packet.
- The corrected saved file was checked throughout.
- Actual review effort, usage, and account capabilities were recorded.
Common questions.
Should I upload the expected result with the source files?
No. Keep expected-result.md for the reviewer after the initial run. Supplying the answer in advance would change what the trial tests. Upload only the three named initial inputs, then use correction.md in a later turn.
Does this pack prove Clanker is better than ChatGPT or Claude?
No. It is a reproducible fictional task and an authored review reference. Run it in the actual products and accounts you are considering, inspect the outputs, and record your observations.
What if my candidate cannot save the requested file?
Record that limitation and the manual handoff it requires. If saved deliverables are a requirement, test the account and tools you intend to use rather than silently substituting a different experience.
Sources: Clanker Workspace: current capabilities and access · Clanker Cloud: current plans and usage · Clanker: how to run a practical pilot
Content reviewed against the Workspace Guide & FAQ. Features and access can depend on your account.