Examples

Prompts you can reuse

Treat these as templates. Replace the bracketed parts with your own context; keep the structure that makes assumptions and verification visible.

Learn a topic

Goal: understand [topic] well enough to [purpose].
Context: I already know [background].
Task: teach it in layers: big picture → key terms → worked example → common mistakes.
Constraints: define jargon before using it. Do not assume specialist knowledge beyond what I stated.
Verification: identify claims that depend on current information and give sources for those claims.

Make a decision

I need to choose between [options] for [goal].
Important criteria: [criteria].
Constraints: [budget/time/risk/compatibility].
First tell me what material information is missing. Then compare the options using the same criteria for each.
Separate factual differences from your judgement. End with the conditions under which each option would be the better choice.

Challenge my thinking

Here is my current view: [view].
Do not simply agree with me.
1. State the strongest version of my argument.
2. State the strongest opposing argument.
3. Identify assumptions in both.
4. Identify evidence that would discriminate between them.
5. Give your provisional conclusion and confidence, including what could change it.

Work from supplied material

Use the supplied files as the primary source for this task.
Goal: [goal].
Authority: [which document/source wins if they conflict].
Task: [analysis/transformation].
Do not invent information that is absent.
For important findings, cite the exact file/page/section or record used.
Separate direct evidence from inference and proposals.

Plan a coding change

Goal: [desired behavior].
Before suggesting implementation, read the authoritative design, relevant configuration and current code.
Authority order: [order].
Diagnose the first point where actual behavior diverges from intended behavior.
Constraints: no hidden fallback; no magic tuning constants; reuse canonical utilities; patch the smallest correct region.
Output: evidence → root cause → fix plan → regression test → real-run verification.
Do not call the work complete solely because code compiles or unit tests pass.

Use connected tools carefully

Use only the tools and roots explicitly available to you.
Before acting, inspect capabilities and choose the least-privileged operation that can do the job.
Never claim to have read a file or performed an action unless the tool actually returned success.
If access is denied or a required capability is absent, report that boundary clearly rather than inventing a workaround.
For writes, use only the designated writable area and verify the result afterward.