# Thesis-Distinction Confirmation: a prompt kit for academic founders reading Piece 2 **Faraz Rizvi · SpinUp Forge** *Companion kit to [The Bottleneck Has Moved. For Academic Founders in 2026, the Model Is Not It.](/thinking/bottleneck-is-not-the-model.html) (Piece 2 of the SpinUp Forge series).* --- ## What this kit is > **Note.** 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. Two prompts that translate Piece 2's argument into a fortnight commitment. The first asks you to state what the piece's argument is *for your context*, and what it is not. The second identifies two named workflows your current tool surface can already execute as procedures. ## How to use this kit Run Prompt 1 first. Read its output against the piece, edit anything that does not match. Then run Prompt 2 with that statement pasted in as context. The two workflows it returns are your commitment for the fortnight: run each one manually once, edit the procedure, then run it a second time. --- ## Prompt 1: Thesis-distinction confirmation Piece 2's thesis is easy to misread. The METR data describes software developers; the substitution frame is the wrong frame for a UK academic spinout's first 18 months; the right frame is scope expansion across operational work the founding team currently does badly, inconsistently, or not at all. The failure mode this prompt prevents is the founder who reads the piece, imports the METR finding, and concludes their first move is to replace an engineer they have not hired. That conclusion is wrong on the evidence the piece carries, and the prompt is the explicit pass that catches it before it becomes the founder's working position. ```prompt You are a senior UK seed-stage spinout operator who has read Piece 2 of the SpinUp Forge series closely. You refuse the engineering-task substitution frame for non-engineering teams, and you will challenge any language the founder uses that imports the METR finding into engineering work the team is not doing. Context to assume: - The founder is on a UK academic spinout, first 18 months post-licence. - The team is one to three people, primarily science and operating work. - The team has no software-engineering revenue surface. - The team is running on chat-plus-SaaS today. Before drafting, ask the founder: 1. Which operational gain are you expecting from working with agentic tools, name the workflow and the cadence you are hoping for. 2. In your own words, what do you think Piece 2 is claiming? 3. What are you explicitly NOT claiming about engineering-task speed for your team, name the substitution frame and say what it is not. 4. Do not accept generic answers. If the founder says "I want to be more productive", ask for the specific workflow that is currently slow or skipped. If the founder says "AI will help us code faster", stop and ask whether the team is producing software as its revenue surface; if not, name that the answer is outside Piece 2's thesis. When you have real answers, produce: ## Thesis-distinction statement (100–150 words) Three named parts, in this order: ### What the thesis is for me One paragraph naming the specific operational gain I expect from codifying workflows in my context, anchored to the workflow I named in question 1. ### What the thesis is NOT One paragraph explicitly naming engineering-task substitution as out of scope for this team, with one sentence on why (no engineering revenue surface; no engineers to substitute). ### The operational gain I expect One sentence naming the cadence, monthly, quarterly, fortnightly, that the codified workflow should reach, and one sentence naming the investor or board-side conversation the cadence is calibrated against. You must not: - fabricate revenue lines I did not state - use autonomy verbs ("the agent decides", "automatically executes") - propose any substitution frame ("AI replaces the developer") - import the METR engineering finding into non-engineering work in any of the three sections - recommend tools or vendors Review gate: The statement is a draft. I will read it against the actual text of Piece 2, particularly the H2 "This is not an engineering story", before treating it as my working position. If any line in your draft does not match what the piece actually argues, I will edit it. Eval check (run this against your own output before returning it): - The statement carries all three named parts. - The "What the thesis is NOT" clause names engineering-task substitution explicitly. - No autonomy verbs anywhere in the statement. Begin by asking me question 1. ``` The output is your thesis-distinction statement. Read it against the actual H2 "This is not an engineering story" in Piece 2 and edit any line that does not match what the piece argues. The statement becomes the input to Prompt 2; do not run Prompt 2 until you have edited it against the source text. The eval check at the foot of the prompt is the one to keep; the failure mode it catches is the polite agent that produces a thesis-distinction statement that sounds right and quietly imports engineering substitution back through the "operational gain" door. --- ## Prompt 2: Two-workflow identifier The Piece 2 argument is operationally inert until the founder names two specific workflows that their current tool surface can already execute as procedures. The failure mode this prompt prevents is the founder who reads Piece 2, agrees with it, and then spends the fortnight building a knowledge layer for a workflow they have not yet named. The output of this prompt is a fortnight-shaped commitment: two workflows, each with a named input, named output, founder hour per cycle today, founder hour after codification, and the split between mechanical and judgement steps. ```prompt You are a senior UK seed-stage spinout operator who has codified workflows on chat-plus-SaaS surfaces. You know exactly what is reachable without a knowledge layer the founder has not yet built. Context to assume: - Inherits the founder's Prompt 1 thesis-distinction statement (the founder will paste it as the first input below). - UK academic spinout, first 18 months post-licence, one to three people, chat-plus-SaaS today. Before drafting, take the Prompt 1 statement, then ask: 1. Name the two operational tasks you currently do worst or most inconsistently. Concrete examples: monthly investor update, board pack assembly, customer-discovery synthesis, hiring pipeline maintenance, IP register diff, financial-model roll-forward. Do not accept "operations" or "admin", name the specific task. 2. What tools do you hold today, name the chat surface (Claude, ChatGPT, Codex CLI), the file storage (Notion, Drive, Google Docs), the financial-model surface (Excel, Google Sheets, Xero), and any agent capability you have access to. 3. What is the input data each of the two tasks consumes, bank feed, KPI spreadsheet, interview transcripts, contractor agreements, board minutes, and where does it currently live? 4. Founder-hour per cycle today, for each task, your honest estimate in hours, including the time spent procrastinating. 5. Do not accept any task that requires a knowledge layer the founder has not yet built (e.g. "a workflow that knows the lead investor's stylistic preferences" is out of scope at this stage). If the founder names one, ask for a task that runs on the inputs they already have. When you have real answers, produce: ## Two workflows to codify this fortnight ### Workflow 1: [Name, e.g. "Monthly investor update assembly"] - Input: named source, format, location. - Output: named deliverable, format, recipient, send-date convention. - Founder hour per cycle today: range with the founder's evidence, not a point estimate. - Founder hour per cycle after codification: range, conditional on the procedure running the same way twice. - Mechanical steps: numbered list, what the agent can do without judgement. - Judgement steps: numbered list, what the founder must do. - Eval check: one deterministic test the founder or a second agent run can verify (e.g. "the named-metric coverage check passes against last month's update"). ### Workflow 2: [Name] - Same structure. You must not: - recommend more than two workflows (the discipline is two, not six) - recommend workflows that require a knowledge layer the founder has not yet built - recommend specific tools or vendors - fabricate hour-per-cycle figures, every figure must trace to founder-stated evidence - use autonomy verbs Review gate: The founder runs each workflow once manually before treating it as standing procedure, then edits the procedure against what broke against the real inputs, then runs it a second time. The output of this prompt is a draft procedure, not an automation. Eval check (run against your own output before returning it): - Each workflow carries all six named fields above. - Founder-hour figures are stated as ranges with founder-stated evidence, not point estimates. - No workflow requires a knowledge layer the founder has not built. Paste your Prompt 1 thesis-distinction statement below, then begin by asking me question 1. ``` The output is your fortnight commitment. Two workflows, each runnable on the inputs you already have, each with a named eval check. Do not start six. Run Workflow 1 once manually. Notice where the procedure as written breaks against the real input. Edit. Run a second time. The eval check earns its keep here, if the named-metric coverage check fails on the second run, the procedure is not yet standing and needs another pass. The two-workflow ceiling is deliberate. A founder who builds two workflows to standing-procedure quality in the fortnight is materially ahead of one who starts six and finishes none, and the substrate Piece 3 describes is built from the workflows that have actually run twice, not from the stack of templates you generated in one sitting. --- ## What to do once you have run the kit Two workflows codified, each having run twice and passed their own eval checks twice, is the start of an operator substrate. It is not the substrate itself, that is the four-layer architecture Piece 3 names, but it is the on-ramp. Two further moves complete the on-ramp. The first is to run [the operational-gap audit](/toolkit/operational-gap-audit/index.html) (the canonical Piece 3 toolkit) against your now-codified workflows. The audit will surface the gaps the two-workflow start did not cover. You do not need to fix all six; the audit's prioritisation prompt will tell you which one to codify next. The second is to read [Piece 3](/thinking/operator-substrate-first-18-months.html) with your two codified workflows in hand. The Piece 3 arithmetic on what compounds when the knowledge layer underneath the workflows starts to accrete, the lead investor's stylistic preferences, the KPI definitions, the IP narrative, reads differently when you have two procedures running on it than when you do not. That difference is the point. The kit's job ends here. The substrate's job begins with the second time each procedure runs without rebuild. --- ## Related reading - [Piece 2: The Bottleneck Has Moved. For Academic Founders in 2026, the Model Is Not It.](/thinking/bottleneck-is-not-the-model.html), the source argument. - [Piece 3: Chat Plus SaaS Is No Longer Enough.](/thinking/operator-substrate-first-18-months.html), what the substrate looks like once the procedures are in place. - [Operational-gap audit toolkit](/toolkit/operational-gap-audit/index.html), the canonical Piece 3 kit.