Toolkit · Piece 3 kit
Build the Procedure
Companion kit to Chat Plus SaaS Is No Longer Enough. What an AI-First Operator Substrate Actually Looks Like. · Markdown source, full toolkit
These kits are designed to help your thinking and focus. LLM outputs vary depending on the model, the inputs, and the context. Treat every output as a draft for your own review, not a finished deliverable.
How to use this toolkit
This kit picks up where the diagnostic leaves off. Once you know which operating gap is costing you most — from the toolkit diagnostic, or your own read — these prompts turn that gap into a written procedure that runs the same way every time. Six procedures (board pack, investor update, financial model, customer discovery, IP register, hiring) plus a prompt that sequences which to build first. The substrate, as Piece 3 sets out, is four layers of named workflows, knowledge, evaluation, and trust; this kit is the workflows layer — the procedures you write down and run twice.
The prompts assume you are early: running on chat-plus-SaaS today, assembling the board pack by hand, with no procedure written down for any of it. Calibrate if you are further along.
The agent drafts; you ship. Every output is a draft you review before any external use — which is why the review gate is named explicitly in each prompt. A founder who pastes a prompt and accepts the output verbatim is doing chat-plus-SaaS dressed up in heavier vocabulary. A founder who pastes the prompt, reads the output critically, edits, and runs the procedure twice is starting to build a substrate.
Once the substrate is in place, these prompts evolve from one-shot copy-paste into agent skills with persistent context and named tools. That is later. The toolkit is the on-ramp.
The procedures
Six procedures plus a prompt that sequences them. Each asks a few questions, then drafts a procedure with named inputs, steps, outputs, a review gate, and a check — so it runs the same way every time and can tell when it has drifted. Pick the one that matches your most expensive gap.
- Find your most expensive gap. Run the toolkit diagnostic, or use your own read.
- Pick the matching procedure from the six below.
- Run the prompt. It asks a few questions, then drafts the procedure.
- Run the procedure once, by hand. Edit what breaks against the real inputs.
- Run it a second time. When it runs the same way twice, it is standing — that is substrate.
Workflow 1. Board pack assembly
The board pack is the workflow that breaks first and shows fastest. A 2026 fund leading a Series A expects four quarters of consistent KPI definitions, a cash bridge that ties to last month's bank statement, and a risk register that diffs cleanly against the prior pack. Most seed-stage spinouts arrive having reinvented those documents three times in nine months — and the fund passes politely without explaining why. Good board-pack assembly is deliberately repetitive: same input feeds, same review gate, same sequence every quarter. The founder reads, flags two or three items that need judgement, and signs the rest. This prompt produces that procedure. It is the worked exemplar of the toolkit because the other five workflows follow the same shape.
Prompt, copy into Claude, ChatGPT, or any LLM
Show the prompt
The board pack is the artefact a fund uses to read whether you run the
company — and the most common reason a fund passes is not the numbers,
it is that the pack looks different every time.
You are an experienced UK seed-stage spinout operator with a background
in finance and board reporting. Your job is to help me write a procedure
for board pack assembly that runs the same way every quarter, against
named inputs, producing a named output, with a named review gate.
What you'll give me: a six-section procedure (Inputs, Steps, Outputs,
Review gate, Eval checks, Failure modes) that I can run manually and
refine twice before treating as standing.
What you'll ask: eight short questions about how the pack works today.
Plain answers are fine. You do not need exact figures, bank balances,
named funding amounts, or document locations — the procedure does not
depend on them.
Context to assume:
- UK academic spinout, first 18 months post-licence, one to three people.
- The pack goes to a seed-stage board (lead investor, founder, one NED).
- No procedure is written down yet.
Before drafting, ask me:
1. When was the last pack assembled and roughly how long did it take?
(Why: it tells me whether the process is a defined procedure or a
rebuild each time.)
2. What sources were used — bank app, accounting system, financial-model
spreadsheet, CRM, customer notes, risk register, prior pack?
(Why: the procedure is only as stable as the inputs it names.)
3. Did KPI definitions match the prior quarter? Where did they drift?
(Why: KPI drift is the most common silent failure in board packs.)
4. Did the cash bridge tie to a specific bank statement? Which one?
(Why: a bridge that does not tie to a named statement cannot be
verified.)
5. What cadence does the board expect — monthly, quarterly, ad hoc?
(Why: cadence determines how often the procedure must run reliably.)
6. What does the board chair say they want and do not want to see?
(Why: the review gate is calibrated to what the chair actually reads.)
7. What format — slides, narrative, both — and what typical length?
(Why: the output section names a specific format and length target.)
8. What needs founder judgement every time vs what is mechanical
reconciliation? (Why: judgement steps and mechanical steps are
flagged separately so the procedure can run without re-deciding.)
When you have my real answers, draft:
## Procedure: Board pack assembly
### Inputs
Named, typed inputs. For each: name, source, producer, format, how the
procedure receives it. Example: "KPI feed, source: financial-model
spreadsheet, sheet 'KPIs', format: rows of {metric_name, current_quarter,
prior_quarter, definition}, received by: paste from spreadsheet, or, once
a knowledge layer exists, queried directly."
### Steps
Numbered procedure steps. Each step names what is done, by whom or what,
and the intermediate output. Mechanical and judgement steps flagged
separately. The procedure runs the same way every quarter.
### Outputs
Named outputs. For each: name, format, recipient, send-date convention.
### Review gate
Named. Who reviews what before it leaves the building, what they look
for, what they may skip, what they must read line by line.
### Eval checks
At least one check that catches regressions. For board pack: KPI
definitions reconcile to the prior pack (list any drift); cash bridge
ties to the most recent month-end bank statement to the penny; risk
register diffs cleanly against prior pack with each added, removed, or
changed item explained in one sentence. Each check must be verifiable
deterministically by a human or a second agent run.
### Failure modes this procedure protects against
One paragraph naming the specific failure modes, e.g. KPI drift
between quarters, cash bridge not tying to bank, risk register
accumulating resolved items.
You must not: fabricate inputs or outputs I did not name; assume the
procedure runs without a founder in the loop (the founder reviews and signs every
pack); recommend a specific tool or vendor; write the procedure to run
without a human in the loop.
Review gate (for this prompt's output): the procedure is a draft. I will
run it once manually before treating it as standing procedure, then edit,
then run it a second time before relying on it. Flag any assumption you
are uncertain about.
Begin by asking me question 1.The output is a procedure, not a board pack. Run the procedure once, manually, for the next pack you would have assembled anyway. Notice where the procedure as written breaks against the real inputs. Edit the procedure, not the pack. Run it a second time on the following pack. The eval checks at the foot are the part you will be tempted to skip, and they are the part that protects you against a board pack that looked right but reconciled wrong. Keep them. Note: the eval checks fire when the procedure runs — not when this draft is read. The first run is the first real test.
Workflow 2. Investor update
The monthly investor update is the cadence object. It is the single artefact that tells a lead investor, every month, that the team does what it says, on the date it said. When the cadence collapses, the trust signal degrades for a reason that has nothing to do with the science. The good investor update is short, named-metric-led, plain-prose, and lands on the same date each month. This prompt produces the procedure that lets you produce one in a defined window of founder time. The agent is not writing the update for you in this toolkit; it is writing the procedure.
Prompt, copy into Claude, ChatGPT, or any LLM
Show the prompt
The investor update is not a summary of progress — it is a trust signal.
A lead investor who receives the same named metrics, on the same date,
every month, reads a team that does what it says. When the cadence slips,
that signal degrades before the news inside the update does.
You are an experienced UK seed-stage spinout operator with a background
in investor relations. Help me write a procedure for the monthly investor
update: same way every month, same send-date, named output the lead
investor can read in two minutes.
What you'll give me: a six-section procedure (Inputs, Steps, Outputs,
Review gate, Eval checks, Failure modes) I can run manually and refine
before relying on it.
What you'll ask: six short questions about how the update works today.
Plain answers are fine — you do not need metric history, named funding
amounts, or confidential figures.
Context to assume: UK academic spinout, first 18 months post-licence,
one to three people, four to ten recipients, no procedure written down.
Ask me first:
1. How many updates in the last six months and on what dates?
(Why: the pattern tells me whether a cadence exists or is being
rebuilt each time.)
2. What named metrics did each cover?
(Why: inconsistency in the metric list is the most common drift; the
procedure anchors it.)
3. Word count and format of the most recent?
(Why: the output section names a format and length target the
procedure holds to.)
4. Input sources — KPIs, customer interviews, hiring, IP, runway?
(Why: the procedure is only as stable as the inputs it names.)
5. What does the lead investor say they want and do not want?
(Why: the review gate is calibrated to what the lead actually reads.)
6. Preferred send-date convention?
(Why: a fixed send-date is the cadence signal; the procedure
encodes it.)
Then draft the procedure in the standard format: Inputs, Steps, Outputs,
Review gate, Eval checks, Failure modes this procedure protects against.
Eval checks must include: named-metric coverage check; word count check;
plain-prose register check (no marketing vocabulary, no autonomy claims,
no number without source).
You must not: fabricate metric history; assume tone I have not stated;
draft the update content itself (you are drafting the procedure, not the
update); recommend tools.
Review gate: the procedure is a draft. I run it once on the next update
manually before relying on it.
Begin by asking me question 1.The output is a procedure that defines what an update is, what it contains, when it ships, and what gets reviewed before it leaves. By month three, the procedure becomes the standing template and the founder time spent per update drops from a half-day to a defined window. The named-metric coverage check is the eval that matters most, because it catches the slow drift where each update covers fewer metrics than the last until what ships is two paragraphs that say nothing. Note: the eval checks fire when the procedure runs — not when this draft is read. Run the procedure on the next update and check the named-metric list before it leaves.
Workflow 3. Financial-model maintenance
The model that closed the seed back-solves from the number the founders wanted. Correct as a fundraising artefact; useless as an operating one. The model that runs the company is rolled forward, not rebuilt — it pulls actuals from the bank feed, updates assumptions explicitly, and can answer "18-month plan to the next round on three named hires" without a rebuild from scratch. This prompt produces the procedure for maintaining the model in that state. It does not build the model. It builds the maintenance discipline.
Prompt, copy into Claude, ChatGPT, or any LLM
Show the prompt
The model that closed the seed was built to produce one number. The
model that runs the company is rolled forward from actuals — and the
difference between those two artefacts is the difference between a
frozen fundraising deck and an operating tool.
You are an experienced UK seed-stage spinout operator with a finance
background who has maintained financial models for science-led companies
through seed and pre-Series A. Help me write a procedure for
financial-model maintenance: rolled forward, not rebuilt, able to model
the next round on named assumptions.
What you'll give me: a six-section procedure (Inputs, Steps, Outputs,
Review gate, Eval checks, Failure modes) I can run manually and refine
before relying on it.
What you'll ask: six short questions about the current state of the
model. Plain answers are fine — you do not need cash positions, named
funding amounts, or exact figures.
Context to assume: UK academic spinout, first 18 months post-licence,
one to three people, model in Excel or Google Sheets, founder is not a
finance professional.
Ask me first:
1. When was the model last meaningfully updated and what changed?
(Why: the gap between the last update and today tells me whether
the model is tracking the business or has drifted from it.)
2. Does it close the round on paper, and on what assumptions?
(Why: the procedure needs to know whether the fundraising scenario
is still live or has been superseded.)
3. Can it answer "18 months on three named hires and £6m Series A in
month 14" without a rebuild? (Why: this is the test a diligence
process will run; the procedure ensures the model stays ready for it.)
4. Where do actuals come from — accounting system, bank app, both?
(Why: the inputs section names each source explicitly so the roll-
forward has a defined feed, not a manual hunt.)
5. Where do assumption changes get recorded — in the model, a separate
doc, nobody's head? (Why: undocumented assumptions are invisible risk;
the procedure gives them a named home.)
6. How often are sensitivities reproduced from current assumptions?
(Why: the eval check tests whether the procedure keeps sensitivities
current or lets them freeze.)
Then draft the procedure in the standard format.
Eval checks must include: actuals reconcile to most recent bank
statement; closes-the-round-on-paper test runs against current
assumptions; sensitivities named in the last board pack reproduce
from current model state.
You must not: rebuild the model; assume a finance background I have not
claimed; recommend specific finance vendors; propose the procedure
execute without human review of the rolled-forward output.
Review gate: the founder reviews every monthly roll-forward before
relying on the model for any external conversation.
Begin by asking me question 1.The output is a maintenance procedure, not a model. The first time you run it you will find at least one assumption that has not been documented anywhere except in your head; write it into the model where the procedure asks for it. The eval check that earns its keep is the closes-the-round-on-paper test against current assumptions, because it forces the model to remain a usable artefact rather than a frozen snapshot of the seed raise. Note: the eval checks fire when the procedure runs — not when this draft is read. The first monthly roll-forward is the first real test; run the closes-the-round check then, not before.
Workflow 4. Customer-discovery synthesis
Post-ICURe, a strong cohort finishes with forty interviews and a write-up. Six months later, the rhythm has settled at two interviews a month and the synthesis is the ICURe document, untouched. When a lead investor asks what the team has learned in ninety days, "we have been heads-down on technical milestones" is the wrong answer. The good customer-discovery practice in a seed-stage spinout maintains a rolling synthesis updated weekly or fortnightly, with named segments, named objections, named willingness-to-pay signals, and every claim traceable to an interview identifier. This prompt produces the procedure that holds that discipline together.
Prompt, copy into Claude, ChatGPT, or any LLM
Show the prompt
The ICURe write-up is a snapshot. What a lead investor reads as signal
is whether you have continued to learn since — and whether you can name
what you have learned, traceable to an interview, in the room.
You are an experienced UK seed-stage spinout operator who has run
customer discovery for science-led companies and knows what an investor
is actually testing when they ask "what have you learned in 90 days."
Help me write a procedure for rolling customer-discovery synthesis.
What you'll give me: a six-section procedure (Inputs, Steps, Outputs,
Review gate, Eval checks, Failure modes) I can run on the next batch of
interviews and refine before treating as standing.
What you'll ask: six short questions about how discovery is running
today. Plain answers are fine — you do not need interview transcripts,
named contacts, or confidential figures.
Context to assume: UK academic spinout, first 18 months post-licence,
one to three people; interviews recorded via Otter, Read.ai, or raw
notes; team did ICURe or equivalent pre-licence.
Ask me first:
1. Roughly how many interviews in the last 30 days, and where are
notes stored? (Why: the procedure's input section names the
source and format; without a rough sense of volume and location,
the steps cannot be specified.)
2. When was the synthesis last meaningfully updated?
(Why: the gap tells me how much catch-up the first procedure run
will require.)
3. Named segments running discovery against?
(Why: the eval check tests whether the procedure keeps the segment
list consistent with what the board pack names.)
4. Top three customer objections in writing right now?
(Why: named objections become the anchor for the objections-by-
frequency sort the eval check runs.)
5. Willingness-to-pay signals on record, and roughly how many?
(Why: the procedure names where these are stored and how they flow
into the synthesis.)
6. Format of the synthesis — doc, table, slide, or a mix?
(Why: the output section specifies the format so the procedure
produces the same shape every time.)
Then draft the procedure in the standard format.
Eval checks must include: every claim in the synthesis traces to an
interview identifier; segment list is consistent with segments named
in the last board pack; objections list sorted by frequency and recency.
You must not: fabricate interviews; assume objections I did not state;
propose the agent runs interviews; recommend specific transcription
vendors.
Review gate: the founder reviews every synthesis update before any
external use, and is responsible for the traceability of every claim.
Begin by asking me question 1.The output is a synthesis procedure that names how interviews flow in, how they get tagged to segments, how the rolling document gets updated, and what the eval check looks like. The traceability eval is the one that protects you in diligence; an investor reading the synthesis can ask "which interview produced this objection" and you can answer in ten seconds. Run the procedure on the next batch of interviews and notice where the segments named in the procedure no longer match the segments showing up in the interviews. That mismatch is the most useful signal the procedure produces in its first month. Note: the eval checks fire when the procedure runs — not when this draft is read. The traceability check is only meaningful once interviews have flowed through the procedure at least once.
Workflow 5. IP register
The licence schedule lists three patent families. By month ten there is a fourth invention disclosure the TTO has not seen, a paper draft mentioning a fifth, a contractor agreement silent on assignment, and a postdoc who joined two months ago whose IP assignment paperwork is in someone's inbox. Nothing malicious. Nobody owns the register and it drifts. The good IP register in a seed-stage spinout is a single live document with assignment status per item, diffed monthly against the TTO contact log, with named owners for each entry. This prompt produces the procedure that holds the register live without requiring a patent lawyer in-house.
Prompt, copy into Claude, ChatGPT, or any LLM
Show the prompt
IP drift is not an event — it is an accumulation. By the time an investor
or acquirer finds the gap in diligence, it has usually been drifting for
six months or more. A live register, maintained on a named cadence, is
the only way to close that gap before it surfaces at the wrong moment.
You are an experienced UK seed-stage spinout operator with TTO and IP
exposure, who has seen IP register drift cause problems at diligence and
knows what a TTO expects to see to stay confident in a company's IP
hygiene. Help me write a procedure for maintaining a live IP register.
What you'll give me: a six-section procedure (Inputs, Steps, Outputs,
Review gate, Eval checks, Failure modes) I can run monthly with the TTO
contact looped in.
What you'll ask: six short questions about the current state of the
register. Plain answers are fine — you do not need patent numbers,
specific legal instruments, or confidential IP detail. Qualitative
descriptions of scope and status are enough.
Context to assume: UK academic spinout, first 18 months post-licence,
one to three people; licence schedule lists patent families and may
include know-how or copyright; team continues to invent, publish, and
contract for work.
Ask me first:
1. Is the licensed IP portfolio one or two key items, or a broader
portfolio of several families? (Why: the scope shapes how the
register is structured and how often the monthly diff is meaningful.)
2. Roughly how many invention disclosures since licence, and has any
been filed? (Why: the count tells me whether the register has active
new items flowing in or is essentially static since licence.)
3. Roughly how many papers drafted or submitted since licence that
describe patentable matter? (Why: publication activity is the most
common source of undisclosed new IP; the procedure needs to capture
it.)
4. Contractor agreements explicit on assignment, and who reviews them?
(Why: contractor assignment is the most common silent gap; the
procedure gives it a named review step.)
5. When did the TTO last receive an updated register from the company?
(Why: the diff frequency tells me how far behind the register is
likely to be at the first procedure run.)
6. Any third-party background-IP items relevant to the company?
(Why: background IP in scope needs an owner and status in the
register just as licensed IP does.)
Then draft the procedure in the standard format.
Eval checks must include: every register entry has an owner, assignment
status, and date last reviewed; monthly diff against the TTO contact
log produces no unexplained gaps; contractor and employee records
reconcile to the register on the assignment column.
You must not: provide legal advice; assume facts about background IP
I did not state; recommend a specific patent attorney or IP-management
vendor; propose the agent files or corresponds with the IPO directly.
Review gate: the IP register is reviewed by the founder and shared with
the TTO before any external IP conversation.
Begin by asking me question 1.The output is a procedure for keeping the register live, not a legal document and not a substitute for counsel. The eval check on contractor and employee assignment is the one that prevents the silent failure where work done in month seven turns out not to belong to the company. Run the procedure monthly with the TTO contact looped in. The first run will surface at least one item that has been drifting for longer than you realised. That is the procedure earning its keep. Note: the eval checks fire when the procedure runs — not when this draft is read. The assignment reconciliation check only has meaning once the first monthly diff has been run against the TTO contact log.
Workflow 6. Hiring pipeline
The founder knows they need a head of commercial and an MLE. Six months pass. No JD. No compensation band. No interview rubric. A warm-intro candidate takes another offer because the founder cannot articulate the role in writing within forty-eight hours. The good hiring discipline in a seed-stage spinout maintains JD drafts on demand, candidates and interview notes in one place, rubric scores recorded against named criteria, and a time-to-JD from "we need this role" to "JD is live" measured in days, not months. This prompt produces the procedure for that.
Prompt, copy into Claude, ChatGPT, or any LLM
Show the prompt
The cost of an unwritten JD is not the vacancy — it is the warm-intro
candidate who takes another offer while the role sits in your head. A
hiring procedure means the JD, the compensation band, and the rubric
exist before the introduction happens, not after.
You are an experienced UK seed-stage spinout operator who has made first
non-academic hires into science-led teams and knows how quickly a warm
introduction stalls when the role is not written down. Help me write a
procedure for the hiring pipeline.
What you'll give me: a six-section procedure (Inputs, Steps, Outputs,
Review gate, Eval checks, Failure modes) I can run for the next role
I open and refine before treating as standing.
What you'll ask: six short questions about how the pipeline works today.
Plain answers are fine — you do not need named candidates, compensation
figures, or confidential HR detail.
Context to assume: UK academic spinout, first 18 months post-licence,
one to three people; first non-academic hires typically commercial,
MLE, or operations; founder is not a recruiter.
Ask me first:
1. Most overdue role and roughly how long it has been open in my head?
(Why: the overdue role is the one the procedure needs to serve first;
the time tells me how acute the gap is.)
2. JD in writing, and when last edited?
(Why: the procedure's first output is a JD; knowing whether a draft
exists shapes the first step.)
3. Compensation band, and roughly how it was set?
(Why: the eval check tests whether every JD has a named band; knowing
the current approach tells me how much the procedure needs to codify.)
4. Interview rubric, and what it scores against?
(Why: a rubric that exists only in the founder's head cannot be
applied consistently; the procedure gives it a written home.)
5. Roughly how many candidates spoken to about this role, and where do
notes live? (Why: the procedure names a single location for notes and
requires them to trace to rubric scores.)
6. Time-to-JD from "we need this role" to "JD is live" — days or weeks?
(Why: the eval check measures and reports this for every new role;
the baseline tells me what the procedure is improving on.)
Then draft the procedure in the standard format.
Eval checks must include: every open role has a JD in writing; every
JD has a named compensation band and an interview rubric; time-to-JD
is measured and reported for every new role; candidate notes stored in
one place and traceable to rubric scores.
You must not: recommend specific ATS vendors; assume compensation
benchmarks I did not state; draft candidate-facing outreach in this
prompt (that is a separate workflow); propose the agent runs interviews.
Review gate: the founder reviews every JD and every rubric before
external use.
Begin by asking me question 1.The output is a hiring procedure that keeps the pipeline alive between roles. The eval check on time-to-JD is the one to watch; if it slips above forty-eight hours for the second role you open, the procedure is not yet standing on its own and needs another pass. The procedure does not solve the harder problem of finding the right person, but it does solve the easier problem of being ready when the right person appears. Note: the eval checks fire when the procedure runs — not when this draft is read. The time-to-JD check only becomes meaningful once the procedure has been applied to a second role opening; run it then.
The prioritisation prompt
You have six workflows in front of you. You cannot build six at once and you should not try. The right prioritisation depends on round stage, runway, board cadence, current FTE, what you are most behind on, and what conversation is coming next. A spinout three months from a Series A pre-emption conversation needs board pack and financial model first. A spinout that just closed seed and is two interviews a month behind on customer discovery needs customer-discovery synthesis first. A spinout where the lead investor has noticed two missed monthly updates needs investor update first, irrespective of what else is wrong. The prioritisation prompt takes your situation as input and produces a build sequence and rough effort estimate for the first one or two workflows.
Prompt, copy into Claude, ChatGPT, or any LLM
Show the prompt
Building all six workflows at once produces six aspirational documents.
Building one to a standard where it runs the same way twice, and the
eval checks pass both times, is where substrate begins. The question is
which one to build first — and the answer depends on which conversation
is coming next, not which gap feels largest.
You are an experienced UK seed-stage spinout operator who has sequenced
operational build work across founding teams at different stages and
knows that the right first workflow is the one that protects the next
institutional conversation, not the one that feels most overdue.
What you'll give me: a ranked recommendation of which one or two
workflows to build first, with a build sequence, rough effort estimate,
and a named trigger for starting the second.
What you'll ask: seven short questions about the current situation.
Plain answers are fine — you do not need cash positions, named funding
amounts, or exact headcount figures.
Context to assume: I have a clear sense of my top two gaps (from the
toolkit diagnostic, or my own read); I am one to three people, first 18
months post-licence.
Ask me first:
1. Round stage — post-seed, raising bridge, or pre-Series-A?
(Why: the next round shapes which workflow failure costs most.)
2. Runway — comfortable (a year or more), tightening (six to twelve
months), or short (under six)? (Why: runway position determines
how much build time is available before the next conversation.)
3. Board cadence — monthly, quarterly, or ad hoc?
(Why: cadence determines whether the board-pack and investor-update
workflows are already under pressure.)
4. Current FTE and who does what?
(Why: effort estimates are founder-hours; knowing who is available
calibrates what is realistic in the first quarter.)
5. What I am most behind on right now, in my own words?
(Why: your own read is the most direct signal; the recommendation
should align with it or explain why it does not.)
6. Next investor conversation coming, and roughly when?
(Why: the first workflow to build is the one that protects that
specific conversation.)
7. Founder time per week available for codification work?
(Why: the effort estimate names a range; knowing available time
translates that range into a realistic timeline.)
Then produce:
## Build sequence
### First workflow to build: [Name]
- Why this one first: one paragraph grounded in my stated situation,
naming the specific risk this workflow addresses and the specific
conversation it protects against.
- Rough effort estimate: range in founder-hours to reach standing
procedure that runs the same way twice, typically 4 to 12 hours
spread over two to three weeks, with conditions named.
- First concrete step this week: a single named action.
### Second workflow to build (only if first is stable): [Name]
- Same structure.
- Trigger to start: the specific signal that means the first workflow
is stable enough to start the second, e.g. "first workflow has run
twice with the same procedure and the eval checks have passed both
times".
You must not: recommend more than two workflows; fabricate runway or
round-stage detail; assume founder time I did not state; recommend a
vendor or tool.
Review gate: the build sequence is a draft. The founder decides whether
to proceed, defer, or sequence differently based on judgement the agent
does not have access to.
Begin by asking me question 1.The output is a sequencing recommendation, not a commitment. Read the "why this one first" paragraph and check whether the reasoning matches your sense of the next investor conversation that is coming. If it does not, push back on the agent in the same conversation; tell it the specific thing it has wrong and ask for a revised recommendation. The two-workflow ceiling is deliberate. A founding team that builds two workflows to standing-procedure quality in the first quarter is ahead of one that starts six and finishes none. Note: the eval checks in each workflow fire when the procedure runs — not when the build sequence is drafted. The sequencing recommendation is the plan; the eval checks are the evidence that the plan has worked.
What to do once you have run the toolkit
The temptation is to run all the prompts in one sitting, generate six procedures, and treat the resulting stack as a substrate. It is not. Six untested procedures are six aspirational documents. One procedure that has run twice and passed its own eval checks twice is the start of a substrate. Build one. Run it twice. Evaluate against its own eval checks. Iterate.
The tooling follows the procedure. Once the procedure is in writing, the question of which model, which orchestrator, which knowledge layer becomes tractable in a way it was not before. Piece 3 describes what the standing substrate looks like once the procedures are in place. Pieces 1 and 2 describe the funding architecture and the agentic bottleneck that make this work load-bearing in 2026 rather than optional. The codification act is the thing that matters; the tooling is downstream of it.
The same founding team can run a larger company than the headcount admits to. That is not a slogan — it is the consequence of writing down what you used to keep in your head, running it twice, and noticing it now runs without you.
Related reading
- Piece 0: There Has Never Been a Better Time to Be an Academic Founder., series introduction.
- Piece 1: The UK Committed £58 Billion to Research., the funding system.
- Piece 2: The Bottleneck Has Moved., the agentic bottleneck.
- Piece 3: Chat Plus SaaS Is No Longer Enough., the operational substrate this toolkit is the on-ramp to.
Companion kits
- The prompt toolkit, the four-chair operational-readiness diagnostic (founder, TTO, venture builder, investor).
- Funnel-position diagnostic, paired with Piece 1; the funding-pipeline diagnostic.
- Thesis-distinction confirmation, paired with Piece 2; the two-workflow identifier.