linersh 0.5.7 → 1.0.0
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.
- package/README.md +65 -165
- package/bin/liner.js +82 -44
- package/cli-update-docs/ABOUT.md +16 -16
- package/cli-update-docs/AI-HANDOFF.md +62 -204
- package/cli-update-docs/CURATION.md +48 -19
- package/cli-update-docs/JTBD-MASTER-PROMPT-ABOUT.md +9 -12
- package/cli-update-docs/JTBD-MASTER-PROMPT.md +1 -1
- package/cli-update-docs/LINER-MASTER.md +77 -63
- package/cli-update-docs/LINER-MD-PRD.md +531 -0
- package/cli-update-docs/MIXTAPE-FORMAT.md +76 -44
- package/cli-update-docs/PLATFORM.md +47 -46
- package/cli-update-docs/README.md +6 -6
- package/cli-update-docs/SKILL.md +72 -37
- package/cli-update-docs/TUI-BACKLOG.md +205 -26
- package/cli-update-docs/quality-check-tests.md +256 -8
- package/cli-update-docs/source-finding-tactics.md +140 -3
- package/cli-update-docs/source-quality-hierarchy.md +83 -0
- package/cli-update-docs/synthesis-guidance.md +19 -5
- package/dist/agents/artifact-validation.js +440 -0
- package/dist/agents/artifact-validation.js.map +1 -0
- package/dist/agents/candidate-longlist.js +100 -0
- package/dist/agents/candidate-longlist.js.map +1 -0
- package/dist/agents/detect.js +3 -2
- package/dist/agents/detect.js.map +1 -1
- package/dist/agents/evaluation-assembly.js +270 -0
- package/dist/agents/evaluation-assembly.js.map +1 -0
- package/dist/agents/headless-runner.js +227 -0
- package/dist/agents/headless-runner.js.map +1 -0
- package/dist/agents/jtbd-clarify.js +42 -41
- package/dist/agents/jtbd-clarify.js.map +1 -1
- package/dist/agents/models.js +6 -7
- package/dist/agents/models.js.map +1 -1
- package/dist/agents/prompts.js +220 -20
- package/dist/agents/prompts.js.map +1 -1
- package/dist/agents/runner.js +462 -21
- package/dist/agents/runner.js.map +1 -1
- package/dist/phases.js +13 -13
- package/dist/phases.js.map +1 -1
- package/dist/source-inbox.js +297 -0
- package/dist/source-inbox.js.map +1 -0
- package/dist/version.js +3 -9
- package/dist/version.js.map +1 -1
- package/dist/yaml-io.js +42 -11
- package/dist/yaml-io.js.map +1 -1
- package/package.json +26 -23
- package/cli-update-docs/JOB-STORY-MIGRATION.md +0 -99
- package/dist/App.js +0 -220
- package/dist/App.js.map +0 -1
- package/dist/colors.js +0 -132
- package/dist/colors.js.map +0 -1
- package/dist/components/Header.js +0 -15
- package/dist/components/Header.js.map +0 -1
- package/dist/components/KeyHints.js +0 -17
- package/dist/components/KeyHints.js.map +0 -1
- package/dist/components/LabeledBox.js +0 -53
- package/dist/components/LabeledBox.js.map +0 -1
- package/dist/components/NextSteps.js +0 -18
- package/dist/components/NextSteps.js.map +0 -1
- package/dist/index.js +0 -17
- package/dist/index.js.map +0 -1
- package/dist/screens/AgentSetup.js +0 -224
- package/dist/screens/AgentSetup.js.map +0 -1
- package/dist/screens/BootSplash.js +0 -163
- package/dist/screens/BootSplash.js.map +0 -1
- package/dist/screens/CompileView.js +0 -567
- package/dist/screens/CompileView.js.map +0 -1
- package/dist/screens/FramingConfirmReview.js +0 -197
- package/dist/screens/FramingConfirmReview.js.map +0 -1
- package/dist/screens/Gate1Review.js +0 -147
- package/dist/screens/Gate1Review.js.map +0 -1
- package/dist/screens/Gate2Review.js +0 -162
- package/dist/screens/Gate2Review.js.map +0 -1
- package/dist/screens/ImportPrompt.js +0 -173
- package/dist/screens/ImportPrompt.js.map +0 -1
- package/dist/screens/JsSetup.js +0 -77
- package/dist/screens/JsSetup.js.map +0 -1
- package/dist/screens/LocalFilePicker.js +0 -139
- package/dist/screens/LocalFilePicker.js.map +0 -1
- package/dist/screens/NewMixtapeWizard.js +0 -662
- package/dist/screens/NewMixtapeWizard.js.map +0 -1
- package/dist/screens/PhaseRunner.js +0 -1203
- package/dist/screens/PhaseRunner.js.map +0 -1
- package/dist/screens/ProcessManifest.js +0 -160
- package/dist/screens/ProcessManifest.js.map +0 -1
- package/dist/screens/ProjectHub.js +0 -557
- package/dist/screens/ProjectHub.js.map +0 -1
- package/dist/screens/SourceModal.js +0 -269
- package/dist/screens/SourceModal.js.map +0 -1
- package/dist/screens/TapeBrowser.js +0 -312
- package/dist/screens/TapeBrowser.js.map +0 -1
- package/dist/screens/TapeDraftReview.js +0 -444
- package/dist/screens/TapeDraftReview.js.map +0 -1
- package/dist/screens/TapeEditor.js +0 -310
- package/dist/screens/TapeEditor.js.map +0 -1
- package/dist/screens/cassette-art.js +0 -72
- package/dist/screens/cassette-art.js.map +0 -1
- package/dist/store.js +0 -10
- package/dist/store.js.map +0 -1
|
@@ -1,241 +1,99 @@
|
|
|
1
1
|
# Liner AI Handoff
|
|
2
2
|
|
|
3
|
-
Last updated: 2026-06-
|
|
3
|
+
Last updated: 2026-06-25
|
|
4
4
|
|
|
5
|
-
This
|
|
6
|
-
marketing-site launch-prep pass, and 0.5.7 PDF-download hotfix prep. It
|
|
7
|
-
is intended for any AI agent continuing the work without the full chat history.
|
|
5
|
+
This is the short orientation document for an AI agent continuing Liner work without the full chat history. It intentionally avoids release-candidate scratch paths and old local worktrees; verify the current checkout with `pwd` and `git status --short` before editing.
|
|
8
6
|
|
|
9
7
|
## Current Product State
|
|
10
8
|
|
|
11
|
-
-
|
|
12
|
-
-
|
|
13
|
-
`
|
|
14
|
-
`
|
|
15
|
-
- The
|
|
16
|
-
|
|
17
|
-
the
|
|
18
|
-
|
|
19
|
-
-
|
|
20
|
-
-
|
|
21
|
-
- Clean npm smoke passed with `npx linersh@latest --version`: `liner 0.5.6 (tui) · 0.5.6 (core)`.
|
|
22
|
-
|
|
23
|
-
## Important Local Paths
|
|
24
|
-
|
|
25
|
-
- Active repo/worktree for this thread: `/Users/arturo/.codex/worktrees/7117/liner`
|
|
26
|
-
- Previous v0.5.5 implementation worktree: `/Users/arturo/.codex/worktrees/44f8/liner`
|
|
27
|
-
- Original Liner project folder: `/Users/arturo/Documents/Projects/Youtube Grabber/liner`
|
|
28
|
-
- Original mixtapes folder: `/Users/arturo/Documents/Projects/Youtube Grabber/liner/mixtapes`
|
|
29
|
-
- CMD-UX copied mixtapes folder: `/Users/arturo/Documents/Projects/CMD-UX/Case Studies/mixtapes`
|
|
30
|
-
- Local TUI test install: `/tmp/liner-playwright-test`
|
|
31
|
-
- 0.5.5 release artifacts: `/tmp/liner-release-artifacts-0.5.5`
|
|
32
|
-
- 0.5.6 release artifacts: `/tmp/liner-release-artifacts-0.5.6`
|
|
33
|
-
- 0.5.7 release artifacts: `/tmp/liner-release-artifacts-0.5.7`
|
|
34
|
-
- Tested mixtape now moved back to: `/Users/arturo/Documents/Projects/Youtube Grabber/liner/mixtapes/staff-design-engenieer`
|
|
35
|
-
|
|
36
|
-
## What Was Fixed In This Pass
|
|
37
|
-
|
|
38
|
-
0.5.7 PDF-download hotfix:
|
|
39
|
-
|
|
40
|
-
- `.pdf` sources that first hit a JavaScript or bot-detection stub and then
|
|
41
|
-
fall back to Playwright can make Chromium report `Page.goto: Download is
|
|
42
|
-
starting`. Liner now captures that Playwright download and extracts it
|
|
43
|
-
through the shared PDF helper.
|
|
44
|
-
- Verified against the failing resume mixtape PDFs:
|
|
45
|
-
- `TheLadders-EyeTracking-StudyC2.pdf?type=standard` -> 4,095 chars.
|
|
46
|
-
- `Formula-for-a-Winning-Resume.pdf` -> 7,208 chars.
|
|
47
|
-
- Full `staff-designer-resume-crafter` compile with `--no-cache` now reaches
|
|
48
|
-
`22/24 usable sources`; the remaining failures are PAIR cookie-consent-only
|
|
49
|
-
output and a Microsoft HAX network timeout.
|
|
50
|
-
|
|
51
|
-
0.5.6 source-extraction hardening:
|
|
52
|
-
|
|
53
|
-
- Remote web PDFs are detected before HTML extraction and extracted through the
|
|
54
|
-
shared PDF helper. This prevents raw `%PDF-` bytes from entering generated
|
|
55
|
-
source Markdown.
|
|
56
|
-
- Bad web cache entries are purged and refetched when they contain raw PDF
|
|
57
|
-
bytes, stale PDF URL fallbacks, tiny soft/playwright fallback bodies, or
|
|
58
|
-
cookie-consent-only text.
|
|
59
|
-
- Server HTML that looks like an empty client-side app shell now raises
|
|
60
|
-
`JsRenderingRequired`, so existing auto-fallback can try Playwright.
|
|
61
|
-
- Cookie-consent-only output is rejected as unusable, including after Playwright
|
|
62
|
-
rendering. This is intentionally an honest failure, not an automatic
|
|
63
|
-
cookie-clicker.
|
|
64
|
-
- Partial compile output now says how many source files are usable versus
|
|
65
|
-
unavailable placeholders.
|
|
66
|
-
|
|
67
|
-
0.5.5 TUI/core release:
|
|
68
|
-
|
|
69
|
-
- Skill bundle resolution for npm installs:
|
|
70
|
-
- TUI now resolves the bundled `cli-update-docs/SKILL.md` reliably from the installed package.
|
|
71
|
-
- `LINER_SKILL_PATH` can point either at the skill directory or at `SKILL.md`.
|
|
72
|
-
|
|
73
|
-
- Playwright/JS rendering onboarding:
|
|
74
|
-
- First-run TUI flow now asks whether to install JS rendering support after agent/model setup.
|
|
75
|
-
- Compile results that detect missing Chromium show a `JS rendering needed` callout.
|
|
76
|
-
- The callout says: `Some pages require headless Chromium to fetch correctly. Press j to run liner setup-js --yes (~150MB).`
|
|
77
|
-
- Pressing `j` runs setup and retries compile.
|
|
78
|
-
|
|
79
|
-
- Compile result UX:
|
|
80
|
-
- Long source lists use an internal viewport with `↑↓` and `pgup/pgdn`.
|
|
81
|
-
- PhaseRunner done screens use an internal viewport for the final response.
|
|
82
|
-
- Partial compiles now count as complete when `MIXTAPE.md` is written.
|
|
83
|
-
- The hub shows `Ready to use — compiled with warnings` when some sources failed.
|
|
84
|
-
- Pressing Enter on completed Compile opens the existing compile result instead of fetching again.
|
|
85
|
-
- Recompile/retry is explicit with `r` from CompileView.
|
|
86
|
-
|
|
87
|
-
- Web extraction fallback:
|
|
88
|
-
- `trafilatura` crashes are caught.
|
|
89
|
-
- Web handlers keep useful fallback text where possible and surface a soft warning instead of raw Python errors like `'NoneType' object is not subscriptable`.
|
|
90
|
-
|
|
91
|
-
- Clean reinstall:
|
|
92
|
-
- `liner uninstall` was added to the npm shim.
|
|
93
|
-
- It removes `~/.liner`, npm `_npx`, and Playwright Chromium cache.
|
|
94
|
-
- It does not remove mixtape project folders.
|
|
95
|
-
|
|
96
|
-
## Known Gotchas
|
|
97
|
-
|
|
98
|
-
- The tested mixtape folder is misspelled `staff-design-engenieer`; do not silently rename it unless the user asks, because existing references and copied paths use that spelling.
|
|
99
|
-
- `LINER_BIN` matters during local testing. To test TUI changes plus local Python handler fixes, run the TUI with:
|
|
9
|
+
- Repo version files currently agree on `1.0.0`:
|
|
10
|
+
- `pyproject.toml`
|
|
11
|
+
- `src/liner/__init__.py`
|
|
12
|
+
- `packages/tui/package.json`
|
|
13
|
+
- The npm package is `linersh`; running `liner` opens the TUI and forwards CLI subcommands to the bundled core.
|
|
14
|
+
- The TUI can run agent-backed methodology phases with Claude or Codex, using
|
|
15
|
+
the tracked skill bundle at `docs/curation-skill/`. During npm packaging, it
|
|
16
|
+
is copied into `packages/tui/cli-update-docs/`.
|
|
17
|
+
- JS rendering support is optional. `liner setup-js` installs Playwright Chromium; the TUI offers this during onboarding and again when compile detects a source that needs browser rendering.
|
|
18
|
+
- Compilation is the product completion milestone. If `MIXTAPE.md` is written with warnings, the project can still be ready to use with warnings shown.
|
|
100
19
|
|
|
101
|
-
|
|
102
|
-
cd /tmp/liner-playwright-test
|
|
103
|
-
LINER_BIN=/Users/arturo/.codex/worktrees/7117/liner/.venv/bin/liner ./node_modules/.bin/liner
|
|
104
|
-
```
|
|
20
|
+
## What Liner Is Building
|
|
105
21
|
|
|
106
|
-
-
|
|
107
|
-
- If Python source changed, publishing only the main `linersh` package is not
|
|
108
|
-
enough. Rebuild and publish all platform packages at the same version first.
|
|
109
|
-
- Cookie-banner auto-dismissal is not implemented in 0.5.6. The safety net is
|
|
110
|
-
to reject cookie-only output; a future dismissal pass should keep that final
|
|
111
|
-
rejection in place.
|
|
112
|
-
- The TUI package generated `packages/tui/cli-update-docs/` during `prepack`; the canonical docs live at repo-root `cli-update-docs/`.
|
|
113
|
-
- The old root `docs/` folder was removed. `LINER-MASTER.md` now lives at `cli-update-docs/LINER-MASTER.md`.
|
|
114
|
-
- The Jhey source URL currently 404s on the live site. The useful archived version is:
|
|
115
|
-
|
|
116
|
-
```text
|
|
117
|
-
https://web.archive.org/web/20250408204038id_/https://jhey.dev/cheep/rotating-gallery-with-css-scroll-driven-animations/
|
|
118
|
-
```
|
|
22
|
+
Liner creates a hyper-specific corpus that helps a downstream AI agent perform one task better. It is not a generic research collector and not a persona builder.
|
|
119
23
|
|
|
120
|
-
|
|
24
|
+
The durable artifact set is:
|
|
121
25
|
|
|
122
|
-
|
|
26
|
+
- `tape.yaml` - source recipe
|
|
27
|
+
- `synthesis.md` - curator framing
|
|
28
|
+
- `working/` - methodology trace
|
|
29
|
+
- `MIXTAPE.md` and `sources/` - compiled consumable context
|
|
30
|
+
- `LINER.md` and root `SKILL.md` - operating layer files that tell future agents how to discover and use the project
|
|
123
31
|
|
|
124
|
-
|
|
125
|
-
cd /Users/arturo/.codex/worktrees/7117/liner/packages/tui
|
|
126
|
-
npm run typecheck
|
|
127
|
-
npm run build
|
|
128
|
-
npm test
|
|
129
|
-
npm pack --json
|
|
130
|
-
```
|
|
32
|
+
For the current design rationale, read `docs/tui/TERMINAL_TOOLING_DESIGN_FRAMEWORK.md`. The final section, "Always Last: Arturo As A Designer," should stay at the bottom when updating that document.
|
|
131
33
|
|
|
132
|
-
|
|
34
|
+
## Current Methodology Shape
|
|
133
35
|
|
|
134
|
-
|
|
135
|
-
cd /Users/arturo/.codex/worktrees/7117/liner
|
|
136
|
-
uv run --extra dev pytest
|
|
137
|
-
```
|
|
36
|
+
Phase 1 framing must now produce more than a knowledge map. `working/01-jtbd-and-knowledge-map.md` needs:
|
|
138
37
|
|
|
139
|
-
|
|
38
|
+
- `Capability Brief`
|
|
39
|
+
- `Required source roles`
|
|
40
|
+
- knowledge map
|
|
140
41
|
|
|
141
|
-
|
|
42
|
+
Each source role needs role name, why it matters, good evidence, and minimum coverage. This is generic: an Art Director Liner, a medical SEO Liner, and a CI debugging Liner should infer different roles from their task.
|
|
142
43
|
|
|
143
|
-
|
|
144
|
-
cd /Users/arturo/.codex/worktrees/7117/liner/packages/tui
|
|
145
|
-
npm ci
|
|
146
|
-
npm run typecheck
|
|
147
|
-
npm test
|
|
148
|
-
npm run build
|
|
149
|
-
npm pack --dry-run
|
|
150
|
-
|
|
151
|
-
cd /Users/arturo/.codex/worktrees/7117/liner
|
|
152
|
-
python3 -m compileall -q src/liner
|
|
153
|
-
uv run --extra dev pytest
|
|
154
|
-
```
|
|
44
|
+
Phase 2 searches against both the knowledge map and required source roles. Phase 5 includes required source-role fit as a quality test. A source is useful only if fetched content actually supports the role it was kept for.
|
|
155
45
|
|
|
156
|
-
|
|
46
|
+
## TUI UX Rules To Preserve
|
|
157
47
|
|
|
158
|
-
|
|
48
|
+
- Enter should advance the primary next action. Preview/log/retry/open actions need their own keys.
|
|
49
|
+
- Long-running work should use the established loading/progress pattern and keep default logs short.
|
|
50
|
+
- Warnings need a recovery route: open, drop, replace, retry, add sources, or continue with a documented limitation.
|
|
51
|
+
- Letter commands must not interfere with typing.
|
|
52
|
+
- Two-option setup/improvement screens should use the shared option style: active orange, inactive gray, selected description white, inactive description gray.
|
|
53
|
+
- Completed compile should open the existing result by default; recompile is explicit.
|
|
159
54
|
|
|
160
|
-
|
|
161
|
-
Status: latest post-release-prep run is green; check `gh run list --workflow platform-bundles.yml --limit 3` if you need the current run ID.
|
|
162
|
-
Artifacts downloaded to: /tmp/liner-release-artifacts-0.5.5
|
|
163
|
-
Local npm bundle smoke: liner 0.5.5 (tui) · 0.5.5 (core)
|
|
164
|
-
```
|
|
55
|
+
## Active Docs
|
|
165
56
|
|
|
166
|
-
|
|
57
|
+
Read these first for product and methodology work:
|
|
167
58
|
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
59
|
+
1. `README.md`
|
|
60
|
+
2. `docs/tui/TERMINAL_TOOLING_DESIGN_FRAMEWORK.md`
|
|
61
|
+
3. `docs/curation-skill/CURATION.md`
|
|
62
|
+
4. `docs/curation-skill/SKILL.md`
|
|
63
|
+
5. `docs/curation-skill/source-finding-tactics.md`
|
|
64
|
+
6. `docs/curation-skill/quality-check-tests.md`
|
|
65
|
+
7. `packages/tui/README.md` if changing user-facing TUI keybindings or flows
|
|
173
66
|
|
|
174
|
-
|
|
67
|
+
Marketing-site work has separate docs in `marketing/site/`.
|
|
175
68
|
|
|
176
|
-
|
|
69
|
+
## Verification Commands
|
|
177
70
|
|
|
178
|
-
|
|
179
|
-
cd /tmp/liner-playwright-test
|
|
180
|
-
npm install /tmp/liner-release-artifacts-0.5.5/linersh-darwin-arm64/linersh-darwin-arm64-0.5.5.tgz /tmp/liner-release-artifacts-0.5.5/linersh-tui/linersh-0.5.5.tgz
|
|
181
|
-
```
|
|
182
|
-
|
|
183
|
-
Run the TUI against the local Python core:
|
|
184
|
-
|
|
185
|
-
```sh
|
|
186
|
-
cd /tmp/liner-playwright-test
|
|
187
|
-
LINER_BIN=/Users/arturo/.codex/worktrees/7117/liner/.venv/bin/liner ./node_modules/.bin/liner
|
|
188
|
-
```
|
|
189
|
-
|
|
190
|
-
Force a fresh compile/fetch:
|
|
71
|
+
TUI:
|
|
191
72
|
|
|
192
73
|
```sh
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
|
|
74
|
+
npm --prefix packages/tui test -- --run
|
|
75
|
+
npm --prefix packages/tui run typecheck
|
|
76
|
+
npm --prefix packages/tui run build
|
|
196
77
|
```
|
|
197
78
|
|
|
198
|
-
|
|
79
|
+
Python/core:
|
|
199
80
|
|
|
200
81
|
```sh
|
|
201
|
-
|
|
202
|
-
|
|
82
|
+
uv run --extra dev pytest
|
|
83
|
+
python3 -m compileall -q src/liner
|
|
203
84
|
```
|
|
204
85
|
|
|
205
|
-
|
|
86
|
+
Docs hygiene:
|
|
206
87
|
|
|
207
88
|
```sh
|
|
208
|
-
|
|
209
|
-
|
|
89
|
+
git diff --check
|
|
90
|
+
rg -n "four tests|five tests|two gates|two human-in-the-loop|current release v0\\.5\\.[56]|EAI-HANDOFF" README.md docs packages/tui/README.md --glob "*.md" --glob "!docs/curation-skill/TUI-BACKLOG.md" --glob "!docs/curation-skill/AI-HANDOFF.md"
|
|
210
91
|
```
|
|
211
92
|
|
|
212
|
-
##
|
|
213
|
-
|
|
214
|
-
Canonical docs now live in `cli-update-docs/`:
|
|
215
|
-
|
|
216
|
-
- `LINER-MASTER.md` — current conceptual and technical overview.
|
|
217
|
-
- `AI-HANDOFF.md` — this document.
|
|
218
|
-
- `TUI-BACKLOG.md` — backlog and done log.
|
|
219
|
-
- `MIXTAPE-FORMAT.md` — tape/mixtape format.
|
|
220
|
-
- `CURATION.md` — methodology.
|
|
221
|
-
- `SKILL.md` and companion files — bundled curation skill.
|
|
222
|
-
|
|
223
|
-
Package-specific docs still live in `packages/tui/`:
|
|
224
|
-
|
|
225
|
-
- `packages/tui/README.md`
|
|
226
|
-
- `packages/tui/PUBLISH-CHECKLIST.md`
|
|
227
|
-
- `packages/tui/PLATFORM-BUNDLES.md`
|
|
228
|
-
|
|
229
|
-
## Suggested Next Work
|
|
93
|
+
## Gotchas
|
|
230
94
|
|
|
231
|
-
-
|
|
232
|
-
-
|
|
233
|
-
|
|
234
|
-
-
|
|
235
|
-
|
|
236
|
-
- Consider surfacing extraction mode/body length in the TUI compile details.
|
|
237
|
-
- Consider adding `liner doctor-source <url>` or equivalent single-source
|
|
238
|
-
diagnostics.
|
|
239
|
-
- Consider adding Wayback as an automatic fetcher tier between Playwright and agent-summary fallback.
|
|
240
|
-
- Add per-source failure actions in CompileView: open URL, drop source, retry one source.
|
|
241
|
-
- Add a regression test for completed Compile opening existing results rather than running `streamCompile`.
|
|
95
|
+
- `docs/curation-skill/` is packaged into the npm TUI, so stale methodology docs become user-facing.
|
|
96
|
+
- Do not update archived research transcripts just to quiet searches.
|
|
97
|
+
- Do not reintroduce "advisor" language for the operating layer. Use artifact names and concrete roles.
|
|
98
|
+
- Do not treat URL existence as source quality. Fetched content quality is the real gate.
|
|
99
|
+
- Before reporting state, separate your edits from pre-existing dirty worktree changes.
|
|
@@ -6,7 +6,7 @@ A methodology for assembling AI-consumable context bundles that actually work.
|
|
|
6
6
|
|
|
7
7
|
## What this document is
|
|
8
8
|
|
|
9
|
-
A methodology for building mixtapes — curated bundles of sources designed to
|
|
9
|
+
A methodology for building mixtapes — curated bundles of sources designed to help an AI agent perform one hyper-specific task better than it could from its training data alone.
|
|
10
10
|
|
|
11
11
|
This document is platform-agnostic. It describes *how to curate well*, not how any specific tool implements curation. Liner is one implementation; the methodology applies equally to mixtapes built with other tools or by hand.
|
|
12
12
|
|
|
@@ -43,9 +43,15 @@ Every mixtape moves through the same phases. The phases are ordered because each
|
|
|
43
43
|
|
|
44
44
|
### Phase 1 — Framing
|
|
45
45
|
|
|
46
|
-
Define the
|
|
46
|
+
Define the reusable capability. Not the topic. The *specific thing a future AI agent should be able to do*.
|
|
47
47
|
|
|
48
|
-
The
|
|
48
|
+
The user-facing prompt is:
|
|
49
|
+
|
|
50
|
+
> What do you want this Liner to help your AI agent do?
|
|
51
|
+
|
|
52
|
+
The user may answer in normal language. They do not need to provide source categories, research lanes, or a formal Job Story. Liner's job is to infer those from the desired capability, ask a few targeted follow-up questions only when the capability is under-specified, and then create a source-grounded resource that future AI sessions can load.
|
|
53
|
+
|
|
54
|
+
Liner still derives an internal job-to-be-done because the downstream phases need a testable target. A Job Story is one useful internal shape: **"When [circumstance], I want [motivation], so I can [outcome]."** The user should not have to know or write this format. The AI may translate the capability into a Job Story silently, then expose the plain-language intent and research plan for review.
|
|
49
55
|
|
|
50
56
|
"Mobile design" is a topic. It is too vague to curate against. Three Job Stories in that same topic produce three different mixtapes:
|
|
51
57
|
|
|
@@ -53,15 +59,29 @@ The JTBD is written as a Job Story: **"When [circumstance], I want [motivation],
|
|
|
53
59
|
- *When I review mobile design portfolios as a senior IC hiring manager, I want to compare candidates against a consistent rubric of taste and decision-making, so I can decide who to advance with confidence.*
|
|
54
60
|
- *When I'm choosing a platform strategy for a new mobile product, I want to weigh native vs. cross-platform against the specific constraints of my team and timeline, so I can commit to one path without re-litigating the question every quarter.*
|
|
55
61
|
|
|
56
|
-
If the
|
|
62
|
+
If the desired capability cannot be made hyper-specific, the mixtape will be unfocused. This is the single most common failure mode. "SEO" is a topic; "SEO keyword research for a mental-health startup specialized in brain surgery" is specific enough for Liner to infer research lanes such as search strategy, medical-content constraints, brain-surgery terminology, and Google guidance.
|
|
63
|
+
|
|
64
|
+
Write a short Capability Brief alongside the internal JTBD. It should name:
|
|
65
|
+
|
|
66
|
+
- what future AI sessions should be able to do,
|
|
67
|
+
- what outputs or decisions the resource should support,
|
|
68
|
+
- the research lanes Liner inferred,
|
|
69
|
+
- source requirements and obvious exclusions,
|
|
70
|
+
- runtime behavior for the future agent, including when to ask the user clarifying questions.
|
|
71
|
+
|
|
72
|
+
Sketch a knowledge map alongside the Capability Brief and internal JTBD: the major areas of the domain, the sub-areas, the edge cases. For mobile design, that might be foundations, patterns, craft, process, edge cases. For another domain, the buckets are different. The map serves three purposes: it structures research, it surfaces gaps, and it becomes the section structure of the finished mixtape.
|
|
57
73
|
|
|
58
|
-
|
|
74
|
+
Also write a capability brief and required source roles.
|
|
75
|
+
|
|
76
|
+
The **capability brief** says what this mixtape should make a downstream AI agent better at. It is not a persona. It is the operational job the corpus must support.
|
|
77
|
+
|
|
78
|
+
**Required source roles** name the kinds of evidence the corpus needs before it can be trusted. Each role should say why it matters, what good evidence looks like, and the minimum coverage needed. For a medical SEO mixtape, roles might include search-engine guidance, medical-topic authority, patient-language evidence, and compliance boundaries. For an art-direction mixtape, roles might include visual-analysis vocabulary, translation methods, high-craft examples, and critique language. The roles change with the JTBD; the requirement does not.
|
|
59
79
|
|
|
60
80
|
Treat the map as a hypothesis. It will get revised during research.
|
|
61
81
|
|
|
62
82
|
### Phase 2 — Candidate discovery
|
|
63
83
|
|
|
64
|
-
Generate a long list of candidate sources covering the knowledge map. Lots of them. This phase is about recall, not precision — gather more than you need; you'll cut later.
|
|
84
|
+
Generate a long list of candidate sources covering the knowledge map and the required source roles. Lots of them. This phase is about recall, not precision — gather more than you need; you'll cut later.
|
|
65
85
|
|
|
66
86
|
Methods that produce better candidates than generic search:
|
|
67
87
|
|
|
@@ -75,21 +95,23 @@ Methods that produce better candidates than generic search:
|
|
|
75
95
|
|
|
76
96
|
**Conference proceedings.** Going through three years of a specific conference is more efficient than searching for talks topic-by-topic.
|
|
77
97
|
|
|
78
|
-
**Ask the AI to find gaps, not sources.** Once you have a candidate list, ask: *what's missing from this collection for
|
|
98
|
+
**Ask the AI to find gaps, not sources.** Once you have a candidate list, ask: *what's missing from this collection for an AI agent trying to [capability]?* AI is bad at recall and good at critique. Use it for the right thing.
|
|
99
|
+
|
|
100
|
+
**Search by source role.** A knowledge-map section can look populated while a required evidence role is missing. Search directly for the role the source needs to play: canonical method, domain authority, applied example, boundary/risk, or whatever the Phase 1 source roles require.
|
|
79
101
|
|
|
80
102
|
No fetching yet. This phase produces URLs and titles, not content.
|
|
81
103
|
|
|
82
104
|
### Phase 3 — Fetching
|
|
83
105
|
|
|
84
|
-
Pull content for every candidate into the cache. Transcripts, articles, metadata. This is the expensive phase — network calls, transcript scraping, content extraction.
|
|
106
|
+
Pull content for every candidate into the cache. Transcripts, articles, PDFs, local files, and only then metadata when the content cannot be reached. This is the expensive phase — network calls, transcript scraping, content extraction.
|
|
85
107
|
|
|
86
108
|
Two things matter here. First, fetching is part of research, not a tail step. A source can't be honestly evaluated without reading it. Second, fetched content should be cached. The same source used in multiple mixtapes should be fetched once.
|
|
87
109
|
|
|
88
|
-
After fetching, every candidate has readable content available for evaluation.
|
|
110
|
+
After fetching, every candidate has either readable content available for evaluation or an explicit failure state. Search snippets, titles, and URLs are not source evidence.
|
|
89
111
|
|
|
90
112
|
### Phase 4 — Evaluation
|
|
91
113
|
|
|
92
|
-
Read the fetched content and rate each candidate against the
|
|
114
|
+
Read the fetched content and rate each candidate against the Capability Brief and internal JTBD. This is where keep/trim/drop decisions actually happen. Kept and trimmed sources must include `fetch_status`, `content_quality`, and at least two content-specific evidence bullets so the corpus can prove the decision came from content, not just URL plausibility.
|
|
93
115
|
|
|
94
116
|
Source quality, roughly in order of preference:
|
|
95
117
|
|
|
@@ -113,7 +135,7 @@ Evaluations should include a brief reason. "This source is canonical for the fou
|
|
|
113
135
|
|
|
114
136
|
### Phase 5 — Quality checks
|
|
115
137
|
|
|
116
|
-
|
|
138
|
+
Run the quality tests deliberately. This phase checks whether the corpus can actually support the future agent's task, not just whether it has plausible sources.
|
|
117
139
|
|
|
118
140
|
**The redundancy test.** Read each source's role in the mixtape. Are any two sources making essentially the same point? If yes, keep the better one and cut the other. Mixtape volume is not a virtue. Five excellent sources beat fifteen good ones.
|
|
119
141
|
|
|
@@ -121,11 +143,15 @@ Four tests every mixtape should pass. Run them deliberately.
|
|
|
121
143
|
|
|
122
144
|
**The disagreement test.** Pick the strongest claim made by sources in the mixtape. Find someone credible who disagrees with it. Either include the disagreement or explicitly note that the mixtape takes a position. A mixtape that only includes one side of a contested question produces worse AI output, because the AI then can't see the contested-ness.
|
|
123
145
|
|
|
124
|
-
**The framing-gap test.** Step back and look at the whole mixtape. Is there a major perspective on this
|
|
146
|
+
**The framing-gap test.** Step back and look at the whole mixtape. Is there a major perspective on this capability that's missing entirely — not just an individual source, but a whole way of thinking about the task? If yes, the framing was too narrow. Expand the knowledge map and revisit Phase 2.
|
|
125
147
|
|
|
126
|
-
|
|
148
|
+
**The source-kind balance test.** Check the distribution of reference, principle, prescription, and example sources. A zero in any role is a decision, not an accident. Backfill or defend it.
|
|
127
149
|
|
|
128
|
-
If a
|
|
150
|
+
**The required source-role fit test.** Return to the roles from Phase 1. Does each role have fetched, readable, useful evidence? Is the evidence strong enough for the role, or merely adjacent? If a role is weak or absent, run a backfill pass, narrow the capability claim, or document the limitation and what custom source the curator should add.
|
|
151
|
+
|
|
152
|
+
The framing-gap and source-role fit tests are the ones most curators skip. They are also the highest-leverage. Single-pass curation tends to produce mixtapes that are well-covered within one narrow framing. These tests catch what the first pass could not see.
|
|
153
|
+
|
|
154
|
+
If a mixtape fails any of these tests, fix it before moving on when the fix is small enough for the quality phase. If the failure points to a wider source-role gap, write `working/05-operating-fit-audit.md` with `status: improvement_recommended`: name the missing role, explain why it matters, suggest search lanes, and list concrete custom sources the user could add if public research remains thin. Do not call the corpus ready with a limitation when the right next step is to run a focused improvement pass.
|
|
129
155
|
|
|
130
156
|
### Phase 6 — Synthesis
|
|
131
157
|
|
|
@@ -154,11 +180,11 @@ Theory aside — here's how to know if the mixtape is actually working:
|
|
|
154
180
|
|
|
155
181
|
1. Compile the mixtape
|
|
156
182
|
2. Paste it into an AI conversation as context
|
|
157
|
-
3. Ask the AI
|
|
183
|
+
3. Ask the AI to do something the mixtape's capability should support
|
|
158
184
|
4. Ask the same question without the mixtape in a separate conversation
|
|
159
185
|
5. Compare the answers honestly
|
|
160
186
|
|
|
161
|
-
If the answer with the mixtape is meaningfully better — more specific, more correct, more nuanced, less generic — the mixtape is working. If the answers are similar, the mixtape isn't earning its place. Either the sources are too generic, the synthesis isn't doing enough work, or the
|
|
187
|
+
If the answer with the mixtape is meaningfully better — more specific, more correct, more nuanced, less generic — the mixtape is working. If the answers are similar, the mixtape isn't earning its place. Either the sources are too generic, the synthesis isn't doing enough work, or the capability is too broad.
|
|
162
188
|
|
|
163
189
|
This empirical check is required for library contributions. Run it. Document the result.
|
|
164
190
|
|
|
@@ -202,7 +228,7 @@ The methodology supports two intensities of engagement.
|
|
|
202
228
|
|
|
203
229
|
**Quick mode** runs the methodology automatically. The curator provides the JTBD and confirms the AI's proposals at each gate. The AI does the heavy lifting — generating candidates, evaluating, drafting curator notes, drafting the synthesis. The curator's job is to catch obvious errors and make final calls. A complete mixtape takes 15–30 minutes. Output is good enough for personal use.
|
|
204
230
|
|
|
205
|
-
**Methodology mode** treats the AI as a research assistant rather than the curator. The curator engages substantively at each gate — revises the knowledge map, reviews evaluation rationales
|
|
231
|
+
**Methodology mode** treats the AI as a research assistant rather than the curator. The curator engages substantively at each gate — revises the capability brief, knowledge map, and source roles; reviews evaluation rationales; makes deliberate keep/drop decisions; writes their own synthesis. The AI accelerates the tedious work; the judgment stays human. A complete mixtape takes several hours. Output is library-eligible.
|
|
206
232
|
|
|
207
233
|
Both modes use the same lifecycle and produce the same artifact shape. They differ in how much human judgment shows up in the working notes and the synthesis. Quick mode mixtapes can be upgraded to methodology mode by going back and doing the substantive work; methodology mode mixtapes can be produced in one pass by curators who already know the domain.
|
|
208
234
|
|
|
@@ -216,7 +242,7 @@ Patterns that produce bad mixtapes. Watch for them.
|
|
|
216
242
|
|
|
217
243
|
**The greatest-hits mixtape.** A list of the most famous resources on a topic. Looks impressive, adds little value because the AI already knows about famous resources from training. Curate for *non-obvious* sources, not popular ones.
|
|
218
244
|
|
|
219
|
-
**The unfocused mixtape.** No clear
|
|
245
|
+
**The unfocused mixtape.** No clear capability; tries to cover the entire field. Result: shallow on everything, deep on nothing.
|
|
220
246
|
|
|
221
247
|
**The author-tribute mixtape.** Three of the five sources are by the same person, because the curator is a fan. This narrows perspective and reduces the AI's ability to synthesize across views.
|
|
222
248
|
|
|
@@ -224,10 +250,12 @@ Patterns that produce bad mixtapes. Watch for them.
|
|
|
224
250
|
|
|
225
251
|
**The noteless mixtape.** Sources without curator notes. Either the curator was lazy or didn't actually have a reason for each source. Both are problems. If a source's role can't be articulated, it doesn't belong.
|
|
226
252
|
|
|
227
|
-
**The aspirational mixtape.** Sources the curator thinks people *should* read, not sources that help with the actual
|
|
253
|
+
**The aspirational mixtape.** Sources the curator thinks people *should* read, not sources that help with the actual capability. Mixtapes are tools, not reading recommendations.
|
|
228
254
|
|
|
229
255
|
**The single-pass mixtape.** Curated without a framing-gap test. Well-covered within one narrow framing, blind to whole perspectives the curator didn't think to look for.
|
|
230
256
|
|
|
257
|
+
**The role-missing mixtape.** Every section has sources, but one required evidence role is absent. The corpus looks full while still failing the job. Fix by backfilling the role, narrowing the claim, or documenting the limitation.
|
|
258
|
+
|
|
231
259
|
---
|
|
232
260
|
|
|
233
261
|
## A note on AI assistance
|
|
@@ -241,6 +269,7 @@ AI is especially prone to:
|
|
|
241
269
|
- Producing generic curator notes that say "this is a useful resource" without specificity
|
|
242
270
|
- Missing primary documents (specs, papers) in favor of secondary commentary
|
|
243
271
|
- Failing the framing-gap test because it doesn't notice what it didn't search for
|
|
272
|
+
- Filling knowledge-map sections while missing required source roles
|
|
244
273
|
|
|
245
274
|
Compensate deliberately. Search for primary sources yourself even when AI doesn't surface them. Verify every URL. Treat AI-drafted notes as first drafts. Run the framing-gap test with intent.
|
|
246
275
|
|
|
@@ -14,7 +14,7 @@ The JTBD Master Prompt fixes that gap. It's a single, drop-in prompt that takes
|
|
|
14
14
|
|
|
15
15
|
## What it is
|
|
16
16
|
|
|
17
|
-
A self-contained master prompt stored at `
|
|
17
|
+
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.
|
|
18
18
|
|
|
19
19
|
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.
|
|
20
20
|
|
|
@@ -36,10 +36,10 @@ Five moves, in order:
|
|
|
36
36
|
|
|
37
37
|
## Where it came from
|
|
38
38
|
|
|
39
|
-
The prompt is the engineering output of a mixtape compiled specifically for this question.
|
|
39
|
+
The prompt is the engineering output of a mixtape compiled specifically for this question. That local source mixtape is archived at:
|
|
40
40
|
|
|
41
41
|
```
|
|
42
|
-
mixtapes/jtbd-master-prompt/
|
|
42
|
+
/Users/arturo/Documents/Projects/0-archive/liner-archive/2026-06-25-root-cleanup/mixtapes/jtbd-master-prompt/
|
|
43
43
|
├── MIXTAPE.md # compiled master file
|
|
44
44
|
├── tape.yaml # the recipe
|
|
45
45
|
├── synthesis.md # the curator's framing
|
|
@@ -83,7 +83,7 @@ Three deployment paths, all using the same prompt:
|
|
|
83
83
|
|
|
84
84
|
**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.
|
|
85
85
|
|
|
86
|
-
**Embedded inside the `curating-mixtapes` skill.** Drop the prompt block into `
|
|
86
|
+
**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.
|
|
87
87
|
|
|
88
88
|
**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.
|
|
89
89
|
|
|
@@ -122,12 +122,9 @@ A few decisions in the prompt aren't obvious and have been pushed back on during
|
|
|
122
122
|
## Related files
|
|
123
123
|
|
|
124
124
|
- The prompt itself: [`JTBD-MASTER-PROMPT.md`](./JTBD-MASTER-PROMPT.md)
|
|
125
|
-
- The format
|
|
126
|
-
- The source mixtape:
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
- The Liner curation methodology that places this work in Phase 1: [`cli-update-docs/CURATION.md`](./CURATION.md)
|
|
131
|
-
- The skill that will likely embed this prompt: [`cli-update-docs/SKILL.md`](./SKILL.md)
|
|
132
|
-
- The mixtape format spec defining the `jtbd:` field the prompt's output lands in: [`cli-update-docs/MIXTAPE-FORMAT.md`](./MIXTAPE-FORMAT.md)
|
|
125
|
+
- The current format spec: [`MIXTAPE-FORMAT.md`](./MIXTAPE-FORMAT.md)
|
|
126
|
+
- The archived source mixtape: `/Users/arturo/Documents/Projects/0-archive/liner-archive/2026-06-25-root-cleanup/mixtapes/jtbd-master-prompt/`
|
|
127
|
+
- The Liner curation methodology that places this work in Phase 1: [`CURATION.md`](./CURATION.md)
|
|
128
|
+
- The skill that will likely embed this prompt: [`SKILL.md`](./SKILL.md)
|
|
129
|
+
- The mixtape format spec defining the `jtbd:` field the prompt's output lands in: [`MIXTAPE-FORMAT.md`](./MIXTAPE-FORMAT.md)
|
|
133
130
|
- Project-level overview of Liner: [`LINER-MASTER.md`](./LINER-MASTER.md)
|
|
@@ -134,7 +134,7 @@ The prompt's first move is always the same — ask the user whether they have pr
|
|
|
134
134
|
|
|
135
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
136
|
|
|
137
|
-
**Inside the `curating-mixtapes` skill.** Drop the prompt block into `
|
|
137
|
+
**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.
|
|
138
138
|
|
|
139
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
140
|
|