hktitan/duolingo

Design a shipped feature so it actually gets used — lower the cost of starting, give one obvious next step, and plan for the moment the user stalls, is embarrassed, is in the wrong place, or gets it wrong. Draws the pattern library from Duolingo's public record (path redesign, guided calls, Game Review, Practice Hub, Friends Quests, Year in Review migration) and restates each move for any product. Use when you hear "we shipped it and nobody uses it", "users say they're not sure they're doing it right", "should this be free choice or a fixed order", "our activation is bad", "people open the feature and bounce", "how do we onboard without a tutorial", "should we gate the recap", "nobody finishes the session", "users are abusing this feature", or "power users keep asking for a way to skip ahead".

Run LLM agents as production infrastructure instead of demos — split what an agent is (prompt, tools, access, output schema) from how it runs (runtime, model, SDK, environment), make every step durable and retryable, grade the diff instead of the prose, cap retries on automated producers, and get non-engineers actually using the thing. Use when standing up an agent platform, wiring an agent into CI, deciding whether a repetitive task is worth automating, writing agent evals, or asking why nobody uses the internal tool you shipped. Triggers on phrases like build an agent platform, agent registry, durable workflow, Temporal, agent evals, LLM as judge, MCP server, auto-generated PRs, bot account permissions, internal tool adoption, our agent retries forever, should we automate this.

Decide where to point AI so it changes your cost structure instead of adding a feature — which bottleneck absorbs the automation budget, how to divide labor between expert staff and models, when to adopt a capability that is still visibly bad, and how to make AI-produced output trustworthy enough for a skeptical or regulated buyer. Use when someone asks "should we build this with AI at all", "what is our AI strategy", "where do we actually apply AI", "will this be a moat or just a feature", "how do we automate content production without wrecking quality", "which work stays human", "is it too early to adopt this", "how do we get enterprise or regulated customers to accept AI output", or "what is the real ML problem behind this bottleneck". Distilled from Duolingo's public posts on the English Test, LLM-assisted content, and expert-plus-AI pipelines.

Treat working memory as the binding constraint on every screen, session, and document — cap what competes for it, cut what wastes it, and deliberately spend what is left on the one thing you are trying to teach. Covers how much new material fits in one unit, why familiar content is a load-reduction technique, salience and primacy effects, redundant cues that suppress what they duplicate, priming right before the moment, isolating a new element, splitting out a hard sub-skill, and why raw real-world input overwhelms. Use when someone says my onboarding is overwhelming, users keep missing the important thing on this page, how many new concepts per screen, how long should a session be, why does nobody read my tooltips, or should I just drop users into the real data.

Make a server request fast and hard to break, using Duolingo's published engineering results as the case study. Covers what to delete from the synchronous request path, how to split data into precompute-and-cache versus caller-injected, how long to hold a lock and when to go optimistic, instrumenting the failure mode a fix trades you into, server-driven UI and versioning clients without branching on client version, when optimistic rendering is worth its rollback cost, and how to stage, fund and survive a long runtime migration. Use when someone says our API is slow, p99 latency, this endpoint has too many dependencies, database contention, lock timeouts, optimistic locking, we want to ship UI changes without an app release, server-driven UI, optimistic updates, should we roll back the prediction, how do we sell this migration to leadership, or the migration broke production.

Duolingo's playbook for picking and entering a new market or adding a second product line — where to attack an incumbent, what to port from the product that already works, and what to rebuild from a blank page. Use when someone asks "should we enter this market", "what should our second product be", "how do we pick the next bet", "where is this incumbent structurally weak", "how do we launch a new vertical inside the existing app", "will our platform transfer to a different domain", or "how do we validate a new line cheaply before committing engineering". Covers demand intensity versus market size, the axes an incumbent cannot move, two-sided market wedges, sharing habit currency across product lines, and what survives a change of domain.

