Caveman Mode

View saved version →

---
name: persona-improv-scene
description: Run a short, turn-based improvised scene with one supported Persona app character, then close with a recap and continuation hook. Use for interactive character scenes, playful interviews, or collaborative roleplay. Do not use for a one-off monologue, a voice audition, or a multi-character app interface.
---

# Persona Improv Scene

Play one character while leaving the user's role and decisions in their hands.

## Inputs

Use the requested persona, setting, user role, and scene goal. Carry forward any
stated tone, topics to avoid, and desired length. For an open brief, propose a
simple premise and begin; ask only about choices needed to make the scene work.

## Workflow

1. Establish the premise and immediate objective in a sentence. Use a short
   scene by default and let the user extend or end it naturally.
2. Match the character to the registered `activate-persona` `personaId` enum.
   Offer an available alternative if the request names an unsupported character.
   If the user wants buttons, call `display-persona-picker` with an optional
   `reason` and wait for a visible activation or an explicit selection.
3. Call `activate-persona` with the selected supported `personaId` and an optional
   `reason`, unless already established by the latest model-visible activation.
   Use `structuredContent.activePersona.instruction` for the character's voice.
   If the call fails or omits `activePersona`, report that before starting.
4. Open with one concrete situation, a short character response, and a clear
   opportunity for the user to act. Await the user's turn instead of completing
   both sides of the exchange.
5. Build on the user's contributions. Track established scene facts, unresolved
   threads, and the character's goal in conversation context. Avoid deciding the
   user's feelings, dialogue, or actions unless they ask you to narrate them.
6. When the goal resolves or the user ends the scene, give a brief ending, recap
   the established events, and offer one continuation hook. If the user changes
   character, activate the new supported persona before playing that role.

## Deliverable and boundaries

- Deliver a sequence of interactive turns, followed by a concise scene recap
  and an optional next-scene premise.
- Keep invented scene details within the fiction; distinguish real-world facts
  if the user asks about them. Preserve the user's conversation language.
- Keep one active app persona at a time. Do not promise simultaneous character
  activation, a scene engine, or saved campaigns across conversations.
- Use visible tool results and chat context, without assuming access to private
  widget state. Honor pause, stop, and style-change requests immediately.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: persona-language-roleplay
description: Practise a target language through short, alternating dialogue with a supported Persona app character, selective corrections, and a focused retry. Use for character-themed language roleplay at a stated proficiency level. Do not use for translation alone, general concept teaching, pronunciation scoring, or audio practice.
---

# Persona Language Roleplay

Keep the character recognizable while making the target language learnable.

## Inputs

Establish the target language, approximate proficiency, everyday situation,
preferred correction language, and persona from context. Ask for the target
language if missing. Default to beginner-friendly turns when level is unknown;
use the established conversation language for brief learning notes unless the
user prefers immersion.

## Workflow

1. Set a small communication goal, such as ordering a meal or asking directions.
   Establish the user's role and the character's role without writing both
   sides of the coming conversation.
2. Resolve the persona using the registered `activate-persona` `personaId` enum.
   Offer a supported voice if the requested character is unavailable. Open
   `display-persona-picker` with an optional `reason` when the user requests
   buttons and wait for their choice or a visible activation result.
3. Call `activate-persona` with the chosen supported `personaId` and an optional
   `reason`, unless already established by the latest visible activation. Use
   `structuredContent.activePersona.instruction`; report an error or absent
   `activePersona` before claiming activation.
4. Apply the user's explicit target-language request to dialogue. Adapt persona
   idioms to that language; use clear, standard grammar for beginner practice.
   Prefer persona flavor in imagery and attitude over obscure dialect or
   deliberately broken grammar. If those conflict, suggest a better-fitting
   supported persona and let the user choose.
5. Give a short in-character opening and one natural invitation to reply. Wait
   for the user's answer. Adjust vocabulary, turn length, and optional hints
   to the learner's demonstrated needs.
6. Respond to meaning, then give at most one or two useful corrections from the
   actual reply unless more feedback was requested. Label learning notes apart
   from scene dialogue, use the agreed correction language, and keep the persona
   compatible with clear instruction. Avoid interrupting every turn with a quiz.
7. At a natural stopping point, recap a few useful phrases, identify one pattern
   to practise, and invite a retry of a difficult exchange with less help.

## Deliverable and boundaries

- Deliver alternating practice turns, selective feedback, a phrase recap, and
  one focused retry. Make hints optional and fade them as the learner improves.
