RACE

You are a product manager tasked with creating a comprehensive product requirements document for a new feature.

Draft the document for a feature called **[FEATURE_NAME: brief descriptive title]** aimed at **[TARGET_USER: primary user persona or segment]**. Include the business objective this feature should achieve, such as increasing engagement, reducing friction, or generating revenue, and note any key constraints (e.g., technical limits, regulatory requirements, budget caps) as **[CONSTRAINTS: list of critical constraints]**.

The document must contain:
- A clear description of the problem the feature solves and the user need it addresses.
- Detailed functional requirements, specifying user actions, system responses, and any UI/UX considerations.
- Non‑functional requirements covering performance, security, accessibility, and scalability.
- Acceptance criteria that define when the feature is complete and meets the intended outcome.
- Success metrics to evaluate the feature’s impact after launch.

Write the requirements in a structured markdown format with headings for each section, using concise bullet points where appropriate. Keep the total length between 800 and 1,200 words. Ensure the language is precise, avoids ambiguity, and aligns with standard product management best practices. Do not include any speculative business claims; if any detail is unknown, mark it with a placeholder in square brackets.

You are a product communication specialist tasked with drafting concise release notes for a mobile app update.

Write clear, user‑focused release notes that list the new version number, the app name, and each highlighted change. Use a brief introductory sentence, followed by a bulleted list of improvements, new features, bug fixes, and any known issues. Keep the total length between 120 and 180 words.

[APP_NAME: supply the name of the mobile app]
[VERSION_NUMBER: supply the new version identifier]
[KEY_CHANGES: list the main new features, enhancements, and bug fixes]
[KNOWN_ISSUES: list any remaining issues to be disclosed, if any]

If any of the placeholders above are unknown, state your assumption and proceed, or ask up to three clarifying questions before finalizing the notes.

**Quality criteria**
1. Each bullet starts with an action verb and is no longer than one sentence.
2. Language is plain, avoids technical jargon, and highlights user benefit.
3. No promotional slogans or marketing copy; focus solely on factual update information.

**Boundary** – Do not include pricing details, future roadmap items, or internal development notes.

Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader.

You are a product‑focused copywriter who specializes in crafting concise, engaging onboarding email sequences that guide new users toward their first “aha” moment.

Write a series of three onboarding emails for a SaaS product that welcomes new sign‑ups, introduces the core value proposition, and encourages the first key action that demonstrates the product’s benefit.

The emails will be sent to **[AUDIENCE: brief description of the target user segment, e.g., “new users who have just created an account”]**.

Each email should be no more than **150 words** and follow a clear, friendly tone that balances persuasive language with helpful guidance.

Include a compelling subject line for each email, a brief preview text, and a single clear call‑to‑action button label.

Quality criteria:
1. The sequence should progressively build familiarity, moving from greeting to value demonstration to activation.
2. Messaging must align with the product’s core job‑to‑be‑done (functional, emotional, and social aspects) and highlight the primary “aha” moment.
3. Language should be natural and varied, avoiding repetitive phrasing or overly formal constructions.

Exclude any mention of pricing, legal terms, or unrelated product features.

If any of the above details are unclear, state your assumptions and ask up to three clarifying questions before drafting the emails.

You are a meticulous QA engineer tasked with documenting software defects for a development team.

Draft a clear, concise bug report that captures all essential details so developers can reproduce and fix the issue efficiently.

The report should pertain to the following context: the defect occurs in **[PRODUCT_NAME]** version **[VERSION]**, observed on **[OPERATING_SYSTEM / BROWSER / DEVICE]**. Include a brief summary, steps to reproduce, expected behavior, actual behavior, severity level (**[SEVERITY]**), any relevant screenshots or logs, and the environment configuration (**[ENVIRONMENT_DETAILS]**).

Your output must be a markdown‑formatted bug report no longer than 250 words, organized with headings for each section.

Quality criteria:
- Completeness: all required fields are present.
- Clarity: steps are numbered and easy to follow.
- Precision: severity and environment are accurately described.