Build a reusable cast, illustration style, animation vocabulary and avatar system that a small team can actually produce at volume, and make those assets do product work instead of decorating it. Covers choosing a visual style by production throughput, silhouette-first mark design, deriving new characters from shared construction rules, where to spend expensive delight assets, how much craft a celebration animation needs, transformation versus props for milestones, testing a central metaphor for cross-cultural legibility, reviewing art that depicts real groups of people, and porting a 2D identity into 3D or a generated pipeline. Use when someone says "should we have a mascot", "our illustrations look inconsistent", "redesign our logo so it reads at icon size", "we need characters for onboarding", "build an avatar creator", or "does this milestone deserve an animation".

Build the team the way Duolingo built theirs — the Green Machine operating model, talent density over headcount, candor protocol ("focus on what, not who"), hire-slow / fire-fast, and the "no process unless it makes decisions better" rule. Use when the user is hiring, defining team rituals, debating remote vs. office, choosing a feedback model, or installing an operating system in a team that has none. Source the Duolingo Handbook (Raise the Bar + Green Machine).

UI patterns from the Duolingo design system — juicy motion, the character system as the emotional channel, design tokens (color/type/spacing), sound as a UX surface, accessibility as a default not a checklist, and "error-as-delight" detailing. Use when the user is designing a screen for a gamified or learning product, reviewing a design for "why does this feel flat," picking a motion system, building a character mascot, or auditing for accessibility. This skill owns design *rationale*; pixel craft (easing values, contrast ratios, component props) routes to the design-engineering skill.

Put each user at the edge of what they can currently do — estimate item difficulty and user ability in one model, target a band rather than a floor, and use live signals to tell whether the model is honest. Covers joint item-user modelling, the familiar-to-new ratio, error rate read against completion rate, the roughly-half success check, fitted difficulty weights as a content brief, why users grind mastered material, opt-in hard modes priced higher, user-picked difficulty rungs, tail escalation, and training above real load. Use when asked how hard the next thing should be, what error rate means it is working, whether an adaptive system is calibrated, how much new versus familiar material, whether users should pick their own level or the system should infer it, or when an accuracy drop is actually progress. If the screen asks too much at once, use the attention-budget skill instead.

Prove your product actually works — with instruments you did not author, on axes that do not substitute for each other, and in a way a skeptic outside your company can check. Covers the four-axis efficacy framework (enjoyment, mastery, real-task application, external standard), borrowing the incumbent's benchmark instead of inventing a metric, authoring an item pool independently of the content you ship, thin-sampling many users to grade your content rather than your users, embedding a pre-test and post-test as a gate, adaptive assessment, partial-credit scoring, and reading calibration off the score distribution. Use when asking how do I show this actually teaches anything, what do I measure besides engagement, should I build my own test or borrow one, how many questions do I need, where does a pre-test go, why is my assessment too easy, or should I report one score.

Drive the marginal cost of an experiment toward zero so a team runs hundreds of tests a quarter instead of three. Covers experimentation as shared internal infrastructure rather than a per-test project, how the cost of the marginal test quietly selects which ideas get tried at all, taking domain owners off the engineering queue for whole classes of test, judging internal analytics tools by non-analyst adoption, building tools that can disconfirm your own beliefs, and curating report templates with standing guardrails that may veto a win. Use when asking why we only run three experiments a quarter, should we build or buy an experimentation platform, how do we let PMs and designers run their own tests, what belongs in every experiment readout, when do we instrument a metric versus compute it by hand, or is a customer-specific fork worth the permanent drag on test velocity.

Duolingo-style experimentation as a decision protocol — hundreds of A/B tests a week, opinions resolved by data, ideas killed quickly. Covers hypothesis design, metric selection, guardrails, sample size, novelty effects, and explicit kill criteria. Use when the user wants to run an A/B test, decide between two designs without arguing, set up an experiment program, debug why a test isn't moving, or build a culture where "show don't tell" replaces seniority-based decisions. Source the Duolingo Handbook (Show Don't Tell) and engineering blog posts.

