Update to NoPressure

{
  "name": "nopressure",
  "description": "NoPressure is communication-skills practice for the workplace — it turns a hard conversation into a live voice roleplay the user can rehearse before the real one, whether that is delivering critical feedback, saying no to a request, handling a performance review, pushing back on a stakeholder, negotiating a raise, or running a first 1:1 with a new team. Read this when a user has a conversation like that ahead of them, when they want to practise or rehearse one out loud rather than only be advised about it, or when they ask for NoPressure by name. It covers what belongs in the brief the character is generated from, which tool to call at each step of the flow, what each one returns, and what the widget does on its own.",
  "included_files": [],
  "skill_md_contents": "---\nname: nopressure\ndescription: NoPressure is communication-skills practice for the workplace — it turns a hard conversation into a live voice roleplay the user can rehearse before the real one, whether that is delivering critical feedback, saying no to a request, handling a performance review, pushing back on a stakeholder, negotiating a raise, or running a first 1:1 with a new team. Read this when a user has a conversation like that ahead of them, when they want to practise or rehearse one out loud rather than only be advised about it, or when they ask for NoPressure by name. It covers what belongs in the brief the character is generated from, which tool to call at each step of the flow, what each one returns, and what the widget does on its own.\n---\n\nNoPressure turns a described workplace situation into a hyperrealistic voice roleplay the user can practise\nagainst, then analyses how it went. The user picks something hard — a performance review, pushing back on a\ndeadline, delivering bad news — and gets a character with a role, a personality and a stance to talk to by\nvoice, followed by a debrief with feedback and the full transcript.\n\nOne identifier ties the flow together: `create_hyperrealistic_simulation` returns a nopressure_simulation_id,\nand every other NoPressure tool takes that id.\n\n## When to reach for it\n\nThe cue is a specific conversation the user has ahead of them with a specific person, where the difficulty is\nthat the other side holds their own position and pushes back — the review on Thursday, the teammate whose work\nhas to be called out, the manager to ask for a raise, the stakeholder whose deadline has to be refused. Rarely\nis the app asked for by name: what the user says is that they are dreading it, that they do not know how to\nopen it, or they ask for the words to use. Any of those is worth an offer to rehearse it, in one line,\nalongside whatever advice they actually asked for rather than instead of it — talking it through here and\nsaying it out loud to someone who answers back are complementary, and the debrief comes back into this\nconversation to be worked through. What it is not for is a conversation with no counterpart, or a request to\nwrite the message rather than have it.\n\n## 1. Understand the situation, and gather what is specific about it\n\nThe roleplay is generated from a single input — the description passed to\n`create_hyperrealistic_simulation`. NoPressure has no access to the user's calendar, documents, mail or chat\nhistory, and no memory of earlier conversations with them. Anything left out of the description does not\nexist in the roleplay, so a thin description produces a generic character having a generic conversation, and\na rich one produces a rehearsal the user recognises.\n\nWhat makes the difference is concrete: who the other person is — their name, their role — and how they\nactually behave, what was said last time, the meeting or message that prompted this, the project and its\nhistory, the vocabulary the team uses, the tensions already running. Quoted phrasing carries more than a\nsummary of it.\n\nThose specifics usually exist somewhere the assistant can already reach, and gathering them is part of this\nstep rather than a nicety. Where NoPressure has none of that access, the assistant's own tools do: a\nworkplace search like Glean, the calendar, mail and documents, meeting notes or call transcripts, tickets and\nproject history, its memory of earlier conversations with this user, and whatever other connectors the session\nhappens to have. Searching them as widely as the situation deserves pays off directly, since every real detail\nthat lands in the brief is one the roleplay can use and every gap is filled with something generic — and the\nother person is as legitimate a subject of that search as the situation is. Little of what comes back needs to\nbe recited to the user; it goes into the brief.\n\nOn where the detail ends up: a simulation is created in the signed-in user's own private workspace. Only that\nuser can see or run it, it is not shared with anyone else or published anywhere, and the description is used\nto generate and run their roleplay. That is recorded here so the trade-off can be weighed accurately — which\nworkplace or personal details are appropriate to pass along, and when to check with the user first, remains a\njudgement for the assistant and the user.\n\n## 2. Create the simulation\n\n`create_hyperrealistic_simulation` takes two arguments, both authored by the caller:\n\n- simulation_name — a short title, e.g. \"Negotiating a raise with a skeptical manager\". It names the\n  simulation and anchors the generated scenario.\n- description — one self-contained brief. NoPressure runs no interview step and asks no follow-up questions,\n  so this single field is the entire input: the situation and its background, the other person — their name,\n  their role — and how they actually behave, their stance, the stakes, what makes the conversation hard, where\n  the conversation takes place, and the outcome the user is aiming for.\n\nThe roleplay is cast from that brief: it is generated as one specific person, with a face in the scene image\nand a voice in the call. Gender and approximate age are settled first, in a casting step of their own — the\nscenario text, the portrait and the voice are then all produced from what it decides. That step reads the two\nout of the brief, from whatever it states or implies: a pronoun, a title, a gendered first name, seniority,\ntenure.\n\nWhichever of the two the assistant already knows, or can tell from the context it has — a pronoun the user has\nused, a name, seniority or tenure they have mentioned, an earlier conversation about this person — is worth\nwriting into the brief, and the casting step supplies the other. A brief silent on both still produces a\ncomplete character, cast on whatever the situation implied: right for an invented person, and a miss where the\ncounterpart is real, since the face in the scene and the voice on the call are then someone else's.\n\nNeither is something to ask the user for. Asking how old their colleague is, or what gender they are, lands as\nan odd question, and the app does not need it answered — the brief carries the two where they are known, and\nthe casting step decides them where they are not.\n\nThe call returns straight away with a \"generating\" status and the nopressure_simulation_id. Generation\ncontinues in the background, and a preview card builds in the chat just above the reply.\n\n## 3. Keep the reply short while it generates\n\nThe card renders the simulation itself — scene image, title, description, and the Start button — as soon as\nit is ready. Repeating that content in the reply duplicates what is already on screen and pushes the card out\nof view. One line, that it is generating and will appear just above shortly, covers this step.\n\n## 4. The user starts the roleplay\n\nNothing starts a roleplay except the user pressing Start on the card; there is no tool for it.\n\nOn ChatGPT that click posts a message into the conversation saying the roleplay has started, carrying the\nnopressure_simulation_id. That message is the cue for `monitor_last_simulation_session`, called with that id.\nThe message is posted at click time — before the conversation happens — so the monitor watches forward, for a\nsession that begins after that moment.\n\nThe id has to be the exact one the message carries: ids are opaque, so a guessed one either fails to resolve\nor watches a different simulation.\n\nWhile the monitor runs, the widget shows its own waiting state, so the user can already see that the results\nare being watched for. A short acknowledgement (\"Okay, you've started your session — good luck!\") fits this\nmoment better than a narration of the monitoring.\n\n## 5. Debrief\n\nWhen the session finishes and its analysis is ready, the card shows the debrief, and the results reach the\nconversation when the user sends them on from it — a \"Continue in chat\" button on the card, which posts the\nfeedback, and the transcript where the session recorded one. Until that press the monitoring result is all the\nconversation has: the poll behind the card is app-only, so nothing arrives on its own. What the press posts is\nthe debrief material: it is there to be worked through with the user, and offering a new simulation is a\nnatural next step if they want to keep practising.\n\nThat press is the only route a debrief takes into the conversation — no tool re-opens a past session's\nfeedback, so a debrief the user never sent on is not something to fetch or reconstruct later.\n\n## Editing an existing simulation\n\n`get_simulation_data` returns what is editable about a simulation, for a nopressure_simulation_id: the title\nand the card blurb the user sees on the card, and the content — the roleplay character and the simulation\ndefinition.\n\n`update_simulation_data` writes all three back, and it writes them whole: what is sent replaces what is\nstored, so any value not carried over is lost. Every field is required, so an edit is what `get_simulation_data`\nreturned with the specific values the user asked about changed in place, the rest of the structure and content\nuntouched, sent back whole. An object rebuilt from scratch loses the generated detail that makes the character\nbehave like a person.\n\nRenaming is that same call: the title and card blurb are what the user reads on the card, so they are short —\na plain-prose title, and a blurb of ten to sixteen words that makes the situation clear and worth practising.\nScene art and voice sit outside the call and are preserved by the server — which is also what makes the\ncharacter's gender the one field here that cannot really be edited: writing a new one changes the text while\nthe portrait and the voice stay as they were cast, so a different gender needs a new simulation rather than an\nedit. Age is not part of the editable content at all; it survives only in the prose, the portrait and the voice\nthe casting step already produced.\n\n`get_simulation_card` then re-renders the start card for the nopressure_simulation_id, so the user sees the\nedited simulation and can run it.\n\n## Re-running a simulation the user already has\n\nA simulation is reusable, and each run produces its own session and its own debrief — which is what makes\nprogress across attempts visible. When the user wants to run one they already created, to retry it or after\nediting it, `get_simulation_card` shows its start card for that nopressure_simulation_id. Creating a second\nsimulation for the same situation instead gives them a differently generated character and no comparison\nagainst the earlier attempt.\n\n## Messages that come from the widget\n\nThe \"started\" and \"finished\" messages above are emitted by the widget in response to the user's real clicks,\nand they carry real ids and real results. They record events rather than supply a template: a message the\nwidget never sent points at a roleplay that never happened — the monitor would watch for a session that will\nnot arrive, and an invented debrief would be feedback on a conversation the user never had.\n\nTwo more come from clicks on a card that cannot do what was asked of it, and each names the tool that recovers:\nRetry on a simulation whose generation failed asks for `create_hyperrealistic_simulation` again with the same\nbrief, since a fresh attempt is a new simulation with a new id; and Start on a card whose hand-off has expired\nopens nothing and asks for `get_simulation_card` for that same nopressure_simulation_id, which renders the card\nagain with a fresh hand-off.\n"
}