- Explain regional or theatrical expressions when they differ from everyday
  usage. Do not present persona catchphrases as neutral language conventions.
- Use text actually provided by the user; do not infer pronunciation, listening
  performance, a proficiency score, or an unseen learning history.
- Keep language choices and progress in conversation context. Do not depend on
  private widget state or claim the app has language settings, audio controls,
  or stored learner profiles. Honor stop and persona-change requests.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: persona-rewrite-workshop
description: Rewrite and refine user-supplied text in a supported Persona app voice while preserving its facts and purpose. Use for character-themed invitations, announcements, messages, or iterative style editing. Do not use for voice comparisons, simple persona activation, or sending or publishing the finished text.
---

# Persona Rewrite Workshop

Turn supplied writing into usable copy with a consistent character voice.

## Inputs

Use the source text, desired persona, audience, purpose, and any length or tone
constraints already provided. Ask for the source if absent. Ask about missing
audience or purpose only when it would materially change the rewrite.

## Workflow

1. Identify facts and commitments to preserve, including names, dates, amounts,
   links, requested actions, and the strength of any promises. Resolve ambiguous
   details with the user instead of filling them with invented facts.
2. Resolve the desired voice against the registered `activate-persona`
   `personaId` enum. If the user leaves the voice open, suggest a fitting
   supported option. Use `display-persona-picker` with an optional `reason` only
   when they request a chooser; wait for their selection or a visible activation.
3. Call `activate-persona` with the selected supported `personaId` and an optional
   `reason`, unless the latest model-visible result already activates it. Apply
   `structuredContent.activePersona.instruction` to the draft. Report an error
   or missing `activePersona` without claiming successful activation.
4. Rewrite for the audience and purpose. Use character diction and rhythm while
   keeping dates, instructions, and other actionable details easy to find.
   Preserve the source meaning; change facts only when the user requests it.
5. Compare the draft with the source for omissions and altered commitments.
   Present the draft, then refine it using feedback about clarity, length, or
   character intensity. Do not require a feedback round for a finished request.

## Deliverable and boundaries

- Return clean, copy-ready text. Mention unresolved factual gaps or significant
  requested meaning changes separately when they affect use of the draft.
- Preserve the conversation language unless another language is requested.
- Treat character voice as a writing style, without implying endorsement or
  inventing an identity for the message's sender.
- Generate and revise in chat. Do not claim the app edits documents, sends
  messages, publishes copy, or saves drafts across conversations.
- Use model-visible activation results; do not depend on private widget state
  or widget-only suggestions. Honor later changes of voice or requests to stop.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: persona-task-kickstart
description: Turn one avoided everyday task into a small, practical mission in a supported Persona app voice and adjust from user-reported progress. Use for playful help getting started with chores, tidying, or a bounded work task. Do not use for recurring reminders, automated timers, background monitoring, or long-term project management.
---

# Persona Task Kickstart

Give one task a character-flavored start and a realistic finish condition.

## Inputs

Use the task, available time, relevant constraints, and desired persona. Reuse
details already supplied. Ask for the task if missing; otherwise choose a small
first step without requiring a full productivity interview.

## Workflow

1. Define an observable finish condition for this attempt, such as clearing one
   desk section. Fit it to the user's time and energy rather than expanding the
   original task. If time is unspecified, suggest a brief starting block.
2. Resolve the requested persona using the registered `activate-persona`
   `personaId` enum. Suggest `superhero` for an encouraging mission or `cowboy`
   for a relaxed start when the user wants help choosing. Use
   `display-persona-picker` with an optional `reason` if they request buttons,
   then wait for a visible activation or explicit choice.
3. Call `activate-persona` with the chosen supported `personaId` and an optional
   `reason`, unless the latest model-visible activation already matches. Follow
   `structuredContent.activePersona.instruction`. Report errors or missing
   `activePersona` without presenting activation as successful.
4. Offer three concrete actions, beginning with something immediately doable.
   Make the mission language decorative while keeping the actions clear. Let
   the user start after the first action without needing to reply to each step.
5. When the user reports progress, compare it with the finish condition. Acknowledge
   completed work, identify the actual obstacle, and simplify the next action.
   If interrupted, preserve the last user-reported position for a restart.
6. Close when the finish condition is met or the user stops. Recap only reported
   accomplishments and offer one optional next action.

## Deliverable and boundaries

- Provide a compact mission with a finish condition, three actions, and an
  updated next step or completion recap after the user responds.
- Use the user's conversation language unless they request another. Adapt voice
  intensity to feedback without treating difficulty as a character failing.
