Complete a task through a scenario

Choose a scenario by its output

The site offers 5 bilingual scenarios: customer meetings, weekly reports, bug retesting, feedback-to-requirements, and product launches. Each provides a small set of relevant roles and a first task to copy.

Review the roles and original tasks, then try the fictional materials below. All five reference outputs are prepared teaching examples. Check the evidence; the wording need not match.

• Practice: from a fact table to a meeting brief
• Practice: separate delivery, testing, and acceptance
• Practice: plan retesting without an environment
• Practice: turn duplicate and conflicting feedback into candidates
• Practice: hold a launch when evidence is missing

Scenario materials and task cards

Practice: from a fact table to a meeting brief

For beginners and team handoffs. All materials below are fictional. The reference output is a prepared teaching example, not a Bot run. Copy the materials, build a sourced fact table, then prepare a one-page meeting brief and five questions. Produce an internal draft without customer commitments.

Practice task and materials

Task: act as the Account Research Specialist. Use only the fictional materials below to prepare a fact table for meeting preparation.
Output: facts, source IDs and dates, need signals, and assumptions to verify. Mark absent dates, budget and decision-maker as unknown; do not infer purchase intent.
Boundary: internal draft only. Do not contact customers, quote prices or promise unverified capabilities.

Fictional materials:
A | Company profile, 2026-10-19: Qinghe Studio is a customer service team of 12.
B | Conversation, 2026-10-20: wants month-end ticket summaries; budget and decision-maker unknown.
C | Internal demo, 2026-10-21: only CSV import verified; real-time sync unverified.
D | Meeting goal, 2026-10-23: clarify summary definitions, data sources, and trial conditions.
E | Attendees: our account manager; customer attendees and responsibilities unconfirmed.
F | Scope: use A-E only; infer no purchase intent, price, or real-time sync commitment.

1. Give A-F to Account Research Specialist (awesome/account-research-specialist): build a table of facts, source dates, need signals, and assumptions to verify.
2. After human review, pass the fact table, B/C, and unknowns to Meeting Prep Buddy (awesome/meeting-prep-buddy). Request one page with an agenda, exactly five questions, and material tasks.
3. Have a human review commitment boundaries and save the draft. Attendees confirm questions and tasks; do not send it automatically.

Teaching reference excerpt

Background: Qinghe Studio, a customer service team of 12 (A, 2026-10-19).
Goal and agenda: clarify month-end ticket summaries (B); definitions, data, then trial conditions (D).
Capability boundary: fictional internal record verifies CSV import only; sync unverified (C); budget and decision-maker unknown (B).
Five questions: Which fields? Which date defines the month? Where is data exported? Who decides on a trial? What budget and evaluation criteria apply?
Material tasks: our account manager prepares a CSV sample and demo scope; customer attendees and responsibilities unconfirmed (C/E).

1. Keep each source ID. Copy supplied dates and mark absent dates as not provided. Separate facts, demand signals and hypotheses; wanting a monthly summary is not purchase intent.
2. Check the one-page draft includes an agenda, five questions, and material tasks covering definitions, dates, sources, decision-making, and budget.
3. Retain unknown budget and decision-maker, and unverified sync. Include no external commitment or sent-message claim.

Revision request

Repair only gaps: keep the reviewed fact table. Replace any sync-support claim with "unverified (C)"; add missing sources or questions. Return affected rows and the revised brief without inventing customer information. If a reviewer finds a gap, return it to the role that produced it. A human reviews the revision before handoff or saving; there is no automatic routing.

• Open scenario task cards
• View scenario roles in the market

Practice: separate delivery, testing, and acceptance

For beginners and team reporting. All materials are fictional. The reference is a prepared teaching example, not a Bot run. Copy the records and draft the report for 2026-10-19 through 2026-10-23 with evidence IDs. Keep earlier work and technical tests separate from current business acceptance.

Practice task and materials

