Daniel Okafor

Help me understand this data. I am not a statistician.

What this data is and where it came from: {{context}}
The question I am trying to answer: {{question}}
Who I need to explain it to: {{audience:my team}}

Do this:
1. Describe what you are looking at: what each row and column represents, the time period, and the number of records.
2. Check quality first: missing values, obvious errors, duplicates, outliers, and anything that looks inconsistent. Tell me before drawing any conclusions.
3. Give the 3 to 5 most important findings. For each one:
   - State it in a plain sentence, with the actual numbers.
   - Say how confident I should be, and why. Is the difference large or small? Is the sample big enough? Could it be chance?
4. Answer my question directly, or tell me that this data cannot answer it and why.
5. Say what the data does not show. Point out anywhere it would be tempting to assume a cause when there is only a pattern.
6. Suggest the one chart that would show the main finding most clearly, and what goes on each axis.
7. Give me a 3-sentence summary I could say out loud to my audience.

Rules:
- Use only the numbers I gave you. Show your working for any figure you calculate, so I can check it.
- Do not call a difference "significant" unless you can justify it. Small samples and small differences should be described as such.
- Keep percentages honest: say "from 4 to 6 customers", not only "a 50% increase".
- If you need to know something about how the data was collected before you can interpret it, ask.

Data:
{{data}}

Help me debug this. Reason through it; do not jump straight to a fix.

Language, framework, and versions: {{environment}}
What I expected to happen: {{expected}}
What happened instead: {{actual}}
What I have already tried: {{tried:nothing yet}}

Work through it in this order:
1. Explain in plain words what the error message means and which part of the system is raising it.
2. Point to the line or call where the problem most likely starts. This is often not the line the error names; say why.
3. List the two to four most likely causes, most likely first. For each, say what in my code or error output points to it.
4. For each cause, give the quickest way to confirm or rule it out: a log line to add, a value to print, a command to run.
5. Give the fix for the most likely cause, as code, and explain why it works.

Rules:
- Base this on the code and error I gave you. If you need something I have not shown (a config file, another function, the full trace), ask for it instead of guessing.
- Do not suggest things I said I already tried.
- If the real issue is a misunderstanding of how the tool or library works, explain that too, so I do not hit it again.

Error output:
{{error}}

Relevant code:
{{code}}

Explain the document below in plain language. I am not a lawyer.

What kind of document it is: {{document_type:a contract}}
My position: {{my_role:the person being asked to sign it}}
What I most want to understand: {{main_question:what I am agreeing to}}

Give me:
1. What this document is and what it does, in two or three sentences.
2. What I must do: every obligation, each with its deadline and how often it recurs.
3. What the other side must do.
4. Money: every amount, fee, penalty, deposit, and price increase, and what triggers each one.
5. Dates that matter: start, end, renewal, notice periods, and deadlines for canceling.
6. How I can get out of it, and what that costs me.
7. Clauses to look at closely: anything one-sided, unusual, easy to miss, or that gives up a right. Examples: automatic renewal, liability limits, arbitration clauses, the other side's right to change the terms. Quote each clause and say why it matters.
8. Questions I should ask before signing.

Rules:
- Quote the clause or section number for every point, so I can find it.
- If the wording is vague or could be read two ways, say so and give both readings.
- If something I would expect to find is missing, say what.
- Explain what the text says; do not tell me whether to sign. This is general information, not legal advice, and the law differs from place to place. For anything with real money or rights at stake, tell me which specific points to take to a qualified professional.

Document:
{{document}}

Create an outline for a blog post.

Topic or target search phrase: {{topic}}
Who is searching for this: {{reader}}
What I know or offer that others do not: {{my_angle}}
Target length: {{length:1,200 to 1,500 words}}

Step 1. Work out the intent behind the search. What is this person trying to get done, what do they already know, and what would make them stop searching? Write that as two or three sentences.

Step 2. List the 6 to 8 questions that reader needs answered, in the order they would ask them.