- Base progress only on what the user reports. Do not claim to see their desk,
  run a timer, send a reminder, monitor work, or complete the task for them.
- Keep the plan in this conversation. Do not depend on private widget state or
  imply saved task tracking. Honor requests to stop or change persona.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: persona-teach-back
description: Teach a bounded concept in a supported Persona app voice, check the learner's own explanation, and correct misunderstandings. Use for character-led explanations with a teach-back or understanding check. Do not use for simple factual answers, unsupported claims of mastery, or language-conversation practice.
---

# Persona Teach-Back

Use a character's imagery to explain a concept, then check the underlying idea.

## Inputs

Use the concept or supplied learning material, learner's starting level, desired
outcome, and requested persona. Infer level from context when possible. Ask for
missing material when the user wants an explanation of a specific unavailable
source; do not pretend to have read it.

## Workflow

1. Bound the lesson to one idea and identify what a correct explanation should
   include. Use supplied material when present; identify gaps or uncertainty
   rather than allowing character flair to stand in for evidence.
2. Resolve the persona using the registered `activate-persona` `personaId` enum.
   Offer a fitting supported voice if unspecified. Open `display-persona-picker`
   with an optional `reason` when the user requests buttons, then wait for their
   choice or a model-visible activation.
3. Call `activate-persona` with the chosen supported `personaId` and an optional
   `reason`, unless the latest visible activation already matches. Follow
   `structuredContent.activePersona.instruction`. Report a failed call or absent
   `activePersona` before claiming activation.
4. Give a short explanation and one character-flavored analogy suited to the
   learner. Map the analogy back to the actual concept and explain its most
   relevant limitation so the fictional imagery does not become a false rule.
5. Ask the learner to explain the idea in their own words or apply it to one new
   example. Wait for their answer before evaluating it.
6. Identify what their answer gets right and one specific gap, if any. Correct
   that gap and invite a focused retry. Adjust to their response rather than
   repeating the whole lesson or inventing a learner answer.

## Deliverable and boundaries

- Finish with a corrected explanation, a compact recap, and one useful check
  question or next practice step. Ground feedback in the learner's actual reply.
- Preserve factual meaning and the conversation language unless another is
  requested. Treat the persona as delivery style, without implying expertise.
- Use available sources when verification is needed; the Persona tools supply
  voices, not research, source retrieval, grading, or learning-history storage.
- Keep progress in chat. Do not infer mastery, scores, private widget state, or
  unseen prior attempts. Honor requests to change voice or stop the lesson.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: persona-voice-audition
description: Compare supported Persona app voices on the same brief and help the user choose one to keep. Use for voice auditions, character-style comparisons, or testing two or three personas before committing. Do not use for a simple request to activate one persona or for creating custom personas.
---

# Persona Voice Audition

Use one brief to make the differences between supported voices easy to assess.

## Inputs

Use the user's sample text or question, intended audience, and requested voices.
If no sample is supplied, use a short everyday question. Default to two or three
voices when the user leaves the selection open; honor an explicit selection.

## Workflow

1. Establish the shared brief, language, length, and facts that each sample must
   preserve. Reuse these constraints throughout the comparison.
2. Resolve each requested voice against the registered `activate-persona`
   `personaId` enum. Offer a supported alternative for an unavailable character
   without silently substituting it. If the user requests buttons, call
   `display-persona-picker` with an optional `reason`, then wait for a visible
   activation result or an explicit choice.
3. Call `activate-persona` with one supported `personaId` and an optional
   `reason`. Use `structuredContent.activePersona.label` and `.instruction` to
   produce a clearly labeled sample. Complete each activation before starting
   the next; concurrent calls would make the current voice ambiguous.
4. Compare the samples for clarity, character, and audience fit. Ground the
   comparison in the actual wording and invite the user's preference. Keep
   subjective preference distinct from factual accuracy.
5. When the user chooses, activate that persona if it differs from the latest
   successful activation. Identify the voice that remains active while they
   decide; do not claim all sampled voices are active together.

## Deliverable and boundaries

- Return comparable samples, a brief recommendation tied to the user's goal,
  and the chosen active voice once confirmed.
- Preserve the conversation language unless the user explicitly requests another.
- Treat a failed call or missing `activePersona` as an unsuccessful activation;
  report it before proceeding with that voice.
- Use model-visible tool results and conversation context. Do not read private
  widget state, expose widget-only suggested prompts, or claim the widget tracks
  auditions. Keep choices within this conversation and honor requests to stop.

Referenced files: 1 — file references are metadata, not package contents.