Task: act as the Status Report Writer. Use only the fictional records below to draft the report for 2026-10-19 through 2026-10-23.
Output: current delivery, technical validation, business acceptance pending, earlier work, and blockers/next steps. Cite source IDs for every status. Mark missing owners and dates unknown and request assignment.
Boundary: do not equate technical tests with business acceptance or earlier work with current delivery. Draft only; do not send.

Fictional materials:
A | Weekly goal: deliver a registration-page draft on 2026-10-23; arrange business acceptance separately.
B | 2026-10-20: Chen submitted page draft v0.3 with a delivery record.
C | 2026-10-21: technical record shows 8 desktop tests passed; mobile testing not started.
D | 2026-10-23: business acceptance still pending; no approval record supplied.
E | 2026-10-16: registration field list completed last week; exclude from new weekly deliveries.
F | 2026-10-22: legal copy pending; owner and response date unknown.
G | Next: Chen plans mobile tests on 2026-10-26; copy owner awaits assignment.

1. Give records to Status Report Writer (awesome/status-report-writer): group current delivery, technical validation, business acceptance pending, earlier work, and blockers/next steps, citing IDs.
2. The report owner checks dates and evidence, flags the copy blocker as an assignment request, and sends only after confirmation.

Teaching reference excerpt

Period: 2026-10-19 through 2026-10-23; page draft v0.3 delivered (A/B).
Technical validation: 8 desktop tests passed; mobile untested (C).
Business status: acceptance pending (D); do not mark the whole project complete.
Earlier work: field list completed on 2026-10-16, background only (E).
Blocker/action: assign a copy owner and response date (F); Chen plans mobile tests on 2026-10-26 (G).

1. Count B as this week's delivery and E as earlier work; distinguish reporting dates from next-step dates.
2. Limit the count of 8 to desktop technical tests; preserve separate mobile and business acceptance states.
3. Source every status. Keep F owner/date unknown and request assignment without inventing a name.

Revision request

Repair only gaps: retain sourced delivery records. Split any "fully accepted" claim into technical validation (C) and pending acceptance (D), move E to background, and add an assignment request for F. Return changed paragraphs only. If a reviewer finds a gap, return it to the role that produced it. A human reviews the revision before handoff or saving; there is no automatic routing.

• Open scenario task cards
• View scenario roles in the market

Practice: plan retesting without an environment

For developers and team handoffs. Browser feedback, logs, and versions below are fictional. The reference is a prepared teaching example, not a Bot run. There is no real test environment. Practice planning and evidence classification only; execution remains pending, with no reproduced or fixed claims.

Practice task and materials

Task: act as Bug Reproduction. Use only the fictional materials below to write a minimal reproduction plan. There is no real test environment; do not run tests.
Output: separate reports, log clues and fix hypotheses. Plan single-click controls, double-click cases and repeated trials. Leave fields for expected/actual outcomes, trial counts, build, environment and evidence blank, and list missing environment details.
Boundary: mark execution pending throughout. Two log lines do not prove a root cause; claim no reproduction, repair or release readiness.

Fictional materials:
A | Fictional report, 2026-10-21: Chrome 129 / macOS 14, draft v0.3; two clicks on Submit show two registrations.
B | Expected: one submission intent creates one entry; reporter says intermittent, frequency unmeasured.
C | Fictional log: 10:02:01 POST /signup 201; 10:02:01 POST /signup 201; no request IDs.
D | Minimal input: name "Test A", email test@example.invalid; planning only.
E | Developer note: candidate v0.3.1 disables the button during submission; no fix verification record.
F | Core paths: normal, blank, failed-request retry; no real environment, account, or actual build supplied.
G | Release conditions: repeatable baseline evidence, candidate retest under matching conditions, and three path records reviewed by an owner.

1. Give records to Bug Reproduction (awesome/bug-reproduction): classify A/B as reports, C as a fictional log clue, and E as a fix hypothesis. Plan a single-click control, double-click case, and repeated trials; list missing environment details.
2. After human review, pass the plan, unverified hypotheses, and blank execution fields to Startup QA Bot (awesome/grok-startup-qa-bot). Sequence normal, blank, retry, and candidate checks, all pending.
3. A real executor obtains an authorized environment and completes records separately. The release owner decides from real evidence, not this fictional example.