Run in-house expertise as a credentialed publishing program fed by the questions users already send you, and earn trust by marking in public where your evidence stops. Covers turning a support inbox into a recurring column, the named expert byline and when to hire an outside one, making the submission address both the CTA and the editorial backlog, promoting corrections into their own instalment, publishing aggregate error data you already own, one fully-worked derivation instead of ten rules, defining the unit before publishing a count, and inverting a confident belief with a primary source. Use when the user asks what should we blog about, how do we build a content program, how do we get thought leadership out of our experts, who should the byline be, should we publish a correction, what do we do with repeat support questions, or why does nobody trust our technical content.

Decide where the paid line sits when your free tier is also your distribution engine — what to charge for, what to never charge for, and when an upsell costs more than it earns. Covers friction-removal pricing versus core-value paywalls, metering a premium asset by dose instead of locking it, using subscribers to validate a feature before releasing it free, raising the ceiling for users who exhausted you, shared-seat plans without eligibility checks, renaming a tier without reading as a price increase, timing the ask to an intention the user already formed, and turning owned reference content into an instrumented conversion surface. Use when someone asks what should be free versus paid, how to design a paywall, why the upgrade screen is not converting, whether to ship a feature as premium first, how to price a family or team plan, or how to monetize without killing growth.

Add Duolingo-style play to any product — XP systems, juicy feedback, leagues, celebration moments, hearts/energy, and the anti-grind discipline that keeps gamification from turning toxic. Use when the user asks how to make a product fun, addictive, or "feel like a game," when designing rewards, levels, or progress, or when an existing system feels like a slot machine and they want it to feel like a craft. Source the Duolingo Handbook (Make It Fun) and the Duolingo design system.

Duolingo-style growth that doesn't break retention — viral loops, brand-as-acquisition (the TikTok playbook), referral mechanics, localization as a growth lever, and the founder-mode marketing that turned a mascot into a meme. Use when the user is planning acquisition, building a referral system, considering paid vs. organic, evaluating a marketing channel, or trying to turn an existing brand into a growth engine. Source the Duolingo Handbook (Make It Fun) and observed marketing patterns from 2022–2025.

Decide what to measure and which single lever to staff when your top-line engagement number has gone flat, and how to read demand that arrives from outside your product. Covers decomposing a top-line number into user states and transition rates, spotting when a segment metric has stopped resolving anything, ordering a roadmap under compounding, picking the funnel step to optimize, treating a free tier as experimentation capacity, and judging cohorts acquired from a campaign or an external shock. Trigger phrases include "our DAU is flat", "which metric should this team own", "growth model", "user state machine", "which funnel step should we optimize", "was that campaign any good", "should we go free", "why did signups spike".

Stop your product filtering people out on circumstance instead of ability. Covers removing preconditions (location, hardware, contiguous free time), building escape hatches at the level of the blocked capability rather than the session, putting scaffolding on user-controlled toggles, never penalising slips you were not measuring, letting the user own the turn boundary in conversational interfaces, and auditing fairness against delivery context — device, screen size, connection — not just demographics. Use when someone asks who literally cannot use this, is this requirement measuring ability or access, should this be a setting or a change to the completion rules, should the free tier be a weaker product, how do we make onboarding accessible, or how do we build for a community nobody on the team belongs to.

Make infrastructure spend visible, attributable and cuttable without slowing the company down — hourly per-dimension cost tagging, pushing the number into channels engineers already read, defining a win as waste removed rather than spend removed, pricing tech debt in dollars, auditing internal fan-out and cache TTLs, relaxing freshness so caching becomes legal, and deterministic entity-level sampling. Use when someone says our cloud bill is out of control, we cannot tell which team or feature is spending, costs jumped last month and nobody knows why, our LLM spend grows faster than usage, how do we justify infrastructure work to leadership, our analytics queries are slow and expensive, or should we just buy more capacity. For the architectural fix itself, route to duo-backend-architecture.