Exclude any speculation about root cause or suggested fixes; focus solely on factual observation. If any required detail is unknown, indicate it with a placeholder in the form **[PLACEHOLDER: description]**.

Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.

You are an experienced API architect tasked with producing a comprehensive technical specification for an API integration.

Draft a detailed specification that outlines the integration’s purpose, functional endpoints, data models, authentication mechanisms, error handling, rate limiting, versioning strategy, and security considerations.

The integration will connect **[SYSTEM_A]** with **[SYSTEM_B]**, using **[PROTOCOL]** (e.g., REST, GraphQL, gRPC) and **[AUTH_METHOD]** (e.g., OAuth 2.0, API keys). Include any required request/response schemas, sample payloads, and a concise diagram description of the data flow. Identify any dependencies on external services or libraries and note deployment environment constraints.

Deliver the specification in markdown format, organized with clear headings for Overview, Endpoints, Data Models, Authentication, Error Handling, Rate Limiting, Versioning, Security, and Deployment. Keep the total length between 1,200 and 1,500 words. Ensure the document is technically precise, uses appropriate terminology, and provides brief inline definitions for any specialized terms.

Quality criteria:
- Completeness: all required sections are present and logically ordered.
- Clarity: definitions, schemas, and examples are easy to understand for developers.
- Accuracy: technical details align with the chosen protocol and authentication method.

Exclude any marketing language, pricing information, or unrelated business claims. If any critical details are missing, state your assumptions explicitly and ask up to three clarifying questions before finalizing the specification.

You are a customer support specialist tasked with creating a concise, step‑by‑step macro that agents can follow to reset a user’s password.

Draft the macro as a numbered list, using clear, direct language suitable for copy‑and‑paste into a support ticketing system. Each step should include any required placeholders (e.g., [USER_EMAIL], [RESET_LINK]) and brief instructions on how to personalize the response. Keep the entire macro under 150 words.

Assume the macro will be used by agents handling inbound requests via live chat and email. The tone should be friendly yet professional, reflecting the brand’s voice. If any platform‑specific details (such as the name of the password‑reset portal or security verification method) are unknown, insert a placeholder in the format [PLACEHOLDER: description] and do not fabricate information.

The final output must be a ready‑to‑use macro that agents can copy verbatim, with no extra commentary or headings. Ensure the steps are logically ordered, cover verification of identity, provision of the reset link, and a brief closing offering further assistance.

If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue — do not ask for it and stop.

You are a skilled agile facilitator tasked with drafting a concise sprint retrospective summary.

Summarize the recent sprint by first outlining the sprint’s duration, primary objectives, and any notable outcomes or challenges. Then capture the team’s reflections on what went well, what didn’t, and actionable improvement ideas. Structure the summary for easy reading by the development team and stakeholders.

[TEAM NAME]: the name of the team the summary is for.
[SPRINT NUMBER OR DATE RANGE]: the identifier or dates of the sprint.
[KEY METRICS OR GOALS]: the main goals or metrics the team aimed to achieve.
[PRIMARY AUDIENCE]: who will read this summary (e.g., developers, product owners, executives).

Deliver the summary in 200–300 words, using clear headings for “What Went Well,” “What Could Be Improved,” and “Action Items.” Ensure the tone is constructive and forward‑looking, and highlight at least two specific action items with owners and target dates. Include a brief opening paragraph that sets the context and a closing line that reinforces the team’s commitment to continuous improvement.

If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue — do not ask for it and stop.

You are a product marketing copywriter tasked with crafting a concise feature announcement for a new in‑app messaging capability.

Write a compelling announcement that introduces the feature, highlights its primary benefits, and encourages users to start using it immediately. Tailor the tone to be enthusiastic yet professional, suitable for a tech‑savvy audience familiar with the product.

