Prompt library

Copy-and-adapt requests for intelligent.page, grouped by the job you are doing, each with the build scope to run it on and why it works.

This is a library of requests to copy into the composer. Use it to explore ways of working you have not tried, or when you are not sure where to start.

They are starting points rather than scripts. Each one names the build scope to run it on and, under Why this works, the pattern behind it so you can write your own. Replace anything in brackets with your own detail.

Note

Ask for the outcome, not the artefact. The system chooses the sheet, deck or board by the shape of the answer; you choose the question. See Best practices.

Understand the business

See what the model believes

What do you understand about our business — who we sell to, what we charge, and where we are weak? Tell me what you are unsure about.

Mode Ask. Why this works: it answers from memory alone and builds nothing, so you see the model's current state — and the doubts are the list of docs to correct first.

Run the audit

Audit the business stage by stage and tell me what we have actually settled and what we have been avoiding.

Scope Entire system, once. Why this works: the audit reads every stage, and the honest gap list is what a company of one most needs and least wants.

Find the bottleneck

Where is the bottleneck right now, given the stage we are at? Rank the candidates and say what evidence would settle it.

Scope Connected. Why this works: the stage answer from onboarding narrows the field; asking for evidence keeps it from guessing.

Map the category

Map our category: who competes with us, on what, and where are we losing? Use the last three months of what we know.

Scope Connected. Why this works: "where are we losing" is a decision question; the map is a means to it, not the deliverable.

Decide

Pricing with alternatives held open

Is our pricing leaving money on the table? Hold three price points open for the [Pro] plan — [current], [+15%], [+30%] — and show me what changes in revenue, conversion and margin under each.

Scope Connected, with Choice variables per task at three. Why this works: one baseline and three variants are comparable; three separate runs would drift.

Timing

Should we launch in [March] or [June]? Hold both open and show what each assumes about the team, the pipeline and cash.

Scope Connected. Why this works: timing is a choice variable; the assumptions each date rests on are what the decision actually turns on.

Build versus buy

We are deciding whether to build [capability] or buy [vendor]. Lay out the case for each against our roadmap and team, and tell me what would have to be true for buy to win.

Scope Connected. Why this works: "what would have to be true" forces the work to name assumptions rather than pick a side.

Kill or keep

[Product line] has been flat for two quarters. Should we keep it? Show what it costs us to run, what it contributes, and what we would do with the team.

Scope Connected. Why this works: it names the three things the decision needs and lets the work find the numbers.

Produce

The board update

Prepare this quarter's board update: what we said we would do, what happened, and what we are asking for. Reconcile the narrative with the numbers rather than writing around them.

Scope Connected. Why this works: the three-part structure is what a board reads for, and the reconciliation instruction turns on the reviewer.

Investor questions

List the questions an investor will ask about [the raise], answer each from what we know, and flag the ones where our answer is weak.

Scope Connected. Why this works: the Issues tab becomes the preparation list — exactly what will be probed in the meeting.

Market sizing you can defend

Size the market for [product] with every assumption exposed and sourced. Where you cannot source a number, say so rather than estimating.

Scope Connected. Why this works: "say so rather than estimating" is what makes the number defensible; the evidence-needed issues are the homework.

Onboarding material from the code

Connect [repository] and write onboarding material for a new engineer: what the service does, how the pieces connect, and where the sharp edges are.

Scope Only this, with the repository attached under Connect. Why this works: the work reads what the software does rather than what the README claims.

A launch plan with dates

Build the launch plan for [product] as a dated plan with milestones, and attach the milestones to the [launch] project.

Scope Connected. Why this works: a plan is a timeline; planned milestones land on the project so progress is visible in one place.

Operate

The weekly review

Review the last seven days: what moved in the numbers we track, what the open projects reported, and what needs a decision this week.

Scope Connected, weekly. Why this works: it reads projects, analytics and issues together, and "needs a decision" is what a review is for.

Project health

For every project in progress, read the latest update and the milestones and tell me which are genuinely on track and which only say they are.

Mode Ask. Why this works: health comes from updates; this reads them critically without building anything.

Reorder list

Build the reorder list for the next thirty days from sell-through and current inventory, and flag anything that will stock out first.

Scope Connected, with Amazon Seller Central or your commerce connector attached. Why this works: it is a calculation over real numbers, so it comes back as a sheet that recalculates.

What did we commit to?

From today's call with [customer]: what did we commit to, what did they commit to, and what contradicts what we believed last week?

Scope Only this, after a captured meeting. Why this works: the transcript is in memory, and "what contradicts" is the question a transcript can answer that notes cannot.

Sell

The best customer

Who is our best customer, by margin and retention rather than revenue, and where do we find more of them?

Scope Connected. Why this works: naming the measure stops the work from defaulting to the biggest logo.

Positioning

Compare how we and our top three competitors describe ourselves. Where do we say the same thing, and where is the difference we should be leaning on?

Scope Connected, ideally with the competitors modelled in their own directories. Why this works: comparable because each site was read the same way.

Channel economics

Where do our competitors acquire customers, what does it cost them, and which of those channels are we not in?

Scope Connected. Why this works: the three-part question maps directly to a comparison the work can build and source.

Build

A working prototype

Prototype [the feature] as a working page a customer could click through, using our brand book.

Scope Only this. Why this works: prototypes come back runnable rather than described; the brand book keeps it on-brand without you asking.

A page for the site

Build a landing page for [offer] in our brand, with the copy grounded in how our customers describe the problem.

Scope Connected. Why this works: "how our customers describe the problem" pulls the persona and research docs into the copy.

Research

Model a competitor

[Create a new directory from the competitor's website, then:] Audit this business as if you were preparing to compete with it. What is it good at, where is it exposed, and what would you do first?

Scope Entire system in the new directory. Why this works: the same modelling that reads your site reads theirs, and the benchmark compares them with the numbers exposed.

Diligence on a repository

Do technical diligence on [repository]: what is load-bearing, where is the coupling, and what would worry you if you were buying this?

Scope Only this, repository attached. Why this works: three concrete questions, answered from the code rather than the pitch.

What makes these requests work

The requests above share a few patterns. Recognising them helps you adapt any of them to your own situation.

State the decision, not the document. "Is our pricing leaving money on the table?" gets a sheet that answers something; "make a pricing spreadsheet" gets a spreadsheet.

Name the measure. "By margin and retention rather than revenue" stops the work from choosing the obvious one for you.

Ask what would have to be true. It forces assumptions into the open, where they become issues you can confirm or refute.

Hold alternatives open. A price, a date or a bundle with options is a choice variable; you get variants off one baseline instead of three arguments.

Say where the truth lives. Attach the repository, connect the tracker, capture the meeting. The work reads the source instead of your description of it.

Choose the scope on purpose. Only this for an answer, Connected for the consequences, Entire system for a reset — and Ask mode when the answer should already be in memory.

Where to go next

Once a request works, the next step is making it repeat: set the measure it serves up as a project so milestones land somewhere, and correct anything it got wrong in Memory so the next run starts from there rather than relearning it. For a request that could widen more than you intended, turn on Ask for permission at interface selection and see the plan before anything is built.