--- name: perspective-ai-interview-project-setup description: Take a new or early-stage Perspective AI conversation agent (a perspective) from a one-sentence brief to a tested, shareable interview, starting from agent templates, reviewing the outline, running test conversations and checking readiness before any participant sees it. Use when the user wants to create, set up, design, draft, revise or get ready to launch a Perspective interview, survey-style conversation, or conversation agent. --- # Set up an interview project in Perspective AI The goal is a perspective that **asks the right questions, in the right order, and is proven to work before a real participant opens it**. A broken or vague agent wastes participants' time and cannot be fixed by the data that comes back. Most setup failures are upstream: a brief with two goals, an outline nobody read, or a share link published after one happy-path test. Work in this order. Do not skip the readiness gate in step 6. ## 1. Pin down the brief and the workspace Before creating anything, confirm the workspace the work belongs to, using `perspective_list` for the workspaces and projects you can reach. If the user has more than one, ask which one. Then get the brief in one or two sentences, and check it contains: - **The decision it informs.** "We are deciding whether to build feature X" beats "learn about users". - **The participant.** Who they are and why they are the right person. - **One primary objective.** If there are three, pick the one that matters most now and park the others for a second perspective. If the brief is vague, ask one focused question. Do not guess at the audience. ## 2. Start from a template before a blank page Search `agent_template_search` for a library template that matches the goal (discovery interview, concept feedback, onboarding feedback, churn, and so on). Open the best two with `agent_template_get`. Use a template when one fits about 70 percent; a blank build from `perspective_create` is for genuinely novel goals. When you build from a template, say which one and what you changed, so the user can judge the adaptation. Ask whether the perspective is new (`perspective_create`) or an existing one being revised (`perspective_get` first, to read the current state and avoid overwriting live work). ## 3. Draft the outline with a sensible shape Whatever the source, check the outline has this shape: - **Opening (1 to 2 questions):** context and permission. Easy, specific, no leading. - **Core (3 to 5 questions):** one objective each. Open-ended, past behaviour before opinion ("Tell me about the last time..." beats "Would you use...?"). - **Probe depth:** for each core question, at least one follow-up that asks *why* or *what happened next*. - **Close (1 question):** anything missed, and a thank-you. Flag the common defects: leading questions ("How much do you love..."), double-barrelled questions, hypotheticals about future behaviour, and more than about 8 to 10 main questions, which will not finish in the time promised. Show the outline to the user in plain text and make the revisions they ask for. Apply changes with `perspective_respond` or `perspective_create` only after they confirm. ## 4. Test it yourself, as a participant would Run at least two test conversations with `conversations_explorer` or the preview path from `perspective_get_preview_link`, using two different personas: one cooperative and one terse or off-topic. Look for: - A question that gets a one-word answer every time (rewrite it as a "tell me about" prompt). - A branch that dead-ends or loops. - An agent that accepts a non-answer and moves on without probing. - Length: a 15-minute promise that runs 30 minutes. Record what you changed and why. Do not report success from one happy-path run. ## 5. Check the settings that decide who can take part Read the project with `perspective_get` and `perspective_get_stats` (for a new project, the stats will be empty; that is expected). Confirm the audience setting, language, expected duration, and whether participants can start without an invite. Use `perspective_get_embed_options` only if the user intends to put the perspective on a website; the embed is a second publication path and needs the same readiness check. Phase matters. A project in **design** or **test** should not be shared. Move it forward only when the user has signed off. ## 6. Readiness gate before any share A perspective is ready only when all of these are true, and you can say so with evidence: - The outline has been reviewed by the user, with the revisions applied. - Two or more test conversations passed without a dead end, and the changes they prompted are in. - Duration matches what the invite says. - The primary objective is answered by at least one question that the test conversations actually reached. - The user has seen the preview link and confirmed it reads correctly on their screen. If any item is missing, say which one and do not proceed. Publishing or sharing a live link is the approval point, covered below. ## Common patterns and traps - **Two perspectives in one.** A brief that asks for both discovery and pricing feedback produces a long, unfocused agent. Split it. - **Testing only as the author.** You know the intended answers, so you will always pass. Use a persona who does not. - **Polishing before the objective is clear.** Fine-tuning wording on a perspective whose goal is still disputed is wasted work. - **Copying a template unchanged.** Templates are starting points for a different product and audience; the brief must drive the edits. - **Forgetting the close.** Without a closing question and a clear end, conversations trail off and completion rates fall. - **Reviving a live project.** Editing a perspective that already has responses can make new answers incomparable with old ones. Check the phase and tell the user before changing questions on a live project. ## Output ``` Perspective: (workspace: , phase: ) Objective: Source: