linersh 0.5.7 → 1.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (97) hide show
  1. package/README.md +84 -159
  2. package/bin/liner.js +89 -44
  3. package/cli-update-docs/README.md +6 -6
  4. package/cli-update-docs/SKILL.md +72 -37
  5. package/cli-update-docs/quality-check-tests.md +256 -8
  6. package/cli-update-docs/source-finding-tactics.md +140 -3
  7. package/cli-update-docs/source-quality-hierarchy.md +83 -0
  8. package/cli-update-docs/synthesis-guidance.md +19 -5
  9. package/dist/agents/artifact-validation.js +440 -0
  10. package/dist/agents/artifact-validation.js.map +1 -0
  11. package/dist/agents/candidate-longlist.js +100 -0
  12. package/dist/agents/candidate-longlist.js.map +1 -0
  13. package/dist/agents/detect.js +3 -2
  14. package/dist/agents/detect.js.map +1 -1
  15. package/dist/agents/evaluation-assembly.js +270 -0
  16. package/dist/agents/evaluation-assembly.js.map +1 -0
  17. package/dist/agents/headless-runner.js +227 -0
  18. package/dist/agents/headless-runner.js.map +1 -0
  19. package/dist/agents/jtbd-clarify.js +42 -41
  20. package/dist/agents/jtbd-clarify.js.map +1 -1
  21. package/dist/agents/models.js +6 -7
  22. package/dist/agents/models.js.map +1 -1
  23. package/dist/agents/prompts.js +220 -20
  24. package/dist/agents/prompts.js.map +1 -1
  25. package/dist/agents/runner.js +462 -21
  26. package/dist/agents/runner.js.map +1 -1
  27. package/dist/phases.js +13 -13
  28. package/dist/phases.js.map +1 -1
  29. package/dist/source-inbox.js +297 -0
  30. package/dist/source-inbox.js.map +1 -0
  31. package/dist/version.js +3 -9
  32. package/dist/version.js.map +1 -1
  33. package/dist/yaml-io.js +42 -11
  34. package/dist/yaml-io.js.map +1 -1
  35. package/package.json +26 -23
  36. package/cli-update-docs/ABOUT.md +0 -69
  37. package/cli-update-docs/AI-HANDOFF.md +0 -241
  38. package/cli-update-docs/CURATION.md +0 -261
  39. package/cli-update-docs/JOB-STORY-MIGRATION.md +0 -99
  40. package/cli-update-docs/JTBD-MASTER-PROMPT-ABOUT.md +0 -133
  41. package/cli-update-docs/JTBD-MASTER-PROMPT.md +0 -147
  42. package/cli-update-docs/LINER-MASTER.md +0 -546
  43. package/cli-update-docs/MIXTAPE-FORMAT.md +0 -398
  44. package/cli-update-docs/PLATFORM.md +0 -210
  45. package/cli-update-docs/TUI-BACKLOG.md +0 -155
  46. package/dist/App.js +0 -220
  47. package/dist/App.js.map +0 -1
  48. package/dist/colors.js +0 -132
  49. package/dist/colors.js.map +0 -1
  50. package/dist/components/Header.js +0 -15
  51. package/dist/components/Header.js.map +0 -1
  52. package/dist/components/KeyHints.js +0 -17
  53. package/dist/components/KeyHints.js.map +0 -1
  54. package/dist/components/LabeledBox.js +0 -53
  55. package/dist/components/LabeledBox.js.map +0 -1
  56. package/dist/components/NextSteps.js +0 -18
  57. package/dist/components/NextSteps.js.map +0 -1
  58. package/dist/index.js +0 -17
  59. package/dist/index.js.map +0 -1
  60. package/dist/screens/AgentSetup.js +0 -224
  61. package/dist/screens/AgentSetup.js.map +0 -1
  62. package/dist/screens/BootSplash.js +0 -163
  63. package/dist/screens/BootSplash.js.map +0 -1
  64. package/dist/screens/CompileView.js +0 -567
  65. package/dist/screens/CompileView.js.map +0 -1
  66. package/dist/screens/FramingConfirmReview.js +0 -197
  67. package/dist/screens/FramingConfirmReview.js.map +0 -1
  68. package/dist/screens/Gate1Review.js +0 -147
  69. package/dist/screens/Gate1Review.js.map +0 -1
  70. package/dist/screens/Gate2Review.js +0 -162
  71. package/dist/screens/Gate2Review.js.map +0 -1
  72. package/dist/screens/ImportPrompt.js +0 -173
  73. package/dist/screens/ImportPrompt.js.map +0 -1
  74. package/dist/screens/JsSetup.js +0 -77
  75. package/dist/screens/JsSetup.js.map +0 -1
  76. package/dist/screens/LocalFilePicker.js +0 -139
  77. package/dist/screens/LocalFilePicker.js.map +0 -1
  78. package/dist/screens/NewMixtapeWizard.js +0 -662
  79. package/dist/screens/NewMixtapeWizard.js.map +0 -1
  80. package/dist/screens/PhaseRunner.js +0 -1203
  81. package/dist/screens/PhaseRunner.js.map +0 -1
  82. package/dist/screens/ProcessManifest.js +0 -160
  83. package/dist/screens/ProcessManifest.js.map +0 -1
  84. package/dist/screens/ProjectHub.js +0 -557
  85. package/dist/screens/ProjectHub.js.map +0 -1
  86. package/dist/screens/SourceModal.js +0 -269
  87. package/dist/screens/SourceModal.js.map +0 -1
  88. package/dist/screens/TapeBrowser.js +0 -312
  89. package/dist/screens/TapeBrowser.js.map +0 -1
  90. package/dist/screens/TapeDraftReview.js +0 -444
  91. package/dist/screens/TapeDraftReview.js.map +0 -1
  92. package/dist/screens/TapeEditor.js +0 -310
  93. package/dist/screens/TapeEditor.js.map +0 -1
  94. package/dist/screens/cassette-art.js +0 -72
  95. package/dist/screens/cassette-art.js.map +0 -1
  96. package/dist/store.js +0 -10
  97. package/dist/store.js.map +0 -1