Teaching reference excerpt

Classification: A/B are reports, C is a fictional log clue, E is a candidate fix note; none proves a cause.
Plan: fix input D; run baseline single-click control and double-click trials, recording each outcome; retest the candidate under matching conditions.
Checks: normal, blank, then failed-request retry; all currently pending (F).
Real executor fills: name___ date___ build/environment___ trials___ expected/actual___ log/screenshot location___.
Completion: repeatable baseline evidence, candidate results, and three path records complete; failures resolved and release owner signs off (G).

1. Require a single-click control, double-click cases, and recorded trial counts. Two 201 lines alone establish neither duplicate entries nor root cause.
2. Include pending baseline, candidate, and three-path checks, with executor, date, environment, build, result, and evidence fields.
3. Without real execution, claim neither reproduction, repair, nor release readiness. Real completion requires G and reviewed execution records.

Revision request

Repair only gaps: keep the plan. Replace unsupported reproduced/fixed claims with "pending real execution". Add only missing controls, paths, or record fields and identify required real evidence; generate no execution results. If a reviewer finds a gap, return it to the role that produced it. A human reviews the revision before handoff or saving; there is no automatic routing.

• Open scenario task cards
• View scenario roles in the market

Practice: turn duplicate and conflicting feedback into candidates

For team handoffs; beginners can start by checking sources. All materials are fictional. The reference is a prepared teaching example, not a Bot run. Copy the records to produce traceable requirement candidates with unconfirmed priorities. A small sample cannot establish majority demand; promise no schedule and do not write to a backlog.

Practice task and materials

Task: act as the Product Feedback Analyst. Use only the fictional records below to organize feedback themes for human review before handoff to Feature Request Tracker.
Output: themes, user tasks, source IDs and quotes, deduplication, conflicts and sample gaps. Count A/B as one incident; retain C/E as separate issues from one user.
Boundary: do not turn a three-user sample into majority demand, set priorities, promise dates or edit a backlog.

Fictional materials:
A | Ticket T01, 2026-10-19, U1/admin: weekly CSV export takes too many steps; wants one-click export.
B | Email M01, 2026-10-20, U1: forwards T01 again, the same incident.
C | Ticket T02, 2026-10-20, U2/admin: wants all members shown by default.
D | Interview I01, 2026-10-21, U3/member: opposes showing all members by default due to roster privacy.
E | Ticket T03, 2026-10-22, U2: cannot find CSV export; a different issue from T02.
F | Existing R07: simplify CSV export, awaiting review; recent change only renamed navigation.
G | Coverage: 3 users, 2 roles; total population, representativeness, impact frequency, and priorities unknown.

1. Start with Product Feedback Analyst (awesome/product-feedback-analyst): preserve IDs and quotes, deduplicate A/B as one incident, separate export tasks from conflicting member-visibility requests, and state sample gaps.
2. After human review, pass themes to Feature Request Tracker (awesome/feature-request-tracker): link A/E to R07, keep C/E distinct despite the shared user, and record candidates, sources, conflicts, validation, and unconfirmed priorities.
3. The product owner verifies impact and access rules before deciding priorities and backlog entry; retain open questions.

Teaching reference excerpt

Deduplication: A/B are one incident with two sources; do not count two users.
R07 candidate addition: simplify and clarify CSV export, A/E from 2 users; retain both step-count and discoverability issues.
Candidate N02: clarify member visibility by role; C requests all-visible, D opposes it; do not default to all-visible.
Validation: walk through export; confirm visibility and access policy with both roles, then measure impact frequency.
Priority: R07/N02 await product-owner confirmation; 3 users do not represent a majority (G); promise no development date.

1. Count A/B as one incident while retaining both sources; do not deduplicate C/E, different issues from one user.
2. Give every candidate an ID, sources, and validation method; link A/E to R07 instead of creating an unsupported duplicate.
3. Retain the C/D conflict, three-user coverage limit, and unconfirmed priorities; claim neither majority demand nor a scheduled feature.

