# Production recipes
The rest of this wiki tells you WHAT you can ask for in a single sentence (the "Just say" lines on every page). This page holds the full production recipes: long, battle-tested prompts that spell out the entire result — the data, the format, the checks, and what NOT to do. Paste them as-is and adjust whatever is in brackets or parentheses (your @handle, your conversion property, your real DMs). Unless a recipe says Claude Code, they all work in Claude web.
The requests on this page are a proven starting point: copy them as-is, or edit and improve them for your case.
---
### An agent that sounds like your client, not like a chatbot
**The problem:** the agent writes correctly but sounds like a robot, because nobody gave it the client's real voice. **When to use it:** every time you build a new agent, before writing a single line — all you need is 10 to 20 real replies from their DMs. **Where:** Claude web.
View the full recipe
```
We're going to build a new client's agent. Before writing a single line, do this:
1. Pull everything we already have on them with get_self_serve_data: their processed Instagram bio, their posts with metrics, the sample conversations and the form they filled out at sign-up. Tell me what's missing and what we have.
2. Look at the sample agents in the manual (get_playbook_index) and tell me which one looks most like this business.
3. Recommend the ARCHETYPE based on the offer's price and explain why:
- under $100 → fast sale
- $100 to $1,000 → consultative, closes in the chat
- over $1,000 and an emotional purchase → premium that closes in the DM
- over $1,000 and closed over Zoom → the one that books calls
If the case doesn't fit any of them cleanly, tell me instead of forcing it.
4. Here are real DMs from the client, so the agent sounds like them and not like a robot:
[PASTE 10 TO 20 REAL REPLIES OF THEIRS HERE: greetings, objections, excitement, and a kind "you're not my fit"]
5. Write me the COMPLETE agent, not a shell: instructions + examples (10 or more, turn by turn) + knowledge base. Those three are never empty. Plus the keywords and the program. Objections, personal story, resources and case studies: fill them in if they apply and tell me which ones you left empty on purpose.
6. The keywords, with the canonical condition: only literal_response, resource_with_flow or contextual. Nothing else. And put the resource's URL inside the keyword itself, so delivery is handled by the platform and doesn't depend on the model.
7. Show me everything BEFORE publishing anything. Don't turn it on yet: I read it first.
```
---
### The full agent X-ray in thirty seconds
**The problem:** the agent "works", but you don't know what you don't know: the typical holes don't show up when reading conversations — they show up in what is *not* wired around it. **When to use it:** after every change — quick mode is free and always returns the same result for the same input. **Where:** Claude web.
View the full recipe
```
Run diagnose_agent (mode: quick) on my agent and explain every finding in plain English, no jargon.
For each finding I want:
1. What's broken or missing, in plain words.
2. What it's costing me in practice (example: "the agent keeps messaging people who already bought from you").
3. The exact tool that fixes it.
4. Whether it's worth fixing or not. You recommend, with judgment.
Give me the score out of 100 and rank the findings by real impact in money, not by technical severity.
After that, if the score is low, run diagnose_agent (mode: full) so it also audits the real conversations and the published instructions. Warn me before running it, because that mode has a cost: it makes the AI think over many real conversations.
```
---
### The map of why they tell you no
**The problem:** you know you're losing leads, but you don't know why. You suspect it's the price, and maybe it's trust, or timing — you're fixing the wrong problem. **When to use it:** when the funnel is leaking people and before touching the objections file. **Where:** Claude web.
View the full recipe
```
I want my agent's objection map.
Run get_agent_insights (days: 30, sections: [objections, funnel]). The objections section groups stalled leads (stage 1 to 3, silent for more than 72 hours) by type: MONEY, TRUST, TIMING, PRIORITY or UNKNOWN.
Heads up: it needs a window of at least 4 days, because a lead only counts as stalled after 72 hours of silence. And if it comes back empty it's because I don't have the objection properties configured: in that case tell me and propose which ones to create, with the prompt to create them.
With the result:
1. Rank the objections by volume and tell me which one is costing me the most.
2. Pull 3 real conversations from the biggest objection (search_conversations, min_funnel: 1, max_funnel: 3) and read them in full.
3. Tell me whether the objection is REAL (the product doesn't fit) or an agent problem (it handles it badly, raises it too early, doesn't work it).
4. If it's the agent's fault: write me the new example for the objections file. A concrete example, with the dialogue, not a rule in prose.
5. If the UNKNOWN block is big, alert me: it means the agent isn't even detecting why leads are dropping.
```
---
### Recover the leads who asked for something and never got it
**The problem:** the most expensive and most invisible case: people who raised their hand, got the booking link and never booked. Leads you already paid for, in content or in ads, dead in your database. **When to use it:** today, and then never by hand again — the recipe closes with the automation that keeps it from happening again. **Where:** Claude web.
View the full recipe
```
I want to recover the leads that slipped away. Find me the ones who ALREADY received the booking link and never booked.
1. search_conversations with: has_booking_link: true, call_booked: false, last_message_before: (7 days ago), limit: 100. Paginate if there's more than one page.
2. Sort them by lead_score descending and by funnel descending: hottest first.
3. For the top 20, read the conversation and tell me in one line why each one dropped (didn't see the link, said they'd look at it, money objection, went silent).
4. Group them by drop reason.
Then, the important part: I never want to recover these by hand again. Build me the automation so this doesn't happen again.
- An automatic follow-up (upsert_workflow, type FOLLOW_UP) conditioned on booking_link_sent = true AND call_booked not true, with minMinutesSinceLastInbound so it only touches the ones who have been silent for a while.
- Show me the exact condition BEFORE creating it and wait for my OK.
Remember: always condition on yes/no properties, never on text.
```
---
### The activation kit: from demo to production system
**The problem:** your agent is loose text that answers well and does nothing else: it keeps writing to people who already bought, doesn't notify you when someone converts, and doesn't chase the one who went cold. **When to use it:** on every new agent before turning it on, and on every old agent that never went through this. **Where:** Claude web.
View the full recipe
```
I want to turn my agent from loose text into a production system.
Step 1. Run diagnose_agent (mode: quick) and tell me what I'm missing from the activation kit.
Step 2. Wire the kit with scaffold_agent_activation. My conversion property is: (call_booked / purchased / whichever applies). I want:
- terminal_property: that one, guaranteed as a yes/no property (never text: text compares badly).
- A contact limit turned on and conditioned on that property, so the agent STOPS WRITING to whoever already converted.
- followup: an automatic follow-up conditioned on NOT converted, with interval_minutes (you recommend the number), to re-engage whoever went cold. Never unconditioned.
- notify: the conversion notification to my alerts destination.
Show me what it will create and what it will reuse BEFORE running it. The tool is safe to run twice: if something already exists it reuses it instead of duplicating it.
Step 3. Run diagnose_agent (mode: quick) again and show me the score before and after.
Step 4. Verify the two things everyone forgets:
- That the terminal property has "keep checking until it's yes" turned on. Without it, it freezes at "no" on the first message and the limit never fires.
- That the contact limit has NO closure message (the cutoff is silent, that's deliberate), and that the operator notification IS wired instead, so the lead who converted isn't left hanging.
```
---
### Audit your keywords: they actually exist and they actually deliver
**The problem:** keywords the agent doesn't recognize, or recognizes but that don't deliver the resource: the lead asks for the guide, gets something generic, and you never find out. It's the most silent and most expensive failure of all. **When to use it:** on every onboarding and every time you touch the keywords. **Where:** Claude web.
View the full recipe
```
Audit all of my agent's keywords. I want to know which ones aren't delivering.
A keyword lives in 3 places, and if it's missing in one it's incomplete and doesn't deliver:
1. DM trigger (trigger_keywords), which captures the match in direct messages.
2. Comments trigger (trigger_comments), if it comes in through a comment on a post or reel.
3. The agent's content (v5Config, keywords section), which defines the delivery condition and the resource.
Process:
- list_triggers (agent_id) to see what exists on the platform.
- get_agent_config (agent_id) to see the keywords in the agent's content.
- Cross the two lists and tell me: which keyword is on the platform but NOT in the content (the trigger captures the lead and the agent doesn't know what to do, so it falls into the generic flow), and which is in the content but NOT on the platform (the agent would know how to respond but nothing ever captures it).
Then check the CONDITIONS. The only 3 valid ones are: literal_response, resource_with_flow and contextual. If you see anything else, that keyword is not delivering the resource. List them for me.
Finally, for the ones that deliver a resource: verify that the content's match type matches the platform's (whole word with whole word, anywhere with anywhere).
Give me a table: keyword, status (OK / missing on platform / missing in content / invalid condition / misaligned match), and the concrete fix for each one.
```
---
### The dashboard you open every morning and it's already fresh
**The problem:** an on-demand dashboard is a snapshot that's stale by tomorrow. This one regenerates itself every morning, with today's numbers, without asking anyone for anything. **When to use it:** when you're operating for real and want a daily view of the whole operation. **Where:** Claude Code — it creates local files and leaves a scheduled task in the operating system. If you only want the snapshot, delete PART 3 entirely and paste it into Claude web or desktop.
View the full recipe
```
I want a visual control panel of my Ninjō operation. It has to be real (data pulled from the MCP, zero invention), it has to look good, and then it has to keep updating itself.
Work in three parts. Don't skip any, and don't ask me anything until Part 1 is done.
═══════════════════════════════════════
PART 1 - PULL THE REAL DATA
═══════════════════════════════════════
Use only the Ninjō MCP tools. Non-negotiable rule: if a data point doesn't come back, it's shown as "no data". Don't estimate, don't fill in, don't invent a single number.
1. Start with `get_me`. That tells you which accounts I have access to and each one's username. If there's more than one account, the panel has to cover all of them, with a selector at the top to switch between them.
2. For each account, run `list_agents` to know which agents it has.
3. Pull the period's data. Main window: 30 days. Also pull the 7-day window so you can show variation.
a) `get_agent_insights` with days=30 and sections=["volume","funnel","sources","objections"]:
- volume: new conversations, qualified leads, booking links sent, plus the last-24-hours line
- funnel: the configured stages of MY funnel. Use the stage names the tool returns, don't invent generic stages. Pull the conversation count per stage and the conversion percentage between consecutive stages
- sources: performance by origin (organic DM, story reply, ad title)
- objections: stalled leads grouped by objection (MONEY / TRUST / TIMING / PRIORITY / UNKNOWN)
Repeat the call with days=7 for the comparison.
IMPORTANT: this tool can return an empty section with an entry in `warnings`. That is expected behavior. If it happens, that section goes on the panel as "no data" and the rest is shown anyway. Do NOT abort the job over it.
b) `get_agent_metrics` with days=30 and min_leads=3, scoped to each account (always pass influencer_id, don't call it unfiltered). From there pull: leads, new_conversations, qualified_leads, avg_engagement_score, avg_funnel, avg_lead_score, bookings_sent, booking_send_rate, calls_booked, call_book_rate_total, avg_happy_path_score, avg_nurturing_score, risk_score_0_100.
If this call fails or takes too long, move on without it and note it in the panel's footer. It's not blocking.
c) The lists that require action from me:
- Hot and unbooked: `search_conversations` with min_funnel=4, call_booked=false, limit=25. These are the leads who got far and didn't book. That's the money left on the table.
- Stuck: `get_conversations` with mode="stuck", limit=10. These are conversations where the agent sent 6 or more messages and the funnel didn't move.
- High intent but low quality: `get_conversations` with mode="bad", limit=10.
d) `get_workflow_activity` with days=30, to know how many times my automations fired. Cross it with `list_workflows` and `list_custom_notifications`. I care a lot about this: if there's an automation configured that did NOT fire even once in 30 days, I want to see it in red.
e) `list_contact_limits`, to know which brakes I have in place and on which conditions.
f) `search_contacts` with created_after = 30 days ago, to know how many new contacts came in. Also run it with from_ads=true to separate how many came from Meta ads.
BEFORE writing a single line of HTML: show me on screen, in plain text, a summary of everything you pulled, with the raw numbers. I want to review it. If something looks off I'll tell you and you fix it before moving on.
═══════════════════════════════════════
PART 2 - THE PANEL
═══════════════════════════════════════
Build ONE self-contained HTML file. All the CSS and JS go inside the file, and the data gets baked in as a JavaScript object. The page must NOT make any calls to the internet: no external fonts, no CDN libraries, no remote images. Zero requests to outside servers.
Structure, top to bottom:
1. HEADER
Account name (or the selector, if there are several), the time window used, and — highly visible — the date and time of the last update. That stamp is what tells me at a glance whether the panel is fresh. Make it readable.
2. MAIN INDICATORS ROW
Big cards: big number on top, label below, and the variation against the previous 7 days with an arrow and a color.
- New conversations
- Qualified leads
- Booking links sent
- Calls booked
- Booking rate (calls booked over leads)
3. FUNNEL
Horizontal bars, one per stage, with MY stage's real name, the number of people, and between stages the percentage that moved on. I want to see at a glance where people fall off.
4. NEEDS ATTENTION
The most important section. If there are items, it goes above everything else.
An actionable list with the hot unbooked leads and the stuck conversations. For each one: user, last stage reached, days of silence, and an excerpt of the last message. Sorted by urgency (hottest and most silent first).
5. SOURCES
A table by source (organic DM, story reply, ad) with volume and conversion. Visually mark which one converts best.
6. OBJECTIONS
The stalled leads, grouped by reason, with each group's count. If this section didn't come from the MCP, show it in gray with the caption "no data".
Show the objection names in plain English: money, trust, timing, priority, unidentified. A client is going to see this panel.
7. AUTOMATIONS
A table with every follow-up and every notification I have configured, how many times it fired in 30 days, and a traffic light:
- green: fires normally
- amber: fires rarely
- red: it's configured and NEVER fired
Below the table, list the active contact limits.
8. FOOTER
Generation time, window used, and an honest line with the sections that couldn't be pulled, if there were any.
Design rules:
- It has to look professional and sober. I don't want a generic template dashboard. Pick a palette with judgment and stick to it.
- It has to look good in light theme and in dark theme. Define the colors as CSS variables in :root, redefine them inside @media (prefers-color-scheme: dark), and also in :root[data-theme="dark"] and :root[data-theme="light"] so the theme switch wins in both directions.
- Truly responsive: on the phone the cards stack and wide tables scroll inside their own container, never the whole page sideways.
- Numbers that sit in columns get font-variant-numeric: tabular-nums, so they stay aligned.
- The traffic-light color (green, amber, red) is information, not decoration. Don't use it for anything else.
- No emojis as section icons.
Save the file in a fixed folder on my computer, creating it if it doesn't exist: ~/Ninjo-Panel/index.html
Then publish it with the Artifact tool, so I get a fixed web address I can open and share. When you publish it, tell me the URL and also save it in ~/Ninjo-Panel/URL.txt. You'll need it in Part 3.
═══════════════════════════════════════
PART 3 - MAKE IT UPDATE ITSELF
═══════════════════════════════════════
(If I'm using Claude on the web or in the desktop app, skip this entire part: it doesn't apply there. It only applies in Claude Code.)
Two things we already know and that you have to respect to the letter:
- An automated Claude run in the background CAN query the Ninjō MCP and CAN rewrite the HTML file. What it CANNOT do is publish Artifacts. So the refresh script must NOT try to use the Artifact tool. It only regenerates the file ~/Ninjo-Panel/index.html.
- Therefore, the scheduled run keeps the local file always fresh. If I also want an internet address that updates itself, that's solved through the publishing path in point 4.B below.
Do the following:
1. Write the refresh routine (the script) at ~/Ninjo-Panel/refresh.sh. Have it run Claude in non-interactive mode — meaning with nobody in front of it to answer — with the allowed tools declared explicitly, so it never sits waiting for a permission nobody will grant. Inside goes a self-contained prompt that redoes exactly Part 1 and Part 2 of this message, without the Artifact step, and overwrites ~/Ninjo-Panel/index.html. Each run should leave a record in ~/Ninjo-Panel/refresh.log.
2. Run that script ONCE by hand, now, in front of me. Show me that the file regenerated and that the "last update" stamp changed. If it doesn't work, fix it before moving forward. Don't tell me it's ready without having tested it.
3. Schedule it with my operating system's task scheduler, in a way that survives a reboot, so it runs every day at 8:05 in the morning. Tell me exactly what you created and how I turn it off the day I want to turn it off.
4. Ask me which of these two options I want, and do the one I choose:
A. OPENING IT MYSELF IS ENOUGH. Leave me a shortcut on the desktop that opens ~/Ninjo-Panel/index.html. It updates itself every morning as long as my computer is on. I don't create any new account.
B. I WANT AN ADDRESS MY WHOLE TEAM CAN SEE. Publish the panel on a free service that hosts web pages, and add the publishing step to the refresh routine, so the address updates itself every morning. Tell me which service to use, explain in plain words which free account I have to create, and walk me through it button by button. No credit card, ever.
Close with a three-line summary: where my panel is, what time it updates, and how I turn it off.
```
---
### The risk board for your entire portfolio, in a single call
**The problem:** with eight, fifteen or thirty sub-accounts, to know which one is on fire you have to open them one by one — and you find out a client is doing badly when they write to you angry. **When to use it:** every week, or every day if the portfolio is large. **Where:** Claude web; requires a multi-client connection.
View the full recipe
```
I'm an agency and I manage several sub-accounts. I want the risk board for my ENTIRE portfolio.
Call get_agent_metrics (days: 30) WITHOUT passing influencer_id. With a multi-client connection that returns one row per client I manage, in a single call. Don't loop get_agent_insights client by client: it's unnecessary.
With that, build me a panel with a table sorted by risk_score_0_100 descending (riskiest on top), and for each client show me:
- leads and new conversations
- avg_funnel and avg_lead_score
- booking_send_rate and call_book_rate_total
- pct_happy_lt_60 (low-quality conversations)
- risk_score_0_100
Paint in red the ones with high risk or a lot of low-quality conversation.
Then, for the 3 worst, run diagnose_agent (mode: quick) and tell me in one line per client what the concrete problem is and which tool fixes it.
Close with: "this week go after these 3, in this order, for this reason".
```
---
### The report that proves how much money the agent touched
**The problem:** you know how many conversations the agent had, but not how much *revenue* it touched. When the client asks "is this even working for me?", you answer with conversations and bookings, which is exactly what doesn't move their needle. **When to use it:** at the end of the month, with the client's buyer list in hand — it's the number that justifies the contract. **Where:** Claude web.
View the full recipe
```
Here's my list of this month's buyers (a spreadsheet with name, email, Instagram username, phone and amount paid). I want a sales attribution report for the agent.
Process:
1. Consolidate and dedupe the buyers by email. Tell me total revenue and number of buyers.
2. For each buyer, look them up in my contacts with search_contacts (try by email, then by instagram_username, then by phone).
3. For the ones that match, pull their conversation with search_conversations (contact_username) and check whether the agent REALLY talked to them. Minimum bar: 5 agent messages (min_agent_messages: 5) and the agent's first contact BEFORE the purchase date.
4. Classify each buyer into 3 tiers: (a) booked a call via the agent, (b) talked to the agent and bought without booking, (c) no contact with the agent.
5. Give me the $ total for each tier, the % of the month's revenue, and the table of the 10 biggest buyers with their tier.
Rules: don't invent a single number. If a buyer doesn't match, they go to "no contact", don't force it. At the end, tell me explicitly what percentage of the revenue the agent touched and with what level of confidence.
Framing: the agent QUALIFIES AND WARMS UP, the human team closes. Never say "the agent closed the sale". Say "the agent worked the buyer".
```
---
### Replicate the agent that performs best, from one client to another
**The problem:** when an agent works for one client, the thing that works is an asset of yours, and a single connection lets you read it from one client and publish it in another — yet it's the lever nobody uses. Three days of onboarding work turns into an afternoon's work. **When to use it:** when onboarding a new client, if you already have one that converts. **Where:** Claude web; requires a multi-client connection. **The rule worth the client relationship:** what gets replicated is the *structure* (the flow, the timing, the objection handling), never the content. The case studies, the personal story and the testimonials belong to each client: copying them from one to another isn't a shortcut, it's a lie, and it gets discovered on the first call.
View the full recipe
```
I want to replicate in one client what's already working for me in another.
Step 1. Pick the winner with data, not my gut: get_agent_metrics (days: 30) without influencer_id, and tell me which of my clients has the best booking rate. That's the model.
Step 2. Read its full configuration (get_agent_config of the winning client): instructions, examples, objections, knowledge base, keywords, program.
Step 3. Tell me in 5 points WHAT makes it win. Concrete: at what moment it sends the link, how it opens, how it handles the price objection, how many examples it has, how it qualifies. That's what we're going to replicate.
Step 4. Read the destination client's configuration and pull their context (get_self_serve_data). Then write me their new agent taking the winner's STRUCTURE, but with:
- the destination client's program, price and links
- the destination client's voice (I'll paste their real DMs)
- their keywords, not the other client's
Do NOT copy the winner's content as-is. If you copy their case studies or their personal story into another client, that's a lie the lead is going to discover.
Step 5. Before publishing: show me the conceptual diff (what I took from the winner and what belongs to the destination), run 5 synthetic conversations and I'll read them myself. Only then do we publish.
Step 6. Wire up its automation with scaffold_agent_activation, same as the winner. A replicated agent without brakes or alerts is half an agent.
```
---
### The weekly report per client, on a schedule
**The problem:** the report you build by hand today, client by client, and that eats the first Monday of every month. It gets built once and arrives on its own. **When to use it:** a single time — after that it runs by itself every Monday. **Where:** Claude Code — it leaves a scheduled task in the operating system.
View the full recipe
```
I want the weekly report for each of my clients, built once and scheduled forever.
For EACH client in my portfolio (get_me gives you the list):
- get_agent_insights (days: 7): volume, funnel by stage with the stage-to-stage conversion, performance by source, and objections.
- get_agent_metrics (days: 7) scoped to that client: link send rate and calls booked.
- The comparison against the previous week, with the variation.
- The hot unbooked leads (search_conversations, min_funnel 4, call_booked false): the money left on the table this week.
Build ONE HTML file per client, self-contained, with the data baked inside, ready to send them. With the client's name at the top and the generation date highly visible.
Rules:
- If a data point doesn't come back, it goes in as "no data". Don't estimate a single number: the client sees this.
- The objection names, in plain English: money, trust, timing, priority, unidentified.
- Close each report with a "what we do this week" section: 2 or 3 concrete actions, not a summary.
Then leave it scheduled to run on its own every Monday at 8 in the morning, and tell me exactly what you created and how I turn it off.
```