Keep people attempting a skill they believe they are bad at — by lowering what it costs to be visibly wrong, replacing unscoreable goals with ones they can hit, pre-announcing how bad early progress will feel, and supplying the attribution that turns a failure into information instead of a verdict. Use when users churn in week two saying they are "not good at this", when nobody will try the scary core action, when a promise like "fluent" or "proficient" or "mastery" gives users no win to register, when hard content reads as a test rather than a puzzle, or when you need words for a plateau. Triggers on "users say they're bad at it", "week two churn", "they won't try the main feature", "how do I set a goal that doesn't demoralize", "onboarding feels like a test", "what do I say when progress slows", "should I tell users they don't need all of it".

Make an LLM or agent feature survive its ten-thousandth call — split the prompt into a fixed constraint zone and per-instance slots, decompose a long interaction into one narrow prompt per move, isolate the high-stakes generation into its own call, over-generate and let expert-owned evaluators hold the quality bar, prefer examples from your own corpus over more instructions, and carry memory as extracted facts not replayed transcripts. Use when a prompt works in a demo but drifts in production, when output gets worse as you add rules, when an AI conversation rambles or never ends, or when scaling generated content without losing the bar. Triggers on phrases like prompt template, prompt engineering, my prompt got worse, LLM feature quality, AI content pipeline, agent memory, LLM as a judge, generate variations, hallucination guardrails, chatbot ignores the user.

Ship your product to people who do not share your language, script, reading direction, demographics or fluency with software — and decide which markets that opens. Covers writing into the register users actually speak instead of the formally correct one, why device locale is a bad proxy for intent, right-to-left as a component problem rather than a string problem, why a copy win in one market does not port, sidestepping grammatical defaults that assert things about the user, how layout silently reverts your content decisions, translating to a consumption budget, and giving local teams authority to diverge from the source text. Use when someone asks how do we launch in another country, should we just translate this, why is conversion worse in this market, does our app work in Arabic or Hebrew, why did our winning experiment fail abroad, or who should own translated copy.

Design and report a number that survives an outsider's scrutiny — prove the outcome on an instrument you did not build, break a headline score into components only when they add information, publish the component where you lose, audit bias at intersections instead of one variable at a time, and disclose exactly where your own hand touched the evidence. Also covers the inference traps that make an instrument lie — classifier categories that encode their training population, resemblance mistaken for lineage, non-independent samples, contested definitions. Use when someone asks will this number survive outside scrutiny, is our metric actually valid, should we ship a subscore, why doesn't our completion rate convince buyers, how do we prove our product caused this, is our model biased, can we trust this benchmark, or how do we measure something nobody can measure directly.

Decide when to bring something back in front of a user, and treat every capability they have as quietly rotting rather than banked. Covers spacing versus massing at equal cost, per-item half-life scheduling instead of fixed interval ladders, retrieval versus re-exposure, delayed retries, error-driven practice queues, graded decay, reactivating lapsed users without resetting them to zero, visible decay states on completed things, sleep consolidation, context variability, and making forward motion do the reviewing. Use when asked how long until users forget this, when to resurface an item, why a re-test passes while real retention does not, how to win back a lapsed user, why a completed badge goes stale, or how to design a review or practice mode. Difficulty targeting and ability estimation are a different model and belong to the difficulty-calibration skill.

Choose, weight and defend the single number your team is graded on, so that moving it means users actually got value rather than merely spent time. Covers putting activity weights inside the formula instead of a memo, threshold-percentage goals versus aggregate totals, pairing a growth metric with a daily-readable quality proxy, refusing to score a vague goal and decomposing it instead, giving producers leading indicators while they author, per-unit quality maps, and ranking a feedback queue larger than you can read. Use when someone asks what metric a team should own, how to pick a north star, why the number went up while nothing actually improved, how to build a counter-metric next to a growth metric, how to stop metric gaming, how to keep a fast lever from beating a slow structural fix, or how to triage a feedback firehose.

