Operationalizing
Your Expertise With AI

I'm working through [WHAT YOU'RE BUILDING OR DECIDING].

Here's everything I know right now:
[BRAIN DUMP — MESSY IS FINE. CONTEXT, CONSTRAINTS, HALF-IDEAS, WHAT YOU'VE TRIED]

Don't write anything polished yet. Help me decide.

Ask me the questions you need answered. Then give me a tight framework or outline — structure, the key decisions, what goes where, and what I still haven't thought about.

Keep it short. I want to see the shape of it, not a finished document.

I worked this out in another tool and I'm bringing it to you to build properly.

HERE IS EVERYTHING I STARTED WITH:
[PASTE YOUR SOURCE MATERIAL — NOTES, TRANSCRIPTS, EXISTING DOCUMENTS, EXAMPLES]

HERE IS THE FRAMEWORK I LANDED ON:
[PASTE THE OUTLINE, STRATEGY, OR SPEC YOU FINALIZED]

HERE IS WHAT I DECIDED AND WHY:
[THE CHOICES THAT ARE ALREADY MADE — DON'T RE-OPEN THESE]

WHAT I WANT YOU TO DO WITH IT:
[BE SPECIFIC — WRITE IT, EXPAND IT, BUILD IT, BREAK IT INTO STEPS]

Work from what I've given you. If something is genuinely missing, ask before you invent it. Don't redesign the decisions I already made.

I'm going to give you a piece of work I created and was happy with. I want you to reverse-engineer it into a reusable skill so I can produce this same quality of output again with different client information, without re-explaining myself every time.

Analyze what I give you and identify: the purpose this output serves and who reads it, what inputs are required to produce it, the structure and section order, the voice and tone rules that make it sound like me, the standards that separate a good version from a weak one, what should never appear in it, and the format and length.

Then write it as a skill: a short description of when to use it, the inputs it needs, step-by-step instructions for producing the output, the quality standards it must meet, and one example of what good looks like.

Ask me questions about anything you had to guess at before you finalize it.

Here is the work:
[PASTE YOUR WORK HERE]

Here is a skill I've been using, and here's a recent output from it that wasn't quite right.

Tell me which specific instruction in the skill allowed that output, then rewrite only that part. Don't rebuild the whole skill. Show me the before and after of what you changed and explain why it fixes the problem.

THE SKILL:
[PASTE SKILL]

THE OUTPUT THAT MISSED:
[PASTE OUTPUT]

WHAT WAS WRONG WITH IT:
[ONE OR TWO SENTENCES]

Here is a transcript from a client session. Extract and organize the following, using only what's actually in the transcript — do not infer or fill gaps:

Decisions made, and who made them.
Insights or realizations the client reached.
Recommendations I gave.
Commitments — who agreed to do what, by when, including mine.
Open questions left unresolved.
Anything flagged as sensitive or confidential.

Bullet points, no prose. Note anything ambiguous rather than guessing at it.

TRANSCRIPT:
[PASTE]

Here is the extraction from a client session, and here is the full transcript for context.

Write a session recap addressed directly to the client.

Open with what we covered in one or two sentences. Move to what they worked through and arrived at, in their language where possible. State their commitments and mine clearly, with dates. Close with what happens before we meet next.

Write to them, not about them. No corporate filler, no motivational language, no summary headers. Reflect their own words back where they said something that mattered. Keep it under 400 words.

EXTRACTION:
[PASTE FROM 3A]

TRANSCRIPT:
[PASTE]

Now write a version for the sponsor who is paying for this engagement, not the participant.

Report themes, patterns, and progress against the engagement's stated goals. Include nothing the participant shared in confidence — no personal disclosures, no specific admissions, nothing that identifies a struggle as belonging to that individual.

If the sponsor should be aware of something I need to raise with them directly rather than in writing, flag it to me separately at the end.

Keep it under 250 words.

Write the follow-up email that sends with this recap. Warm, brief, professional.

Confirm the next session date, name the one thing they're focused on before then, and nothing else. Under 100 words.

I want to build a scored assessment that works as a front door to my [SERVICE] work.

My audience: [WHO]
What I want it to reveal: [THE PROBLEM YOU DIAGNOSE]
What I want them to do next: [BOOK A CALL / REQUEST A REPORT]

Help me decide:
What it should be called.
The three categories it should measure, and why those three.
Four scale statements per category — specific enough that the answer isn't obvious, plain enough that a senior leader answers honestly.
Where the score bands should break, and what each band means operationally.

Ask me what you need. Keep it tight — I want the structure, not a document.

Take what we just landed on and write it as a build spec for a web-based assessment app.

Cover: the welcome screen, the question screens and how they advance, the scale, the lead capture fields, the scoring math, the result bands, what the results screen shows, and where the data goes on submission.

Then generate a visual mockup image of the welcome screen and the results screen so I have something to build against. Use [YOUR COLORS] and keep it clean and professional.

Here is a build spec for an app I'm building in an AI app builder, and a mockup image of how it should look.

The builder does not handle a full spec well — it interprets, fills gaps its own way, and skips things. So I need you to break this into between 6 and 12 smaller prompts that I will paste in one at a time, in order.

Rules for the prompts you write:
Each one does a single job and builds on what exists.
Prompt one establishes the shell, the look, and the navigation only.
Later prompts add the questions, then the scoring, then the results screen, then the data submission.
Each prompt must be specific enough that there is nothing left to interpret — exact wording, exact values, exact behavior.
Number them and tell me what I should see on screen after each one, so I can catch a problem at step three instead of step eleven.

BUILD SPEC:
[PASTE FROM 4B]

MOCKUP:
[ATTACH IMAGE]

I built this app from the prompts you wrote, and I've downloaded the project files. Here they are.

Check the build against the original spec. Tell me:
What was built correctly.
What is missing.
What was built differently than specified.
Anything that will break — scoring math, field mapping, the submission.

Then write the additional prompts I need to paste back into the builder to fix each problem. Same rules as before: one job per prompt, nothing left to interpretation.

ORIGINAL SPEC:
[PASTE]

PROJECT FILES:
[ATTACH]

I've built an assessment with a category called [CATEGORY NAME] measuring [WHAT IT MEASURES]. I need interpretation language for three score bands: low, middle, and high.

For each band, write two to three sentences that name what's actually happening operationally at that level, name the specific risk or cost it creates, and point toward what changes it — without prescribing the solution, because that's the conversation I want to have with them.

Write to the reader directly. No jargon, no motivational language, no softening. These are senior leaders who will respect being told the truth.

Here are the four statements in this category:
[PASTE THE FOUR STATEMENTS]

I want to build [WHAT THE APP DOES] for [WHO USES IT].

Here's what I know:
[THE PROBLEM IT SOLVES, WHO TOUCHES IT, WHAT THEY DO IN IT]

Help me decide:
The screens it needs and what happens on each.
What data has to be stored, and what connects to what.
Who logs in and what each type of user can see or do.
What it must do on day one, versus what can wait.

Then write a first build spec covering all of that. Then generate a mockup image of the two most important screens.

Here's a first-pass build spec for an app, plus mockups of the key screens.

Turn this into a comprehensive build spec I can build from. Cover:
Every screen, including empty states and error states.
The data model — every table, every field, every relationship.
User roles and exactly what each can see and do.
Every action a user can take and what happens after it.
Validation rules and what happens when they fail.
What the app must never allow.

Flag every place my first spec was ambiguous and tell me what you assumed, so I can correct you before anything gets built.

FIRST SPEC:
[PASTE FROM 5A]

MOCKUPS:
[ATTACH]

Using the comprehensive spec, write me a single prompt for an AI app builder that produces the WIREFRAME ONLY.

It should build the screens, the navigation, the layout, and the visual style. It should not build the scoring, the business logic, the integrations, or anything clever. Placeholder data is fine.

Say so explicitly in the prompt — I want a shell I can look at and confirm, not a half-working app I have to untangle.

The wireframe is built and here are the project files.

Finish this app directly in the code, against the comprehensive spec. Work through it in order: data model first, then the logic, then the integrations, then the states and validation.

As you go, tell me what you changed and why. If the wireframe made a structural choice that fights the spec, say so before you build on top of it.

COMPREHENSIVE SPEC:
[PASTE FROM 5B]

PROJECT FILES:
[ATTACH]

Help me document how I actually run a discovery call, so I can turn it into a system.

Here's what I know about my process:
[HOW CALLS START, WHAT YOU ASK, WHAT YOU LISTEN FOR, HOW YOU DECIDE FIT, HOW YOU CLOSE]

Here's who I'm talking to:
[YOUR BUYER]

Here's what I sell:
[YOUR SERVICES AND ROUGH STRUCTURE]

Interview me until you have the full picture, then give me a clean outline: the phases of the call in order, what each phase is for, the questions that belong in each, what I'm listening for, and the decision points where the call can branch.

Tell me where my process has a gap.

Here's the outline of my discovery call process. Build it into something I can actually use.

I want [A ONE-PAGE SITE I CAN OPEN DURING CALLS / AN INTERNAL PLAYBOOK / A PROSPECT-FACING PAGE THAT PREPARES THEM BEFORE WE TALK].

It should carry the phases in order, the questions inside each, what I'm listening for, and the branch points. Make it something I can follow live without losing my place — not a document I read once.

MY OUTLINE:
[PASTE FROM 6A]

MY VOICE AND BRAND:
[HOW YOU SOUND, YOUR COLORS, ANY EXAMPLES TO MATCH]

Here's what I know about a prospect before our call:
[APPLICATION, INTAKE FORM, LINKEDIN, EMAIL THREAD — WHATEVER YOU HAVE]

Build me a prep brief:

What they said their problem is, and what it's more likely to actually be.
Which of my services this points toward, and which would be wrong for them.
Eight diagnostic questions in the order I should ask them, moving from situation to impact to cost.
What they'll probably push back on, and what's behind each objection.
What I should be listening for that would change my recommendation.
Two things I should not assume.

Be direct about where the information is thin and I'll be guessing.

Here's the transcript from a discovery call.

Produce:

A one-paragraph statement of their situation in their own language — close enough that they'd read it and feel understood.
The engagement I should recommend, and why that one.
Scope: what's included, stated specifically.
Exclusions: what's explicitly not included, so it doesn't get assumed in later.
Deliverables with a realistic timeline.
The three biggest risks to this engagement succeeding.
Proposal language for the situation and approach sections.

If anything in the call suggests they aren't a fit, say so before you write any of it.

TRANSCRIPT:
[PASTE]

I'm building a recurring invite-only executive roundtable. Small container, senior leaders, invited directly rather than publicly.

My work: [WHAT YOU DO AND WHO YOU SERVE]
My point of view: [WHAT YOU BELIEVE THAT OTHERS IN YOUR FIELD DON'T]
Why I'm doing this: [AUTHORITY, RELATIONSHIPS, MARKET INTELLIGENCE, PIPELINE]

Help me build the foundation:
The framing — what this room is, in one sentence someone would repeat to a peer.
Format and length, and how a facilitated peer conversation differs from a presentation.
Room size, and who should not be in it.
The first three topics, each as a provocative question rather than a subject line.
What I contribute versus what the room contributes.
What I want to walk away knowing about these leaders' businesses.

Push back where this sounds like a webinar with a different name.

For a roundtable on [TOPIC], define the ideal participant: title and seniority, company size and type, what they're currently dealing with that makes this urgent, and what would make them decline.

Then five signals I can look for on LinkedIn that suggest a fit, and three that suggest not.

Then write the direct message sequence. This is a private invitation, not marketing:
Message one — connection request, under 200 characters, references something specific about them, no pitch.
Message two — after they connect. The invitation: what the room is, who's in it, why them. Under 150 words.
Message three — one follow-up a week later. Brief, no pressure, easy to decline.

Peer to peer. No exclamation points, no hype, no "pick your brain."

I'm building the mechanics for a recurring executive roundtable so I can run it repeatedly without rebuilding anything.

Here's the foundation and framework:
[PASTE FROM 7A AND 7B]

First, separate what stays the same every time from what changes per roundtable. Be specific — I want to know exactly which fields I'm swapping on run number two.

Then build me [A PRIVATE REGISTRATION PAGE / AN INVITATION EXPERIENCE] that matches the tone of a personal invitation rather than an event signup. It should capture what I need to know before they walk in, and feel like a door, not a funnel.

Include registration questions that do downstream work — what I ask here should make the pre-event briefing and the follow-up possible without me writing anything twice.

MY BRAND:
[COLORS, VOICE, ANY EXAMPLE TO MATCH]

The first roundtable is done. Turn the whole thing into something I can run again without rebuilding it.

Here's everything from round one:
[THE FRAMEWORK, THE PAGE, THE MESSAGES, THE REGISTRATION QUESTIONS, THE TRANSCRIPT]

Produce:
A skill that generates the full set for a new roundtable when I give it a topic, a date, and a participant profile.
A checklist of everything that has to happen, in order, from choosing the topic to sending the follow-up.
A pre-event briefing format built from registration responses — who's in the room, the themes across responses, the two or three tensions where people disagree, and five opening questions ordered so the room warms up before it gets honest.
A post-event set: themes and insights attributed by role not name, the attendee follow-up, a publishable insight recap with no identifying details, and a private note on who's worth a direct conversation.

Every Friday, review all active client projects and write me a status report.

For each project: what moved this week, what's blocked and who it's waiting on, anything overdue, and anything due in the next seven days.

Then a section at the top: the three things that need me specifically, ordered by what breaks first if I ignore them.

Plain language. No project management jargon. If nothing moved on a project this week, say so plainly instead of padding it.

Look across all my active work and tell me what's quietly going wrong.

Anything with no activity in [X] days.
Anything whose due date has moved more than once.
Anything assigned to someone who hasn't touched it.
Any client with a deliverable due and nothing in progress.

For each one, tell me the single next action that unsticks it and who owns that action.

Document exactly how we created this, including the inputs, the decision logic, the standards applied, the formatting, the output requirements, and the quality criteria. Turn that process into reusable instructions so I can reproduce this outcome with new client information.

Then tell me what you had to guess at, so I can make those decisions explicit instead of leaving them to chance next time.

Here's a task I'm about to start:
[DESCRIBE IT]

Here's the index of skills and assets I've already built:
[PASTE YOUR INDEX]

Tell me whether something on this list already covers it, partially covers it, or doesn't. If something partially covers it, tell me what to add rather than what to rebuild.