linersh 1.0.0 → 1.0.1

package/cli-update-docs/JTBD-MASTER-PROMPT-ABOUT.md

@@ -1,130 +0,0 @@
-# About the JTBD Master Prompt
-
-Companion document to [`JTBD-MASTER-PROMPT.md`](./JTBD-MASTER-PROMPT.md). Explains what the prompt is, why it exists, how it works, where it came from, and where it can still go wrong.
-
----
-
-## Why this exists
-
-Liner's curation methodology has eight phases. Phase 1 — Framing — is the single highest-leverage step in the lifecycle. The job-to-be-done statement defined here drives every downstream decision: which sources land in the candidate longlist, how the knowledge map is sectioned, what gets cut at evaluation, how the synthesis is framed. A bad JTBD propagates through everything else and produces a mixtape that looks complete but doesn't measurably improve AI output. A good JTBD makes every downstream phase easier.
-
-The methodology already knows what a tight JTBD looks like. `CURATION.md` says it must be a "single specific sentence." `SKILL.md` says the AI must "push back" if the user offers a topic. `MIXTAPE-FORMAT.md` documents the `jtbd:` field. But that guidance is spread across multiple docs and lives in the curator's head, not in a deployable prompt. The result, in practice: users land at "topic" level ("mobile design," "SEO content," "contract law") instead of "job" level. Once they do, the rest of curation drifts.
-
-The JTBD Master Prompt fixes that gap. It's a single, drop-in prompt that takes a user from wherever they are — a vague topic, a folder of content, a half-formed idea — to one tight Job Story that passes a rubric. That Job Story is the input to the rest of Liner's pipeline. Everything else (knowledge map, candidate discovery, evaluation, synthesis) is already handled.
-
-## What it is
-
-A self-contained master prompt stored at `docs/curation-skill/JTBD-MASTER-PROMPT.md`. The body sits between `---BEGIN---` and `---END---` markers and is meant to be copy-pasted into an AI conversation, embedded inside the `curating-mixtapes` skill, or spawned as a TUI subprocess.
-
-The prompt's sole deliverable is a single sentence in the Intercom Job Story form: *"When [circumstance], I want [motivation], so I can [outcome]."* No rationale, no knowledge map, no commentary — those belong to later phases. One sentence on one line.
-
-The prompt is interactive: it offers to read project material, conducts a small interview (capped at five questions, three typical), runs the draft through an internal rubric, and emits.
-
-## How it works
-
-Five moves, in order:
-
-**Step 0 — Offer to read project material.** The agent's first message is a single short question: *"Do you have any documents or project material I should look at first?"* The user can drop files into the chat, point at a folder (if the agent has filesystem access), or say no and move straight into conversation. This question fires unconditionally and does not count against the question budget. The reason for asking rather than detecting: users frequently have load-bearing material they wouldn't think to share unprompted, and silent inference of context produces wrong JTBDs that propagate through every downstream phase.
-
-**Step 1 — Read what the user shared, if any.** If the user shared material, the agent reads enough to confidently characterize the project — start with project-description files (`README`, `CLAUDE.md`, `synthesis.md`, `tape.yaml`), then any flagged content, then any additional material needed to name domain, audience, stage, and explicit goal. Token cost is not optimized; user-time is. If the agent has no file tools and the user pointed at a folder, it says so plainly and asks for files-in-chat or a description instead. It never invents file contents.
-
-**Step 2 — Confirm what was inferred.** After reading, the agent's next message is a confirmation: *"I see your project is [X] for [Y], focused on [Z]. Is the mixtape meant to help you (a) [candidate], (b) [candidate], (c) [candidate], or (d) something else?"* One turn, one confirmation. Option (d) is required. The agent never bakes inferred context into the JTBD silently.
-
-**Step 3 — Run a budgeted interview, if needed.** If the user shared no material, or if reading wasn't enough, the agent opens with a single batched message of two or three basic questions (domain, role, concrete activity), then descends the scope ladder one question at a time. Each follow-up walks the user from aspiration → big → little → micro. The agent stops asking when the next question wouldn't change the draft. Hard cap: five total questions, three typical.
-
-**Step 4 — Draft, critique, refine, emit.** The agent drafts the Job Story silently. Before emitting, it runs the draft through a six-test rubric: structural (all three slots present and non-empty), solution-free (no vendor / framework / tool named), single-scope (one job per slot), specific (not generic or aspirational), externally readable (a stranger could understand it without context), and slot hygiene (audience clauses live in the circumstance, not the motivation). If a test fails, the agent fixes the draft and re-checks. The rubric is never shown to the user. Output is one line — the Job Story, no preamble, no commentary, no quote marks, no code fence. If the user pushes back, the agent doesn't defend; it takes the correction, re-runs the rubric, and emits a revised statement in the same format.
-
-## Where it came from
-
-The prompt is the engineering output of a mixtape compiled specifically for this question. That local source mixtape is archived at:
-
-```
-/Users/arturo/Documents/Projects/0-archive/liner-archive/2026-06-25-root-cleanup/mixtapes/jtbd-master-prompt/
-├── MIXTAPE.md              # compiled master file
-├── tape.yaml               # the recipe
-├── synthesis.md            # the curator's framing
-├── sources/                # 32 extracted sources
-└── working/                # the curation trace
-```
-
-**Curator:** cmdux. **Compiled:** 2026-05-27. **Mode:** quick.
-
-Thirty-two sources span two literatures that don't usually meet: JTBD theory (Ulwick, Christensen, Klement, Kalbach, Moesta, the Intercom Job Story canon and its critics) and prompt engineering (Anthropic's prompting best practices, the meta-prompting literature, elicitation patterns for agentic AI, the evaluator-optimizer pattern, the persona-injection ablation studies). The synthesis bridges them: how do you design a system prompt that talks to a human and produces a tight JTBD sentence on demand?
-
-Six generative rules from that synthesis show up directly in the prompt:
-
-1. **Job Story format with three required slots.** The synthesis recommends the Intercom "When [circumstance], I want [motivation], so I can [outcome]" form over alternatives because the required slots fail structurally when missing — a sentence-shaped non-job ("Help me with healthcare marketing") can't survive the Job Story format's structural check, where it could survive a single-slot form.
-2. **Solution-free, single-scope, specific, externally readable** as the spine of the tightness rubric — those tests come from Ulwick's outcome-statement grammar via the SIVO clarity rubric, adapted to the Job Story slots.
-3. **The aspiration → big → little → micro scope ladder** as the structure of the descent interview — from User Interviews' UX field guide on hyper-specificity.
-4. **Evaluator-optimizer loop (draft → critique → refine)** as the internal generation pattern — from Anthropic's "Building Effective Agents" pattern taxonomy and the LLM self-critique prompting literature.
-5. **One question at a time, hard budget, stop when next question wouldn't change the draft** — from the active-questioning and elicitation literature on agentic AI.
-6. **No persona in the prompt** — from the Zheng et al. 2023 ablation showing persona injection doesn't improve task accuracy and optimal-persona prediction is no better than random.
-7. **Failure-mode-first engineering register** — from the Claude 4 system-prompt teardown and the prompt-engineering anti-patterns catalog. Production system prompts are lists of mistakes the model used to make; the JTBD prompt is shaped the same way.
-
-A few choices in the prompt deliberately diverge from the mixtape's center of gravity, and they're worth naming:
-
-- **No passing examples in the final prompt.** The synthesis recommends concrete examples as a teaching tool. We dropped them because passing examples carry an anchoring risk — the model copies surface features from the example domain. Failing examples teach a rule that generalizes; passing examples teach a style that doesn't. The rubric is doing the work passing examples normally would. The single passing example that does appear (the clinical Job Story for the diabetes case in the descent section) illustrates *the casual-language-to-Job-Story translation*, not the target shape itself.
-- **Quality over token economy in the read step.** Early drafts capped reads at "two or three sampled files." That cap is gone. If the user shared material, the agent reads enough to confidently characterize the project. Stopping condition is *confidence*, not file count.
-- **Single context-sharing question, not a multi-path router.** An earlier draft offered the user three explicit routing options (folder / files / skip) in a ~120-word message. That turned out to be friction solving for the wrong problem. The deployment scenario is narrower than the router assumed: this prompt is only ever used to create a fresh JTBD from scratch. Users don't paste pre-drafted JTBDs (the whole point is they don't have one), and the choice between "files" and "folder" is mechanical, not strategic. The single short question — *"Do you have any documents or project material I should look at first?"* — surfaces the affordance without forcing the user through a decision tree.
-
-### Historical note: the house form
-
-Earlier versions of Liner — and the first published version of this prompt — used a different JTBD form: *"Help me [verb] [object] [scope]."* That form matched the surface shape of every Liner artifact at the time (the methodology docs, the example mixtapes, the schema), so the prompt was designed to produce what Liner already consumed.
-
-The trade-off became clear once the prompt was used in practice. The house form has no required slots: a sentence like "Help me with healthcare marketing" satisfies the form template but is not a JTBD. That meant the qualitative rubric had to do all the work of catching topic-shaped non-jobs — a soft check rather than a hard one. The Job Story format has the same forgivingness against mush in its individual slots but fails structurally when a slot is empty, which raises the floor before the rubric runs.
-
-The format switch realigned the prompt with the original synthesis recommendation. The cost is a one-time migration of existing artifacts; the benefit is a structurally tighter floor on every future JTBD.
-
-## How to use it
-
-Three deployment paths, all using the same prompt:
-
-**Pure-chat (Claude.ai, ChatGPT, Cowork web).** User pastes the prompt block into a fresh chat. When the context-sharing question fires, the user can drop files into the chat or say they have no material. Folder paths aren't viable in this environment; the prompt handles that case gracefully.
-
-**Agent with filesystem access (Claude Code, Cowork desktop, Codex, the Liner TUI as a subprocess).** Both file attachments and folder paths are live. The user picks; the agent reads accordingly.
-
-**Embedded inside the `curating-mixtapes` skill.** Drop the prompt block into `docs/curation-skill/SKILL.md` as the body of Phase 1 — Framing, replacing the current "Ask the user for the JTBD" paragraph. The skill's outer context provides Liner framing; this prompt handles JTBD elicitation. Filesystem access is the default in the skill's runtime.
-
-**As a TUI subprocess.** A future `liner jtbd <folder>` command could spawn this prompt with the folder path in context. The context-sharing question still fires — the user might want to add files or skip the folder — but the path is available if they want it.
-
-## Design choices worth understanding
-
-A few decisions in the prompt aren't obvious and have been pushed back on during design:
-
-**Why fire the context-sharing question unconditionally?** Capability detection is brittle: file tools may be advertised but broken, sandboxed, or scoped to a different path than the user expects. Silent inference of context is worse than no context. Asking once is one extra turn; getting it wrong is a wrong JTBD that propagates through every downstream phase. Asking respects user agency and removes a class of silent-failure bugs. The question is short — three sentences — to keep the friction low.
-
-**Why a hard question budget?** The most reliable failure mode for interview prompts is death by clarification — the model keeps asking because "one more question" feels safer than committing. A budget forces a draft. Five questions max, three typical. If the model finds itself drafting a fourth follow-up, the prompt instructs it to draft the JTBD instead.
-
-**Why no persona block?** Empirically (Zheng et al., 2023, 162 personas × 2,410 questions) persona injection doesn't improve task accuracy and optimal-persona prediction is no better than random. "You are an expert JTBD practitioner with twenty years of experience" buys hedging language, not skill. The prompt names the task instead.
-
-**Why failure modes before instructions?** Production system prompts shipped by frontier labs read as enumerated lists of mistakes the model used to make. That's the right register: the prompt prevents the five specific failures (solution baked in, conflated jobs, topic-as-JTBD, aspirational mush, death-by-questions) more than it teaches JTBD theory.
-
-**Why no passing examples (mostly)?** Asymmetric example design — failing examples teach a generalizable rule, passing examples anchor on style and domain. The one passing example in the prompt (the clinical Job Story for the diabetes case) appears only to demonstrate the casual-language-to-Job-Story translation, not the shape of the target output. If users in adjacent fields start pattern-matching on it, swap or strip it.
-
-**Why a slot hygiene check?** The first five rubric checks (structural, solution-free, single-scope, specific, externally readable) caught most failures in early use but consistently missed one: audience-scoping camped in the motivation slot. A draft like "I want to design a single-page site that explains the tool to people who already use AI" is technically one motivation, but the audience clause belongs in the circumstance. When audience drifts into the motivation, the circumstance reads thinner than the JTBD actually is, and the synthesis underneath misses signal it should have caught. Slot hygiene is the rule that promotes this from per-curator judgment to a generalizable check. It does not police mush, weak audience scoping, or product-positioning that doesn't earn its slot — those remain curator-level judgments and the qualitative rubric stays load-bearing.
-
-## What this prompt does NOT do
-
-- It does not produce a knowledge map. Phase 1 of curation wants both JTBD and knowledge map; this prompt produces only the JTBD. The knowledge map is the next move in the skill.
-- It does not produce sources, citations, or curator notes. Those are Phase 2 and Phase 4.
-- It does not produce a synthesis. Phase 6.
-- It does not validate the JTBD against a real mixtape. The rubric is necessary but not sufficient. The empirical test (Phase 8) is the only real validation.
-- It does not defend against adversarial users. Cooperative-user assumption is baked in. If the prompt ever ships in a context with hostile input (public web form, untrusted API), add a refusal clause.
-- It does not accept a pre-drafted JTBD as input. The deployment scenario is fresh JTBD creation from scratch; users with an existing draft don't need this prompt.
-
-## Known limits and watch items
-
-- **Anchoring risk on the process examples.** The descent section contains examples from clinical, engineering, and creative domains. These illustrate *the scope-ladder shape*, not target output, so the anchoring risk is weaker than it would be for passing JTBD examples — but it's nonzero. If users in those fields consistently produce ladder-shaped artifacts that don't fit their actual work, swap or strip them.
-- **The structural and slot-hygiene rubric checks are necessary, not sufficient.** Slot 1 catches *omitted* slots; slot 6 catches misplaced audience clauses. Neither catches mush, weak audience scoping, or product-positioning that doesn't earn its slot. A Job Story like "When I'm doing marketing, I want to do it well, so I can succeed" passes both structural checks and fails on the qualitative ones. The qualitative rubric stays load-bearing.
-- **Soft dependency on user calibration.** The prompt assumes the user can identify their most relevant material. Almost always true for someone curating a mixtape; less true for a first-time user. If you observe weak JTBDs from less-experienced users, the fix is a checklist of *kinds* of content that tend to be load-bearing (project briefs, requirements docs, customer research, prior synthesis attempts), not more rules in the prompt.
-- **Big-repo reads.** If a user points the agent at a very large folder, the "read enough to confidently characterize" rule may still under-sample the part of the repo that defines domain. The fix isn't a token cap; it's better signposting in the context-sharing question if you observe drift.
-
-## Related files
-
-- The prompt itself: [`JTBD-MASTER-PROMPT.md`](./JTBD-MASTER-PROMPT.md)
-- The current format spec: [`MIXTAPE-FORMAT.md`](./MIXTAPE-FORMAT.md)
-- The archived source mixtape: `/Users/arturo/Documents/Projects/0-archive/liner-archive/2026-06-25-root-cleanup/mixtapes/jtbd-master-prompt/`
-- The Liner curation methodology that places this work in Phase 1: [`CURATION.md`](./CURATION.md)
-- The skill that will likely embed this prompt: [`SKILL.md`](./SKILL.md)
-- The mixtape format spec defining the `jtbd:` field the prompt's output lands in: [`MIXTAPE-FORMAT.md`](./MIXTAPE-FORMAT.md)
-- Project-level overview of Liner: [`LINER-MASTER.md`](./LINER-MASTER.md)

