IT / Product

Write a 2-3 sentence headline for a release, led by the single most important change.

Translate a raw changelog into grouped, benefit-focused release notes.

Generate a PRD outline with problem statement, success metrics, and open questions flagged.

Write Given-When-Then user stories including at least one edge case.

Group survey/interview feedback into ranked themes with representative quotes.

Build distinct, research-grounded personas rather than variations of the same person.

Communicate a roadmap change and address anticipated pushback directly.

Categorize features into Must/Should/Could/Won’t have with a rationale per item.

Identify defensible product gaps against a named competitor, ranked by user impact.

Classify and prioritize incoming tickets, flagging duplicates and under-specified ones.

Ask only the questions that would actually help diagnosis, plus one thing to try meanwhile.

Order fixes from simplest to most involved, written for the user’s stated technical level.

Rank likely causes of a recurring technical error and give a confirm step for each.

Communicate an ongoing outage, committing to a next-update time instead of a guessed ETA.

Confirm resolution clearly and only mention prevention if something concrete is planned.

Generalize a resolved ticket into a self-service KB article with an escalation path.

Flag specific outdated statements and gaps in an existing KB article, with fixes.

Build an IT setup checklist ordered by timing, with approvals flagged separately.

Turn an informal, rambling explanation into a structured, precise internal doc.

Draft a compliance-framework-aligned policy template, flagging where current practice likely falls short.

Document an endpoint fully, with a realistic example request/response, not placeholders.

Turn informal technical notes into a numbered guide with prerequisites and checkpoints.

Prioritize what a new engineer needs day 1 vs. what they’ll pick up naturally.

Explain system architecture component-by-component, including the why behind decisions.

Write a blameless postmortem with a real timestamped timeline and separated fix/prevention.

Extract action items that trace to specifics in the postmortem, prioritized against team capacity.

Recommend architecture changes justified by a specific scale target, with trade-offs stated.