Revision request

Repair only gaps: retain traceable candidates. Correct the A/B count, add missing C/D opposition or sources, and mark unsupported priorities unconfirmed. Return affected candidates and deduplication notes only. If a reviewer finds a gap, return it to the role that produced it. A human reviews the revision before handoff or saving; there is no automatic routing.

• Open scenario task cards
• View scenario roles in the market

Practice: hold a launch when evidence is missing

For team handoffs and product-owner review. All materials are fictional. The reference is a prepared teaching example, not a Bot run. Copy the materials to prepare positioning and a calendar with dependencies. Include failed checks and unknown metrics; record a human hold decision without inventing a live launch.

Practice task and materials

Task: act as the Product Marketer. Use only the fictional materials below to draft positioning for human review before scheduling.
Output: audience, customer task, evidenced capabilities, value hypotheses, content needs and open validation items. Cite source IDs for each claim and retain failed checks and the human hold.
Boundary: invent no metrics, testimonials or live-launch status. Do not confirm a launch date or publish.

Fictional materials:
A | Audience: small event teams; 3 interviews mention time spent organizing registrations, not a representative sample.
B | Product evidence, 2026-10-21: demo verifies CSV export only; time-saving percentage and conversion rate unknown.
C | Quality record, 2026-10-22: mobile failed-request retry check failed; no retest result yet.
D | Target: introduction page and email proposed for 2026-10-28; date unconfirmed, not live.
E | Assets: page draft ready; email copy incomplete; no authorization for customer testimonials.
F | Owners: Lin creates, Zhou reviews; review slot fixed on 2026-10-27; email depends on page approval.
G | Human decision, 2026-10-23: hold external release; resume only with passing C retest evidence, approved assets, and owners reconfirming the date.

1. Start with Product Marketer (awesome/grok-product-marketer): draft audience positioning from A/B, separating demonstrated capability from value hypotheses. Include no invented metrics or testimonials; retain C/G gates.
2. After human review, pass it to Marketing Calendar Owner (awesome/marketing-calendar-owner): work backward through creation, review, and channel checkpoints, with F dependencies and fixed slot; keep 2026-10-28 as an unconfirmed target.
3. A human maintains the hold under G. Once real evidence is complete, owners review the date again and execute publication under separate authorization.

Teaching reference excerpt

Positioning draft: a CSV export workflow for small event teams (A/B); time savings remain a hypothesis.
Copy boundary: no saving percentage, conversion uplift, or customer testimonial (B/E).
Calendar: Lin completes email draft, Zhou reviews page and email on 2026-10-27, then channel checks; email depends on page approval (E/F).
Status: human hold (G); mobile retry failed (C); 2026-10-28 awaits reconfirmation, not live (D).
Resume evidence: passing C retest record, both asset approvals, and an owner-confirmed date; unknown outcome metrics need a separate validation plan.

1. Source value claims to A/B or mark them hypotheses. Invent no missing metrics and include no unauthorized testimonials.
2. Include creation/review owners, the fixed 2026-10-27 checkpoint, and the email dependency; do not turn the target into a promise.
3. State the failed C check, human hold G, and all three resume-evidence requirements; a draft plan is not a live launch.

Revision request

Repair only gaps: retain sourced positioning and calendar entries. Remove unsupported metrics and add missing C/G gates or dependencies. Return changed lines and outstanding resume evidence; do not lift the hold or mark the launch live. If a reviewer finds a gap, return it to the role that produced it. A human reviews the revision before handoff or saving; there is no automatic routing.

• Open scenario task cards
• View scenario roles in the market

Accept one scenario result

1. Prepare the minimum materials listed in the scenario, starting with sanitized samples.
2. Give the first task to its role and check scenario acceptance criteria.
3. Resolve gaps and pass outputs, sources, and unknowns with a handoff card to the next owner.
4. Save final outputs and failure causes. A scenario download does not execute the workflow.

Sources

Sources checked: 2026-10-25

• Scenario source data
• Scenario first-use guide