Each playbook gives you the exact text to enter into every WaxFrame field for a specific document type. Open WaxFrame on one screen and this page on another. Work through the fields top to bottom — replace anything in [brackets] with your own information.
Tip: Every playbook on this page is also available as a template inside the app. On the Project screen, click 📋 Use Template, pick whether you're starting from scratch or refining an existing draft, then click the template to populate all six Goal fields automatically — no copy/paste needed. Use this page when you want to read the full reasoning behind each playbook, and the in-app templates when you want to apply one fast.
New to WaxFrame? Read the User Manual first — it walks you through every screen step by step.
A small, low-stakes first project. Classic chocolate chip cookies — pantry ingredients, familiar territory for almost everyone — written from scratch by the hive. Same complete WaxFrame flow as any other document; the topic is just harmless enough that you can focus on learning the workflow without anything riding on the outcome. The goal fields below are written in plain human voice, the way you'd actually describe what you want to a friend. With a well-phrased goal, the hive typically converges in 2 rounds.
Copy each value into the matching field on the Project screen. Fields marked * are required to continue.
| Field | What to enter |
|---|---|
| Project name * | Chocolate Chip Cookies |
| Version * | v1 |
| Document type * | Recipe |
| Target audience * | Myself and friends that enjoy chocolate chip cookies that are easy to make |
| Desired outcome * | Create a recipe that is simple and easy but makes great cookies |
| Scope & constraints | Leave blank |
| Tone & voice | Leave blank |
| Additional instructions | No extra ingredients like nuts |
| Length Constraint (field below the goal fields) | Leave blank |
Click Start from Scratch and leave the text box empty. That's it — the six goal fields above are all the hive needs. Head to the work screen and click Smoke the Hive.
This is your first hands-on look at the workflow. While you run it, pay attention to:
Once the cookies run converges, export the final recipe — it's a real working recipe you can use. Then click 🏁 Finish on the work screen and choose Start New Project to wipe the session and begin work on your next document. The playbooks below have field-by-field templates for common document types — pick the one closest to what you're writing.
The round counts shown in the playbooks below were measured on public-AI hives — ChatGPT, Claude, Gemini, and similar consumer-facing models with internet access. If you're running WaxFrame on the AI platform your IT team set up at work (Open WebUI, LM Studio, on-prem deployments), expect different round counts and convergence patterns.
The substrate matters. An internal AI server hosts whatever models your IT team has provisioned, and those models can have knowledge cutoffs months or years apart. On factually-anchored documents this can extend convergence or cause non-convergence. On opinion-or-style-driven documents — which most of the playbooks below are — the substrate matters much less.
Two quick mitigations:
Full guidance on running WaxFrame in enterprise environments is in the user manual: Appendix C — Using WaxFrame at Work ↗.
↑ Back to topEvery playbook below shows a measured round count. Two stopping signals can produce that number, and they mean different things.
Neither convergence type means the document is perfect — only YOU can decide that, it's your document after all. So, If you would like to make hand crafted amendments you can do so as always on the working document itself or if you want to have the builder "tighten the third paragraph" or "adjust the closing line it is too long" you can send those NOTES and run another round, you are in charge!
↑ Back to topFill in each field on the Project screen. Replace anything in [brackets] with your own information.
| Field | What to enter |
|---|---|
| Document type * | Cover letter |
| Target audience * | Hiring manager at [company name] reviewing applications for a [job title] position |
| Desired outcome * | Reader wants to interview me. Three short paragraphs: a strong opening hook, a direct connection between my experience and the role, and a confident close with a clear call to action. |
| Scope & constraints | Three paragraphs maximum. No generic openers like "I am writing to express my interest." No filler phrases. No sign-offs like "I look forward to hearing from you." |
| Tone & voice | [Professional / conversational / enthusiastic] — pick one that fits the company |
| Additional instructions | Do not add claims about my experience that are not supported by what I provide. Do not fabricate anything. |
| Desired outcome | Generate a cover letter from scratch using only the talking points I provide in Notes. Three paragraphs: strong hook, direct connection to the role, confident close with a call to action. |
On Setup 4 — Reference Material, paste the full job description. The hive will see it every round and check that your cover letter language, emphasis, and examples actually match what the employer is asking for. The AIs cannot visit URLs, but a pasted JD gives them direct authoritative source to cite against — much more reliable than describing the role in Notes.
Fill in each field on the Project screen. Replace anything in [brackets] with your own information.
| Field | What to enter |
|---|---|
| Document type * | Job description |
| Target audience * | Candidates applying for a [job title] role — be specific: e.g. Mid-level software engineers with 3–5 years of experience, Entry-level candidates in defense or aerospace |
| Desired outcome * | Qualified candidates immediately understand the role, the requirements, and why the job is worth applying for. Unqualified candidates self-select out. Responsibilities are listed in order of importance, most critical first. |
| Scope & constraints | List responsibilities from most important to least. Flag any must-have requirement that could unnecessarily narrow the candidate pool. Include a brief company culture statement at the end. Salary range: [amount or write OMIT]. |
| Tone & voice | [Professional / startup / enterprise] — match the culture of the company |
| Additional instructions | Do not add requirements that are not on my original list. Do not soften or remove must-have qualifications without flagging it as a suggestion first. |
| Desired outcome | Generate a complete job description for a [job title] role at a [company type] from the list of responsibilities and requirements I provide in Notes. List responsibilities by importance, most critical first. |
| Project name | JD — Network Engineer Altura Systems |
| Version | v1 |
| Document type | Job description |
| Target audience | Network engineers with 3 to 7 years of experience, currently at an MSP or small-to-mid enterprise, who want more hands-on work and less ticket-queue churn |
| Desired outcome | Qualified candidates read it and apply. The non-qualified self-select out — we don't need to filter through 200 resumes. Responsibilities ranked by time spent, not vanity. |
| Scope & constraints | Salary range goes at the top, not buried. List must-haves separately from nice-to-haves. No jargon like "ninja" or "rockstar." Include one sentence about the company culture that is actually true — we are small, loud, and nobody micromanages. |
| Tone & voice | Honest and specific, not startup-cute. Write like a person, not a recruiter. |
| Additional instructions | If any required qualification looks like it would narrow the pool unnecessarily, flag it and suggest an alternative. Do not list certifications as required — list them as preferred. |
| Length Constraint | Leave blank |
| Starting Document | Click Start from Scratch and leave the text box empty |
Role: Network Engineer, full-time, in-office 3 days per week, hybrid otherwise Location: Tampa, FL Salary: $95k to $120k DOE + profit share We are Altura Systems, 14 people, IT services for small healthcare and law firms across Florida. Responsibilities, in order of time spent: - Design and deploy small-to-mid office networks (40 to 200 users), mostly Cisco Meraki and UniFi - Troubleshoot client network issues — remote and on-site - Run site surveys and wireless heatmaps with Ekahau - Document everything in our internal wiki - Occasional after-hours cutovers, comp time given Must have: - 3+ years hands-on network engineering - Comfortable with Meraki or equivalent cloud-managed platform - Can read a switch config and know what's broken - Clean driving record (client site travel) Preferred: - CCNA or equivalent - Any wireless certs (CWNA, CWDP) - MSP background Culture: small team, we fix our own mistakes, no politics, no unnecessary meetings, you own your work end to end.
Before Round 1, open Notes and write: "Flag any must-have requirement that could reasonably be a nice-to-have — overly strict requirements reduce applicant quality by narrowing the pool too early."
Fill in each field on the Project screen. Replace anything in [brackets] with your own information. Fields marked * are required to continue.
| Field | What to enter |
|---|---|
| Document type * | Résumé |
| Target audience * | Hiring manager or recruiter reviewing candidates for a [job title] role — e.g. Hiring manager at a defense technology company |
| Desired outcome * | Reader invites me to interview. The résumé shows clear impact and achievements, not just job duties. Every bullet demonstrates value. |
| Scope & constraints | Do not fabricate experience. Do not remove job titles, companies, or dates. Strengthen what is already there — do not invent. |
| Tone & voice | Confident, professional, action-oriented — strong verbs, no passive voice, no "responsible for" |
| Additional instructions | Do not remove or change any metrics, percentages, or dates — these are factual and verified by me. |
| Length Constraint (field below the goal fields) | Enter 1 · select Pages for a one-page résumé, or 2 for two pages |
| Desired outcome | Generate a complete résumé for a [job title] role from the notes I provide. Use only what I give you — do not add experience I have not mentioned. |
| Additional instructions | Build only from my notes. Do not fabricate any experience, skills, or achievements. |
| Project name | Resume — Dana Reyes Wireless |
| Version | v1 |
| Document type | Résumé |
| Target audience | Hiring manager at a mid-size enterprise or defense-adjacent company reviewing candidates for Senior Wireless Engineer roles |
| Desired outcome | Reader invites me to interview. The résumé leads with impact — not job duties. Every bullet shows a result, a scale, or a problem solved. |
| Scope & constraints | Do not invent experience. Do not remove job titles, companies, or dates. Strengthen what is there. Tighten the older entries so the more recent work gets more space. No "responsible for." No "utilized" when "used" works. |
| Tone & voice | Confident, direct, active verbs. |
| Additional instructions | Do not change any numbers, dates, percentages, or dollar amounts. Those are verified. |
| Length Constraint | Enter 1 · select Pages |
| Starting Document | Click Paste Text and paste the text below |
Dana Reyes Tampa, FL · dana.reyes@example.com · 813-555-0114 Summary Wireless network engineer with 8 years of experience. CWNA, CWDP, CWAP. Aruba, Cisco Meraki, and Ruckus. Specializes in warehouse and industrial RF environments. Experience Senior Wireless Engineer, Vantage Logistics — Jan 2022 to Present - Responsible for wireless network across 12 warehouse sites and 3 corporate offices - Led migration from Cisco Meraki to Aruba ArubaOS 8 - Did site surveys with Ekahau - Supported autonomous mobile robots operating on the floor Wireless Engineer, Meridian IT Services — Jun 2018 to Dec 2021 - MSP role supporting 30+ small and mid-size clients - Handled escalations for wireless issues - Designed networks for new client buildouts Network Technician, Gulfstream Communications — Aug 2016 to May 2018 - Installed and configured wireless access points - Ran cable, tested drops, closed tickets Certifications CWNA, CWDP, CWAP, Aruba ACMA Education BS Information Technology, University of South Florida — 2016
Job posting I'm targeting: Senior Wireless Engineer at a defense technology company. They emphasize industrial RF, mobility for robotics, and large-scale deployments. Title on posting is "Senior Wireless Network Engineer." Things I forgot to include in my resume: - At Vantage, I cut wireless-related Tier-1 tickets by 42% year-over-year after the Aruba migration - Designed the RF for a 46-foot ceiling warehouse in Memphis with 6-foot aisle widths — unusual deployment, delivered on time, zero post-deployment escalations - At Meridian I was the only engineer with CWAP — became the go-to escalation point for wireless issues across all clients
On Setup 4 — Reference Material, paste the full job description from the posting. The hive will align language, emphasis, and skill phrasing to the actual role on every round — this is one of the highest-leverage moves you can make on a résumé. Notes are cleared after each round; reference material persists, so you only have to paste it once.
Fill in each field on the Project screen. Replace anything in [brackets] with your own information. Fields marked * are required to continue.
| Field | What to enter |
|---|---|
| Document type * | LinkedIn About Profile |
| Target audience * | Recruiters scanning for [your key certs / platforms / tools] keywords in 30 seconds. Peers in the field reading it on a closer pass to decide if you actually do the work. |
| Desired outcome * | Recruiter sees credentials and platform experience and flags it as a match. Peer reads it and thinks "this person actually does the work, not just talks about it." |
| Scope & constraints | Lead with what you actually do, not where you work. Include credentials and platform experience without it reading like a resume bullet list. End with one line that gives a peer something to connect on. |
| Tone & voice | Professional but human. Not stiff. Engineer that can speak customer. |
| Additional instructions | No "passionate about," "results-driven," or "proven track record." If a sentence sounds like it could have been written about anyone in this field, rewrite it until it could only have been written about me. No "open to opportunities" or "looking for my next chapter." |
| Length Constraint (field below the goal fields) | Enter 2000 · select Characters (LinkedIn's About section permits up to 2,600 — leaving headroom keeps the run from bumping the ceiling) |
| Project name | LinkedIn Profile — About Section |
| Version | v1.0 |
| Document type | LinkedIn About Profile |
| Target audience | Recruiters scanning for CWNA / CWAP / Aruba / Ekahau keywords in 30 seconds |
| Desired outcome | Recruiter sees credentials and platform experience and flags it as a match. Peer reads it and thinks "this person actually does the work, not just talks about it." |
| Scope & constraints | Lead with what I actually do, not where I work. Include credentials (CWNA, CWDP, CWAP) and platform experience (Aruba, Ruckus, Cisco Meraki, Ekahau) without it reading like a resume bullet list. End with one line that gives a peer something to connect on. |
| Tone & voice | Professional but human. Not stiff. I'm not "corporate" — I am an engineer that can speak customer. |
| Length Constraint | Enter 2000 · select Characters |
| Starting Document | Click Start from Scratch — leave the text box empty |
Role: Senior Wireless Network Engineer (contractor) at Anduril Industries. Credentials: CWNA, CWDP, CWAP. Working through CWNE. Primary platform: Aruba on-prem ArubaOS 8.x. Past platforms include Ruckus and Cisco Meraki. Tools: Ekahau and iBwave for predictive and validation surveys. Strong on enterprise, warehouse, and industrial RF environments. What I actually do day to day: design wireless networks for sites where the floor plan and the predictive model disagree, validate them on-site, and own the deployment through Day 2 operations. The work is half RF physics and half "the customer told me there's no metal in the ceiling and the ceiling is actually a metal grid." Identity stack at work: Okta, Kolide, Cloudflare. Not Active Directory. What I want a peer to know about me: I'd rather walk a site than guess at one. Predictive surveys are a starting point. The answer is always on the floor with a laptop. What I want a recruiter to know about me: I have shipped production wireless deployments at scale, on-prem, in industrial environments, with constraints (air-gapped networks, restricted CDN access, no AD). I know what I don't know.
No "passionate about." No "results-driven." No "proven track record." If a sentence sounds like it could have been written about anyone in my field, rewrite it until it could only have been written about me.
The identity scaffold structure (Role / Credentials / Primary platform / Tools / What I actually do / Identity stack / What I want a peer to know / What I want a recruiter to know) is reusable across roles. Swap the field values for your own and the hive aligns to whatever profile you're writing — wireless engineer, accountant, ops manager, lawyer. The structure is the trick; the values are personal.
Fill in each field on the Project screen. Replace anything in [brackets] with your own information.
| Field | What to enter |
|---|---|
| Document type * | Thank-you letter |
| Target audience * | The person receiving it — be specific: e.g. My hiring manager John Smith, A client named Sarah at Acme Corp, My mentor Dr. Jones |
| Desired outcome * | Reader feels genuinely appreciated and remembers the specific moment I am referencing. |
| Scope & constraints | No generic openers like "I hope this finds you well." No corporate sign-offs like "Best regards." One specific moment or gesture must be named — no vague thank-yous. |
| Tone & voice | [Warm and personal / professional but sincere / heartfelt] — pick one |
| Additional instructions | Reference the specific thing I am thanking them for. Do not add any details I have not provided. Do not fabricate anything. |
| Length Constraint (field below the goal fields) | Enter 200 · select Words |
| Desired outcome | Generate a thank-you letter from scratch using only the bullet points I provide in Notes. Make it feel specific and genuine — not generic. |
| Project name | Thank-You — Marco Contractor |
| Version | v1 |
| Document type | Thank-you letter |
| Target audience | Marco Delgado, general contractor who led the remodel of our kitchen and back porch |
| Desired outcome | Marco feels genuinely appreciated and remembers the specific moment that made this job different. I want him to feel like he can use this as a reference in his own work. |
| Scope & constraints | No "I hope this finds you well." No "Best regards." Name the one specific thing he did that went beyond. Handwritten tone — this is going in a card, not an email. |
| Tone & voice | Warm, personal, specific — from one person to another, not a form letter |
| Additional instructions | Do not invent details. Only use what is in Reference Material. Don't mention price — this isn't about money. |
| Length Constraint | Enter 200 · select Words |
| Starting Document | Click Start from Scratch and leave the text box empty |
Marco Delgado, owner of Delgado Build, finished our kitchen and back porch remodel last Friday. Things to thank him for: - The big one: when the countertop supplier delivered the wrong slab on day 17 and the project was going to slip two weeks, Marco drove to Orlando on a Saturday, picked up the right slab himself, and installed it Sunday morning. We had our son's birthday party on the new porch the following Saturday as planned. - He showed up when he said he would, every day, for six weeks. - His crew cleaned up every night — my wife kept commenting on it. - He caught a framing issue the inspector missed and fixed it before closing the wall. What we want him to know: - We'll absolutely use him again. - Our neighbor Janet has already asked for his number. - He's welcome to drop by and show the kitchen to a future client if he ever needs to.
If the result sounds like a corporate email instead of a personal letter, add a Note before the next round: "This should sound like a real person wrote it, not a template. Rewrite any sentence that sounds generic or corporate."
Fill in each field on the Project screen. Replace anything in [brackets] with your own information. The Scope & constraints field is where you tell the hive who you are and what you sell — fill in the identity/offering/pricing scaffold below the section list.
| Field | What to enter |
|---|---|
| Document type * | Business proposal |
| Target audience * | [Client name or type] — be specific: e.g. IT Director at a mid-size manufacturing firm, Procurement committee at [company name], Owner Operator at [client business] |
| Desired outcome * | Reader approves the proposal or schedules a follow-up meeting. They clearly understand what we are offering, what it costs, and what happens next. |
| Scope & constraints | Required sections: executive summary, problem statement, proposed solution, pricing or next steps. Do not add claims not supported by the existing content. Identity & offering — fill these in: • Who you are: [your company name + what kind of business] • Services or products you offer: [be specific] • What you do NOT offer: [explicit guardrail — e.g. "Do not invent services I don't offer"] • Pricing structure: [hourly rate + minimum, or fixed-fee, or tiered packages] |
| Tone & voice | Confident, credible, professional — not salesy |
| Additional instructions | Do not change any pricing figures, timelines, or deliverable commitments. These are factual. Use [PRICE] or [TIMELINE] as placeholders where you've left them blank. |
| Length Constraint (field below the goal fields) | Range mode, 1–2 pages (template default — 1 page = ~600 words, 2 pages = ~1200 words). Adjust if your proposal needs different length bounds. |
| Setup 5 — Starting Document | Click Start from Scratch and leave the text box empty. The hive will build the proposal from your Project-screen Scope & constraints field — that's where your company name, services, pricing, and "what I don't do" guardrails live now. No Notes-drawer setup needed before Round 1; the identity content is already in the prompt envelope via Scope. |
| Project name | BP - Wireless Survey Service for Brightwater Canoe and Kayak |
| Version | v1.0 |
| Document type | Business proposal |
| Target audience | Brightwater Canoe and Kayak — Owner Operator |
| Desired outcome | Reader approves the proposal or schedules a follow-up meeting. They clearly understand what we are offering, what it costs, and what happens next. |
| Scope & constraints | Required sections: executive summary, problem statement, proposed solution, pricing or next steps. Do not add claims not supported by the existing content. I am Eye Productions a full service Wireless Engineer. I can do surveys (predictive, active and passive, validation) and troubleshooting as well as turnkey operations and deployment my basic service rate is $100 an hour min 4 hours. Do not make up stuff I don't do |
| Tone & voice | Confident, credible, professional — not salesy |
| Additional instructions | Do not change any pricing figures, timelines, or deliverable commitments. These are factual. Use $100/Hour as placeholders where I have left them blank. |
| Length Limit | Range mode, 1–2 pages |
| Hive composition | Builder: Gemini (free tier). Reviewers: ChatGPT (paid), Claude (paid), Gemini-as-reviewer (free). All other AIs toggled off via the per-session bee toggles on the work screen. |
| Starting Document | From Scratch (no draft pasted) — the proposal was generated entirely from Setup 3 fields. Identity, services, and pricing all flowed in through Scope & constraints; no Notes-drawer pre-injection needed. |
The "Do not make up stuff I don't do" line in the Brightwater example is the most important sentence in that Scope field. AIs default to filling gaps with plausible-sounding boilerplate; an explicit anti-invention guardrail keeps the proposal honest. State exactly what you don't offer alongside what you do — "I do not provide ongoing managed services. Do not invent ongoing service tiers." — and the hive will respect those boundaries through every round.
Fill in each field on the Project screen. Replace anything in [brackets] with your own information.
| Field | What to enter |
|---|---|
| Document type * | Be specific about the email type: e.g. Cold outreach email, Follow-up email after a meeting, Sales introduction email |
| Target audience * | Who is receiving this — be specific: e.g. VP of Engineering at a mid-size SaaS company, A former colleague I have not spoken to in two years, Hiring manager who interviewed me last week |
| Desired outcome * | Reader opens it, reads it in full, and takes one specific action — e.g. replies to schedule a 20-minute call, clicks the link, responds with a yes or no. |
| Scope & constraints | Lead with value to the recipient — not background on the sender. One clear ask only. No fluff, no jargon, no "I hope this email finds you well." Include a subject line as the first line of the document. |
| Tone & voice | [Professional / direct / warm] — pick one. For cold outreach, direct tends to work better than warm. |
| Additional instructions | Do not add background about me unless I specifically provide it. The email should be about what the reader gets, not who I am. |
| Length Constraint (field below the goal fields) | Enter 150 · select Words |
| Desired outcome | Generate a complete email from scratch using only what I provide in Notes. Lead with value to the recipient. One clear ask. Include a subject line as the first line. |
| Project name | Outreach — Ferris at Lightkeeper |
| Version | v1.0 |
| Document type | Cold outreach email to a potential channel partner |
| Target audience | Ferris Okafor, VP of Partnerships at Lightkeeper Security, a managed security services firm. We've never spoken. He's active on LinkedIn and posts about SMB cybersecurity. |
| Desired outcome | Ferris replies to schedule a 20-minute intro call. One clear ask, no bait-and-switch. |
| Scope & constraints | Lead with value to him, not background on us. One ask. No "I hope this email finds you well." Include a subject line as the first line. Reference one thing from his recent LinkedIn activity so it doesn't read as scraped. |
| Tone & voice | Direct, warm, not a vendor |
| Additional instructions | Do not add claims about our company unless they appear in Reference Material. Do not oversell the first call — the ask is 20 minutes, nothing more. |
| Length Constraint | Enter 0.5 · select Pages |
| Starting Document | Click Start from Scratch and leave the text box empty |
Ferris's recent LinkedIn post (last week): he wrote that most SMB security incidents start with unmanaged wireless — not ransomware, not phishing. Direct quote: "your MSP partner should be treating your Wi-Fi like a security surface, not a convenience." Our company: Altura Systems, a 14-person MSP in Tampa. We run wireless for about 40 SMB clients across healthcare and legal. We've seen the same pattern Ferris is describing — clients keep getting breached through guest SSIDs that were stood up in 2019 and forgotten. The ask: 20-minute intro call to see if the pattern he's describing matches what we're seeing. Sender: - Name: Dana Reyes - Role: Director of Wireless Services, Altura Systems
Short emails sometimes produce conflicts over single word choices. If a conflict feels trivial, use the Builder Decision path and let the Builder decide — or bypass it if you have already made the edit directly in the document.
Fill in each field on the Project screen. Replace anything in [brackets] with your own information.
| Field | What to enter |
|---|---|
| Document type * | Executive summary |
| Target audience * | Be specific about who reads this — e.g. VP of Operations and CFO, Board of Directors, Program managers and senior leadership |
| Desired outcome * | Reader understands the situation, the recommendation, and why it matters — in that order. They can make a decision or take action without reading the full source document. |
| Scope & constraints | Lead with the conclusion. Strip jargon. Do not expand — only tighten and clarify what is already here. |
| Tone & voice | Direct, authoritative, jargon-free — written for someone who has 90 seconds to read it |
| Additional instructions | Do not add detail not present in the source material. Do not change any figures, recommendations, or conclusions. |
| Length Constraint (field below the goal fields) | Enter 400 · select Words — or enter 1 · select Pages for a one-pager |
| Desired outcome | Generate an executive summary for [project, report, or initiative name] from the bullet points I provide. Answer three questions in order: what is the situation, what is the recommendation, why does it matter. Lead with the conclusion. |
If the AIs keep adding detail back in, open Notes before the next round and write: "Do not expand this document. Only tighten and clarify what is already here. Remove anything that does not directly support the recommendation."
Fill in each field on the Project screen. Replace anything in [brackets] with your own information.
| Field | What to enter |
|---|---|
| Document type * | RFP response |
| Target audience * | Evaluation committee at [issuing organization] reviewing responses to [RFP name or number] |
| Desired outcome * | Every stated requirement in the RFP is addressed directly and clearly. Evaluators can find our response to each item without hunting for it. Our differentiators are clear and credible. |
| Scope & constraints | Formal, precise, no marketing language. Do not add capability claims not supported by the existing content. Address requirements in the order they appear in the RFP. |
| Tone & voice | Formal, authoritative, direct — this is a compliance document, not a sales pitch |
| Additional instructions | Do not change any figures, dates, or technical specifications. Do not omit or skip any RFP requirement, even if the answer is brief. |
| Length Constraint (field below the goal fields) | Check the RFP for a page or word limit and enter it here — e.g. 20 · Pages. Leave blank if the RFP has no stated limit. |
| Desired outcome | Generate a draft RFP response for [project name] issued by [organization]. We are [brief description of your team or company]. Our relevant experience: [list]. Address each requirement in the order it appears in the RFP. Do not add capability claims not supported by what I provide. |
If the RFP has a page or word limit, enter it in the Length Constraint field on the Project screen — that is where it belongs, not in the goal fields. WaxFrame will enforce it as a hard constraint every round.
Fill in each field on the Project screen. Replace anything in [brackets] with your own information.
| Field | What to enter |
|---|---|
| Document type * | Blog post — or be specific about format: e.g. Opinion piece, How-to article, Listicle |
| Target audience * | Who reads this and where — e.g. Small business owners new to AI, reading on LinkedIn, Senior engineers evaluating wireless platforms |
| Desired outcome * | Reader finishes the post and [takes a specific action or understands a specific thing]. End with a clear call to action. e.g. Reader understands the three main options and clicks through to learn more. |
| Scope & constraints | Must cover: [list 3–5 key points]. Do not add statistics or facts that are not already in the draft — flag anything uncertain instead of inventing it. |
| Tone & voice | Be specific: e.g. Direct, short sentences, slightly sarcastic, no jargon or Authoritative and data-driven, formal but approachable. Without this the AIs will default to a bland, generic style. |
| Additional instructions | Do not change my unique angle or perspective. Strengthen the voice — do not sand it down into something that sounds like everyone else. |
| Length Constraint (field below the goal fields) | Enter your target word count — e.g. 800 · Words |
| Desired outcome | Generate a complete [X-word] blog post on [topic] from the notes I provide. My unique angle is [describe what makes your take different]. Build the full post from my key points — do not add facts or statistics I have not provided. |
| Project name | Blog — Why I Stopped Trusting One-Shot AI |
| Version | v1.0 |
| Document type | Blog Post |
| Target audience | Senior engineers and technical leads who already use ChatGPT or Claude for work, reading on LinkedIn or a company-internal blog |
| Desired outcome | Reader finishes the post and understands why running a document through multiple AI models in sequence produces meaningfully better output than a single high-quality model. They click through to the linked demo at the end. |
| Scope & constraints | Cover: the "one-shot trap," why different models catch different issues, a concrete example with rough numbers, and what the reader can try today. Do not invent statistics. |
| Tone & voice | First-person, slightly opinionated, conversational — written the way you'd say it out loud, not how you'd write a whitepaper. Voice is someone who's been frustrated with single-model output for a year and finally solved the problem. Not promotional. Not AI-generated-sounding. |
| Additional instructions | No buzzwords like "synergy," "leverage," "revolutionary." If a section feels padded, cut it. No marketing fluff just real world shit. |
| Length Constraint | Leave blank |
| Starting Document | Click Upload File and select your existing draft post (a .docx, .txt, or .md file) |
Thesis: any single LLM, no matter how good, has blind spots. One model will confidently write fluff where another catches it. One model will tighten structure while another improves tone. Run the same document through 4 or 5 different models in sequence, each refining what the previous one did, and the output is better than any single model can produce on its own. Concrete example to reference (real, from last month): - Took a 900-word draft of a proposal - Ran it through Claude alone: got a polished version, maybe 15% better - Ran the same draft through Claude, then GPT-4, then Gemini, then back to Claude: got a version where the structural argument was noticeably stronger, the jargon was stripped, and two factual hedges had been flagged that the author hadn't noticed What the reader should try today: pick a document they care about, hand it to 3 different models in sequence with the same prompt, compare the result to running it through any one model once. Call to action at the end: link to a tool that automates this — multiple models, single document, convergence loop. (This is WaxFrame, but the post should not name it overtly — the link speaks for itself.)
If the voice starts sounding generic after a few rounds, open Notes and describe the author's style in a sentence — even a few adjectives like "direct, slightly sarcastic, uses short sentences" will steer the hive back toward a distinct voice.
Fill in each field on the Project screen. Replace anything in [brackets] with your own information.
| Field | What to enter |
|---|---|
| Document type * | LinkedIn Post |
| Target audience * | My LinkedIn network — be specific: e.g. Wireless engineers, IT managers, recruiters in my field, Former colleagues from my last industry, current peers in this one. They scroll fast. If the first two lines don't land, they keep scrolling. |
| Desired outcome * | Reader stops scrolling, reads the whole post, and either comments or sends a connection request. Post should feel earned, not braggy. |
| Scope & constraints | Cover one specific topic with a clear opinion or lesson. Hook in the first line. Use real numbers and specifics where you have them. End with a question that invites comments. Do not name a current employer if there are confidentiality or OPSEC concerns. |
| Tone & voice | Conversational, direct, no LinkedIn-influencer voice. Sounds like a peer talking to peers, not a thought leader trying to grow an audience. |
| Additional instructions | No "I'm proud to announce," "thrilled," or "humbled" — the LinkedIn opener virus. No emojis except maybe one at the end. No call to "DM me to learn more." No buzzwords (synergy, leverage, revolutionize). If a paragraph reads like a brochure, cut it. |
| Length Constraint | 2000 characters (LinkedIn's hard cap), hardcap mode |
| Setup 4 — Reference Material | Paste the topic, the specific facts and numbers you want to anchor the post around, the lesson or opinion you want it to land on, and the question you'd like to end with. The hive uses Reference Material as source-of-truth — anything you put here will be reflected directly in the post; anything you don't put here, the AIs will not invent. |
| Project name | LinkedIn Post — 6 Months in and what I have learned about DFS |
| Version | v1.0 |
| Document type | LinkedIn Post |
| Target audience | My LinkedIn network (wireless engineers, former colleagues from the cable industry I was in for 30 years, some assorted high school classmates, IT people, and a few recruiters) |
| Desired outcome | Reader stops scrolling, reads the whole post, and either comments or sends a connection request |
| Scope & constraints | Cover: What is DFS, who uses it and why. How many channels does 5 GHz have and how many are DFS. Do not cover any other frequency. Explain CCI and how those of us in the industry are now calling it CCC because it isn't "really interference" you are mitigating. Explain how it is now inevitable in a mixed-use (office, production, warehouse) large building (some as big as 952k sq ft). My company is in defense and I abandoned DFS immediately after being hired. |
| Tone & voice | Technical, direct, a bit sarcastic but willing to teach |
| Additional instructions | We now call CCI "CCC" thanks to my friend Peter MacKenzie (@mackenziewifi) |
| Length Limit | 2000 characters, hardcap |
| Hive composition | Builder: Gemini (free tier). Reviewers: ChatGPT (paid), Claude (paid), Gemini-as-reviewer (free). All other AIs toggled off via the per-session bee toggles on the work screen. |
| Starting Document | From Scratch (no draft pasted) — the post was generated entirely from Setup 3 fields and the Tone direction |
If you work in a sensitive industry (defense, healthcare, finance, legal), keep employer specifics out of the post. "My company is in defense" is fine; naming the company, the building square footage, the specific platforms, or active vendor evaluations is not. The DFS post above worked because it discussed a universal RF problem with attribution to a public industry figure (Peter MacKenzie) — none of the content was company-confidential. State your OPSEC constraints in Scope & constraints explicitly: "Do not name my employer. Do not reference any active project."
Fill in each field on the Project screen. Replace anything in [brackets] with your own information.
| Field | What to enter |
|---|---|
| Document type * | Presentation outline — speaker notes format |
| Target audience * | The audience for the talk — e.g. C-suite leadership team, New hire onboarding group, External conference attendees |
| Desired outcome * | A slide-by-slide outline ready to copy into a presentation tool. Each slide must have: a slide title, 3–5 speaker note bullets, and one suggested visual or data point. Open with a strong hook, close with a clear call to action. |
| Scope & constraints | [X]-minute talk. [Number] slides maximum. Bullet points only — no prose paragraphs. This is a speaker outline, not a script. WaxFrame outputs text — you will paste this into your presentation tool separately. |
| Tone & voice | [Informative / persuasive / conversational] — match the formality level of the audience |
| Additional instructions | Do not write full sentences in the speaker bullets. Keep each bullet to one line. Do not add slides beyond the count I specify. |
| Desired outcome | Generate a complete slide-by-slide presentation outline for a [X]-minute talk on [topic]. Each slide: title, 3–5 speaker note bullets, one suggested visual. Open with a hook, close with a call to action. Build it from the topic list I provide in Notes. |
| Project name | Deck Outline — Wi-Fi 7 Readiness |
| Version | v3.0 |
| Document type | Powerpoint Presentation |
| Target audience | IT leadership at a 1,200-person professional services firm — CIO, Director of Infrastructure, and two senior architects, sitting in a 45-minute meeting |
| Desired outcome | Audience leaves with a clear answer to one question: should we include a Wi-Fi 7 pilot in our FY27 budget? The outline should end with a concrete recommendation, not a list of considerations. |
| Scope & constraints | Maximum 12 slides. Opening slide is the question, closing slide is the recommendation with a dollar figure. No "agenda" slide. No "thank you" slide. |
| Tone & voice | Executive-ready, direct, no hedging. If the answer is "not yet," say "not yet" and explain why. |
| Additional instructions | Structure the information to fit on slides. Don't write speaker notes I'll do that later |
| Length Constraint | Leave blank — the "Maximum 12 slides" line in Scope is the cap that mattered |
| Starting Document | Click Start from Scratch and leave the text box empty |
Driving question: "Should we pilot Wi-Fi 7 in FY27, or wait?" Recommendation: pilot in FY27 at a single floor of HQ, budget $95k, defer enterprise-wide deployment to FY28 or FY29 depending on client device penetration. Reasoning: - Wi-Fi 7 standard is ratified. Enterprise APs are shipping in volume from Cisco, Aruba, Juniper, Extreme. - Client device penetration is still low — under 12% of the user base has a Wi-Fi 7 capable endpoint as of Q1 2026. No reason to refresh the fleet now. - HQ 14th floor is being refreshed in FY27 anyway due to an expiring lease remodel. That gives a "free" pilot footprint. - Pilot goals: validate real-world throughput gains, test roaming behavior with mixed Wi-Fi 6E and Wi-Fi 7 clients, train the team on the new management platform. - If pilot is successful, shovel-ready plan for FY28 enterprise rollout. If not, $95k spent to learn instead of $2.1M to fail. Context the deck must establish: - Where we are today: Wi-Fi 6E, Aruba Central managed, last refreshed FY24 - Where the industry is going: Wi-Fi 7 ratified, deployment guidance from Gartner suggests "selective pilots in FY26/FY27, mainstream in FY28" - Client device mix: 70% corporate-managed laptops, 25% BYOD phones, 5% IoT/sensors Hard constraints: - FY27 budget cycle closes in July 2026. Decision must happen before then. - Any dollar figure in the deck is directional — detailed pricing comes from the RFP, not this deck.
WaxFrame outputs plain text. Once the outline is where you want it, export it and use it as your script layer when building the actual slides in PowerPoint or Keynote. Each slide's bullet points become your speaker notes.
Fill in each field on the Project screen. Replace anything in [brackets] with your own information.
| Field | What to enter |
|---|---|
| Document type * | Recipe |
| Target audience * | Who will cook from this — e.g. Home cook, beginner level, Experienced baker, Meal prep audience, intermediate skill |
| Desired outcome * | Anyone following this recipe can cook the dish successfully on the first try. Instructions are clear, ingredient quantities are precise, and steps are in a logical order with nothing assumed. |
| Scope & constraints | Do not change the core recipe — only clarify and improve what is there. Ingredient quantities and cooking times must stay as written. Include: ingredient list with quantities, numbered steps, and at least one tip on substitutions or storage. |
| Tone & voice | [Warm and conversational / precise and technical / beginner-friendly] — pick one |
| Additional instructions | Do not substitute ingredients without flagging it as an optional variation. Do not add unverified cooking times or techniques — flag anything uncertain instead of inventing it. |
| Desired outcome | Generate a complete recipe for [dish name] from the notes I provide. Include an ingredient list with quantities, numbered steps, and at least one tip on substitutions or storage. Do not add unverified techniques or cooking times. |
| Scope & constraints | Cuisine or tradition: [e.g. Southern Italian, Korean BBQ, or leave blank]. Servings: [X]. Build only from the ingredients and details I provide. |
If you want the recipe to stay true to a specific cuisine or tradition, state it explicitly in Scope & constraints: "Keep this authentic to Southern Italian technique — do not substitute ingredients or modernise methods." Without this the AIs will suggest variations freely.
Fill in each field on the Project screen. Replace anything in [brackets] with your own information.
| Field | What to enter |
|---|---|
| Document type * | Letter to my [contractor / vendor / service provider] regarding [the first invoice / scope dispute / punch-list items] |
| Target audience * | The [contractor / vendor / project manager] who did the work — be specific about the relationship: The general contractor we hired, The vendor that installed our HVAC |
| Desired outcome * | A clear, professional record of my concerns and the items I need addressed before [I pay / we close out the project / we move forward]. The recipient understands what is wrong, what I expect, and what comes next. |
| Scope & constraints | Include all of the items I have listed including pricing but don't make anything else up and don't change my dollar figures — they are all actual. Keep my factual claims (dates, amounts, names) intact. |
| Tone & voice | Professional and courteous but firm. Not adversarial, not apologetic. |
| Additional instructions | Do not soften my concerns. Do not invent context, dates, or amounts I haven't provided. If a section is unclear, suggest a rewording rather than guessing what I meant. |
| Project name | Bay Area First Invoice Concerns |
| Version | v3.0 |
| Document type | Letter to my contractor regarding the first invoice |
| Target audience | The contractor that did the work |
| Desired outcome | a better understanding of my concerns about the costs and the work performed and an explanation of items that need to be addressed before I pay him |
| Scope & constraints | Include all of the items I have listed including pricing but don't make anything else up and don't change my dollar figures they are all actual |
| Tone & voice | Professional and courteous but firm |
| Additional instructions | (blank — Notes left empty for this run) |
| Length Constraint | Leave blank |
| Hive composition | Builder: Gemini (free tier). Reviewers: ChatGPT (paid), Claude (paid), Gemini-as-reviewer (free). All other AIs toggled off via the per-session bee toggles on the work screen. |
| Starting Document | Existing draft pasted in (refining, not from scratch) |
State your factual constraints explicitly in Scope & constraints: "Don't change my dollar figures — they are all actual." Without this, AIs will round, rephrase, or "improve" specific numbers and dates in ways that quietly invalidate your record. The literal language above kept all dollar amounts and the 75% overrun calculation intact across 12 rounds.
Fill in each field on the Project screen. Replace anything in [brackets] with your own information. Fields marked * are required to continue.
| Field | What to enter |
|---|---|
| Document type * | Restaurant review |
| Target audience * | People deciding whether this restaurant is worth visiting. They want practical details about food, service, atmosphere, value, and logistics, not vague praise or complaints. |
| Desired outcome * | Create a useful, honest review that explains what the experience was actually like, what was ordered, what was good, what was disappointing, whether the price made sense, and whether I would return. |
| Scope & constraints | Include visit context, food and drinks ordered, pricing if known, service, atmosphere, cleanliness, parking or location notes, standout items, disappointments, and final recommendation. Do not invent dishes, prices, staff names, dates, or facts that were not provided. |
| Tone & voice | Conversational, detailed, fair, practical, and direct. Preserve the reviewer's natural voice. Honest criticism is fine, but avoid making it sound like a rant unless the source material genuinely supports that tone. |
| Additional instructions | End with a clear bottom line: whether I would return, who this restaurant is best for, and any specific warning, recommendation, or timing advice for future visitors. |
| Length Constraint (field below the goal fields) | Default 500 · select Words. For Google Maps use 750–1,200 · Characters. For TripAdvisor leave blank for full long-form. |
| Desired outcome | Generate a complete restaurant review from the details I provide in Reference Material (Setup 4). Organize the review around the actual visit, what I ordered, food quality, service, atmosphere, value, and final recommendation. |
| Additional instructions | If important details are missing, write around them without inventing. Do not add fake menu items, fake prices, fake staff names, or fake dates. |
Reference Material persists across every round and is never altered by the hive — exactly the right home for raw visit facts. Notes is for one-shot mid-round Builder tweaks (like "tighten the third paragraph"), not setup facts.
Restaurant: Location: Date/time: Who was there (solo / couple / family / group / business): Dine-in / takeout / delivery / patio / bar: Reservation or walk-in: Parking notes: First impression of exterior/interior: Noise / lighting / seating / cleanliness: What was ordered (drinks, apps, entrées, sides, dessert): Prices remembered: Food quality (flavor, temperature, portion, freshness, presentation): Best item: Worst item or disappointment: Service quality: Problems and how staff handled them: Would you return: Who is this restaurant best for:
| Project name | Review - Pearl's Saltwater Grille |
| Version | v2.0 |
| Document type | Restaurant review |
| Target audience | People deciding whether this restaurant is worth visiting. They want practical details about food, service, atmosphere, value, and logistics, not vague praise or complaints. |
| Desired outcome | Create a useful, honest review that explains what the experience was actually like, what was ordered, what was good, what was disappointing, whether the price made sense, and whether I would return. |
| Scope & constraints | Include visit context, food and drinks ordered, pricing if known, service, atmosphere, cleanliness, parking or location notes, standout items, disappointments, and final recommendation. Do not invent dishes, prices, staff names, dates, or facts that were not provided. |
| Tone & voice | Conversational, detailed, fair, practical, and direct. Preserve the reviewer's natural voice. Honest criticism is fine, but avoid making it sound like a rant unless the source material genuinely supports that tone. |
| Additional instructions | End with a clear bottom line: whether I would return, who this restaurant is best for, and any specific warning, recommendation, or timing advice for future visitors. |
| Length Constraint | Range — 200 to 1,500 words |
| Starting Document | Upload (or paste) the v1.0 draft below into Setup 5 — Starting Document |
| Desired outcome | Generate a complete restaurant review from the details I provide in Reference Material (Setup 4). Organize the review around visit context, food and drinks, service, atmosphere, value, and final recommendation. |
| Additional instructions | If important details are missing, do not invent them. Focus on the details provided and flag missing items only if needed. |
Savannah, GA " A romantic dining establishment directly on the water" I made reservations at this location online for Saturday 8:30 PM through the OpenTable app. In the notes I asked for a booth. When I arrived I was told that a table was not quite yet ready and I could head to the bar. We did so and just as we were ordering a drink we were told that the table was ready. It would seem that this location does not have any booths but we were seated right by the window on a four top. For entrées we ordered the shrimp and grits and stuffed fish with crab. I had glanced over a few reviews so I ordered a cup of she crab soup to try it out because all of the reviews rave about it. It did not disappoint! Additionally we were brought out a basket of hush puppies that were perfectly golden brown and served up with an herb butter that was delicious. Truthfully, these were the best hush puppies I've had in years. The flavor was perfect and they were not dry at all. For a little variety I even dunked them in to the soup. I really couldn't stop eating them and there were quite a few in the basket. Our entrées came really quickly. My fish was perfectly prepared and not only was it stuffed with crab but there was additional crab next to the Rice that easily amounted to quite a few ounces of crab I was pretty impressed. The only change I made to the dish was scrapping the asparagus in lieu of the mixed vegetables, including zucchini, squash, and carrots. The shrimp and grits contained decent sized shrimp wrapped with bacon and an occasional bit of andouille sausage. The grits were creamy and delicious as well. Although I was relatively stuffed I ordered the peach cobbler. I must preface by saying that I truly love desserts and this did not disappoint! It was served warm in a special ramekin with crumbly cobbler and whole peach slices. Ice cream was served on the side which was perfect topped with whipped cream. Needless to say I made room! As for the ambience, the restaurant is of medium noise level the tables are not really isolated all that much although there is some separation and each table does have a candle on it which is a nice touch of course. Just before we received our entrée, we were able to go out onto the deck and take some really nice pictures even though the sun had already gone down. If am ever in the area again I will definitely revisit this fine restaurant.
The best restaurant reviews aren't just about whether the food was good. They tell the reader what to expect: parking, seating, noise, service pacing, portion size, prices, and whether the place is worth the money. Specifics outperform adjectives.
Fill in each field on the Project screen. Fields marked * are required to continue.
| Field | What to enter |
|---|---|
| Document type * | Hotel review |
| Target audience * | Travelers deciding whether to book this hotel — especially business travelers, families, road-trippers, or people comparing nearby properties. |
| Desired outcome * | Create a detailed, practical hotel review that helps readers understand the room, sleep quality, location, amenities, service, value, and any problems that affected the stay. |
| Scope & constraints | Cover trip context, room type or room number if provided, rate/value, check-in, room layout, cleanliness, bed, bathroom, HVAC, noise, darkness, internet, breakfast, gym, pool, bar, parking, location, staff, and final recommendation. Do not invent amenities, prices, loyalty benefits, room numbers, or facts. |
| Tone & voice | Practical, detailed, fair, and conversational. Preserve useful personal observations and specific traveler-focused details. |
| Additional instructions | Include whether I would stay again and what type of traveler this hotel is best suited for. Mention dealbreakers clearly. |
| Length Constraint (field below the goal fields) | Default 800 · select Words. For Google Maps use 750–1,200 · Characters. For TripAdvisor leave blank for full long-form. |
| Desired outcome | Generate a complete hotel review from the details I provide in Reference Material (Setup 4). Organize the review around the stay context, check-in, room, sleep quality, bathroom, amenities, location, value, and final recommendation. |
| Additional instructions | If important details are missing, do not invent them. Focus on the details provided and flag missing items only if needed. |
Reference Material persists across every round and is never altered by the hive — exactly the right home for raw stay facts. Notes is for one-shot mid-round Builder tweaks (like "tighten the third paragraph"), not setup facts. Writing a review weeks after the trip? The checklist scaffolds your memory by prompting for the specifics that matter — bed, noise, HVAC, blackout curtains, hot water, Wi-Fi, parking, fees — the stuff that fades fast.
Hotel: Location: Dates of stay: Trip type (business / vacation / family / event / road trip): Who was there (solo / couple / family / group): Room type and number if relevant: Rate / points / resort fee / parking fee / other fees: Check-in experience: Staff interactions: Room size, layout, furniture, outlets, desk: Cleanliness and maintenance: Bed and pillows: Noise (hallway, street, airport, neighbors, elevators, kids): Room darkness / blackout curtains: HVAC / temperature control: Bathroom layout, shower pressure, hot water, towels, toiletries: Wi-Fi speed and reliability: Breakfast quality and variety: Gym / pool / bar / lounge / laundry / shuttle / parking: Nearby restaurants / walkability / transit / airport / attractions / work site: Problems and how staff handled them: Would you stay again: Who is this hotel best for:
| Project name | Review — Melbourne Marriott Hotel |
| Version | v1.0 |
| Document type | Hotel review |
| Target audience | Travelers deciding whether to book this hotel — especially business travelers, families, road-trippers, or people comparing nearby properties. |
| Desired outcome | Create a detailed, practical hotel review that helps readers understand the room, sleep quality, location, amenities, service, value, and any problems that affected the stay. |
| Scope & constraints | Cover trip context, room type or room number if provided, rate/value, check-in, room layout, cleanliness, bed, bathroom, HVAC, noise, darkness, internet, breakfast, gym, pool, bar, parking, location, staff, and final recommendation. Build only from the stay details in my Reference Material — do not invent amenities, prices, loyalty benefits, room numbers, or facts. |
| Tone & voice | Practical, detailed, fair, and conversational. Preserve useful personal observations and specific traveler-focused details. |
| Additional instructions | Include whether I would stay again and what type of traveler this hotel is best suited for. Mention dealbreakers clearly. |
| Length Constraint | No limit (template default — set per-platform at publish time) |
| Starting Document | Click Start from Scratch and leave the text box empty |
Hotel: Melbourne Marriott Hotel Location: Corner Exhibition and Lonsdale Streets, Melbourne Dates of stay: 04/01/2026 - 04/03/2026 Trip type (business / vacation): I was traveling to Australia for the first time ever and it was a last minute work trip that I pulled together in 4 days. Who was there: Solo Room type and number if relevant: 1 Bedroom King Suite, Room 403 Rate / points / resort fee / parking fee / other fees: AUD $320-$350 a night credit card fee of $13.07 Check-in experience: I arrived early and was prepared to drop my bags and just take off exploring but they provided me a room instead! Staff interactions: Excellent and Friendly staff who were expedient. Room size, layout, furniture, outlets, desk: Very Spacious Suite view of the city corner and nightlife. Cleanliness and maintenance: quite clean and well maintained property Bed and pillows: Comfortable bed and I always ask for extra pillows and had no trouble getting them here. Noise (hallway, street, airport, neighbors, elevators, kids): Very quiet Room darkness / blackout curtains: It was probably almost a 9 with the bedroom door shut. With it open it was more like a 7 out of 10 HVAC / temperature control: excellent I sleep cold and this was great. I lowered it as low as it would go in celcius and it felt great Bathroom layout, shower pressure, hot water, towels, toiletries: Water pressure on the shower was AMAZING definitely an incredible feature Wi-Fi speed and reliability: wi-fi at my level is free for "gold" and I never had any issues connecting or using the wifi Breakfast quality and variety: This breakfast was the highlight! It was the most amazing breakfast I have ever had in any Marriott property ANYWHERE. It was filled with traditional, and non-traditional items, 5 juices, pastries and danishes, fresh fruit, savory and sweet options I mean it was amazing the wait staff are super friendly and accommodating. Nearby restaurants / walkability / transit / airport / attractions / work site: This is in the heart of downtown and you can walk to comedy clubs, shows, restaurants and parks. It's really in the thick of it. There is even a 7-11 directly across the street for last minute I forgot items. Problems and how staff handled them: Would you stay again: YES! Who is this hotel best for: Business and pleasure travelers alike
For hotel reviews, sleep quality and hidden friction matter more than lobby marketing. Noise, HVAC, blackout curtains, hot water, Wi-Fi, parking, and fees are often what help the next traveler most.
Fill in each field on the Project screen. Fields marked * are required to continue.
| Field | What to enter |
|---|---|
| Document type * | Business or service review |
| Target audience * | People deciding whether to hire, visit, book, or use this business. They care about reliability, value, professionalism, communication, and how problems are handled. |
| Desired outcome * | Create a fair but useful review that explains why I used the business, what happened, what went well, what went wrong, how the business handled it, and whether I would recommend them. |
| Scope & constraints | Include reason for using the business, booking or arrival process, staff behavior, service quality, pricing/value, problems, resolution attempts, observed business practices, and final recommendation. Do not exaggerate, speculate beyond the facts, or invent details. |
| Tone & voice | Clear, direct, specific, and fair. Honest criticism is allowed, but avoid sounding like a rant unless the source material genuinely supports it. |
| Additional instructions | End with practical advice: who should use this business, who should avoid it, and what to watch out for. Do not add legal conclusions, accusations, or claims beyond the facts provided. |
| Length Constraint (field below the goal fields) | Default 500 · select Words. For Google Maps use 750–1,200 · Characters. For Yelp/TripAdvisor leave blank for full long-form. |
| Desired outcome | Generate a complete business or service review from the details I provide in Reference Material (Setup 4). Organize the review around why I used the business, what happened, staff behavior, service quality, value, problem handling, and final recommendation. |
| Additional instructions | Do not add legal conclusions, accusations, or claims beyond the facts provided. If the experience was negative, keep the review specific and evidence-based. |
Reference Material persists across every round and is never altered by the hive — exactly the right home for raw service-experience facts. Notes is for one-shot mid-round Builder tweaks (like "tighten the third paragraph"), not setup facts. "They quoted X, charged Y, did Z, and responded this way" is useful; "they ripped me off" is not — the more specific your details, the stronger and more defensible the review.
Business: Location: Type of service or product: Why you used them: Date/time: Booking process (app / website / phone / walk-in / reservation / estimate / quote): Price quoted vs. price paid: Arrival/check-in process: Staff behavior and communication: What went well: What went wrong: Delays / confusion / unexpected charges / damage / poor workmanship / service failures: How the business responded when a problem came up: Whether they fixed the issue: Observed practices future customers should know about: Would you use them again: Who should use them and who should avoid them:
Bad service reviews are strongest when they are specific. "They ripped me off" is weak. "They quoted X, charged Y, did Z, and responded this way" is useful. Keep the review grounded in what actually happened.
This is a refine-only template. It works on a review you already have — typically the output of the Restaurant, Hotel, or Business / Service playbook. You paste that source review in, and the hive shapes it into a TripAdvisor-format version. There is no "from scratch" path: write the review first with one of the review playbooks, then bring it here.
These fields are pre-filled by the template. Listed here so you know what the hive is working toward.
| Field | What the template sets |
|---|---|
| Document type | TripAdvisor review |
| Target audience | TripAdvisor readers deciding whether to visit or book based on detailed travel reviews — they want narrative arc, practical context, and an honest recommendation. |
| Desired outcome | Produce a TripAdvisor-ready review from the source: detailed narrative travel-context tone, 500–900 words, full experience arc from arrival to departure to recommendation. |
| Scope & constraints | Use only the facts from the source review. Preserve the chronological arc: arrival/booking context, the experience, the recommendation. Cut redundancy where helpful, but TripAdvisor readers expect detail — do not over-compress. |
| Tone & voice | Detailed narrative. Travel-context. Slightly more formal than Yelp, more thorough than Google Maps. Honest. Helpful. Specific. |
| Length Constraint (field below the goal fields) | Range · 500–900 · Words (pre-set). TripAdvisor rewards detail — this is the longest of the three platform formats. |
If your source review is significantly longer than 900 words, also paste it into Reference Material. That keeps the original visible to reviewers every round so they can verify facts and judge what got cut. If your source is already close to 500–900 words, Reference Material isn't necessary — the working document holds the same content. Reference Material persists across every round and is never altered by the hive; it's the right home for the source of truth.
Go to Setup 5 — Starting Document. Click Paste Text and paste your existing long-form review. The hive trims and reshapes it into the TripAdvisor format.
Write your full, messy review once with the Restaurant / Hotel / Business-Service playbook, then run it through Trim to TripAdvisor. You get a platform-ready version without re-writing from scratch or losing the facts — and the source stays in Reference Material so nothing drifts.
This is a refine-only template. It works on a review you already have. Google Maps cuts are aggressive — typical source-to-target ratio is 5–10×, so the source belongs in Reference Material where reviewers can check that the cuts kept the right facts. There is no "from scratch" path here.
These fields are pre-filled by the template. Listed here so you know what the hive is working toward.
| Field | What the template sets |
|---|---|
| Document type | Google Maps review |
| Target audience | Google Maps readers scanning quickly for the bottom line — they want the recommendation up front, the key facts that support it, and to leave. |
| Desired outcome | Produce a Google Maps-ready review: skim-friendly, bottom-line-first, 750–1,200 characters. Lead with the recommendation. Keep only the few facts that actually support the verdict. |
| Scope & constraints | Brutal cut. Drop the chronological narrative arc. Lead with the bottom line. Keep only specific details that justify the recommendation. Strip everything else. |
| Tone & voice | Direct. Practical. Skimmable. First-person fine. No fluff, no marketing-speak, no corporate polish. |
| Length Constraint (field below the goal fields) | Range · 750–1,200 · Characters (pre-set). Note that's characters, not words — Google Maps reviews are short. |
Strongly recommended: paste the source review into Reference Material as well. Google Maps cuts are brutal — a typical 800+ word source loses 70%+ of its content. Without the source visible every round, reviewers can't evaluate whether the cuts kept the right facts. Reference Material persists across every round and is never altered by the hive.
Go to Setup 5 — Starting Document. Click Paste Text and paste your existing review. If it's well over 1,200 characters, the Source Size Check will fire an oversized recommend card on paste — that's expected. Move the long source into Reference Material and let the working document hold the trimmed version as it forms.
The measured run trimmed an 888-word review to 1,003 characters in 5 rounds — that's the job. Don't fight the aggressiveness; Google Maps readers genuinely won't read more than ~1,200 characters. Keep the source in Reference Material so the hive cuts hard and safely.
This is a refine-only template. It works on a review you already have. Unlike the trim templates, the main job here isn't cutting length — it's voice transformation: same facts, rewritten into a real Yelp register. There is no "from scratch" path here.
These fields are pre-filled by the template. Listed here so you know what the hive is working toward.
| Field | What the template sets |
|---|---|
| Document type | Yelp review |
| Target audience | Yelp readers — they value real voice, personality, specific lived details. They smell fake reviews and corporate polish from a mile away. |
| Desired outcome | Rewrite the source review as a Yelp review: conversational, personality-forward, first-person, 300–700 words. Same facts, different prose register. Real voice. |
| Scope & constraints | Voice transformation is the main job. Same facts, different rendering. Casual phrasing OK. First-person fine. No corporate polish, no marketing-speak, no AI-generated blandness. |
| Tone & voice | Conversational, first-person, personality-forward. Casual phrasing ("honestly," "tbh," "look —") is fine when it fits. Specific lived details over generic praise. Yelp readers reward authenticity. |
| Length Constraint (field below the goal fields) | Range · 300–700 · Words (pre-set). Mid-length — enough room for voice to breathe without rambling. |
Recommended: paste the source review into Reference Material. Voice rewrites preserve facts, but the new prose register can mask drift — "he gave us instructions for wet conditions" quietly becoming "he gave us a free poncho" is invisible without the source for comparison. Reference Material keeps the original visible to reviewers every round so they can catch silent fact-slip while the voice changes.
Go to Setup 5 — Starting Document. Click Paste Text and paste your existing review. If it's over the 700-word ceiling, the Source Size Check will fire an oversized recommend card on paste — move the long source into Reference Material and let the working document hold the Yelp rewrite as it forms.
The measured run landed at 60% of the Yelp range versus the retired combined template's 10% — same source, dramatically better positioning. The single-platform template gives voice room to breathe instead of squeezing it out under length pressure. If the rewrite reads corporate, smoke another round — the register usually loosens up by R3–R4.
About
Built with ❤️ by WeirDave and Claude.
Your WaxFrame Pro license is active.