← Plugin catalog
Data & Analytics
august
Fermat Commerce v1.0.0
august builds Digital Twins of the people your business needs to understand. Digital Twins are mirrors of your real users trained on your data to think, make decisions and respond like their real-life counterparts. This plugin allows you signup for august and interact with your Digital Twins all from within ChatGPT or Codex.
Language: English · Automatically detected from descriptions.
Package details
Publisher declarations from the archived package. These are separate from our research and the live service's terms.
- Package author
- Fermat Commerce
Package observed Sep 30, 2026.
Files & skills
File archives
Plugin package11 files · 21 KBBrowse files →
Skill instructions
august-concept-compare6.49 KB
--- name: august-concept-compare description: > Run the same concept, design, or copy past August twins across two or more variants (A/B/C/D) and return a side-by-side comparison instead of one twin's take at a time. Use whenever the user has multiple candidate concepts and wants twin-simulated preference signal before committing — landing page variants, packaging concepts, positioning angles, hero designs, pricing framings, ad creatives. Different from /august-feedback (single artifact). Also handles text-only variants (headlines, CTAs, taglines) — hard-scope output to phrase-level notes in that case. Triggers on: "compare these concepts", "A/B test with twins", "which variant do twins prefer", "run these variants past twins", "concept test", "/august-concept-compare". --- # August Concept Compare Compare 2–4 variants of the same concept across August twins and return a matrix of reactions plus a recommended winner. Tools live under the August MCP. **When to use:** the user has multiple candidate concepts and wants relative preference signal (which is stronger, and why). **When NOT to use:** - Only one concept exists → use `/august-feedback` instead. - User wants step-by-step friction on a flow → use `/august-flow-audit`. **Text-only variants (headlines, CTAs, taglines, body copy):** still use this skill, but hard-scope the output to phrase-level notes — comment only on wording, not on layout, imagery, or design drift. Flag any design/layout observations that surface anyway as "out of scope — worth a full concept test?" rather than including them in the main matrix. **Core rule:** if the org, the audience, or the comparison format is unclear, ASK once. Don't silently pick — mis-routed comparisons are worse than mis-routed single feedback because they influence a choice. --- ## STEP 1 — Confirm the variants + audience Before any MCP call, be clear on: - **How many variants?** (2, 3, or 4 — cap at 4; more than that dilutes signal.) - **What form?** Text, image/screenshot, Figma link, full page mock? - **What are they variants OF?** A hero section, an entire landing page, a pricing card, a value prop, a packaging design, etc. - **What audience should judge?** Brand shopper twins (consumer artifact) or Fermat-org dashboard-user twins (internal tool)? If any of these are missing, ASK. Ask the user for closed choices (2–4 options); prose otherwise. --- ## STEP 2 — Pick the organization Call `list_organizations`. Then match audience → org: | Artifact | Likely org | |---|---| | Consumer landing page, DPP, ad, packaging, pricing | Brand org (GNC, Backcountry, etc.) | | Fermat/August dashboard UI, admin tooling, internal workflow | Fermat org | If the user named a brand or audience, resolve directly. If ambiguous, ASK with `list_organizations` results as options. --- ## STEP 3 — Pick the comparison format Three viable shapes. Default to (B) unless the user signals otherwise. **(A) Single twin sees all variants (one interview)** - Best for: tight cost, quick gut check, one strong-fit persona. - Method: pick 1 twin via `list_twins`, call `start_interview(twin_id)`, then call `ask_question(interview_id)` once per variant with matching framing and the artifact in `design_context`. Do NOT reveal that other variants exist until the final preference question. **(B) One focus group sees all variants together — DEFAULT** - Best for: real A/B/C preference signal with diversity. - Method: use `list_focus_groups` to select an existing ready group, then `start_focus_group`. Attach Figma variants with `add_focus_group_stimuli`; for text or described-image variants, include the labelled artifacts in the round question instead. Run the reaction round, then a preference round, then `end_focus_group` → `get_focus_group_results`. If no suitable ready group exists, ask the user to configure one in August or use (A). **(C) One focus group per variant (parallel groups)** - Best for: when priming across variants would contaminate reactions (e.g., strongly branded concepts where seeing variant B changes how you read variant A). - Method: use N existing ready groups with matched twin composition, one per variant. The MCP cannot create groups or select their panels. If those groups do not exist, use (A) or ask the user to configure them in August. If the user didn't specify, ASK which shape — offer A/B/C as options. --- ## STEP 4 — Run it For each MCP call, pass the actual artifact content — the copy text, image description, Figma frame contents, or pasted screenshot description. Vague stimuli = vague comparison. **Prompts to use in the group / interview:** 1. Reaction round: "Here are [N] variants of [artifact]. React to each one independently: what stands out, what confuses you, what makes you want to click / keep reading / bounce." 2. Preference round: "Now pick the one that would most make you [target action — buy, sign up, keep browsing]. Explain why in one sentence." Retrieve results via `get_focus_group_results` or `get_interview_transcript` depending on the route. --- ## STEP 5 — Synthesize into a side-by-side matrix Do NOT dump raw transcripts. Return this template: ``` ## Concept Comparison: [artifact name] Audience: [org] · Format: [single twin / focus group / N parallel groups] Twins: [names or count] | Variant | What landed | What didn't | Who preferred it | Why | |---|---|---|---|---| | A — [label] | ... | ... | [twin names or count] | [core reason] | | B — [label] | ... | ... | ... | ... | | C — [label] | ... | ... | ... | ... | ### Recommended winner: **Variant [X]** - **Why it wins:** [1–2 sentence synthesis of the strongest signal] - **Tradeoff to know:** [what it loses vs. runner-up — every winner has one] - **Suggested next move:** [ship as-is / merge X's headline + Y's visual / re-test with tighter audience / etc.] ### Source [Focus group name(s) or twin name(s), org, dates] ``` If signal is thin, tied, or contradictory across twins, SAY SO explicitly in the "Recommended winner" section — don't force a call. Offer to re-run with a different format (e.g., swap to parallel groups) or a different audience. --- ## Quick reference | Situation | Action | |---|---| | 2–4 concrete variants + clear audience | Proceed with default (B) | | Only 1 variant | Redirect to `/august-feedback` | | Text-only variants | Proceed, but hard-scope output to phrase-level notes | | Variants strongly primed / branded | Ask about (C) parallel groups | | Org or audience unclear | ASK once, then proceed |
august-feedback9.78 KB
---
name: august-feedback
description: >
Get feedback on ideas, designs, copy, flows, products, dashboards, or
research questions by routing to the August MCP — a directory of LLM twins
organized by org. Twins represent BOTH end shoppers (per brand org, e.g.,
GNC, Backcountry) AND product/dashboard users (under the Fermat org, e.g.,
researchers, PMs, ops users of the Fermat or August dashboards). Picks the
best twin or runs a focus group depending on the task. Use whenever the
user asks for feedback, reactions, customer perspective, user testing,
persona input, dashboard-UX feedback, or "what would shoppers / dashboard
users think." Triggers on: "get feedback", "ask August", "what would
customers say", "run this by a twin", "focus group this", "/august-feedback".
---
## ⚠️ MANDATORY TRIGGER RULE
**Any time the user says the word "feedback" — or asks for a reaction, gut
check, review, or critique on an artifact — this skill MUST run.** This is
non-negotiable.
- Do NOT offer to run it ("want me to also route this through August?"). Just
run it.
- Do NOT skip it because the primary ask is something else (brief-alignment
check, code review, copy review, etc.). Run it *in addition to* answering
the primary ask.
- Do NOT ask "do you want twin feedback too?" — the word "feedback" *is* the
green light.
- Only skip when the user explicitly says "no twin feedback" or "skip August."
If the primary ask is something twins can't directly evaluate (e.g., "does
this align with Josh's brief?"), still invoke this skill on the artifact with
a question they *can* answer — a gut reaction, a usability read, an
emotional reaction to the design. Always frame the twin question to be
answerable, not to be a thin proxy for the primary ask.
# August Feedback
Route a feedback request to the right August twin(s) — either a single twin
(best fit interview) or a focus group (multiple twins, broader signal).
Tools live under the August MCP.
**Two flavors of twin exist:**
- **Shopper twins** — live under each brand org (GNC, Backcountry, etc.).
Model real retail customers. Use for feedback on consumer-facing artifacts:
funnels, DPPs, product copy, pricing, ads, packaging concepts.
- **Dashboard-user twins** — live under the **Fermat org**. Model the
internal/B2B users of Fermat and August dashboards (researchers, PMs,
merchandisers, ops). Use for feedback on tooling, dashboard UX, internal
workflows, admin UIs, settings screens, and the August product itself.
Match the audience to the artifact: a consumer landing page → brand-org
shopper twins. An internal survey-builder UI → Fermat-org dashboard-user
twins. If you're not sure which kind, **ASK**.
**Core rule:** when you don't have enough context to confidently pick the
organization, the twin, or the format (single vs. focus group), STOP and ask.
Never silently guess. Better to ask one question than to return feedback from
the wrong audience.
---
## STEP 1 — Understand the ask
Before calling any August tool, be clear on:
- **What is being evaluated?** Copy, a design, a product concept, a pricing
idea, a flow, a positioning angle, a feature, a marketing message, etc.
- **What decision will the feedback inform?** (gut check, prioritization,
go/no-go, refinement, A/B framing)
- **Who is the intended audience?** A specific brand's existing customers? A
category buyer in general? A demographic slice?
- **What format of response is useful?** A single deep reaction (twin),
multiple varied reactions (focus group), or a quick gut check?
If any of the above are unclear from the conversation, **ask the user before
proceeding.** Use the a concise question tool when you have 2–4 discrete options
to choose between; use plain prose questions when the answer is open-ended.
---
## STEP 2 — Pick the organization
The August MCP is org-scoped — every twin and focus group belongs to an
organization. You MUST know the org before you can pick a twin or run a
group.
### Quick audience → org mapping:
| Artifact being evaluated | Likely org |
|---|---|
| Consumer landing page, funnel, DPP, ad, product copy, packaging | The relevant **brand org** (GNC, Backcountry, etc.) |
| Fermat dashboard UI, August dashboard UI, internal admin tool, survey builder, research workflow | **Fermat org** (dashboard-user twins) |
| Internal-facing copy / docs / onboarding for Fermat employees or platform users | **Fermat org** |
### Resolution order:
1. If the user has named a brand or audience type (e.g., "GNC shoppers",
"dashboard users", "Fermat researchers"), match to an org via
`list_organizations`.
2. If they haven't named one, infer from the artifact: is this consumer-
facing (→ brand org) or internal/B2B/dashboard (→ Fermat org)?
3. If they haven't named one AND the artifact's audience is ambiguous,
**ASK.** Present available orgs from `list_organizations` as options.
Never assume.
Example question if ambiguous:
> Which audience should I get feedback from?
> - Shoppers from a brand org (e.g., GNC, Backcountry) — for consumer-facing work
> - Dashboard users in the Fermat org — for internal/product UX work
> - Or name a specific persona and I'll find the closest match
---
## STEP 3 — Decide: single twin vs. focus group
Use this rubric to decide. When the signal is mixed or you're not sure,
**ASK the user** rather than guessing.
### Pick a SINGLE TWIN when:
- The user wants a deep, conversational reaction ("what would Sarah think
of this?")
- The audience is narrow and one persona clearly fits (e.g., "a budget-
conscious first-time supplement buyer")
- The user wants to interview / probe / follow up with the same persona
- The task is a quick gut check on copy, a headline, or a single CTA
- The user explicitly named a twin or persona type
→ Use `list_twins` to browse, then `start_interview` followed by
`ask_question`.
### Run a FOCUS GROUP when:
- The user wants a *range* of reactions or to see disagreement
- The decision affects a broad audience and one twin isn't representative
- The user is comparing multiple concepts (A vs. B vs. C) and wants varied
takes on each
- The user wants signal on "what % of customers would..." style questions
- The task involves pricing, positioning, or product-market fit where
diversity matters
→ Use `list_focus_groups` to find an existing relevant group, or surface
the option to the user. Use `get_focus_group_results` to retrieve results.
### ASK THE USER when:
- The ask could go either way (e.g., "feedback on this landing page" — could
be one twin's deep walkthrough OR a focus group's varied first impressions)
- You don't know how broad/narrow the intended audience is
- The user hasn't signaled urgency or depth preference
Example question when format is ambiguous:
- **Single twin** — "Deep reaction from one persona who fits the target"
- **Focus group** — "Varied reactions from multiple personas"
- **Quick ask** — "Open an interview and ask one question"
---
## STEP 4 — Pick the specific twin (if single-twin route)
Once the org is set and you're going single-twin:
1. Call `list_twins` for the org.
2. Match against the feedback ask — demographics, behavior, category
affinity, buying stage, etc.
3. **If multiple twins could fit, ASK.** Show the top 2–3 candidates with
one-line summaries and let the user pick.
Example question when twin choice is ambiguous:
> I can route this to one of these twins — which fits best?
> - Twin A: [one-line description]
> - Twin B: [one-line description]
> - Twin C: [one-line description]
Never pick a twin silently when two or more reasonably fit. Mis-routing
wastes the user's time and produces feedback from the wrong audience.
---
## STEP 5 — Run it
### For a single twin:
- Call `start_interview` with the selected `twin_id`, then call
`ask_question` with the returned `interview_id`. Put the artifact in
`design_context` when applicable. For a quick ask, stop after one answer;
for a deeper conversation, continue with follow-up `ask_question` calls.
- Use `get_interview_transcript` with the interview ID as `conversation_id`
when the full transcript is needed.
### For a focus group:
- Use `list_focus_groups` to select an existing relevant group. To run new
rounds it must already be configured and ready in August; the MCP does not
create focus groups or choose their panel.
- Use `get_focus_group_results` for completed results. If a relevant ready or
completed group doesn't exist, tell the user to configure one in August.
Always pass the **actual artifact** being evaluated (the copy text, an image
or description of the design, the product details). Vague prompts produce
vague feedback.
---
## STEP 6 — Synthesize and return
Don't dump the raw transcript. Return:
1. **TL;DR** — 2–3 sentence summary of the reaction
2. **What landed** — what the twin(s) responded positively to
3. **What didn't** — concerns, confusion, objections
4. **Surprises** — anything unexpected worth flagging
5. **Suggested next move** — based on the feedback, what to change/test/keep
6. **Source** — twin name(s) or focus group name + org, so the user can
trace back
If feedback was thin or off-target, say so — and offer to re-route to a
different twin or format.
---
## When to ask vs. proceed — quick reference
| Situation | Action |
|---|---|
| Org is named or obvious from context | Proceed |
| Org is unclear | **ASK** |
| One twin clearly fits the ask | Proceed |
| 2+ twins could fit | **ASK** |
| Format (single vs. group) clearly indicated | Proceed |
| Format ambiguous | **ASK** |
| Artifact (copy/design/concept) is concrete | Proceed |
| User said "get feedback" with no artifact | **ASK** what to evaluate |
Defaulting to "ask when uncertain" is the whole point of this skill. The cost
of one clarifying question is tiny; the cost of feedback from the wrong
audience is a wasted decision.
august-flow-audit5.93 KB
--- name: august-flow-audit description: > Walk August twins through a proposed onboarding, checkout, signup, or funnel step-by-step and surface friction points before we ship. Screenshots, Figma frames, or step descriptions are attached as focus group stimuli one step at a time; twins call out where they'd get confused, hesitate, or drop off. Pre-launch, twin-simulated version of the friction points Commerce Graph measures post-launch. Triggers on: "audit this flow", "walkthrough with twins", "onboarding friction check", "test this funnel with twins", "friction check", "flow audit", "/august-flow-audit". --- # August Flow Audit Walk twins step-by-step through a proposed flow and produce a per-step friction report plus a top-3 overall list. Tools under the August MCP. **When to use:** the user has an ordered flow (onboarding, checkout, signup, quiz, guided-shopping funnel, dashboard first-run) and wants friction signal before shipping. **When NOT to use:** - Single screen or artifact → `/august-feedback`. - Comparing variants of the same screen → `/august-concept-compare`. - Text/microcopy only → `/august-feedback` for one version or `/august-concept-compare` for multiple versions. - Already-shipped flow with live traffic → skip this and pull the real friction points from Commerce Graph. **Core rule:** the flow order MATTERS. Twins react to step N with step N-1's context in their head. Never scramble the order and never merge steps into one stimulus batch — the whole point is step-by-step signal. --- ## STEP 1 — Confirm the flow Before any MCP call, be clear on: - **Ordered list of steps** — screenshots, Figma frame URLs, or written descriptions. Cap at ~8 steps per audit; if longer, chunk into two audits (e.g., "onboarding" and "first-purchase"). - **What is this flow FOR?** (new-user onboarding, checkout, guided quiz-to-recommendation, dashboard first-run, etc.) - **Who is the target user?** (first-time visitor, returning buyer, internal dashboard user, etc.) - **What's the desired end state?** (completed purchase, activated account, added product to cart, etc.) Missing any → ASK. A flow audit without a stated goal produces directionless friction complaints. --- ## STEP 2 — Pick the organization Call `list_organizations`. Map audience → org: - Consumer flow (checkout, funnel, onboarding on a brand site) → brand org. - Internal flow (Fermat dashboard first-run, admin setup wizard, August research-builder onboarding) → Fermat org. If unclear, ASK. --- ## STEP 3 — Start the focus group Use a focus group, not single-twin — friction signal wants diversity. Call `list_focus_groups` for the org and select an existing ready group whose configured panel matches the target user. Then call `start_focus_group` with its `focus_group_id`. The MCP cannot create a group or choose its panel; if no suitable ready group exists, ask the user to configure one in August. Keep this focus group open across every step. Do NOT end it between rounds — the twins' running memory of prior steps IS the signal. --- ## STEP 4 — Run the walkthrough, step by step For each step in order: 1. For a Figma URL, attach it with `add_focus_group_stimuli`. For a screenshot description or text step, include the full labelled artifact directly in the round question; the stimuli tool accepts only Figma URLs. 2. `run_focus_group_round` with a friction-focused prompt: > This is step [N] of [total]: [step name]. Imagine you just came from > the previous step. React honestly: > - Where would you get confused here? > - Where would you hesitate, second-guess, or want to go back? > - Where might you drop off entirely? > - What would you expect to happen next? 3. Optionally, on complex steps, run a second `run_focus_group_round` asking each twin to score friction 0–3 on that step (0 = smooth, 3 = would abandon) — this gives a rough severity anchor. After the last step: - `end_focus_group` - `get_focus_group_results` for the full transcript across all rounds. --- ## STEP 5 — Synthesize into a friction report Do NOT dump transcripts. Return this template: ``` ## Flow Audit: [flow name] Audience: [org] · Twins: [N] · Goal state: [end state] ### Per-step friction report **Step 1 — [name]** - Top friction points: - [point 1 — one line] - [point 2 — one line] - Standout quote: "[verbatim from a twin]" — [twin name] - Severity: **[low / med / high]** - Suggested fix: [one line — concrete change, not vibes] **Step 2 — [name]** - ... (repeat per step) ### Top 3 friction points overall 1. **[step + issue]** — [why it matters + severity] 2. **[step + issue]** — [...] 3. **[step + issue]** — [...] ### Cross-step patterns - [e.g., "twins repeatedly forgot what step 2 asked them, suggesting progress indicator is under-weight" — patterns visible only across steps, not within a single step] ### Post-launch note Worth running a real Commerce Graph friction-points check on this flow after ship — the twin signal above is directional, not measured. Compare the top-3 twin frictions against actual drop-off funnels once live traffic accrues. ### Source Focus group [name/id], org [name], twins [names] ``` Severity guidance: - **High** — twin explicitly said they'd bounce, or multiple twins hit the same wall. - **Med** — twin hesitated / had to re-read / needed to guess. - **Low** — nit or preference, not a blocker. If any step's signal was thin (twins just said "looks fine"), SAY SO — don't pad. Suggest re-running with a different twin composition or a more specific prompt. --- ## Quick reference | Situation | Action | |---|---| | Ordered flow with 3–8 steps + clear goal | Proceed | | >8 steps | Chunk into 2 audits, run separately | | Single screen | Redirect to `/august-feedback` | | Already-shipped flow with traffic | Pull real Commerce Graph friction points instead | | Twin signal thin on a step | Note it; offer to re-run with different panel |
august-focus-group-report5.86 KB
---
name: august-focus-group-report
description: >
Take an already-finished August focus group and turn its raw results into
an actual readout — consensus points, disagreements with named sides,
standout quotes, a rough sentiment split, and unresolved follow-up
questions. Post-hoc synthesis only; does NOT trigger a new focus group.
Use when the user has an FG that already ran and wants it read out for
them instead of scrolling raw output. Triggers on: "focus group report",
"synthesize focus group", "read out this focus group", "FG readout",
"summarize the focus group", "/august-focus-group-report".
---
# August Focus Group Report
Post-hoc synthesis of a completed August focus group. This skill does
NOT run a new focus group — it reads out an existing one. Tools live
under the August MCP.
**When to use:**
- A focus group has already been run (the user references it by name /
id, or says "the focus group I did yesterday")
- The user wants consensus, disagreements, and quotes — not raw output
- The user is preparing a share-out, doc, or decision brief off the FG
**When NOT to use:**
- The user wants to START a new focus group — that's a different flow
(`start_focus_group` + `run_focus_group_round`), not this skill
- The user wants deep 1:1 depth on one twin → use `/august-interview`
- The user wants a quick gut check → use `/august-feedback`
**Core rule:** never fabricate consensus or attribution. If the raw
results don't clearly show who said what, say so — do not paper over
gaps to make the readout cleaner.
---
## STEP 1 — Identify the focus group
Get to a specific `focus_group_id` before doing anything else.
1. If the user provided an id or exact name, use it directly.
2. If they described the FG loosely ("the pricing one from last week",
"the Backcountry hero image FG"), call `list_focus_groups` on the
likely org and match by name/date/topic.
3. If multiple candidates match, ask the user with the top 2–3
with one-line summaries (topic + date + twin count) and let the user
pick. Never guess.
4. If no FG matches, tell the user plainly — do not fabricate results,
and do not silently start a new one.
---
## STEP 2 — Pull the raw results
Call `get_focus_group_results` with the confirmed `focus_group_id`.
Also note, from the results payload:
- List of participating twins (names + ids)
- List of stimuli that were shown
- Number of rounds run
You'll need all of these for attribution in the readout.
If the results are empty or the FG hasn't finished, stop and tell the
user — do not synthesize a partial FG as if it were complete.
---
## STEP 3 — Synthesize
Read the full results carefully. Build the readout in this order:
1. **Group by stimulus / question**, not by twin. The unit of analysis
is "what did the group think about X?" not "what did Twin A think?"
2. **For each stimulus, sort takes into agree / disagree / mixed** based
on the actual content — do not force a 3-way split if there wasn't
one.
3. **Attribute every disagreement** to the specific twins on each side.
Attribution is the whole point of running a group vs. a single
interview.
4. **Extract quotes** that are punchy, specific, and representative —
not the longest, the shortest, or the most anodyne.
5. **Score sentiment** at the twin level per stimulus (positive / mixed
/ negative). Report the split as raw counts, not percentages — the
sample is too small for percentages to be honest.
6. **Flag unresolved questions** — places where twins clearly wanted
more info, contradicted themselves, or where the stimulus didn't
land clearly enough to draw a conclusion.
---
## STEP 4 — Return the readout
Use this exact structure:
```
# Focus group readout — <FG name>, <org>
Participants: <N twins> · Stimuli: <M> · Rounds: <R>
## TL;DR
3–5 sentences capturing the overall read. What did the group broadly
believe? Where was there real disagreement? What's the biggest signal
for the decision this FG was meant to inform?
## Consensus — what the group agreed on
Bulleted list. Each bullet: one claim, then in parens the count of
twins who supported it (e.g., "Price feels too high (5 of 6)"). Only
include items with clear majority backing.
## Disagreements — where the group split
For each real split:
- **The question / stimulus:** <what they were reacting to>
- **Side A (<count>):** <twin names> — <their position, 1–2 sentences>
- **Side B (<count>):** <twin names> — <their position, 1–2 sentences>
- **Why the split matters:** 1 sentence on the decision implication.
## Sentiment breakdown
Per stimulus, raw counts:
- Stimulus 1: <N positive> / <N mixed> / <N negative>
- Stimulus 2: ...
(Only include stimuli where sentiment was actually captured.)
## Standout quotes
3–5 direct quotes, each attributed to a specific twin and stimulus.
Preserve the twin's voice and phrasing.
> "quote" — <twin name>, on <stimulus>
## Unresolved — worth a follow-up
Bulleted list of questions the FG raised but didn't answer. These are
candidates for a targeted follow-up interview via `/august-interview`.
## Source
focus_group_id, org, participants list (names + ids), so the user can
trace back.
```
If the raw results are thin (short answers, low engagement, twins
staying vague), say so at the top and note that a re-run with tighter
stimuli might help — do not inflate weak signal into strong claims.
---
## Quick reference — when to ask vs. proceed
| Situation | Action |
|---|---|
| User gave an FG id or exact name | Proceed |
| User described the FG loosely, one clear match | Proceed |
| Multiple FGs match description | **ASK** with top candidates |
| No FG matches | Tell the user; do not fabricate; do not start a new one |
| FG has finished, results are rich | Full readout |
| FG has finished but results are thin | Deliver readout + honest thinness note |
| FG hasn't finished / no results | Stop; report status back |
august-interview5.29 KB
---
name: august-interview
description: >
Run a structured 1:1 interview with a single August twin off a discussion
guide (a list of questions or topics the user provides), and return a
clean synthesized write-up instead of raw back-and-forth. Use when the
user wants depth on one persona and does NOT want to read the full
transcript themselves. Triggers on: "interview a twin", "structured
interview", "run a discussion guide", "walk a twin through these
questions", "1:1 twin interview", "/august-interview".
---
# August Interview
Drive a structured 1:1 interview with a single August twin using a
discussion guide, then hand back a clean write-up. Tools live under
the August MCP.
**When to use:**
- User has a list of questions/topics they want walked through with one twin
- User wants depth on a single persona (not a range of reactions)
- User explicitly does not want to read the full transcript
**When NOT to use:**
- User wants varied reactions across personas → use focus group tooling
- User wants a single gut-check reaction → use `/august-feedback`
- User just wants to find the right twin → use `list_organizations` and
`list_twins` directly
**Core rule:** if org, twin, or the discussion guide itself is unclear, ASK
before calling any tool. Better one clarifying question than an interview
with the wrong persona off the wrong questions.
---
## STEP 1 — Confirm the discussion guide
Before touching August, make sure you have:
- A concrete list of questions or topics (the "discussion guide")
- A rough sense of interview depth per question (one probe, or several
follow-ups?)
- The intended audience for the twin (which org / persona type)
If the user pasted a wall of text, extract the questions into an ordered
list and mirror it back for confirmation. If the guide is vague ("ask them
about pricing"), ASK for the actual questions — do not invent them.
---
## STEP 2 — Pick the organization
The August MCP is org-scoped. Every twin belongs to an org.
1. If the user named a brand or audience (GNC, Backcountry, Fermat
dashboard user), match to an org via `list_organizations`.
2. If they haven't, infer from the discussion guide: consumer-facing
questions → brand org; internal/dashboard/workflow questions → Fermat
org.
3. If ambiguous, ask the user with 2–4 candidate orgs pulled from
`list_organizations`. Do not guess.
---
## STEP 3 — Pick the specific twin
Call `list_twins` for the chosen org.
- Match twin traits to the discussion guide's target persona.
- If exactly one twin clearly fits, proceed.
- If 2+ twins reasonably fit, ask the user with the top 2–3
candidates and one-line summaries. Never silently pick.
Record the selected `twin_id` for the interview call.
---
## STEP 4 — Start the interview and loop the guide
1. Call `start_interview` with the selected `twin_id` and save the returned
`interview_id`.
2. For each question in the discussion guide, call `ask_question` with that
`interview_id`. Include the discussion framing in the first question and
preserve the guide order.
3. If a response is thin or dodges the question, follow up with ONE
clarifying `ask_question` before moving on. Do not spiral — the goal
is coverage of the full guide, not exhaustive probing on one item.
4. Once every guide question has been asked (and any needed follow-ups are
done), call `get_interview_transcript` with the interview ID as
`conversation_id` to retrieve the full record.
Pass the actual artifact (copy, screenshot description, product details)
when a question references one. Vague prompts produce vague answers.
---
## STEP 5 — Synthesize the write-up
Do NOT return the raw transcript. Return this structured format:
```
# Interview write-up — <twin name>, <org>
## TL;DR
2–3 sentence overall read on the twin's stance across the guide.
## Per-question responses
For each question in the original guide order:
### Q1 — <the question, verbatim>
- **Summary:** 1–3 sentences capturing the twin's answer.
- **Key points:** 2–4 bullets of the specific things they said.
- **Confidence / hedging:** note if they hesitated, hedged, or were firm.
(Repeat for each guide question.)
## Cross-cutting themes
Patterns that showed up across multiple questions (e.g., recurring
concern about price, recurring positive on brand trust).
## Surprises
Anything the twin said that you did not expect given the persona
profile — worth flagging to the user.
## Verbatim quotes
3–6 short direct quotes from the transcript, attributed with the
question they came from. Preserve tone and phrasing exactly.
## Source
Twin name + twin_id + org + interview id, so the user can trace back.
```
If the transcript came back thin, off-topic, or the twin refused
questions, say so explicitly at the top of the write-up and offer to
re-route to a different twin.
---
## Quick reference — when to ask vs. proceed
| Situation | Action |
|---|---|
| Discussion guide is concrete | Proceed |
| Discussion guide is vague ("ask about X") | **ASK** for the actual questions |
| Org is named or obvious | Proceed |
| Org is unclear | **ASK** from `list_organizations` |
| One twin clearly fits | Proceed |
| 2+ twins fit | **ASK** with top 2–3 candidates |
| Twin dodges one question | Follow up once, then move on |
| Twin dodges most questions | Stop, flag, offer to re-route |
august-pricing-check6.41 KB
---
name: august-pricing-check
description: >
Run a Van Westendorp-style pricing sensitivity study across August twins for
a product, plan, or feature. Ask each twin the four canonical price questions
(too cheap = quality suspect, bargain = good deal, expensive = would pause,
prohibitively expensive = wouldn't buy) and aggregate into the acceptable
price band plus the four inflection points (PMC, PME, OPP, IPP). Better than
eyeballing one twin's answer. Use whenever the user wants directional price
sensitivity, willingness-to-pay, or a price-band read from twins instead of
live shoppers. Triggers on: "price check with twins", "van westendorp",
"pricing sensitivity", "how much would twins pay", "what should I charge",
"price band", "/august-pricing-check".
---
# August Pricing Check
Van Westendorp-style pricing sensitivity across N=8–12 August twins. Returns
the acceptable price band and its four inflection points, with representative
quotes for each band. Tools live under the August MCP.
**What Van Westendorp gives you:**
- **PMC** (Point of Marginal Cheapness) — below this, quality is suspect
- **PME** (Point of Marginal Expensiveness) — above this, buyers walk
- **OPP** (Optimal Price Point) — resistance is balanced (too-cheap = too-expensive)
- **IPP** (Indifference Price Point) — where "bargain" = "expensive" (typical
actual paid price)
**When to use:** setting an anchor price, sanity-checking a plan tier, testing
a promo, comparing two SKUs' willingness-to-pay.
**When NOT to use:** you only have one twin available (use `/august-feedback`
instead), the product has no clear price yet (do concept work first), or you
need statistical significance (use a real survey — twins are directional).
---
## STEP 1 — Get the artifact and anchor
Before touching MCP, confirm:
- **What is being priced?** A specific product (name, SKU, description), a
subscription plan (features + billing cadence), a bundle, a feature add-on.
- **Anchor price** (optional but helpful) — the user's current price or
candidate range. If none, twins will float; that's fine but noisier.
- **Currency / market** — default USD unless the user specifies.
- **Audience org** — which brand's shoppers? If ambiguous, ASK.
If the artifact is thin ("what should I charge for a supplement?"), push back
once for a real description — twins price better with concrete material.
---
## STEP 2 — Pick the org
Call `list_organizations`. Match the audience:
- Consumer product / plan / bundle → the relevant **brand org**
- B2B / dashboard / Fermat platform pricing → **Fermat org** (dashboard-user
twins)
If ambiguous, ASK via a concise question with the top 2–3 orgs as options.
---
## STEP 3 — Pick twins (8–12) OR run as focus group
Call `list_twins` for the org. Aim for **8–12 twins** with variety across:
buying stage, budget tier, category affinity, demographic slice. Homogeneous
panels produce narrow bands; diverse panels surface the real spread.
**Two execution paths — pick one:**
- **Fan-out interviews** (default, more control): for each twin, call
`start_interview(twin_id)` and then `ask_question(interview_id)` with the
four VW questions bundled. Faster to parse, cleaner attribution.
- **Focus group** (use when the user wants cross-talk / disagreement signal):
use `list_focus_groups` to select an existing ready group, then
`start_focus_group` → optionally `add_focus_group_stimuli` for Figma URLs
→ `run_focus_group_round` with the artifact context and four VW questions
→ `end_focus_group` → `get_focus_group_results`. If no suitable ready group
exists, ask the user to configure one in August or use fan-out interviews.
If you can't find 8+ suitable twins in the org, note the sample size in the
output and continue — don't fabricate.
---
## STEP 4 — Ask the four Van Westendorp questions
For each twin, ask (adapt phrasing to the artifact):
1. **Too cheap** — "At what price would you think this is so cheap that you'd
doubt its quality?"
2. **Bargain** — "At what price would you think this is a bargain — a great
deal for the money?"
3. **Expensive** — "At what price would you think this is starting to get
expensive, so that it's not out of the question, but you'd have to think
about it?"
4. **Prohibitively expensive** — "At what price would you think this is so
expensive that you would not consider buying it?"
Always pass the full artifact context in the question payload. Ask for a
one-line rationale per price so you have quotable material.
---
## STEP 5 — Aggregate
Parse each twin's four dollar values into a table. Then compute:
- **PMC** — intersection of "too cheap" (descending cumulative) and
"not cheap = bargain-or-higher" (ascending cumulative). Below this,
more people say "too cheap" than "acceptable."
- **PME** — intersection of "expensive" (ascending cumulative) and "not
expensive" (descending cumulative). Above this, more people say "too
expensive" than "acceptable."
- **OPP** — intersection of "too cheap" and "prohibitively expensive"
cumulative curves. Balance point of extreme resistance.
- **IPP** — intersection of "bargain" and "expensive" cumulative curves.
Median indifference price.
The **acceptable band** is PMC → PME. OPP and IPP sit inside that band.
If a twin gave nonsense answers (all four the same, non-monotonic), drop
them from the aggregate but note it.
---
## STEP 6 — Return the output
Use this template. Don't dump raw transcripts.
```
## Pricing Check — {artifact name}
Org: {org} | Twins: N={count} | Anchor: {price or "none"}
### Acceptable band: ${PMC} – ${PME}
- OPP (optimal): ${OPP}
- IPP (typical paid): ${IPP}
### Price bands with rationale
- **Too cheap (< ${PMC})** — "{one representative twin quote}"
- **Bargain (${PMC} – ${IPP})** — "{quote}"
- **Acceptable / thinking about it (${IPP} – ${PME})** — "{quote}"
- **Prohibitive (> ${PME})** — "{quote}"
### Notable spread
{1–2 lines on twin variance — e.g. "budget-tier twins capped ${PME} $10 lower
than premium-tier twins"}
### Caveat
N={count} twins is directional, not statistically significant. Validate the
band with a real survey or A/B before locking a price.
### Source
Org: {org} | Twins: {twin_1}, {twin_2}, ... {twin_N}
```
If the bands overlap weirdly (e.g., PMC > PME, or IPP outside the band), say
so plainly — that's a signal the twins disagree wildly and the product may
not have a clear price point yet.
august-weekly-digest5.17 KB
---
name: august-weekly-digest
description: >
Build a Slack-ready weekly digest of all August research — interviews and
focus groups — run against a given org (or across all orgs) in the past 7
days. Surfaces top themes with supporting quotes, standout twin verbatims,
and unresolved questions to follow up on, so the team stays caught up on
customer signal without skimming raw transcripts. This workflow can be
scheduled to run every Monday morning. Triggers on: "weekly august digest", "august
weekly recap", "summarize this week's research", "what did we learn from
twins this week", "/august-weekly-digest".
---
# August Weekly Digest
Roll up every August interview transcript and focus-group result from the
past 7 days into a Slack-ready markdown digest, one section per org. All
tools live under the August MCP.
The output is **copy-paste-ready markdown**, not an auto-post. The user
pastes it into #research, #product, or their own channel.
---
## When to use
- User asks for a weekly recap of research / twin conversations.
- User is prepping for a Monday standup and wants the customer signal from
the prior week.
- A scheduled run fires every Monday morning.
## When NOT to use
- User wants deep synthesis of a *single* interview → use `/august-interview`.
- User wants live feedback on a new artifact → use `/august-feedback`.
- User wants a single focus-group readout → use `/august-focus-group-report`.
- Time window is not "past 7 days" — for arbitrary windows, ask the user
and pass the date range through instead of hardcoding.
---
## STEP 1 — Resolve the org(s)
The digest is org-scoped. Figure out which org(s) to summarize.
- If the user names a specific org ("weekly digest for GNC") → resolve via
`list_organizations` and use that one.
- If the user says "all my orgs" / "across everything" → call
`list_organizations` and iterate over every org they have access to.
- If ambiguous, default to **all orgs** rather than blocking — the digest is
cheap to skim and easy to trim. Note at the top which orgs were included.
---
## STEP 2 — Pull the past 7 days of activity per org
For each org, in parallel where possible:
1. `list_conversations` with `org_id` and filter to conversations whose
`created_at` (or equivalent timestamp) falls within the last 7 days.
2. `list_focus_groups` with `org_id` and filter to focus groups completed in
the last 7 days.
If both lists are empty for an org, produce the **empty-week fallback**
(see STEP 5) — do NOT skip the org silently.
---
## STEP 3 — Fetch content for each item
For each conversation ID from step 2: call `get_interview_transcript`.
For each focus group ID from step 2: call `get_focus_group_results`.
Batch these calls in parallel where the tool signatures allow. If any
individual fetch fails, note the item as "unavailable" in the digest
rather than failing the whole run.
Keep track of:
- twin name / persona (for quote attribution)
- artifact or topic evaluated
- the raw response body
---
## STEP 4 — Synthesize the per-org digest
For each org, cluster across all items pulled and produce:
- **3–5 top themes** — recurring reactions, objections, or observations that
showed up in more than one conversation. For each theme:
- one-sentence description of the theme
- one supporting verbatim quote (≤25 words), attributed to twin + org
- **3–5 standout quotes** — the punchiest single lines from the week that
don't necessarily belong to a theme but are worth circulating. Attribute
each.
- **Unresolved questions** — 2–4 things the research raised but didn't
answer, worth following up on next week.
**Hard budget: ≤400 words per org.** If it runs long, cut themes down to 3
and standout quotes down to 3. Slack readers scan; density beats completeness.
---
## STEP 5 — Format output
Return one markdown block per org, in this shape:
```
*August weekly digest — {Org name} — {date range}*
_{N interviews, M focus groups} from the past 7 days_
*Top themes*
1. *{Theme name}* — {one-line description}
> "{quote}" — {twin name}
2. …
*Standout quotes*
- > "{quote}" — {twin name}, on {topic}
- …
*Unresolved questions*
- {question 1}
- {question 2}
_Source: {N} interviews, {M} focus groups. Full transcripts in August._
```
If a run turned up nothing for an org, use the **empty-week fallback**:
```
*August weekly digest — {Org name} — {date range}*
No new interviews or focus groups this week. Consider spinning up a round
on {suggested topic based on prior weeks or open questions}.
```
At the top of the whole response, add a one-line summary: "Digest across N
orgs — copy-paste each block into Slack."
---
## Output rules
- **Do NOT auto-post to Slack.** This skill produces markdown; the user
posts it.
- **Do NOT include the raw transcript.** Only synthesized themes + quotes.
- **Every quote must be attributable** to a real twin from the actual
transcripts — never invent verbatims.
- **Keep it human.** Punchy quotes > paraphrases. If a twin said something
striking, use their words, not yours.
- If the user later asks "expand theme 2" or "what did Sarah say in full,"
re-fetch that specific transcript rather than reconstructing from memory.
feedback-loops5.5 KB
---
name: feedback-loops
description: >
Run an iterative feedback loop with August twins: put the same artifact
(copy, design, concept, variant set) in front of a panel of twins round
after round, applying the top suggestion from each round as a new variant,
until the responses converge on a preferred direction. Auto-invokes
/fix-question when a twin response is vague or hedged and re-asks that
twin with a sharper prompt. Meta-skill that orchestrates other August
skills so you don't have to manually kick each round. Triggers on: "run
a feedback loop", "iterate feedback with twins", "keep iterating until",
"loop twins on this", "converge on a variant", "/feedback-loops".
---
# Feedback Loops
Orchestrate an N-round twin panel: same question, same twins, evolving
artifact, until responses converge. Tools live under
the August MCP. This skill calls out to `/fix-question` for
sharpening prompts mid-loop.
> **Wall-clock note:** each round makes one MCP call per twin plus any
> rephrase retries. Expect **several minutes per round**. Let the user know
> up front so they don't ctrl-C mid-run.
---
## When to use
- User wants to converge on the best variant of copy / a headline / a
concept, not just get a one-shot reaction.
- User has an explicit stopping condition ("until 4 of 5 twins pick the
same variant", "until reactions stabilize").
- User is willing to wait multiple rounds.
## When NOT to use
- Single-round gut check → `/august-feedback`.
- Deep 1:1 discussion guide → `/august-interview`.
- Comparing pre-existing variants without iteration → `/august-concept-compare`.
---
## STEP 1 — Nail the inputs
Confirm you have:
- **Artifact** — the concrete copy, design description, concept, or
variant set being tested. If vague, ask.
- **Convergence criterion** — the explicit stopping rule. Common shapes:
- "≥ K of N twins pick the same variant"
- "responses stabilize (no new objections in a round)"
- "top objection from round 1 is resolved"
- **Org + twin panel** — which org and which twins are on the panel. If
the user hasn't picked, use `list_organizations` + `list_twins` and
propose a 3–5 twin panel matching the target audience.
**Hard cap: 4 rounds.** State this to the user at kickoff.
---
## STEP 2 — Round 1 (baseline)
For each twin in the panel:
1. Call `start_interview` with its `twin_id` and retain the returned
`interview_id` for every round.
2. Call `ask_question` with that `interview_id`, the question, and the
artifact in `design_context` when applicable.
3. Capture the answer directly; call `get_interview_transcript` with the
interview ID as `conversation_id` only when the full thread is needed.
Reuse the same interview IDs in later rounds so each twin retains context.
Record for each twin: preferred variant (if applicable), top suggestion,
top objection, one-line summary.
---
## STEP 3 — Detect weak responses and repair
After each round, scan every twin response for:
- Vagueness ("it's fine", "I guess it works")
- Hedging without content ("kind of", "maybe", "depends")
- Off-topic drift (twin answered a different question)
- Missing the concrete artifact (twin talked in generalities)
For any twin whose response fails this check:
1. Invoke `/fix-question` internally with the original question. The skill
returns a sharper rewrite.
2. Re-ask that twin using `ask_question` with the same `interview_id`.
3. Replace the weak response with the repaired one.
4. Cap re-asks at **1 per twin per round** — if it still comes back weak,
note "twin response remained thin" and move on.
---
## STEP 4 — Convergence check + next-round variant
After every round, evaluate:
- Does the panel meet the user's convergence criterion? → **STOP**, go to
STEP 5.
- Are we at round 4? → **STOP** with "hit hard cap without convergence".
- Otherwise → mint the next variant:
- Cluster the top suggestions from this round.
- Apply the highest-signal suggestion (most twins raised it, or the
strongest single suggestion) to produce a new variant of the artifact.
- Announce the change in the round trace ("Round 3 variant: shortened
headline per twin B's suggestion").
- Loop back to STEP 2 with the new variant.
Do NOT silently change more than one dimension per round — one variable
per round keeps the signal clean.
---
## STEP 5 — Return the trace
Output structure:
```
# Feedback loop — {artifact name}
*Panel:* {twin A}, {twin B}, … from {org}
*Convergence criterion:* {criterion}
*Rounds run:* {N} of 4
*Outcome:* {converged | hit cap | stopped early}
## Round-by-round
### Round 1 — baseline
- Variant: {description of artifact}
- Responses:
- {twin A}: {one-line takeaway}
- {twin B}: …
- Top suggestion applied to next round: {suggestion}
### Round 2 — {what changed}
…
## Final winner
{variant description}
## Convergence commentary
{2–4 sentences on how the panel moved across rounds — what shifted, what
stayed stable, whether the panel actually agreed or just fatigued}
## Suggested next move
{one line — ship it, run another loop with a fresh panel, escalate to a
focus group, etc.}
```
---
## Output rules
- Always show the round-by-round trace, not just the final winner — the
journey is the signal.
- Be honest about non-convergence. "Panel did not converge; twin B held
out on X" is more useful than a forced consensus.
- Never fabricate a round. If a twin didn't respond or the MCP call failed,
say so in the trace.
- If `/fix-question` had to be invoked, note it inline: "(re-asked with
sharpened prompt)".
fix-question4.88 KB
---
name: fix-question
description: >
Rewrite a loose or vague research question into a sharper, twin-friendly
version that produces a better response from an August twin (or any
human-like respondent). Standalone helper — invoke on its own to sharpen
a question before sending to August, or let other skills (notably
/feedback-loops) call it programmatically when a twin response comes back
too vague to use. Does NOT call any August MCP tools — pure text rewrite.
Triggers on: "rewrite this question", "make this question better",
"sharpen my ask", "fix this research question", "this question is vague",
"/fix-question".
---
# Fix Question
Take a user's research question (or any question destined for an August
twin) and return a sharpened version that will produce a more useful
response. This skill does not call any tools — it is a pure prompt
rewriter.
---
## When to use
- User pastes a question and asks to make it better.
- User is about to send a vague question to August and wants a rewrite first.
- Another skill (e.g. `/feedback-loops`) invokes this programmatically
because a twin response was too thin.
## When NOT to use
- The question is already sharp — say so, don't rewrite for the sake of
rewriting.
- User wants to actually run the question against a twin → use
`/august-feedback` or `/august-interview`.
---
## STEP 1 — Read the question and diagnose
Identify which of these weaknesses apply. A question can have several.
1. **Abstract reference** — refers to the artifact without naming it ("this",
"the design", "our idea"). Twins do better with concrete anchors.
2. **No decision framing** — doesn't say what the answer will inform, so
the twin can't calibrate depth or angle.
3. **Compound** — asks two or three things in one sentence. Twins tend to
answer only one, usually the last.
4. **Under-specified dimension** — "what do you think" style, no axis.
Better: what specifically — clarity, appeal, credibility, price,
emotion, next step?
5. **Leading** — presupposes an answer ("don't you think this is clearer?").
6. **Abstract detail-ask** — "what" instead of "what specifically" or
"give me an example of".
---
## STEP 2 — Apply the rewrite rules
Apply in order:
- **(a) Name the artifact concretely.** Replace "this" / "our thing" with a
short concrete label ("the new GNC PDP hero", "the two-line headline
variant B").
- **(b) State the decision the answer informs.** Add a clause like "so we
can decide whether to ship this" or "to prioritize between A and B".
- **(c) Constrain to one dimension per question.** If the ask is
compound, split into 2–3 focused questions — return them as a numbered
list.
- **(d) Ask for concrete detail.** Prefer "what specifically…" / "give me
one example of…" over bare "what".
- **(e) Strip leading language.** Replace "don't you think X is better"
with "how does X land — is it clearer, less clear, or the same?".
- **(f) Keep it under ~35 words per question.** Long prompts get skimmed.
If applying a rule would break the user's intent, don't. Preserve intent
first; sharpen second.
---
## STEP 3 — Return the rewrite
**Standalone invocation** (user is the caller):
```
*Original*
> {user's original question}
*Rewritten*
> {sharpened question — or numbered list if split}
*What changed*
{one-line explanation, e.g. "Named the artifact, split the compound ask
into two questions, added the decision context."}
```
**Programmatic invocation** (another skill is the caller — signaled by
the args being just the raw question with no framing, or by the invoking
skill setting a `terse: true` style flag):
Return **only** the rewritten question(s). No preamble, no explanation,
no bullets. If the rewrite is a single question, return one line. If it's
split, return a numbered list. This lets the caller drop the string
straight into an `ask_question` MCP call.
---
## STEP 4 — Edge cases
- **Question is already sharp.** Return the original unchanged, with a
one-line note: "Question is already well-formed — no rewrite needed."
- **Question is unanswerable by a twin.** (e.g. "does this align with
Josh's brief?"). Flag it: "Twins can't evaluate brief-alignment — offer
a gut-reaction rewrite instead?" and propose one.
- **Question is too broad to sharpen without more context.** Ask the user
what artifact / decision / audience the question is about — but only in
standalone mode. In programmatic mode, do your best with what's given
and note the ambiguity in a comment.
---
## Output rules
- Never invent context the user didn't provide. If they didn't say what
the artifact is, don't make up a name — ask, or leave a placeholder like
`{artifact name}`.
- Never over-rewrite. If two of the six rules apply, apply two — not all
six.
- In programmatic mode, keep output copy-paste-clean: no markdown, no
quotes around the question unless the caller expects them.
Technical details
- First seen
- Sep 30, 2026 · 22:02 UTC
- Last seen
- Oct 1, 2026 · 12:00 UTC
- Collection status
- Collected
plugin_asdk_app_6a552795016c8191b525649af7df1a78
Download listing JSON