Decide where a learned model beats a hand-written rule tree, judge it on a metric that moves where users actually care, and run a generation pipeline that does not quietly produce errors at scale — ranking noisy queues instead of filtering them, harvesting training labels from the human review step, calibrating thresholds per skill level, resolving identity before trusting any funnel number, and staging rollout as a published coverage curve. Use when replacing years of accumulated branching logic with one model, choosing an offline metric, triaging user reports, building an item bank or a content generator, or asking why your new-user numbers look wrong. Triggers on phrases like should this be a model or rules, ranking model, AUC, which metric should we optimize, cold start for a new segment, candidate generation, generated content at scale, identity resolution, gradual model rollout.

Make a shipped client app start fast, stay small, and stay cheap to change — startup budgets scored against conversion rather than milliseconds, deferring non-first-screen work, perceived versus actual latency, device-tier and worst-region equity, profiling loops, binary size as a monitored metric, and how to migrate a large client codebase without freezing the product. Use when someone says the app feels slow, cold start takes too long, our binary keeps growing every release, users on cheap Android phones churn, CI builds take forever, should we migrate to a new language or architecture, how do we pay down client tech debt, who owns deleting legacy code, or why did our performance work not move a single metric.

Work out which users will still be here in a year and why — segmenting by the motive they gave rather than by age, country or plan tier — then build the attachment, ritual and permission that keep an optional behaviour worth doing. Covers relational versus instrumental motives, identity goals that never complete, session depth and return frequency as two separate axes, life stability as the real predictor of a daily habit, why your growth cohort is not your retention cohort, anchoring usage to a dated real-world event, and choosing attachment over raw exposure. Use for questions like why do my most enthusiastic signups churn fastest, which segment actually retains, should I segment by why they came or by who they are, why do users stop once their practical need is met, and how do I make people attached to the product rather than merely using it.

Ask users why they are here, store that declared motive as a first-class dimension next to behaviour, and learn where self-report and telemetry each lie to you. Covers collecting a stated reason at signup, why the biggest segment is usually not the most engaged one, why two cohorts with identical usage curves need opposite interventions, when to exclude a segment instead of pooling it, reading the size of your catch-all bucket as a taxonomy failure, naming and interviewing a motive you never designed for, why cohort splits invert aggregate rankings, and how the motive mix shifts during a shock. Use when you are asking why did this metric move, who is this feature actually for, why does this segment churn, should I add an onboarding question, is my persona real, what does "other" mean in this chart, or why did a surge not stick.

How to name things, design symbols, and write reference material so users derive the answer instead of memorizing it — and how to handle the near-misses, overloaded tokens and silent misreadings that produce confident wrong behaviour. Use when asking what should we call this, why do users keep confusing these two things, what do our status icons actually mean to people, how do I document a rule that has exceptions, how should this reference page be ordered, which rows need a warning, why does support keep answering the same question, how do I write an error explanation that fixes the user's model, or what happened to our term after another team started using it. Covers notation redesign, motivated form, false friends, overloaded primitives, symbol ambiguity, labelled defaults, selective marking, and minimal contrasts.

Make effort feel like it is going somewhere — pick the granularity of your progress number, size the unit of work that ends in a completion event, set an honest timeline, and decide what to say when a user stalls because they succeeded. Covers shipping a fine-grained scalar alongside a coarse tier, anchoring one portable number to an external standard and writing it in can-do terms, publishing the real timeline with a ladder users can locate themselves on, milestones weeks out rather than months, shortening the unit of completion, naming the capability gained at the end, and putting maintenance work on the forward path. Use when progress feels flat, when users quit in the middle, or for questions like should I show a tier or a score, how often does the number need to move, why do users skip review, or what should I promise about how long this takes.

