Some work is not one prompt.
It is a sequence.

TASK
Help me frame this before I analyse any data, whether it feeds a
decision or I am exploring a topic. Ask what you need to know first,
then write the frame.

CONTEXT
What I am trying to do:
[in your own words: the request, the decision, the topic or angle I
want to explore, or just the gist]

The data I have: [attach the files if you have them: spreadsheets,
exports, PDFs or reports. Or, if your data is connected (SharePoint,
email, etc.), paste a link to where it lives, specify the connector
to use, and say which files to read. If neither, say what the data
is and what it covers, as far as you know]

BOUNDARIES
- Do not answer the question or analyse any numbers.
- If files are attached, look only far enough to see what they hold,
  such as sheet names, headings, table titles or report sections. Do not
  read or analyse the figures yet.
- If anything is unclear or missing, ask me up to three short questions
  and wait for my answers. If nothing is unclear, go straight to the frame.
- Where I am asking several things at once, make the one that matters
  most the main question, and the others its sub-questions.
- Name the measure in plain words, such as rooms sold over rooms
  available. Do not say which sheet or column it comes from: that is
  settled when the file is prepared.
- Do not recommend anything or guess at the answer.
- If I am exploring rather than deciding, frame it the same way. WHY
  is who the observations are for. If I have not said, ask.
- Write the frame in the chat as well as in the file. Every later
  stage points back at the frame in this chat.
- Keep the chat copy short enough to read aloud in a minute.

DELIVERABLE
Two things: the frame in the chat, then the same frame as a file.

1. IN THE CHAT
Labelled lines, each 30 words or fewer, in this order:

WHY: the decision this informs, who decides and by when. If I am
exploring: who the observations are for, and what they could do with
them
WHAT: the main question, or the topic I am exploring, as a question
the data can answer, naming the measure, the period, and who or what
is counted
SUB-QUESTIONS: only the ones the WHY needs, each answerable from the
data, most important first. When exploring, the angles that matter to
the WHY. Write none if it stands alone
WHAT GOOD LOOKS LIKE: what a good result would be, from a single figure
to a convincing report with clear recommendations backed by the data,
and who it is for
DATA WORTH GETTING, briefly: up to three things beyond what I have that
would make the answer stronger, such as last year's figures or a market
benchmark, and where each would come from. If I can get it now, it
goes through Prepare with the rest