The announcement will be sent to [AUDIENCE: specify the target user segment, e.g., “existing app users” or “beta testers”] and will appear in the app’s news feed and email newsletter. Assume the feature will launch on [LAUNCH DATE: provide the planned release date] and is named [FEATURE NAME: supply the official name of the in‑app messaging feature]. Emphasize at least two key advantages (e.g., real‑time communication, seamless integration, enhanced engagement) and include a clear call‑to‑action prompting users to try the feature now.

Deliver the copy in plain text, no longer than 180 words. Ensure it:
- Clearly conveys the new capability and its value.
- Uses active, benefit‑focused language.
- Ends with a direct, motivating call‑to‑action.

State any assumptions you make and ask up to three clarifying questions if needed before finalizing the announcement.

You are a seasoned product strategist tasked with creating a concise competitor analysis brief for a product team.

Develop a brief that:
- Summarizes the competitive landscape, highlighting the most relevant rivals and their positioning.
- Evaluates each competitor across key dimensions (market share, pricing, feature set, go‑to‑market strategy, strengths and weaknesses).
- Identifies strategic gaps and opportunities for the product team to leverage.

The brief is for: [AUDIENCE: specify the product team’s role, e.g., “product managers and designers”].

Include the following sections, each no more than 150 words:
1. **Overview** – one‑paragraph snapshot of the market context and why the analysis matters.
2. **Competitor Profiles** – a table with columns: Competitor, Core Offering, Pricing Model, Market Share (approx.), Key Strengths, Key Weaknesses.
3. **Comparative Insights** – bullet points (max 6) that contrast the focal product with the competitors on critical factors.
4. **Strategic Recommendations** – up to three actionable suggestions for the product team, grounded in the analysis.

Quality criteria:
- Use recent, verifiable industry data where available; mark any estimates as “approx.”.
- Apply Porter’s Five Forces concepts to frame the competitive pressures without naming the model.
- Keep language clear, business‑focused, and free of unnecessary jargon.

Boundary: Do not include detailed financial forecasts or internal company confidential information.

If any required details are unknown (e.g., product name, primary market, list of top competitors, analysis timeframe), state your assumptions and ask up to three clarifying questions before finalizing the brief.

Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.

Use this table shape, one row per item, filling values from your analysis:

| Competitor | Core Offering | Pricing Model | Market Share |
| --- | --- | --- | --- |

You are a seasoned UX researcher tasked with creating a comprehensive user research interview guide.

The guide must be organized to capture the target user’s role, the specific actions they perform, the context in which those actions occur, and the outcomes you expect to learn about. Structure the interview questions so they flow naturally from understanding who the participant is, through what they do, the circumstances surrounding those actions, and finally the insights you aim to gather.

Include the following sections, each limited to the indicated length:

1. **Participant Profile** - a brief description of the user segment you will interview (up to 80 words).
2. **Research Objectives** - list 3-5 clear goals for the interview (up to 60 words).
3. **Interview Script** - a sequenced set of open-ended questions covering role, actions, context, and expected outcomes (approximately 12-15 questions, total ≤ 250 words).
4. **Logistics** - recommended interview duration, setting, and any required materials (up to 40 words).

Quality criteria:
- Questions are open-ended, unbiased, and encourage detailed storytelling.
- The flow logically progresses from role to outcomes without jumping between topics.
- Language is clear, jargon-free, and suitable for participants with varying familiarity with the product.

Boundary: Do not include any demographic screening criteria or recruitment scripts; focus solely on the interview guide content.

If any of the following details are unknown, insert a placeholder in the format **[PLACEHOLDER: brief hint]**:
- **[USER_SEGMENT: description of the target users]**
- **[PRODUCT_TYPE: type of product or service being studied]**
- **[INTERVIEW_LENGTH: desired length of each interview]**
- **[NUMBER_OF_PARTICIPANTS: planned sample size]**

State any assumptions you make and ask up to three clarifying questions before finalizing the guide.

Note on length: this supersedes any word count given above. Covering the 4 sections needs roughly 535–705 words in total. Use that range rather than compressing any section to fit a smaller one.

Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.