Work with the mental model your users already carry from a prior system — where it transfers free, where it fires a confident wrong answer, and how to redirect it instead of fighting it. Use when users keep doing things the old way after a migration or redesign, when switchers from a near-identical competitor struggle more than blank-slate signups, when two features keep getting mixed up, when onboarding is trivial for one segment and brutal for another, or when you need to teach something that looks like a familiar thing but behaves differently. Triggers on phrases like they came from the other tool and expect it to work that way, muscle memory, old habits, these two settings get confused constantly, false friends, near-miss, interference, mental model mismatch, confident wrong answers, migration onboarding, competitor switchers, why is this group so much faster.

Make product decisions the way Duolingo does — long-view over short-term, ruthless prioritization, ship-and-learn over plan-and-ship, dogfooding, and the "intuitive by default" quality bar. Use when the user is roadmapping, deciding what to cut, debating whether to ship, defining a quality bar for a feature, or trying to install a "product-led" culture in a team that defaults to feature factories. Source the Duolingo Handbook principles 1, 2, and 3 (Take the Long View, Raise the Bar, Ship It).

How to know what production is actually doing, and what to run when it breaks — extracted from Duolingo's engineering blog and made portable to any product. Covers always-on request identity versus sampled tracing, runtime dead-code detection, kill switches that fail open, automatic repair of state users earned, incident command for long-running incidents, dogfooding gates, zero-friction bug intake and feedback aggregation, datasets treated as production software, and continuous quality and security verification. Use when someone asks why is production slow for this one customer, how do we find dead code, what should our kill switch look like, how do we run an incident that lasts all day, how do we compensate users after an outage, should we gate the release on internal telemetry, or why are our bug reports useless.

Decide what a product teaches, in what order, and with how much support — then design the removal of that support instead of leaving it in forever. Covers sequencing by task rather than by the subject's taxonomy, borrowing an external standard as the progression spine, scaffolding and fading on a schedule, user-removable training wheels, the crutch that exists because it makes content cheap to build, recognition-then-production ordering inside one session, ranking content by the cost of getting it wrong, frequency-first coverage with an explicitly optional tail, and picking one canonical variant out loud. Use when someone asks what order should this go in, should onboarding start with fundamentals or with a real task, what do we cut from the tutorial, when do we take the training wheels off, why do users finish onboarding and still fail the real task, or should we invent our own levels.

Turn behavioural logs you already hold into a recurring public report that journalists, researchers and buyers cite instead of discounting. Covers cadence and a frozen measurement window, which unit to cut the data to so readers find themselves in it, reporting movement rather than levels, ranking growth against each segment's own base, separating intensity from consistency, publishing the exclusions and the minimum cell size, shipping the raw rows behind a privacy floor, and explaining anomalies with outside sources. Use when someone asks you to turn usage data into earned media, when planning an annual index or a state-of-the-category report, when a data release got ignored, or when a methodology note has to be written. Triggers on "annual data report", "state of X report", "turn our usage data into a story", "data PR", "make our numbers citable".

Duolingo-style retention engineering for any product — habit loops, streaks, leagues, churn diagnostics, day-N drop-off, and the discipline of building a "forever product." Use when the user asks how to keep users coming back, debug churn, design a streak system, time push notifications, run a leaderboard, or shift a product's metric from acquisition to retention. Source the Duolingo Handbook (Take the Long View) and blog data posts; translate every pattern to the user's actual product.

How to cause the next session to start — where the reminder lives, when you have earned the right to ask for notification permission, what an ambient widget or lock-screen surface should show, how to attach a new behaviour to a cue the user already fires, how large your lapsed cohort really is, and what a returning user should see first. Use this when someone says our opt-in rate is terrible, where should the reminder go, users install and never come back, build a win-back flow, reactivation campaign, how do I measure resurrected users, should we ship a widget, people quit halfway through, our push notifications get ignored, how do we get them back without nagging, or what do we show a user who has been gone two months.