2. AS A FILE
The same frame again as one HTML file I can download and keep, named
frame-[two or three words from the question]-[today's date].html. Do
not reword the frame to fit the page. The page carries one section the
chat copy does not: ASSUMPTIONS, last.

The page, in this order:
- A title that is the main question itself, with the date and who the
  answer is for underneath
- WHY, as a labelled block
- WHAT, as a labelled block, with SUB-QUESTIONS inside it as a numbered
  list sitting directly under the main question, most important first,
  or None. Keep them with the question they hang off. Never give them a
  separate section further down the page
- WHAT GOOD LOOKS LIKE, as a labelled block
- DATA WORTH GETTING as a small table: what it is, what it would make
  stronger, and where it comes from
- ASSUMPTIONS: anything you assumed because I did not answer it, as a
  bulleted list with a visible bullet on every line, or None

One page. Build the file the way my set-up message asks, with the
labels coloured, a tint behind each block, a coloured header row on the
table, and ASSUMPTIONS set apart in its own colour. If you have not seen
that message, ask me for it before you build the page.

TASK
Prepare the attached files for my framed question. Do not answer the
question yet.

CONTEXT
My frame is earlier in this chat. [If it is not, paste it here.]

The files are [say what each one is, such as a system export, a PDF
report, or a spreadsheet somebody built by hand. Leave this line as it
is and work from whatever is attached to this chat].

BOUNDARIES
- Do not analyse anything or answer the question.
- Do not change the data yet. Tell me what you would change, and why.
- Where you are unsure whether something is a problem, say so.
- One line per item. Leave out any list that has nothing in it.

DELIVERABLE
LEAVE OUT: sheets, columns or rows my question does not need,
including totals, subtotals, test rows and cancellations
RESHAPE: anything that is not one table with one header row, such as
title blocks, merged cells, notes and annotations in the grid, or a
PDF or report that has to become rows and columns
FIX: duplicates, blanks, one thing named two ways, numbers or dates
stored as text, missing periods, headers without a unit
ASK ME: up to three questions about what the data I am keeping cannot
tell you,
such as what changed during the period or whether a blank means zero

Then wait for my answers.

TASK
Analyse the files for my frame. My questions are the key angles. Add
any other angle that matters to the WHY, and aim at WHAT GOOD LOOKS
LIKE. A reviewer will then rebuild every figure from the files, and the
result will be turned into WHAT GOOD LOOKS LIKE, so write it to make
both easy.

CONTEXT
My frame is earlier in this chat. [If it is not, paste it here.]

The files: the cleaned files from the Prepare stage in this chat. If
there are none, the files I uploaded. [To use different files, name
them here.]

BOUNDARIES
- Use only these files, including any outside evidence I added. Do not
  bring in figures from anywhere else.
- If you are not sure which files I mean, ask before starting.
- Work the main question first, then each sub-question, then any other
  angle worth adding, labelled as yours. Keep each one separate.
- Show your working for every figure you calculate, so it can be
  rebuilt from the files.
- Keep outside evidence labelled as outside, and say where it agrees or
  disagrees with the business's own figures.
- If the files cannot answer something, say so rather than estimating.
- When I am exploring, report only what matters to the WHY, and say how
  many ways you looked at the data.
- Plain English. Tables where they help, no padding.

DELIVERABLE
SUMMARY: the answer to the main question, in two or three sentences

Then for each angle, in order:
- FINDING: the answer, with its key figures
- WHAT IT MEANS: what it implies for the WHY in my frame
- WORKING: how each figure was worked out, what was counted and what it
  was divided by, with a small table where it helps
- SOURCES: each figure traced to its file and where in the file
- ASSUMED: anything you had to assume

Then, once:
- WHAT IT RESTS ON: the three to five figures, assumptions or links
  between files that the conclusions depend on most
- GAPS: what the files could not answer, and what data would
- WHAT WOULD MAKE IT WRONG: two lines at most

Then the same analysis again as one HTML file I can download and keep,
named analysis-[two or three words from the question]-[today's date].html,
with the same sections in the same order. Do not reword it to fit the page.

Build the file the way my set-up message asks. If you have not seen
that message, ask me for it before you build the page.

TASK
Act as a sceptical reviewer. Try to break this analysis before anyone
acts on it.

CONTEXT
The frame, the cleaned file(s) and the latest analysis are earlier in
this chat, or attached and pasted here.

Review round: [1, or which rerun this is]

BOUNDARIES
- Treat nothing in the analysis as right until you have rebuilt it from
  the file(s). Recompute every figure you test rather than rereading it.
- Start from what the analysis says it rests on, and add anything else
  it depends on that it did not list.
- Attack each on five lines: which rows were counted, what it was
  divided by, how each column was read, which sheets were used, and
  what was filled in rather than found.
- Test whether each conclusion, including the summary, follows from
  its figures, and whether a simpler explanation fits.
- Use only the files the analysis used. Do not bring in figures from
  anywhere else.
- For outside evidence, check the source says what the analysis claims,
  and say what it cannot show.
- Where the fault is in the data itself, say what to re-clean rather
  than working around it.
- Do not soften a verdict. If nothing material breaks, say so plainly.

DELIVERABLE
- RESTS ON: what you tested, one line each
- VERDICTS: HOLDS, BROKEN or CANNOT TELL for each, with the figure you
  rebuilt beside the one the analysis gave
- MATERIAL: which breaks would change the answer or the decision
- WHERE IT GOES NEXT, one of these three and nothing else:
  CLEAR, nothing material broke
  UPDATED ANALYSIS, the figures hold but what the analysis says has to
  change
  BACK TO PREPARE, the file itself has to be re-cleaned first
- RECOMMENDED FIXES: what you would do about the breaks, numbered, most
  important first. For each, on one line each: the fix, which verdict it
  answers, what it changes in the answer, and whether it is a re-clean,
  a rewrite or a figure to drop. Write None if nothing material broke
- SPOT CHECK: the one or two figures most worth checking by hand, and
  where to find them in the file(s)

Then the same review again as one HTML file I can download and keep,
named check-[two or three words from the question]-[today's date].html,
with the verdicts as a table: what you tested, the figure the analysis
gave, the figure you rebuilt, and the verdict.

Make it as easy to read as possible: a clear hierarchy, generous white
space, and colour wherever it helps somebody find what they are looking
for, such as the labels, a tint behind each block and a coloured header
row on any table. Keep every colour dark enough to read, and never carry
meaning by colour alone. Build everything into the file itself, with no
outside libraries, fonts or images, so it opens the same anywhere. If
you cannot create a file, give me the HTML as one block I can save.

Then stop. Ask me to confirm the fixes, change any of them, or add my
own. Change nothing and rebuild nothing until I answer. When I do, carry
out the list as I have agreed it and nothing else.

TASK
Write the answer to my frame, in the form WHAT GOOD LOOKS LIKE asks
for, as one HTML file I can download and keep, named
onepager-[two or three words from the question]-[today's date].html.

CONTEXT
My frame, including who this is for, and the analysis that came back
clear from Check are earlier in this chat. [If they are not, paste them here.]

Brand colours, if any: [colour names or hex codes]
If this line still shows the text in square brackets, ignore it.

BOUNDARIES
- Use only the checked analysis, including the outside evidence it
  used. Leave out anything Check found wrong.
- Write for the reader named in the frame.
- Any figure you calculate for a table or chart uses the method
  confirmed at Check, and the page says so.
- Give every outside figure its source, and say what it cannot show.
- Every headline, title and chart title must match the figures in its
  table.
- Do not calculate anything the frame did not ask about.
- Make it look finished, in colour: one main colour, one accent for
  what needs attention, and softly tinted panels to group the sections.
  Use the brand colours if given. Never a black-and-white page.
- Show better or worse than a comparison in green or red, always with
  a + or - sign as well, so it still reads without colour.
- Draw every chart in colour, with filled bars or lines and each value
  labelled, built into the document itself with no outside libraries,
  fonts or images, so it looks the same wherever it is opened.
- Before you hand it over, check that every chart shows its bars or
  lines and every colour is set, rather than left to a default.
- Plain English. No preamble.

DELIVERABLE
Unless my frame asks for something else, a one-page document, or two
pages if the charts need the room, with:
- A title that states the answer, not the topic
- Up to four headline figures
- FINDING: the answer and how it was worked out, in two sentences
- A table of the figures behind each finding
- Charts wherever they make a finding faster to see than a table: a
  trend over time, a comparison with the market, a mix or a gap. Give
  each a title that says what it shows, label the axes and units, and
  use only checked figures
- MEANING: what it implies for the decision or the reader, with the
  outside evidence and its source
- RECOMMENDATION: what you would do, named and sized. When exploring,
  what is worth looking into next, and why
- CONFIDENCE: high, moderate or low, and what would change it
- METHOD AND SOURCES, in small print: the sheets used, the method,
  what Check reviewed, any figure checked by hand, and what was assumed

TASK
Turn what I know about this report, and the exports attached, into a
complete plan for automating it. Plan only. Do not build or connect
anything yet.

CONTEXT
What I know about this report. A blank field is for you to propose:
Report name: [what it is called]
Audience: [who reads it, and what they decide with it]
Key figures and charts: [what the page must show, named]
Sample report: [the file name of a past copy of this report, if one is
attached]
Source data: [which exports, from which systems, and where they are
saved today, such as a shared drive, a SharePoint folder or an email
inbox]
What changes between periods: [such as rows added or dropped, a totals
row only some periods, columns moved or renamed]
Schedule: [when it runs, and who runs it]

The exports are attached, or linked here:
[say where any linked file lives, and specify the connector to use]

Other report information: [anything else about this report, such as
targets or budgets, how a figure is defined, house style, who signs it
off, and what the reader always asks]

BOUNDARIES
- Read every file before you plan. For each file, and each sheet in a
  workbook, list its columns, row count and date format, and anything
  that looks wrong: totals rows, blanks, numbers stored as text,
  duplicates, renamed columns. If a file is a PDF or a formatted report
  rather than a table, say whether its figures can be read reliably.
- If files from more than one period are attached, compare them, list
  what differs, and plan a step that handles each difference.
- If files are attached that I did not name, list them and ask me
  before using them.
- If a past copy of this report is attached, treat it as the target:
  plan the same figures, order and layout unless I say otherwise, and
  say which of its figures these files cannot produce. It is not a data
  file, so do not tag it, and never take a figure from it. Leave out any
  guest names or other personal details it holds.
- Use only what is in this message, this chat and the files attached.
  Do not fill anything in from memory or other chats.
- Tag each file USE AS IS, USE WITH A MANUAL STEP, or NOT USABLE TODAY
  (it needs a connection, a login or IT). Exporting or downloading the
  file as usual is not a manual step. A manual step is extra work before
  attaching it, such as saving a PDF as a CSV or removing columns. Anything your steps can fix is not a manual step either.
- Where a field is blank or vague, propose the detail and mark each item
  PROPOSED: the exact figures, the comparisons, and every chart with
  its type, unit and period. Tie each one to a question my reader has.
- Say which file and column every figure comes from. If a figure I
  asked for cannot come from these files, say so. Do not invent a
  source.
- Build the page and the steps only from files usable today. Mark any
  figure that depends on a file not usable today LATER, not PROPOSED.
  Mark any figure that no file holds at all NOT AVAILABLE, and say why.
  Only do this for figures the report fields ask for, or that you would
  otherwise propose. Do not list everything the files lack.
- Each run sees only the files attached to it, such as that period's
  exports and last year's figures. Do not plan any file that
  has to be updated and saved back each time. Mark any figure or check
  that needs earlier periods, such as a trend, LATER.
- Include the checks to run first, the cleaning steps, how the files
  join, and how each figure is calculated.
- Today's route is always the files attached by hand, and that is what
  gets built now. Then assess how the data could reach you later without
  anyone attaching files: connectors this chat already has, connectors or MCP
  servers that exist for these systems or for where the files are
  saved, and other routes such as a scheduled export to a shared
  folder. For each, say whether it exists today or needs setting up,
  who would set it up, the effort, and any personal data or approval it
  raises. List a connector only if it could reach the systems or the
  place the exports are saved, as named above. Name a connector only if
  you know it exists; otherwise say it would need to be built. Recommend
  only. Do not connect anything.
- Done is fixed, so do not propose another: the checks pass on a new
  period's files, one figure is checked by hand, it has a run date and an
  owner, and someone else can run it without you.
- Write for a busy manager who is not technical: plain English, no
  code, and explain any technical term in a few words the first time it
  appears.
- If something depends on what my readers need, ask me rather than
  guessing. Do not describe how the report is made today beyond what I
  have told you; ask instead.

DELIVERABLE
One HTML file. The main page must read in five minutes, in this order:
1. Summary: what the report will do and your recommendation, in one
   short paragraph.
2. The report: readers, the decision it supports, when it runs and who
   runs it.
3. The page: every figure and chart, with PROPOSED, LATER and NOT
   AVAILABLE marked, and where it differs from any sample report.
4. The data: one line per file, with its tag and the problems that
   matter.
5. How the data gets here: first, Today: the files attached by hand,
   which is what we build now. Then, under For later, each connection
   option in a simple table with effort, who sets it up and the risk.
6. Open questions for me: only those whose answer changes a figure, a
   check or a step, most important first, and no more than six.
Then a collapsible appendix, closed by default, with the detail Process
needs: each file's columns, row count and faults, and the steps for
today's files only (checks, any manual steps, cleaning, joining and
calculations).
Short sections, clear headings, simple tables and plenty of white space.
No code on the page. If you cannot create a file, give the HTML as one
block I can save.

TASK
Build the recipe from the plan, then run it on this period's exports.

CONTEXT
The plan is [earlier in this chat, or attached].
This period's exports are [attached to this message, or already in this
chat: name them, or linked: paste the link, specify the connector,
and say which files to read].

BOUNDARIES
- Follow the plan. Where it cannot be followed as written, stop and
  tell me which part, rather than improvising.
- Use only the files I name or attach with this message. If none are
  attached, list the files already in this chat and ask which to use.
  If the files cover a different period, or more periods, than the plan
  expects, ask which to use. Never choose the period yourself.
- If the plan still has open questions that change a step, list them
  and ask me to finalise the plan first, rather than writing a
  placeholder.
- Before building, if any answer in the plan would let a wrong or
  missing figure reach the page without the run stopping, tell me and
  ask me to confirm.
- A check that finds a problem affecting a figure on the page either
  stops the run, or is shown beside that figure on the Report sheet.
  Never only on the Checks sheet.
- The spreadsheet is output only. Never invite anyone to correct a
  figure in it. Corrections go into the recipe, and the run is
  repeated.
- Build only for this period's exports as named above, plus any file the
  plan names, such as last year's figures. Treat every connector,
  MCP server, API or scheduled-export idea in the plan as for later: do
  not use it, ask for access to it, or design a step around it. If a
  step depends on a connection, use the attached file instead where you
  can, or leave that figure blank and say why.
- Recognise each file by its columns and content, not its file name,
  because files attached by hand are named differently each time. Find
  columns by name and meaning, never by position, and expect the number
  of rows to change between periods.
- Write any manual step from the plan, such as saving a PDF as a CSV,
  into the recipe's opening lines, so the next runner does it too.
- Numbered steps in plain English, each saying what it does and why,
  starting with the plan's checks, with a step for each difference the
  plan expects between periods.
- Build these rules into the recipe. STOP, with no report, only when a
  figure on the page would be wrong or missing: a file or column the
  recipe needs is not there, the figures do not add up to a total in the
  file, or a figure is blank. CARRY ON AND LIST what you handled, beside
  the figure it touches, when the fix is clear: a renamed or extra
  column, an identical duplicate row removed, a format quirk. ASK only
  when the files cannot settle it.
- Never change a value by hand. Every fix is a step.
- Every figure comes from a step. Do not type, estimate or carry
  forward any number. If one cannot be calculated, leave it blank and
  say why.
- End the recipe with the page layout from the plan, so the next run
  comes back in the same shape.

DELIVERABLE
The recipe as one block of text I can keep,
what each check found on these files, and a spreadsheet
with two sheets: Report, and Checks. If a check fails, stop the run but
still give me the recipe and the Checks sheet, with the Report sheet
left empty. If you cannot create a spreadsheet, give the Report and
Checks as two tables in the chat.

TASK
Design the report page from this period's report table,
following the page set out in the final plan: one page, unless the plan
says otherwise.

CONTEXT
The report table, its Checks sheet and the final plan are earlier in
this chat, or attached. Look there first:
the plan names the reader, the decision, the figures, the charts and
the comparison.

Optional, only to override those, or if they are in none of those
places:
Report name: [what it is called]
Audience: [who reads it, and what they decide with it]
Figures and comparison: [paste the key figures with their labels, and
the comparison that matters]
Brand colours: [colour names or hex codes, if you have them]
If these lines still show the text in square brackets, ignore them and
use what you found. If they are filled in and disagree with the plan,
follow these lines and tell me.

BOUNDARIES
- If the Checks sheet shows a failed check, stop and tell me. Do not
  design a page from a run that did not pass.
- Use only the figures in the report table. Do not calculate new ones.
- Follow the plan's page: its figures and charts, in its order. Leave
  out anything it marks LATER.
- The single most important figure goes at the top, with its comparison
  if the plan has one.
- One chart per question the reader has. Label every chart with its
  unit and its period.
- Every headline and chart title must match the figures beneath it.
- Same number format throughout: decimals, currency, separators.
- Make it look finished, in colour: one main colour, one accent for
  what needs attention, and softly tinted panels to group the sections.
  Use the brand colours if given. Never a black-and-white page.
- Where there is a comparison, show better or worse in green or red,
  always with a + or - sign as well, so it still reads without colour.
- Draw every chart in colour, with filled bars or lines and each value
  labelled. Build the charts
  into the page itself, with no outside libraries, fonts or images, so
  it looks the same wherever it is opened.
- Before you hand it over, check that every chart shows its bars or
  lines and every colour is set, rather than left to a default.
- Leave one short line for commentary that I will write myself.

DELIVERABLE
A page layout in colour that I can export, with the headline figure
first. If it is a web page, keep it to one self-contained file. If you
cannot create a file, give it as one block I can save.

TASK
Try to break this report before anyone reads it: rebuild its headline
figures from the raw exports, then review the page as its most
sceptical reader.

CONTEXT
This period's exports, the recipe, the report table, the page and the
final plan are attached, or earlier in this chat. The plan names the
reader and the decision the page supports.

Optional, only to override the plan:
Audience: [who reads it, and what they decide with it]
If this line still shows the text in square brackets, ignore it.

BOUNDARIES
- First the figures. Rebuild each headline figure from the raw exports
  before you look at the report, then compare. Give each a verdict:
  HOLDS, BROKEN or CANNOT TELL, with the reason. Rebuild them to check
  them, not to replace the report's table.
- Read the recipe against the plan. Look for rows that should not
  count, a wrong join, a blank read as zero, a duplicate, or a column
  read as the wrong thing.
- Then the page. Start with ten seconds: say what a reader takes away at
  a glance, and whether that is the point the page should make.
- Check every chart and title: does it match the report table, is its
  unit and period clear, is the comparison the right one, and could
  anything mislead? Check the page looks finished, in colour, with every
  chart drawn.
- Say what the reader would ask for that is missing, and what could be
  cut because nobody will act on it.
- Name the exact figure, chart, line or recipe step each point is about.
- Never change a figure. A broken figure is fixed by rewording the
  recipe step and running it again. Improve only how the page presents
  the figures.

DELIVERABLE
- WHERE IT GOES NEXT, one of these three and nothing else:
  READY, the page can go to its reader as it is
  FIX FIRST, the figures hold but the page or the recipe needs work
  RETHINK, a figure is broken or the page makes the wrong point
- FIGURES: your rebuilt figures against the report's, as a table, with a
  verdict on each and the reason
- RECIPE STEPS TO REWORD: any step that let a wrong figure through, or
  could let one through next period, with the wording to use instead.
  None if there are none
- PAGE IMPROVEMENTS: ranked, each marked MUST, SHOULD or COULD, with the
  reason and the exact figure, chart or line it is about
- COULD NOT FIX: anything these files cannot settle

Then the same review again as one HTML file I can download and keep,
named review-[two or three words from the report name]-[today's
date].html: the figures as a table, then the recipe rewordings, then the
ranked page improvements, then what you could not fix.

Make it as easy to read as possible: a clear hierarchy, generous white
space, and colour wherever it helps somebody find what they are looking
for, such as the verdict column and a tint behind each block. Keep every
colour dark enough to read, and never carry meaning by colour alone.
Build everything into the file itself, with no outside libraries, fonts
or images, so it opens the same anywhere. If you cannot create a file,
give me the HTML as one block I can save.

Then stop. Do not rebuild anything: no new page, no reworded recipe run,
no figures recomputed into a new table. Ask me which fixes to keep, and
wait. I apply the ones I choose with the next prompt.

TASK
Write one complete run prompt for this report, so anyone can paste it
into a new chat with the period's files attached and get the
finished report, in any AI tool.

CONTEXT
The recipe, the final plan and the page prompt are earlier in this
chat, or attached. Look there first: the plan names the
owner and the schedule.

Optional, only to override the plan:
Owner: [a role, not a person's name]
Runs on: [when]
If these lines still show the text in square brackets, ignore them and
use the plan.

BOUNDARIES
- If you cannot find the recipe, stop and ask for it. Never rebuild it
  from the plan on your own.
- Put the whole recipe inside the prompt, word for word, so it works
  in any new chat.
- Open the prompt with four plain lines for whoever runs it: the files
  to attach and any manual step before attaching them, how to run it,
  what to check afterwards, and who owns it.
- Carry these rules inside it, so every run follows them:
  STOP, with no report, only when a figure on the page would be wrong
  or missing: a file or column the recipe needs is not there, the
  figures do not add up to a total in the file, or a figure is blank.
  Say which check, which file and what it found.
  CARRY ON AND LIST what you handled, beside the figure it touches,
  when the fix is clear: a renamed or extra column, an identical
  duplicate row removed, a format quirk.
  ASK only when the files cannot settle it. Settle what they can first,
  such as reading a date the way that matches the other files' period,
  and say how you settled it.
  ALWAYS run the checks before any calculation, never type, estimate or
  carry forward a figure, use only the files attached, and treat the
  spreadsheet as output only, with
  corrections going into the recipe.
- Take the period from the files: when the files being reported on
  agree on a week, month or quarter, use it and say which. Reference
  files, such as last year's figures, do not count. Never leave a period
  for anyone to fill in. Ask only if those files disagree, or show none.
- No jargon, and nothing that assumes the reader was in the room.

DELIVERABLE
The run prompt as one block of text, ready to save beside the report
and paste each time it is due. Then one line reminding me to put the run
date in the owner's calendar.

TASK
Set up a scheduled task that runs this report's recipe each time it is
due and delivers the finished report.

CONTEXT
The recipe and the final plan are earlier in this chat, or
attached. Look there first: the plan names the schedule, the owner
and the reader.

Optional, only to override the plan, or where it says nothing:
Runs on: [when, for example the third working day at 8am]
Files arrive in: [the connected folder or connector, and how the files
are named]
Report goes to: [who, and how: a file in the folder, an email or a
message]
If these lines still show the text in square brackets, ignore them and
use the plan. If neither the plan nor these lines say where the files
arrive or where the report goes, ask me.

BOUNDARIES
- First confirm you can reach the files through the connector. If you
  cannot, stop and tell me, rather than scheduling a task that will
  fail.
- Every run follows the recipe exactly and runs its checks first. It
  sends nothing, and tells the owner named in the plan, only when a
  figure on the page would be wrong or missing.
  Anything it handled, such as a renamed column or a duplicate row
  removed, is listed with the report. Where the files cannot settle a
  question, it asks the owner rather than guessing.
- Only use files for the period being reported, never the last one's.
- If this tool cannot do part of this, say so rather than working round
  it.

DELIVERABLE
The scheduled task, named after the report, and a four-line summary: when
it runs, where it reads from, where the report goes, and who is told if
a run stops. Then run it once now on the last period's files so I can
check the result.

TASK
Create a Skill called [skill name] that produces this report from the
period's files, so I invoke it by name instead of pasting the run
prompt.

CONTEXT
The recipe, the final plan and the run prompt from 4A are earlier in
this chat, or attached. The plan names the files, the owner and the
schedule.

Optional, only to override the plan:
Skill name: [skill name, lower case with hyphens, for example
month-end-report]
If this line still shows the text in square brackets, use the name in
the TASK line.

BOUNDARIES
- If you cannot find the recipe, stop and ask for it. Never rebuild it
  from the plan on your own.
- Put the whole recipe inside the Skill, word for word. A Skill that
  points at a chat is useless in a new one.
- Carry the stopping rules across exactly as they are: where the recipe
  stops, the Skill stops and says why, rather than guessing or carrying
  on.
- Never type or estimate a figure, and never edit the files.
- Name the files the Skill expects, how they arrive, and the one manual
  step before attaching them, if there is one.
- Say what the Skill does not do: it does not fetch the files, and it
  does not decide whether the report goes out.

DELIVERABLE
- THE SKILL: its name, its description in one line, and its
  instructions in full, ready to save.
- HOW TO USE IT: what to type in a new chat, what to attach, and what
  comes back.
- WHAT TO CHECK: the two or three figures worth checking by hand after
  a run, and what to do when one is wrong.
- WHEN TO UPDATE IT: after any change to the recipe, because the Skill
  holds its own copy.

Then stop, and tell me where to save it in my tool.