package/cli-update-docs/JTBD-MASTER-PROMPT.md

@@ -1,147 +0,0 @@
-# JTBD Master Prompt
-
-A drop-in prompt that interviews a Liner user and emits one tight, hyper-specific Job Story — the kind that belongs in the `jtbd:` field of a `tape.yaml`. Paste it into any AI chat as the opening message, or load it as Phase 1 inside the `curating-mixtapes` skill. Its only output is the Job Story sentence; everything downstream (knowledge map, candidate discovery, evaluation, synthesis) is Liner's job, not this prompt's.
-
----
-
-## The prompt
-
-Copy everything between the `---BEGIN---` and `---END---` markers.
-
-```
----BEGIN---
-You run a focused interview that ends in exactly one sentence: a job-to-be-done (JTBD) statement for the `jtbd:` field of a Liner `tape.yaml`. That sentence drives every downstream Liner decision, so it has to be tight. Your only deliverable is that statement, on its own line.
-
-## What "tight" means
-
-The form: "When [circumstance], I want [motivation], so I can [outcome]."
-
-All three slots are required. The form is permissive on what fills them — a legal Job Story, a clinical Job Story, and an engineering Job Story share this shape but no vocabulary. The form's only structural guarantee is that no slot can be empty; the rubric below catches the rest.
-
-Failures to refuse:
-
-- "When I'm working in healthcare, I want to do healthcare marketing, so I can grow the business." — All slots filled but each is mush; circumstance and motivation both restate the topic.
-- "When I'm practicing law, I want to be a better lawyer, so I can serve clients well." — Motivation is aspiration, not a concrete job.
-- "When our database hits scale limits, I want to migrate to PostgreSQL using Prisma, so I can ship features faster." — Solution baked into the motivation.
-- "When I'm prepping a class, I want to design a curriculum and teach it, so I can finish the term." — Two motivations joined by "and."
-- "When I'm doing marketing, I want to do it the right way, so I can succeed." — Circumstance, motivation, and outcome are all undefined.
-
-## Hard rules
-
-- No vendor, framework, library, methodology, or tool name in any slot of the final statement.
-- No "and," comma, or slash joining two circumstances, two motivations, or two outcomes. If the user describes two, ask which one this mixtape is for.
-- A bare noun phrase ("mobile design," "contract law") is not a JTBD. A JTBD has a scoped circumstance, a concrete motivation, and a meaningful outcome.
-- Do not invent context. If you don't know the user's role, platform, deadline, or audience, ask.
-- Do not credentialize ("As an expert JTBD practitioner..."). Name the task instead.
-- Do not narrate, summarize, or restate the conversation.
-- Output the statement alone on its own line. No quotes, code fence, header, or commentary.
-- Hard cap: five questions across the entire interview. Three is typical. If you're about to ask a fourth follow-up, draft instead.
-
-## Step 0: Offer to read project material
-
-Your first reply is one short question, before any interview questions:
-
-> Before we begin, do you have any documents or project material I should look at first? If yes, drop them into this chat (or point me at a folder if I have filesystem access here). If not, just say so and we'll talk it through.
->
-> A few well-chosen files beat a full dump.
-
-This question does not count against the question budget.
-
-**If the user shares material:** Read it. Stop when you can name domain, audience, stage, and an explicit goal. Then go to confirmation (below).
-
-**If the user has no material to share:** Go straight to the interview protocol.
-
-**If the user points at a folder and you have no file tools:** Say so plainly and ask them to drop files into the chat or describe the project. Do not pretend you read something you couldn't.
-
-## Confirmation (after reading, if material was shared)
-
-One turn, one message:
-
-> I see your project is [X] for [Y], focused on [Z]. Is the mixtape meant to help you (a) [candidate], (b) [candidate], (c) [candidate], or (d) something else?
-
-Candidates are casual-language scopings, not Job Stories yet — you translate at emit time. `(d)` is required. If the user picks it, ask one descent question and draft.
-
-If the user contradicts what you read, the user wins. Probe the contradiction once if it changes the circumstance, motivation, or outcome; otherwise accept and proceed.
-
-## Interview protocol
-
-Open with a single batched message asking only what you can't infer from material the user shared:
-
-1. What domain or topic is this mixtape about?
-2. Who are you in this work — what role or context shapes which sources count as canonical?
-3. What will you actually do with an AI that has this context — one concrete activity, not a vibe?
-
-Skip any of those that shared material already answered.
-
-After the batch, one question at a time, walking down the scope ladder. The user expresses each level in casual language; you translate the micro level into Job Story form at emit time. Three illustrative fields (substitute the user's actual field):
-
-- **Clinical:** "be a great doctor" → "communicate diagnoses well" → "explain new diagnoses to patients" → "explain a new Type 2 diabetes diagnosis to an adult with low health literacy at a first visit."
-- **Engineering:** "ship faster" → "reduce CI runtime" → "speed up the integration test suite" → "speed up the integration test suite for a Rails 7 monolith with 3,200 tests while keeping coverage above 85%."
-- **Creative:** "write better" → "improve my essays" → "structure long-form essays" → "structure 4,000-word tech essays for a developer audience reading on mobile."
-
-The corresponding final Job Story for the clinical example would be: "When I deliver a new Type 2 diabetes diagnosis to an adult with low health literacy at a first visit, I want to explain the condition and the immediate care plan, so the patient leaves able to describe what diabetes is and one thing they need to do this week."
-
-The JTBD is done when the micro level is single-circumstance, single-scope, concrete enough that a mixtape built against it could be measurably better than no mixtape.
-
-**Prefer multi-choice over free-form.** Offer 2–4 candidate scopings in casual language; the user picks or overrides.
-
-**Stop when the next question wouldn't change the draft.** After the second descent question, draft silently. Only ask another question if the draft fails the rubric *and* the fix requires user input you don't already have.
-
-## Internal rubric (silent)
-
-Before emitting, check the draft. If any fail, fix and re-check.
-
-1. **Structural.** "When [X], I want [Y], so I can [Z]" — all three slots present and non-empty.
-2. **Solution-free.** No tool, framework, vendor, library, methodology, or specific method named in any slot.
-3. **Single scope.** No "and"/comma/slash joining two circumstances, two motivations, or two outcomes. If a slot decomposes into two complete jobs when split, you had two.
-4. **Specific, not generic or aspirational.** Circumstance is scoped to a real situation, not "when I'm working." Motivation is a concrete action, not "be better at X." Outcome is meaningful, not "so I can succeed."
-5. **Externally readable.** A stranger who has never seen this project could read it and understand what's being asked. Strip "my app," "the team," "our process" unless enough scope makes them legible cold.
-6. **Slot hygiene.** Audience and situational context belong in the circumstance, not the motivation. The motivation describes the action the user is taking; the circumstance describes who it's for and the situation around it. If the draft reads "I want to [action] for [audience]" or "I want to [action] that [explains/serves/teaches] [audience]," move the audience clause into the circumstance and tighten the motivation to the action alone. Sequential clauses in the outcome ("install, then understand, then build") are not a violation — they're one composite outcome.
-
-## Emit
-
-One line. The Job Story. Alone. No preamble, no "Here's your JTBD," no quotes, no code fence.
-
-If the user pushes back, do not defend. Take the correction, re-run the rubric, emit a new statement in the same format.
----END---
-```
-
----
-
-## Why it's shaped this way
-
-A few choices that aren't obvious:
-
-**Job Story format, not Liner's older house form.** Earlier versions of Liner used "Help me [verb] [object] [scope]." That form was easy to write and matched existing Liner artifacts, but it had no required slots — "Help me with healthcare marketing" looks like the form but isn't a job. The Job Story format ("When [circumstance], I want [motivation], so I can [outcome]") fails structurally when any slot is missing, which raises the floor on what counts as a JTBD before the rubric even runs. This realigns with the recommendation in the mixtape's own synthesis.
-
-**The first question is always the context-sharing offer.** This prompt is only ever used for one purpose: to help a user create a fresh JTBD for a Liner mixtape from scratch. Users won't paste pre-drafted JTBDs (the whole point is they don't have one yet) and they may not think to attach material unprompted. The single context-sharing question puts the affordance in front of them once, then gets out of the way. Earlier drafts of this prompt had a longer routing question and multiple "fast paths" for pre-attached material; both turned out to be friction solving for scenarios that don't happen in this prompt's actual deployment.
-
-**Slot hygiene as a sixth rubric check.** The other rubric tests catch missing slots, solution leakage, multi-scope jobs, mush, and unreadable references. They miss a recurring quieter failure: audience-scoping camped in the motivation slot. "I want to design a single-page site that explains the tool to people who already use AI" is technically one motivation, but the audience clause ("to people who already use AI") belongs in the circumstance. When audience drifts into the motivation, the circumstance gets thinner and the JTBD reads as less situated than it actually is. The sixth rubric check makes this generalizable rather than per-curator-judgment.
-
-**No persona block.** Recent empirical work on persona injection (Zheng et al., 162 personas / 2,410 questions) shows persona prompts don't improve task accuracy on average and that optimal-persona prediction is no better than random. Telling the model "you are an expert JTBD practitioner with twenty years of experience" buys nothing and costs a hedge in the output. The prompt names the task instead.
-
-**Failure modes listed before instructions.** Production system prompts shipped by frontier labs read as enumerated lists of mistakes the model used to make. That's the right register here — the prompt's job is to prevent the five specific failure modes (solution-baked-in, conflated jobs, topic-as-JTBD, aspirational mush, death-by-questions) more than it is to teach JTBD theory.
-
-**Hard question budget.** Five questions, three typical. The most common interview failure mode is death by clarification — the model keeps asking because "one more question" feels safer than committing. The budget forces a draft.
-
-**No rationale or knowledge map in the output.** This prompt has one job: produce the Job Story line. Anything else belongs to the next phase of curation, which Liner already runs.
-
-## How to use it
-
-The prompt's first move is always the same — ask the user whether they have project material to share, then either read what they hand over or interview them directly. What changes by environment is what counts as "shareable":
-
-**Pure chat (Claude.ai, ChatGPT, Cowork web).** Users paste the prompt block (between the BEGIN/END markers) into a fresh chat. They can drop files into the chat when the context-sharing question fires; folder paths aren't viable.
-
-**Agent with filesystem access (Claude Code, Cowork desktop, Codex, the Liner TUI as a subprocess).** Both file attachments and folder paths work. If the user gives a path, the agent reads from disk.
-
-**Inside the `curating-mixtapes` skill.** Drop the prompt block into `docs/curation-skill/SKILL.md` as the body of Phase 1 — Framing, replacing the current paragraph about asking the user for the JTBD. The skill's outer context handles Liner-specific framing; this prompt handles the Job Story elicitation. The skill runs in environments with full filesystem access.
-
-**Inside the TUI as a dedicated subprocess.** A `liner jtbd <folder>` command can spawn the agent with the folder path already in context. The agent still asks the context-sharing question — the user might want to add files or skip the folder — but the path is available if they want to use it.
-
-## Where it can still go wrong
-
-Three known soft spots worth knowing:
-
-- **Cooperative-user assumption.** The prompt has no defenses against a user trying to coax a JTBD that legitimizes a harmful product, or against prompt injection from pasted material. If you ever ship this in a context with hostile input, add a refusal clause.
-- **Asymmetric examples by design.** The prompt includes failing Job Story examples but no passing ones. Failing examples teach a rule (the failure mode generalizes the moment you read it); passing examples teach a style and anchor the model on whatever domains they're drawn from. The clinical example in the descent section illustrates *process shape*, not target output shape, which is a weaker anchor — but it's nonzero. If you observe users in adjacent fields pattern-matching on it, swap in two more descent examples from different fields, or strip the example entirely.
-- **Structural and slot-hygiene checks are necessary, not sufficient.** Slot 1 of the rubric only catches *omitted* slots, and slot 6 only catches misplaced audience clauses. They don't catch mush, weak audience scoping, or product-positioning that doesn't earn its slot — those remain curator-level judgments. The qualitative rubric stays load-bearing. The format and the structural checks raise the floor; they don't replace the rubric.