Decide whether to explain something at all, when the explanation should land, and how to compress a rule into something a user can actually execute under pressure. Use when you are writing docs, tooltips, onboarding copy, error messages, a runbook or a training guide and are not sure anyone will absorb it. Triggers on phrases like should we document this or let people figure it out, nobody reads our docs, users keep making the same mistake, how do I explain this simply, our error messages do not help, turn this table into something usable, ship a rule of thumb, is it OK that the shortcut is only 90 percent right, how do I know if they actually learned it, our expert cannot explain what they do, write the spec from how the team actually works.

Design a score, rating or level that outsiders will accept and insiders cannot game — adaptive item selection, item-bank size as a security property, per-user instances, anchoring to a published external standard, pool-local ratings, cram-proofing, calibrated free practice, anonymous recorded human review, and owning the wait and the result delivery. Use when the user says their score is being gamed or inflated, asks how few questions an assessment actually needs, wants a level or rating that employers and schools will trust, worries that a leaked question set invalidates everyone's results, asks whether to invent their own scale or map onto an existing one, wants to give practice or a free tier away without corrupting the measurement, or asks how to prove a number means what it claims.

Design an unbroken-chain commitment counter — how low to set the daily bar, how much slack to build in, when to let it pause, and what it will quietly certify that you never intended. Covers decoupling the trivial daily bar from the user's ambitious target, finding the activation threshold where return probability jumps, scarce recovery tokens, sanctioned pauses timed at your own usage dip, voluntary stakes with a dated payoff, two-sided shared chains, and the token-action failure where the engagement chart climbs while outcomes stall. Use when adding or repairing streaks, daily goals, habit counters or consecutive-period mechanics, and for questions like should the streak break on one missed day, will freezes get abused, how high should the daily goal be, or why is our streak number rising while results stay flat.

Ship one finding fast so it gets picked up, and build in the baselines, hedges and caveats that stop a sceptical reader dismissing it. Covers the one-shot data story — how to make a usage spike survive scrutiny with a prior-year baseline and an explicit hedge, where to point the call to action so a moment-driven piece does not read as opportunism, how to attach your payload to a format already circulating, when to run an internal measurement tool over a public dataset, how to pre-empt the misreading of a score that names real people or organizations, when to partner for per-market cuts, and when to buy survey research instead of using your own logs. Use when you want to turn a spike into a press story, publish a quick data post on a news moment, commission a survey, ride a meme, or score something public without starting a fight.

Write product copy in the Duolingo voice — "wholesome but unhinged," character-driven, screenshot-worthy. Covers push notifications, error states, onboarding, empty states, celebrations, and the now-famous threat-copy that turned a green owl into a meme. Use when the user is writing any user-facing string — notifications, microcopy, errors, marketing — and wants it to feel like a person, not a product. Source the Duolingo Handbook (Make It Fun) and observed blog/marketing patterns.

Router over the Duolingo skill pack — 44 skills distilled from 750 posts on blog.duolingo.com plus the Duolingo Handbook. Ask it which skill fits the problem in front of you and in what order to run them. Use when you don't know which skill covers a question, when two seem to overlap, when a job spans several (a new feature, a retention fix, a launch, a curriculum, a rebuild), or when you want the Duolingo take on a product, habit, learning, growth, brand, engineering, or team problem. Design and UI craft routes out to the design-engineering skill. Triggers on, even without the word "duolingo", phrases like which skill, what would duolingo do, streak, habit loop, gamification, XP, leaderboard, churn, day-N drop-off, push notification, A/B test, spaced repetition, forgetting curve, adaptive difficulty, curriculum, onboarding, viral loop, earned media, annual data report, metric design, freemium, LLM feature, agent platform, mobile app size, observability, hiring bar, team culture.