@@ -1,147 +0,0 @@
1
- # JTBD Master Prompt
2
-
3
- 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.
4
-
5
- ---
6
-
7
- ## The prompt
8
-
9
- Copy everything between the `---BEGIN---` and `---END---` markers.
10
-
11
- ```
12
- ---BEGIN---
13
- 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.
14
-
15
- ## What "tight" means
16
-
17
- The form: "When [circumstance], I want [motivation], so I can [outcome]."
18
-
19
- 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.
20
-
21
- Failures to refuse:
22
-
23
- - "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.
24
- - "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.
25
- - "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.
26
- - "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."
27
- - "When I'm doing marketing, I want to do it the right way, so I can succeed." — Circumstance, motivation, and outcome are all undefined.
28
-
29
- ## Hard rules
30
-
31
- - No vendor, framework, library, methodology, or tool name in any slot of the final statement.
32
- - 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.
33
- - 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.
34
- - Do not invent context. If you don't know the user's role, platform, deadline, or audience, ask.
35
- - Do not credentialize ("As an expert JTBD practitioner..."). Name the task instead.
36
- - Do not narrate, summarize, or restate the conversation.
37
- - Output the statement alone on its own line. No quotes, code fence, header, or commentary.
38
- - Hard cap: five questions across the entire interview. Three is typical. If you're about to ask a fourth follow-up, draft instead.
39
-
40
- ## Step 0: Offer to read project material
41
-
42
- Your first reply is one short question, before any interview questions:
43
-
44
- > 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.
45
- >
46
- > A few well-chosen files beat a full dump.
47
-
48
- This question does not count against the question budget.
49
-
50
- **If the user shares material:** Read it. Stop when you can name domain, audience, stage, and an explicit goal. Then go to confirmation (below).
51
-
52
- **If the user has no material to share:** Go straight to the interview protocol.
53
-
54
- **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.
55
-
56
- ## Confirmation (after reading, if material was shared)
57
-
58
- One turn, one message:
59
-
60
- > 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?
61
-
62
- 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.
63
-
64
- 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.
65
-
66
- ## Interview protocol
67
-
68
- Open with a single batched message asking only what you can't infer from material the user shared:
69
-
70
- 1. What domain or topic is this mixtape about?
71
- 2. Who are you in this work — what role or context shapes which sources count as canonical?
72
- 3. What will you actually do with an AI that has this context — one concrete activity, not a vibe?
73
-
74
- Skip any of those that shared material already answered.
75
-
76
- 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):
77
-
78
- - **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."
79
- - **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%."
80
- - **Creative:** "write better" → "improve my essays" → "structure long-form essays" → "structure 4,000-word tech essays for a developer audience reading on mobile."
81
-
82
- 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."
83
-
84
- 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.
85
-
86
- **Prefer multi-choice over free-form.** Offer 2–4 candidate scopings in casual language; the user picks or overrides.
87
-
88
- **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.
89
-
90
- ## Internal rubric (silent)
91
-
92
- Before emitting, check the draft. If any fail, fix and re-check.
93
-
94
- 1. **Structural.** "When [X], I want [Y], so I can [Z]" — all three slots present and non-empty.
95
- 2. **Solution-free.** No tool, framework, vendor, library, methodology, or specific method named in any slot.
96
- 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.
97
- 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."
98
- 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.
99
- 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.
100
-
101
- ## Emit
102
-
103
- One line. The Job Story. Alone. No preamble, no "Here's your JTBD," no quotes, no code fence.
104
-
105
- If the user pushes back, do not defend. Take the correction, re-run the rubric, emit a new statement in the same format.
106
- ---END---
107
- ```
108
-
109
- ---
110
-
111
- ## Why it's shaped this way
112
-
113
- A few choices that aren't obvious:
114
-
115
- **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.
116
-
117
- **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.
118
-
119
- **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.
120
-
121
- **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.
122
-
123
- **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.
124
-
125
- **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.
126
-
127
- **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.
128
-
129
- ## How to use it
130
-
131
- 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":
132
-
133
- **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.
134
-
135
- **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.
136
-
137
- **Inside the `curating-mixtapes` skill.** Drop the prompt block into `cli-update-docs/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.
138
-
139
- **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.
140
-
141
- ## Where it can still go wrong
142
-
143
- Three known soft spots worth knowing:
144
-
145
- - **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.
146
- - **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.
147
- - **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.