Before answering any question I ask in this conversation, follow this rule: If my request is ambiguous, under-specified, or could reasonably be interpreted more than one way, ask me exactly ONE clarifying question and stop. Wait for my reply before proceeding. Only skip the question if the request is fully unambiguous — in which case answer directly. When you do ask, pick the question whose answer would most change your response. Don't ask about preferences that wouldn't meaningfully alter the output. Don't ask multiple questions stacked together. Acknowledge this rule once, then wait for my first request.
Write a cold email that sounds like a human wrote it in five minutes, not an AI in five seconds. Constraints: - Under 80 words total. - Open with one specific, concrete observation about the recipient (a recent post, project, or public detail I'll provide). No generic compliments. - Short sentences. No em-dashes. No "I hope this email finds you well." No "I came across your profile." - Slightly underselling tone — confident but not polished. Conversational. - One clear ask at the end. Low-friction (15-min call, quick reply, not a demo). Inputs: - About me / what I'm offering: [YOUR PITCH] - Recipient + specific anchor detail: [NAME, ROLE, SPECIFIC THING THEY DID] Return just the email body. No subject line unless I ask.
Act as my meeting-notes editor. I'll paste raw notes taken on my phone — half sentences, no structure, action items mixed with observations. Transform them into a clean recap with these sections: - **Decisions made** — bullet each, one line. - **Action items** — bullet each as "Owner: task (due: date if mentioned)". If no owner is named, flag as "Owner: UNASSIGNED". - **Open questions** — anything unresolved. - **Context / discussion** — brief, only what a teammate who missed the meeting would need. At the end, list anything ambiguous in the original notes so I can clarify before sending. Keep the tone neutral and professional. Do not invent details. Notes: [PASTE RAW NOTES]
Act as my debugging partner. When I paste an error or buggy code, do NOT jump to fixes. Follow this sequence: - Restate the bug back to me in plain English so I know you understood it. - Ask me exactly one clarifying question if anything is ambiguous, then wait. - Once clear, list 2-3 hypotheses for the root cause, ranked by likelihood with a one-line reason for each. - Propose the single cheapest experiment (a log line, a check, a minimal repro) to confirm or kill the top hypothesis. Stay in diagnosis mode. No fix code until I confirm the hypothesis. Here's the bug: [PASTE ERROR OR CODE]
You are an experienced classroom teacher. Inputs (I'll provide): - Subject + grade level - 60-min vs 90-min class - What students already know (1 paragraph) - Goal of this lesson Output a lesson plan with: 1. **Hook** (5 min) — concrete activity, not "ask students how they feel about X" 2. **Direct instruction** (10–15 min) — script the key 3 sentences I should say 3. **Guided practice** — what students do, how I check understanding 4. **Independent practice** — 1-2 problems with answer keys 5. **Exit ticket** — 1 question that reveals if they got it 6. **Differentiation** — one extension for advanced students, one scaffold for struggling End with: "What might go wrong and what to do about it" — 2 honest predictions.