Step 3. Build the outline:
- Three title options under 60 characters. They should be clear and specific, not clickbait.
- A meta description under 155 characters.
- An introduction plan that gets to the answer quickly. The main point should appear within the first 100 words.
- Section headings (H2), with sub-headings (H3) where needed. Phrase them the way the reader would phrase the question.
- Under each heading: the points to cover, the example or evidence needed, and a rough word count.
- Where a table, checklist, screenshot, or step-by-step list would help more than paragraphs.
- A closing section that tells the reader what to do next.

Step 4. Tell me what would make this post better than what is probably already ranking: where my angle, my experience, or original data should go.

Rules:
- Do not pad it. If a section does not help the reader with their task, cut it.
- Do not invent statistics, studies, or expert quotes. Mark where I need to supply a real source with [SOURCE NEEDED].
- I cannot rely on you for search volumes or current rankings, so do not state any. Tell me what to check in a keyword tool instead.

Write a commit message and a pull request description for the change below.

Why I made this change: {{reason}}
Anything reviewers should know (trade-offs, follow-ups, things I am unsure about): {{notes:nothing extra}}

Commit message:
- Subject line: imperative mood ("Add", "Fix", "Remove"), under 72 characters, no full stop.
- Blank line.
- Body: why the change was needed and what it does at a high level. Do not walk through the diff line by line.

Pull request description:
- Summary: what changes for a user or for the system, in two or three sentences.
- Why: the problem or need behind it.
- What changed: a short list by area, not by file.
- How to test: the steps a reviewer can follow to see it working.
- Risks: anything that could break, any migration or config change, and whether it can be rolled back.
- Review focus: the one or two places where a careful second look matters most.

Rules:
- Describe only what the diff actually does. If the diff does something my stated reason does not explain, point it out.
- Do not claim tests were added or run unless the diff shows them.
- Plain language. No "various improvements" or "minor fixes".

Diff:
{{diff}}

Help me tailor my resume to a specific job. Use only experience I actually have.

Step 1. Read the job description and list the 8 to 10 things this employer cares about most: skills, tools, responsibilities, and outcomes. Rank them by how much weight the posting gives them.

Step 2. For each one, mark my resume as:
- Strong match: quote the line that shows it.
- Partial match: say what is there and what is missing.
- No match.

Step 3. Rewrite my resume bullets so the strong and partial matches are easy to see.
- Start each bullet with what I did, then the result. Keep any numbers I gave.
- Use the posting's wording for a skill only where it honestly describes what I did.
- Put the most relevant bullets first within each role.
- Cut or shorten bullets that do nothing for this job.

Step 4. Write a 2 to 3 line summary for the top of the resume, aimed at this role.

Rules:
- Do not invent or inflate anything: no new skills, tools, titles, numbers, or dates.
- Where a bullet would be stronger with a number I did not give, write [add number: what to measure] rather than guessing.
- For each "no match", tell me plainly whether it looks like a requirement or a nice-to-have, and how I could address it honestly in a cover letter or interview.

Job description:
{{job_description}}

My resume:
{{resume}}

Explain the code below so I could confidently change it.

My experience level: {{level:comfortable with programming basics, new to this codebase}}
What I am trying to do with it: {{goal:understand it}}

Structure your answer like this:
1. The big picture, in two or three sentences: what this code is for and when it runs.
2. Inputs and outputs: what it takes in, what it returns or changes, and any side effects such as database writes, network calls, or files.
3. A walkthrough in the order the code runs. Group lines into steps and explain each step, not each line.
4. Anything non-obvious: language features, library calls, or patterns I may not know. Explain each in a sentence or two.
5. Why it is probably written this way, where that is not obvious.
6. Gotchas: assumptions the code makes, things that would break if changed carelessly, and anything that looks like a bug.

Rules:
- Use plain words. When you have to use a technical term, define it the first time.
- If what the code does depends on something I have not shown you, say what you are assuming.
- Do not rewrite the code unless I ask.

Code:
{{code}}