A one-line prompt beats a recipe you can’t reproduce
Organized by role and task—copy, run, verify.
Each recipe has eight fixed sections: scenario, preparation, inputs, full instruction, run log, output, acceptance checklist, failures & boundaries.Run logs stay "to be tested" until we actually run it; no estimated numbers.
Anything marked Verified was actually run here; its log carries duration, result, and leftovers. The rest are still templates: we do not fill numbers for a run we have not done, and each page says what is blocking it. Claim one on the contribute page.
Seven sections
Status and progress are shown plainly.
- Recipe / Office100 PDFs, one searchable Markdown indexVerified
- Recipe / OfficeAn Excel ledger into a monthly report, with formulas you can recompute and checkVerified, with one caveat
- Recipe / AutomationWatch competitor prices weekly, only speak up when something movesNot run
- Recipe / OfficeTurn a meeting transcript into a properly formatted .docxVerified
- Recipe / MigrationTurn exported group chat into a searchable Markdown archiveNot run
- Recipe / CodeHave DSH review the changes and list the risksNot run
- Recipe / DataAsk for a SQL in plain language, but verify before runningNot run
- Recipe / ReadingCompress a long doc / webpage into a usable summaryNot run
- Recipe / CodeProduce a refactor plan before touching codeNot run
- Recipe / CodeGive a function, get runnable unit testsNot run
- Recipe / TranslationTranslate technical docs between Chinese and English, with a glossaryNot run
- Recipe / TriageTurn errors and stack traces into a triage orderVerified
- Recipe / ProductTurn a pile of user feedback into a backlog that keeps the original wordingNot run
- Recipe / ContentOne long article into multi-platform copy without altering a single factNot run
- Recipe / OfficeBatch-rename images and produce a mapping tableNot run
- Recipe / AutomationA weekly task: built-in schedule cannot do it, use the OS schedulerNot run
- Recipe / ReadingA batch of paper abstracts into a sourced reference tableNot run
- Recipe / OperationsCampaign data into a weekly report with anomalies called out separatelyNot run
- Recipe / ProductA requirements doc into an acceptance checklist you can tick offVerified
- Recipe / ReadingA handout into a revision outline that shows which sections it coversVerified
- Recipe / AutomationWhere scheduling actually lives: an optional Web overlay, not a pluginNot run
- Recipe / MigrationBringing another tool's old conversations into DSH: where the formats differNot run
- Recipe / MigrationWhat migration loses: a per-field account of the metadataNot run
Find a recipe by role
One row per role, with whether it has been run marked on the right. Run ones link to a run log and what the run showed.
Unclaimed: recipes never run, and what is blocking them
Only unrun recipes appear here. Each states its blocker, so claiming one means preparing that condition. Once it is run, the log goes on the recipe page and the status flips from unrun to verified.
| Recipes | Role | Blocked on |
|---|---|---|
| Watch competitor prices weekly, only speak up when something moves | Automation | Needs real competitor pages with a stable, long-term price source. We have no such target, and a synthetic page cannot reproduce the noise that decides this recipe: caching, A/B tests, and regional pricing. |
| Turn exported group chat into a searchable Markdown archive | Migration | Needs a real chat export. Every sample on hand contains real names and contact details and cannot go on a public page, while a synthetic chat cannot reproduce the real mess: line breaks, quotes, image placeholders. |
| Have DSH review the changes and list the risks | Code | Needs a small real changeset containing a real defect. A synthetic repo validates the flow but not whether it finds genuine problems, which is the entire value of this recipe. |
| Ask for a SQL in plain language, but verify before running | Data | Needs a real schema and real data distribution. Without them the generated SQL can be syntactically right and semantically wrong, making any conclusion worthless. |
| Compress a long doc / webpage into a usable summary | Reading | Runnable, but 'is the summary good' has no mechanically checkable criterion. Today only length and structure can be verified, not whether key conclusions were dropped. Criteria come first. |
| Produce a refactor plan before touching code | Code | Same as code-review: needs a real repo with real debt. A refactor plan for synthetic code always reads correctly because that code has no traps. |
| Give a function, get runnable unit tests | Code | Runnable on a real repo, but 'are these tests any good' must be measured by coverage change and whether they catch a known bug, which means wiring coverage tooling and planting a defect. |
| Translate technical docs between Chinese and English, with a glossary | Translation | Needs real domain documents plus a native reviewer who can judge the translation. Without a reviewer only format and glossary consistency are checkable, not correctness. |
| Turn a pile of user feedback into a backlog that keeps the original wording | Product | Needs real multi-source feedback (support chat, comments, tickets). Synthetic feedback reads too uniformly to test whether the merge rule holds when one complaint arrives in ten different phrasings, which is the hard part. |
| One long article into multi-platform copy without altering a single fact | Content | Runnable, but proving no fact was altered needs a real published long-form piece carrying real figures and names. Synthetic text cannot show whether a number gets quietly swapped. |
| Batch-rename images and produce a mapping table | Office | Needs a set of images with real content, including a corrupt one, before 'what you actually saw' can be judged. Synthetic colour blocks turn confidence into guesswork. |
| A weekly task: built-in schedule cannot do it, use the OS scheduler | Automation | Confirmed: the built-in schedule has no calendar rules (the docs state the protocol contains no cron expressions or calendar rules), so weekly work must go through the OS scheduler. What is missing is registering one here and waiting for a real trigger, which takes a week — hence method only. |
| A batch of paper abstracts into a sourced reference table | Reading | Needs real paper abstracts. Synthetic ones miss the two features that matter: how different study types describe themselves, and the genuine absence of sample sizes — exactly the errors this recipe guards against. |
| Campaign data into a weekly report with anomalies called out separately | Operations | Needs real consecutive-week campaign data. Without genuine variance there is no way to see whether the anomaly rule under- or over-reports, which is this recipe's only substance. |
| Where scheduling actually lives: an optional Web overlay, not a plugin | Automation | Runnable, but end-to-end verification needs the Schedule overlay enabled first: create a reminder, wait for it, confirm it returns to the original session. Not loaded here yet. |
| Bringing another tool's old conversations into DSH: where the formats differ | Migration | The DSH side is measured (path escaping, multi-frame zstd, header and event shapes); what is missing is a real sample from the other side. With no Claude Code or Codex session file on hand, the mapping can be reasoned but not measured. |
| What migration loses: a per-field account of the metadata | Migration | Same: the DSH session header is measured (type, version, id, createdAt, cwd, parentSession, origin, delegationDepth, agentPreset, with seq and time per event line). The other side's field list is what is missing for a per-field comparison. |