Better Prompts.Bigger Possibilities.

Edit the following text for [audience]. My intended tone is [tone].

Text:
[draft]

Preserve my meaning, facts, and level of certainty. Remove repetition and unnecessary jargon. Do not invent examples, results, or personal details.

Return:
1. A revised version.
2. Three short notes explaining the most important changes.
3. Any ambiguity I should resolve before sending it.

Example: Audience: a project teammate. Tone: direct and friendly. Draft: a status update that needs a clearer next step.

Review the revision for accuracy before sending it.

Help me move this project forward: [project].

Current state: [current state]
Available time: [time available]
Constraints: [constraints]

Separate confirmed information from assumptions. Identify the smallest useful outcome I can complete in the available time. Give me exactly three sequential actions, each with a concrete deliverable and a way to check that it is done. Flag decisions that require my approval. Do not assume access to tools or accounts I have not named.

Example: Project: launch a one-page portfolio. Time available: two hours. Constraint: use existing writing and images.

Use the plan as a starting point, not a promise about how long the work will take.

Develop three genuinely different creative directions for [project or idea].

Audience: [audience]
Desired feeling: [feeling]
Must keep: [requirements]
Must avoid: [exclusions]

For each direction, provide a short name, a one-sentence concept, a visual or verbal treatment, and one concrete example. Explain the tradeoff that distinguishes it from the other two. Avoid invented audience research, testimonials, or success metrics. End with one question that would help me choose.

Example: Project: a neighborhood gardening newsletter. Feeling: welcoming and useful. Avoid: generic corporate language.

Choose a direction before asking for a polished final version.

Review this code for its stated purpose: [intended behavior].

Code:
[code]

Environment: [language and environment]

Prioritize correctness, security boundaries, and edge cases. Separate confirmed defects from risks that need testing. For each issue, identify the relevant code, explain a reproducible failure scenario, and propose the smallest safe fix. Suggest focused tests. Do not rewrite unrelated parts or claim that tests ran unless you actually ran them. Never request production secrets.

Example: Intended behavior: filter a public list of prompts. Environment: browser JavaScript. Check empty queries and unusual characters.

Remove credentials and private data before sharing code with an external tool.

Teach me [topic]. My current knowledge is [starting point], and I want to be able to [learning goal].

Start with the minimum background I need. Explain the central idea in plain language, then work through one concrete example. Point out where an analogy stops being accurate. Give me three practice questions, but wait for my answers before revealing solutions. Identify claims that need a current source and distinguish established facts from simplifications.

Example: Topic: CSS Grid. Starting point: basic HTML and CSS. Goal: build a responsive two-column page.

Answer the practice questions before requesting the next lesson.

Investigate this question: [research question].

Scope: [scope]
Relevant timeframe: [timeframe]
Decision this will inform: [decision]

Use primary sources when available. Cite the sources you actually inspect, with dates where relevant. Separate evidence, inference, and unanswered questions. Explain meaningful disagreements between sources. Never invent a citation. If you cannot browse, say so and provide a research plan rather than implying that you checked current information. Finish with the most decision-relevant finding and its main limitation.

Example: Question: which static hosting option fits this small website? Scope: deployment workflow, commercial-use terms, and portability.

Open important sources yourself before relying on the conclusion.

Organize these meeting notes:
[meeting notes]

Return three sections: confirmed decisions, action items, and unresolved questions. For each action, list the task, owner, and due date only when they appear in the notes; otherwise write 'not assigned' or 'not specified'. Distinguish suggestions from commitments. Preserve disagreements rather than resolving them by assumption. End with a short follow-up message I can review and send.

Example: Notes from a website launch check-in covering content review, image approval, and a still-unconfirmed launch date.

Check names, deadlines, and commitments before circulating the summary.

Create an article outline about [topic] for [reader].

The reader's main question: [question]
What I can contribute from experience or evidence: [material]
Target length: [length]

Give the article a clear promise. Propose a title and a logical sequence of sections, describing the purpose of each. Mark where an example or source is needed. Do not fabricate my experience, statistics, or expert quotes. Remove any section that does not help answer the reader's question.

Example: Topic: making a small personal website. Reader: a beginner. Material: notes from building a first static page.

Add your own observations and verify factual claims before publishing.

Turn this idea into a design brief: [idea].

Audience: [audience]
Reference qualities I like: [references]
Required content or actions: [requirements]
Technical or accessibility constraints: [constraints]

Include purpose, information hierarchy, visual direction, essential components, responsive behavior, and acceptance checks. Keep inspiration distinct from copying protected assets or brands. Identify missing decisions without inventing requirements. End with the smallest prototype that could test the direction.

Example: Idea: a calm, light prompt library. Requirements: browse, read, and copy prompts. Constraint: no login required.

Approve the brief and visual preview before committing to implementation.

Help debug this problem.

Expected behavior: [expected]
Actual behavior: [actual]
Exact error or logs: [error]
Relevant code and environment: [context]
What changed recently: [recent changes]

Start by summarizing the evidence. Rank the likely causes, but do not call one confirmed without a test. Propose the smallest diagnostic step first and explain what each possible result would mean. Avoid destructive commands and unrelated upgrades. Ask for missing evidence only when it changes the next step.

Example: Expected: copy a prompt. Actual: clipboard permission denied. Context: a local preview in a browser.

Share the exact error, but remove tokens, passwords, and sensitive paths.

Create a practice plan for [skill].

Starting ability: [current ability]
Available time per session: [time]
Number of sessions: [sessions]
Outcome I want to demonstrate: [outcome]

Each session should include a focused exercise, a tangible result, and a simple self-check. Include a review step before increasing difficulty. Keep the workload within the time provided. Do not guarantee mastery or invent progress data. Explain how to adjust the next session when an exercise is too easy or too difficult.

Example: Skill: writing clear product descriptions. Time: 20 minutes. Sessions: four. Outcome: three revised descriptions.

Adjust the workload after the first session using your actual experience.

Compare these options: [options].

Decision: [decision]
Non-negotiable requirements: [requirements]
Nice-to-have qualities: [preferences]
Budget or other limits: [limits]

Evaluate the options against the same criteria. Identify disqualifying constraints before scoring preferences. Cite current primary sources for changing facts such as prices, policies, and capabilities; do not invent them. State unknowns explicitly. Recommend the best fit for the supplied criteria, explain the main tradeoff, and say which new evidence would change the recommendation.

Example: Options: two hosting providers already under consideration. Requirements: portable static files and a suitable commercial-use plan.

Verify changing terms directly with the provider before spending money or deploying.