atypica.AI (atypica.ai) platform help — an AI research-agent platform that simulates consumers: build AI Personas from a four-layer "subjective world model", run AI-moderated Deep Interviews and studies against 300K synthetic + ~10K interview-grounded "real person" agents, and get an insights report in minutes. Its public API is a team-provisioning + embedding API (Bearer team key; impersonation login URLs to embed studies in your app), NOT a studies-execution API — studies run in the UI. Use when setting up an atypica study or AI Persona, running a concept/pricing/message test against synthetic consumers, embedding atypica in your product via the impersonation API, provisioning team members via the API, reading the 85%-human-likeness or flywheel claims critically, or deciding whether a synthetic 'yes' is real demand. Do NOT use for comparing synthetic-research/persona/idea tools across the market (use /sales-idea-validation) or analyzing real-customer NPS/VoC feedback (use /sales-customer-feedback).
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
atypica.AI (atypica.ai) platform help — an AI research-agent platform that simulates consumers: build AI Personas from a four-layer "subjective world model", run AI-moderated Deep Interviews and studies against 300K synthetic + ~10K interview-grounded "real person" agents, and get an insights report in minutes. Its public API is a team-provisioning + embedding API (Bearer team key; impersonation login URLs to embed studies in your app), NOT a studies-execution API — studies run in the UI. Use when setting up an atypica study or AI Persona, running a concept/pricing/message test against synthetic consumers, embedding atypica in your product via the impersonation API, provisioning team members via the API, reading the 85%-human-likeness or flywheel claims critically, or deciding whether a synthetic 'yes' is real demand. Do NOT use for comparing synthetic-research/persona/idea tools across the market (use /sales-idea-validation) or analyzing real-customer NPS/VoC feedback (use /sales-customer-feedback).
argument-hint
[describe what you need help with in atypica]
license
MIT
version
1.0.0
tags
["sales","pre-launch","platform"]
atypica.AI Platform Help
atypica.AI (atypica.ai) is an AI research-agent platform that simulates
consumers. You build AI Personas on a four-layer "subjective world
model" (Expression → Story → Cognition → Behavior), run AI-moderated
interviews and studies against them, and get an insights report in minutes — a
synthetic-research alternative to a traditional agency or focus group. Its cluster
edge is that persona construction and a flywheel (validate synthetic personas
against real interviews) aim beyond plain LLM roleplay, plus ~10K
interview-grounded "real-person" agents alongside the 300K synthetic ones.
Its signal is directional, not demand: personas model existing/social/
interview/training data, so they skew agreeable, generic, and Western-biased
and can be confidently wrong. Treat any synthetic result as a hypothesis to
disconfirm with real behavior, never a green light.
Step 1 — Gather context
If references/learnings.md exists, read it first for accumulated platform knowledge.
Ask only what you can't infer:
What do you want from atypica?
A) Build a persona / run a study — set up an AI Persona or an AI Interview /
study, and read the insights report
B) Embed atypica in your own app (mint an impersonation login URL so a user
lands in a study with no separate login)
C) Provision team access via the API (list / create / invite members)
D) Interpret a study/report you already ran, or decide whether to trust it
What's the research question and who's the audience? A sharp objective + a
well-defined persona yields usable answers; a vague one yields generic filler.
Skip-ahead: if the user wants to compare synthetic-research/persona/idea tools
across the market, or the validate-before-building method, that's a
/sales-idea-validation question — route in Step 2.
Step 2 — Route or answer directly
If the user's question is about…
Route to
Comparing synthetic-research/persona/idea tools, or the validate-before-building method
/sales-idea-validation {question}
Running a demand test (smoke-test page, waitlist, pre-sale) after synthetic signal
A census-calibrated demographic panel with a free-tier API, or a documented studies REST API
/sales-ditto or /sales-syntheticusers{question}
When routing, give the exact command: "This is a {domain} question — run: /sales-idea-validation {original question}"
Otherwise, answer atypica-specific questions using Step 3.
Step 3 — atypica platform reference
Read references/platform-guide.md for the full reference — the three
capabilities + flywheel, the module → automation-surface table (what's API-
accessible vs UI-only), best-effort token/enterprise pricing, the data model (JSON
shapes for the team/embedding API), and quick-start recipes.
For raw endpoints, auth, JSON schemas, and error codes, read
references/atypica-api-reference.md.
Answer using only the relevant section — don't dump the full reference.
Step 4 — Actionable guidance
A synthetic "yes" is not demand — say so every time. Whatever the user asks,
make explicit that atypica's personas model existing/interview/training data, so
they run agreeable, generic, and Western-biased and can be confidently
wrong. Frame every study result as a hypothesis to disconfirm with a real
behavior test (smoke-test click, reply, pre-sale) — keep the objections,
segments, and language it surfaces (its real value), take the go/no-go from real
strangers, and route the real test to /sales-idea-validation.
The public API is a team + embedding API, not a studies API — never invent
study endpoints. There is no documented endpoint to create a persona or run a
study over HTTP; studies run in the app UI. Base https://atypica.ai/api,
auth Authorization: Bearer <team-scoped key>. The only endpoints are GET /team/members, POST /team/members/create, POST /team/members/invite, and
POST /team/members/:userId/impersonation. If the user asks to "run a study via
the API," correct the premise and offer the embedding path instead.
To automate/embed a study, use the impersonation login URL.POST /team/members/:userId/impersonation with callbackUrl: "/newstudy" returns a
loginUrl you redirect/iframe so the user lands authenticated on the new-study
screen with no separate atypica login. Honor expiryHours (default ~24) — mint
a fresh URL per session, don't cache. The user must be a team member first
(create or invite). Pull the exact request/response from the references.
Present the accuracy and flywheel claims as best-effort, cite the source. The
85% human-likeness, 100× cheaper, and validate-against-real-interviews
flywheel are vendor-reported; the four-layer "subjective world model" is a
real differentiator over pure-LLM roleplay but calibrates who the persona is,
not whether real buyers act. Say figures are best-effort and point to atypica.ai.
Present pricing as best-effort — it's token-metered. Freemium includes
1,000,000 free tokens; there's an enterprise SOC2 tier. The /pricing
page is JS-rendered — confirm current tiers on the live site before relying on them.
Sharpen the persona and objective — output tracks input. A vague audience or
question yields generic filler; recommend a specific objective and (where useful)
importing real interview transcripts to ground a private persona library
before running the study.
If you discover a gotcha or tip not in references/learnings.md, append it there with today's date.
Gotchas
Best-effort from research (2026-07) — pricing (token counts), the accuracy claims,
persona counts, and the API surface move; verify at atypica.ai and atypica.ai/docs/api.
Sycophancy / agreeableness bias. Personas skew favorable — they can approve
a concept or price real buyers would reject. Never read a positive synthetic
reaction as validation.
Simulated ≠ real behavior. The four-layer world model matches how a persona
is described, not the messy choices of a real person — and it can't surface a
genuinely new unmet need. The "expression-behavior gap" is a calibration signal,
not a fix for it.
Western/English and identity-flattening bias. Outputs skew Western/majority
and can flatten segments — be cautious generalizing across markets or narrow niches.
The API can't run studies. It's a team-provisioning + embedding API only.
Don't promise "run a study via the API" — automate by embedding via an
impersonation login URL; studies execute in the UI.
Impersonation URLs expire and are identity-scoped. They honor expiryHours
(default ~24) and require a real team member (403 if the email domain isn't
whitelisted for create). Mint per session; use invite for users on other domains.
Vendor accuracy figures. "85% human-like", "100× cheaper", the flywheel
validation — all vendor-reported. Cite them as claims, not proof.
Related skills
/sales-idea-validation — The tool-agnostic validate-before-building method + the full synthetic-research/persona/validator tool landscape (use this to actually decide build-or-not; a synthetic "yes" is not demand)
/sales-syntheticusers — Synthetic Users platform help (the pure-play interview-study peer with a documented public REST studies API [Python/TS SDKs, SSE streaming]; atypica's API is team/embedding-only)
/sales-ditto — Ditto platform help (census-calibrated demographic panels with a free-tier studies API + official Claude Code skills; atypica has richer persona construction but no studies API)
/sales-imario — iMario platform help (the reusable-persona canvas — a Synthetic Individual with cross-session memory across six jobs; atypica's flywheel validates personas against real interviews)
/sales-societies — Artificial Societies platform help (the self-serve network simulator that predicts how a post/message spreads; atypica asks isolated personas, Societies models influence between them)
/sales-customer-feedback — Real-customer NPS/CSAT/VoC strategy across tools (use once you have live customers; synthetic research is pre-launch only)
/sales-funnel — Build the smoke-test / fake-door landing page that turns a synthetic hypothesis into a real demand test
/sales-do — Not sure which skill to use? The router matches any sales objective to the right skill. Install: npx skills add sales-skills/sales --skill sales-do -a claude-code
Examples
Example 1: "atypica's synthetic consumers loved my concept — should I build?"
User says: "My atypica study says 85% human-like and the personas loved the idea. Green light?"
Skill does: Explains atypica's personas model existing/interview/training data
and skew agreeable, so an enthusiastic reaction is a directional signal, not
demand, and flags the 85% figure as a vendor claim (calibration, not
validity). Tells the user to mine the report for objections and language (the
real value) and take the go/no-go from a real behavior test — a smoke test or
pre-sale — routed via /sales-idea-validation.
Result: The founder keeps the objections, runs a real pre-sale before committing.
Example 2: "Run a persona and a study from my script via the API" (developer/automation)
User says: "How do I use the atypica API to create a persona and run a research study programmatically?"
Skill does: Corrects the premise — the public API is a team-provisioning +
embedding API, with no endpoint to create a persona or run a study; studies
run in the UI. Gives base https://atypica.ai/api + Bearer team key, and offers
the real path: embed atypica via POST /team/members/:userId/impersonation
(callbackUrl:"/newstudy") so the user lands in a study in your app. Points to
references/atypica-api-reference.md; refuses to invent study endpoints.
Result: The user embeds a study flow instead of chasing a nonexistent studies API.
Example 3: Embed a study in my product with no separate login (references/platform-guide.md)
User says: "I want users of my app to run an atypica study without logging into atypica separately."
Skill does: Points to the impersonation login endpoint — provision/invite
the user as a team member, then POST /team/members/{userId}/impersonation
with expiryHours + callbackUrl:"/newstudy" returns a loginUrl to redirect or
iframe; the user arrives authenticated on the new-study screen. Notes the token
expires (default ~24h, mint per session) and a 403 means the domain isn't
whitelisted (use invite). Pulls the Python snippet from the platform guide.
Result: The user ships an embedded, no-extra-login atypica study flow.
Troubleshooting
"The personas agreed with everything — is that real signal?"
Symptom: Study answers are uniformly positive and agreeable.
Cause: LLM-based personas exhibit sycophancy and model plausible agreement —
the four-layer world model fixes who they are, not the agreeableness bias.
Solution: Discard the "verdict," keep the objections and language surfaced,
and validate with real behavior (smoke test, pre-sale). Sharpen the objective
and persona (ground it in real interview transcripts) to cut generic agreement.
Cross-check via /sales-idea-validation.
"I can't find the API endpoint to launch a study"
Symptom: The docs only show /team/members* — no way to create a persona or run a study.
Cause: The public API is a team-provisioning + embedding API; studies are a
UI operation, not an HTTP endpoint.
Solution: Run studies in the app, or embed the flow with an impersonation
login URL (POST /team/members/:userId/impersonation, callbackUrl:"/newstudy").
Don't invent study endpoints. See references/atypica-api-reference.md.
"My create-member call returns 403 / the impersonation URL stopped working"
Symptom: POST /team/members/create returns 403, or a saved loginUrl no longer authenticates.
Cause: 403 = the email domain isn't whitelisted for the team; a dead login
URL = the impersonation token expired (expiryHours, default ~24).
Solution: For users on an unverified domain use POST /team/members/invite
(existing registered users) instead of create; mint a fresh impersonation URL
per session rather than caching it. See references/atypica-api-reference.md.