zheng
dd8e0f55c3
Improve first-run and channel setup for non-technical users: detect newer Gemini key formats, pin Node 22.22.3, add Control Panel Telegram approve flow, and keep channels/models when config is rewritten. Persist uclaw wizard state via uclaw-meta.json so restarts skip language/persona prompts. Co-authored-by: Cursor <cursoragent@cursor.com>
78 lines
2.6 KiB
Markdown
78 lines
2.6 KiB
Markdown
---
|
|
name: claude-helper
|
|
description: "Getting better results from the model - prompting, context, and knowing when the tool is wrong for the job"
|
|
metadata: { "openclaw": { "emoji": "🤖" } }
|
|
---
|
|
|
|
# Getting Better Results
|
|
|
|
How to ask, what to include, and when to stop asking.
|
|
|
|
## The three things that change output most
|
|
|
|
**1. Say what the output is for.** "Summarise this" and "summarise this for
|
|
someone deciding whether to attend" produce different, both-correct summaries.
|
|
The purpose does more work than any phrasing trick.
|
|
|
|
**2. Give the real material.** A paraphrase of a document produces an answer
|
|
about the paraphrase. Paste the document, attach the file, share the error in
|
|
full — including the parts that look irrelevant.
|
|
|
|
**3. Say what a good answer looks like.** Length, format, who reads it. "Three
|
|
bullets a non-technical manager can act on" beats "be concise".
|
|
|
|
## What does not help
|
|
|
|
- Politeness formulas, threats, or claiming urgency
|
|
- "You are a world-class expert in…" — state the task, not a persona
|
|
- Asking the same thing again in the hope of a different answer. Change what you
|
|
gave it instead.
|
|
|
|
## When to start a new conversation
|
|
|
|
Long conversations drift. Start fresh when:
|
|
- You have changed subject entirely
|
|
- Earlier wrong turns keep resurfacing
|
|
- The context has filled with material that no longer matters
|
|
|
|
Carry forward a short summary rather than the whole history.
|
|
|
|
## When the answer might be wrong
|
|
|
|
Language models produce fluent text regardless of whether they know the answer.
|
|
Confidence is not a signal. Check independently when the answer involves:
|
|
|
|
- **Specific numbers, dates, prices, versions** — especially recent ones
|
|
- **Citations, links, case law, standards** — these get fabricated convincingly
|
|
- **Anything you will act on** without being able to reverse it
|
|
|
|
Ask for the reasoning or the source, and treat a refusal to give one as a warning.
|
|
|
|
## When to use something else
|
|
|
|
- **Arithmetic on real data** — use a spreadsheet or a script, not the model
|
|
- **Anything needing today's facts** — the model needs to be given them
|
|
- **Legal, medical or financial decisions** — a draft to take to a professional,
|
|
not the answer
|
|
|
|
## Example prompts
|
|
|
|
```
|
|
Rewrite my prompt so it gets a more useful answer
|
|
```
|
|
|
|
```
|
|
What information are you missing to answer this properly?
|
|
```
|
|
|
|
```
|
|
Which parts of that answer should I verify before I use it?
|
|
```
|
|
|
|
## Working notes
|
|
|
|
- When the user's request is ambiguous in a way that changes the answer, ask one
|
|
question rather than producing two versions.
|
|
- Say plainly when something is outside what you can check, rather than hedging
|
|
through it.
|