linersh 0.5.6 → 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 -190
- 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
package/cli-update-docs/SKILL.md
CHANGED
|
@@ -1,11 +1,11 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: curating-mixtapes
|
|
3
|
-
description: Use when the user wants to build a "mixtape" — a curated bundle of sources (videos, articles, papers, specs) assembled as AI context for
|
|
3
|
+
description: Use when the user wants to build a "mixtape" — a curated bundle of sources (videos, articles, papers, specs) assembled as AI context for one hyper-specific future-agent task. Triggers include "help me make a mixtape on X", "curate sources on Y for AI", "build a context bundle for Z", "let's research X with Liner", "make me a tape on Y", "help me build a Liner mixtape", or "I want this Liner to help my AI agent do X". Drives the eight-phase Liner curation methodology end-to-end and produces a corpus folder — `tape.yaml`, `synthesis.md`, and `working/*` notes, under `mixtape/` in v2 projects — ready for `liner compile`. Defaults to quick mode (the AI does the heavy lifting, the user confirms at two gates); methodology mode is available when the user wants to engage substantively at every step or is targeting library contribution.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Curating Mixtapes
|
|
7
7
|
|
|
8
|
-
This skill implements the Liner curation methodology (CURATION.md v2.0). A mixtape is a curated bundle of sources designed to make AI
|
|
8
|
+
This skill implements the Liner curation methodology (CURATION.md v2.0). A mixtape is a curated bundle of sources designed to make future AI sessions meaningfully better at one hyper-specific task. The bar: a good mixtape demonstrably improves agent output inside the capability it was built for.
|
|
9
9
|
|
|
10
10
|
The output of this skill is a project folder ready for `liner compile`. The skill does not compile.
|
|
11
11
|
|
|
@@ -14,25 +14,26 @@ The output of this skill is a project folder ready for `liner compile`. The skil
|
|
|
14
14
|
## Terminology — get these right
|
|
15
15
|
|
|
16
16
|
- **Tape file** (`tape.yaml`) — the recipe. Sources with notes and sections.
|
|
17
|
-
- **Mixtape** — the
|
|
18
|
-
- **Consumable mixtape** — `MIXTAPE.md` plus the `sources/*.md` files. What gets pasted into an AI conversation. Produced by `liner compile`.
|
|
17
|
+
- **Mixtape** — the corpus folder. In v2 projects it lives under `mixtape/`.
|
|
18
|
+
- **Consumable mixtape** — `MIXTAPE.md` plus the `sources/*.md` files inside the corpus folder. What gets pasted into an AI conversation. Produced by `liner compile`.
|
|
19
19
|
|
|
20
20
|
Tape ≠ mixtape. The recipe is small; the mixtape is the realized artifact.
|
|
21
21
|
|
|
22
22
|
## What this skill produces
|
|
23
23
|
|
|
24
|
-
A project folder named for the topic (e.g., `mobile-design-foundations/`) containing:
|
|
24
|
+
A project folder named for the topic (e.g., `mobile-design-foundations/`) containing a corpus folder. In v2 projects, these files live under `mixtape/`; legacy or standalone skill runs may use the project root:
|
|
25
25
|
|
|
26
26
|
- `tape.yaml` — the recipe, conforming to MIXTAPE-FORMAT v1 (with v1.1 additions: `mode`, `jtbd`, `local_file` sources, optional `render` field on web sources)
|
|
27
27
|
- `synthesis.md` — the curator's distilled understanding of the domain
|
|
28
|
-
- `working/01-jtbd-and-knowledge-map.md` — framing artifacts
|
|
28
|
+
- `working/01-jtbd-and-knowledge-map.md` — framing artifacts: JTBD, capability brief, knowledge map, and required source roles
|
|
29
29
|
- `working/02-candidate-longlist.md` — the unfiltered candidate pool
|
|
30
|
-
- `working/03-evaluation.yaml` — keep/trim/drop decisions with rationales and
|
|
31
|
-
- `working/04-quality-checks.md` — redundancy, coverage, disagreement,
|
|
30
|
+
- `working/03-evaluation.yaml` — keep/trim/drop decisions with rationales, ratings, content evidence, and source-role mapping
|
|
31
|
+
- `working/04-quality-checks.md` — redundancy, coverage, disagreement, framing-gap, source-kind, note-quality, and source-role findings
|
|
32
|
+
- `working/05-operating-fit-audit.md` — optional improvement recommendation when the corpus is not yet strong enough for the Operating Layer
|
|
32
33
|
|
|
33
|
-
`sources/` and `MIXTAPE.md` are produced later by `liner compile
|
|
34
|
+
`sources/` and `MIXTAPE.md` are produced later by `liner compile` in the same corpus folder. The optional `working/06-empirical-test.md` file is produced only when the curator runs the methodology validation step; it is not a driven TUI phase.
|
|
34
35
|
|
|
35
|
-
When the curator has supplied local material (book chapters, exported PDFs, Reader-Mode-saved articles), the skill may write `local_file` entries in `tape.yaml` pointing at files the curator has placed under `personal
|
|
36
|
+
When the curator has supplied local material (book chapters, exported PDFs, Reader-Mode-saved articles), the skill may write `local_file` entries in `tape.yaml` pointing at files the curator has placed under `local-sources/` or the legacy `personal/` folder. This is a methodology-mode affordance — the curator's local context belongs to them, not the public web, and the `local_file` source type makes it first-class. Library contributions still exclude `local_file` sources; the skill should not invent them or suggest paths the curator hasn't supplied.
|
|
36
37
|
|
|
37
38
|
## Companion files
|
|
38
39
|
|
|
@@ -44,7 +45,7 @@ This skill is split across files in its own directory. Read each companion file
|
|
|
44
45
|
- `quality-check-tests.md` — read before Phase 5
|
|
45
46
|
- `synthesis-guidance.md` — read before Phase 6
|
|
46
47
|
|
|
47
|
-
The orchestration logic, the two modes, the
|
|
48
|
+
The orchestration logic, the two modes, the review gates, the AI-bias list, and the failure-mode list stay in this file because they apply across the whole lifecycle.
|
|
48
49
|
|
|
49
50
|
## Two modes
|
|
50
51
|
|
|
@@ -69,27 +70,40 @@ Run these phases in order. Each phase's output feeds the next. Do not reorder.
|
|
|
69
70
|
|
|
70
71
|
### Phase 1 — Framing
|
|
71
72
|
|
|
72
|
-
Define the
|
|
73
|
+
Define the reusable capability and sketch a knowledge map.
|
|
73
74
|
|
|
74
|
-
|
|
75
|
+
The user-facing question is: **What do you want this Liner to help your AI agent do?** The user can answer in plain language. Do not make them supply source categories, research lanes, or a formal Job Story.
|
|
75
76
|
|
|
76
|
-
|
|
77
|
+
Your job in Phase 1 is to translate that plain-language goal into a Capability Brief:
|
|
77
78
|
|
|
78
|
-
|
|
79
|
+
- what future AI sessions should be able to do,
|
|
80
|
+
- what outputs, decisions, or behaviors the resource should support,
|
|
81
|
+
- the internal job-to-be-done that will let later phases judge fit,
|
|
82
|
+
- research lanes inferred from the goal,
|
|
83
|
+
- source requirements and exclusions,
|
|
84
|
+
- runtime behavior for the future agent, including when it should ask the user clarifying questions.
|
|
85
|
+
|
|
86
|
+
The internal JTBD should be hyper-specific. "SEO" is a topic. "SEO keyword research for a mental-health startup specialized in brain surgery" is a capability narrow enough to research. If the user's goal is still broad, ask targeted questions and descend until the capability is specific enough that a corpus built for it could outperform generic model knowledge.
|
|
87
|
+
|
|
88
|
+
**Capability brief.** A short statement of the concrete capability this mixtape should give a downstream AI agent. This is not a persona or project name. It is the work the corpus must make the agent better at.
|
|
79
89
|
|
|
80
90
|
**Knowledge map.** A short outline of the conceptual territory the corpus needs to cover. Four to eight sections, each with a few sub-areas. Treat it as a hypothesis — it will get revised during research.
|
|
81
91
|
|
|
82
|
-
|
|
92
|
+
**Required source roles.** The evidence plan for the corpus. Name the kinds of sources the downstream agent needs before the mixtape can be trusted. Each role must include: role name, why it matters, what good evidence looks like, and minimum coverage. These are inferred from the user's desired capability, not hardcoded categories.
|
|
93
|
+
|
|
94
|
+
**Capability patterns.** If the user's goal implies a recurring evidence shape, name it in the Capability Brief. The most important current pattern is `reference-translation`: the future agent receives images, moodboards, visual references, inspiration, style examples, artifacts, or examples from one medium/domain and must turn them into another output. For this pattern, source roles must separate input/reference-domain interpretation, cross-domain translation method, target-output constraints, critique/clarification, and caller handoff language. Target-output implementation sources are bridge evidence; they cannot satisfy the reference-domain or translation-method roles by themselves.
|
|
95
|
+
|
|
96
|
+
Write the Capability Brief, internal JTBD, research lanes, knowledge map, and Required source roles to `working/01-jtbd-and-knowledge-map.md`. In quick mode: draft, show, get a one-line confirmation. In methodology mode: iterate with the curator until the capability brief, knowledge map, and source roles feel right.
|
|
83
97
|
|
|
84
98
|
### Phase 2 — Candidate discovery
|
|
85
99
|
|
|
86
100
|
**Read `source-finding-tactics.md` before starting this phase.**
|
|
87
101
|
|
|
88
|
-
Generate a long list of candidate sources across the knowledge map. URLs and titles only — no fetching yet. Aim wide: two to four times the eventual kept count. This phase is recall, not precision.
|
|
102
|
+
Generate a long list of candidate sources across the knowledge map and required source roles. URLs and titles only — no fetching yet. Aim wide enough for the evidence contract: roughly two to four times the eventual kept count, with the actual candidate count derived from the required source roles, capability pattern, and source ecology. This phase is recall, not precision.
|
|
89
103
|
|
|
90
104
|
Verify each candidate exists at the URL given. AI is prone to hallucinating plausible-sounding URLs. Treat unverified URLs as candidates only until they're confirmed.
|
|
91
105
|
|
|
92
|
-
Write to `working/02-candidate-longlist.md`, grouped by knowledge-map section. For each candidate: URL, title, one-line reason it's a candidate.
|
|
106
|
+
Write to `working/02-candidate-longlist.md`, grouped by knowledge-map section. For each candidate: URL, title, required source role served, and one-line reason it's a candidate.
|
|
93
107
|
|
|
94
108
|
**At Gate 1, show the long-list and ask:** "Anything obviously missing? Anything obviously wrong? Confirm to start fetching." In quick mode the default is "looks good, continue." In methodology mode, expect real edits.
|
|
95
109
|
|
|
@@ -101,6 +115,8 @@ For each URL, retrieve the full text. YouTube: transcript. Articles, papers, doc
|
|
|
101
115
|
|
|
102
116
|
If a URL fails to fetch (paywall, dead link, no transcript, geographic block): note the failure, decide whether the source is critical enough to chase via an alternate route (Wayback Machine, alternate venue), and either find a substitute or drop it. Don't silently lose candidates.
|
|
103
117
|
|
|
118
|
+
Bound the chase: try one direct fetch/read and at most one recovery attempt per candidate. After two failed retrieval attempts total, stop searching for that candidate and carry the failure into Phase 4 as part of the decision rationale.
|
|
119
|
+
|
|
104
120
|
A successful transcript fetch is not the same as a high-value source. Many tutorial videos transcribe cleanly but contain no transferable content. The next phase handles that judgment.
|
|
105
121
|
|
|
106
122
|
Don't write fetched content into the project folder yet. That happens at compile time, only for kept sources.
|
|
@@ -111,7 +127,15 @@ Don't write fetched content into the project folder yet. That happens at compile
|
|
|
111
127
|
|
|
112
128
|
Read every fetched source against the JTBD. Decide keep / trim / drop. Rate kept sources 1–5. Draft curator notes for kept and trim sources.
|
|
113
129
|
|
|
114
|
-
|
|
130
|
+
If content was unavailable after the bounded fetch attempts, still write a decision for that candidate. Usually choose `dropped`. Do not mark a source `kept` or `trim` from title, URL, search snippet, crawler metadata, or model memory alone.
|
|
131
|
+
|
|
132
|
+
Every `kept` or `trim` source must carry evidence fields in `working/03-evaluation.yaml`:
|
|
133
|
+
|
|
134
|
+
- `fetch_status: readable | partial` — `readable` means the substantive article, transcript, PDF body, or local content was retrieved. `partial` means enough real source content was retrieved to judge, such as an abstract plus substantial excerpt. `metadata_only` and `unavailable` candidates must be `dropped`.
|
|
135
|
+
- `content_quality: high | medium` — low-quality content, SEO filler, AI-generated sludge, generic listicles, homepages, galleries without rationale, or shallow transcripts must be `dropped`.
|
|
136
|
+
- `evidence:` — at least two content-specific bullets from the fetched/read source. These are concrete claims, examples, sections, transcript moments, methods, or limitations seen in the content. Search snippets and titles do not count.
|
|
137
|
+
|
|
138
|
+
Write decisions incrementally as section-sized fragments in `working/evaluation-decisions/`, then write or let Liner assemble `working/03-evaluation.yaml`. Do not hold all decisions in conversation memory until the end.
|
|
115
139
|
|
|
116
140
|
```yaml
|
|
117
141
|
candidates:
|
|
@@ -119,6 +143,12 @@ candidates:
|
|
|
119
143
|
title: Source title
|
|
120
144
|
decision: kept # kept | trim | dropped
|
|
121
145
|
rating: 5 # 1-5; required for kept and trim
|
|
146
|
+
fetch_status: readable # readable | partial; metadata_only/unavailable are dropped
|
|
147
|
+
content_quality: high # high | medium; low is dropped
|
|
148
|
+
source_role: canonical method
|
|
149
|
+
evidence:
|
|
150
|
+
- First content-specific claim, section, example, or method retrieved from the source.
|
|
151
|
+
- Second content-specific detail proving the source was read.
|
|
122
152
|
section: foundations
|
|
123
153
|
rationale: One-sentence reason this decision was made.
|
|
124
154
|
```
|
|
@@ -129,11 +159,11 @@ Drafted curator notes land in `tape.yaml` at Phase 7. Write them now in their fi
|
|
|
129
159
|
|
|
130
160
|
**Read `quality-check-tests.md` before starting this phase.**
|
|
131
161
|
|
|
132
|
-
Step back from the keep-pile. Run the
|
|
162
|
+
Step back from the keep-pile. Run the core-action test and the eight standard tests. Document findings in `working/04-quality-checks.md`.
|
|
133
163
|
|
|
134
|
-
If a test fails, fix it before moving on.
|
|
164
|
+
If a test fails, 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`, the gap, why it matters, concrete search lanes, and custom-source suggestions. Do not call the corpus "ready with limitation"; let Liner offer the user an improvement pass or a clear Skip.
|
|
135
165
|
|
|
136
|
-
*Tip: this phase benefits from running with fresh attention. If the conversation has been long, consider starting a separate chat with just the JTBD, knowledge map, and the kept-source list (titles + notes only) to run the checks. Optional, not required by the methodology.*
|
|
166
|
+
*Tip: this phase benefits from running with fresh attention. If the conversation has been long, consider starting a separate chat with just the JTBD, capability brief, required source roles, knowledge map, and the kept-source list (titles + notes only) to run the checks. Optional, not required by the methodology.*
|
|
137
167
|
|
|
138
168
|
**At Gate 2, show the final keep-list, the curator notes, and the quality-check findings. Ask:** "Confirm to proceed to synthesis." Quick mode default: continue. Methodology mode: expect substantive edits.
|
|
139
169
|
|
|
@@ -141,7 +171,7 @@ If a test fails, fix it before moving on. Don't proceed to synthesis with known
|
|
|
141
171
|
|
|
142
172
|
**Read `synthesis-guidance.md` before starting this phase.**
|
|
143
173
|
|
|
144
|
-
Draft `synthesis.md`. The synthesis is the curator's distilled understanding of the domain expressed as continuous prose. 800–2000 words.
|
|
174
|
+
Draft `synthesis.md`. The synthesis is the curator's distilled understanding of the domain expressed as continuous prose. 800–2000 words. It must include `## Generative rules` and `## Stances this corpus takes` so the consuming AI gets explicit operating rules and corpus stances before reading individual sources.
|
|
145
175
|
|
|
146
176
|
Quick mode: draft, show, default to "looks good, save it." The curator lightly edits if they want.
|
|
147
177
|
|
|
@@ -157,8 +187,8 @@ Write `tape.yaml`.
|
|
|
157
187
|
|
|
158
188
|
**Each kept source needs:**
|
|
159
189
|
|
|
160
|
-
- `type` — `youtube` or `
|
|
161
|
-
- `url`
|
|
190
|
+
- `type` — `youtube`, `web`, `local_file`, or `skill`
|
|
191
|
+
- `url` for `youtube` and `web`; `path` for `local_file` or local/installed `skill` sources; `citation` for `local_file`
|
|
162
192
|
- `note` — the curator note drafted in Phase 4
|
|
163
193
|
- `section` — matches a knowledge-map section
|
|
164
194
|
- `priority: optional` — only for sources the user can skip with `--skip-optional`
|
|
@@ -184,10 +214,10 @@ The only real test of whether the mixtape works.
|
|
|
184
214
|
|
|
185
215
|
1. Compile: `liner compile <project-folder>`
|
|
186
216
|
2. Open a fresh AI conversation. Don't paste the mixtape. Ask a substantive question that should benefit from the JTBD. Save the response.
|
|
187
|
-
3. Open another fresh AI conversation. Paste `MIXTAPE.md` plus relevant `sources/*.md` files. Ask the same question. Save the response.
|
|
217
|
+
3. Open another fresh AI conversation. Paste `mixtape/MIXTAPE.md` plus relevant `mixtape/sources/*.md` files. Ask the same question. Save the response.
|
|
188
218
|
4. Compare. Is the with-mixtape response meaningfully better — more specific, more accurate, more nuanced, less generic?
|
|
189
219
|
|
|
190
|
-
Write findings to `working/
|
|
220
|
+
Write findings to `working/06-empirical-test.md`: the question, the two responses (or summaries), the honest verdict. If the mixtape didn't help: what's missing? Back to Phase 2 or 5.
|
|
191
221
|
|
|
192
222
|
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 JTBD is too broad. Don't skip this for library contributions.
|
|
193
223
|
|
|
@@ -200,6 +230,8 @@ The skill is the AI running the methodology. The AI has systematic biases that p
|
|
|
200
230
|
- **Generic curator notes.** AI drafts notes that say "this is a useful resource" without specifying role, location of value, or limitations. Compensate by writing each note against the three-thing template in `curator-notes.md`.
|
|
201
231
|
- **Primary-document blindness.** AI gravitates to secondary commentary over primary sources. If a domain has a spec, a standard, or a foundational paper, search for it specifically. Don't accept commentary as a substitute.
|
|
202
232
|
- **Framing-gap blindness.** AI can't see what it didn't search for. The framing-gap test in Phase 5 is the methodological correction for this. Run it with intent — not as a checkbox, as a genuine "what am I missing" question.
|
|
233
|
+
- **Source-role blindness.** AI can fill every knowledge-map section while missing an evidence role the job depends on. Use the required source roles from Phase 1 as a contract in Phase 2 and an audit checklist in Phase 5.
|
|
234
|
+
- **Pattern flattening.** AI turns specialized capabilities into generic topic packs. A reference-translation project becomes "web design"; a medical SEO project becomes "SEO"; a legal drafting project becomes "writing." When Phase 1 names a capability pattern, Phase 2 and Phase 5 must preserve that pattern-specific evidence contract.
|
|
203
235
|
- **Synthesis-as-recap.** AI-drafted synthesis tends to recap source content rather than distill the curator's framing of the domain. Push toward principles, contested questions, and framework distinctions — not "Source 1 says X; Source 2 says Y."
|
|
204
236
|
|
|
205
237
|
If you find yourself producing any of these patterns, stop and correct.
|
|
@@ -210,22 +242,24 @@ When all phases complete, the project folder contains:
|
|
|
210
242
|
|
|
211
243
|
```
|
|
212
244
|
<topic-slug>/
|
|
213
|
-
|
|
214
|
-
├──
|
|
215
|
-
|
|
216
|
-
|
|
217
|
-
|
|
218
|
-
|
|
219
|
-
|
|
220
|
-
|
|
245
|
+
└── mixtape/
|
|
246
|
+
├── tape.yaml
|
|
247
|
+
├── synthesis.md
|
|
248
|
+
└── working/
|
|
249
|
+
├── 01-jtbd-and-knowledge-map.md
|
|
250
|
+
├── 02-candidate-longlist.md
|
|
251
|
+
├── 03-evaluation.yaml
|
|
252
|
+
├── 04-quality-checks.md
|
|
253
|
+
├── 05-operating-fit-audit.md # if an improvement pass is recommended
|
|
254
|
+
└── 06-empirical-test.md # if empirical validation was run
|
|
221
255
|
```
|
|
222
256
|
|
|
223
|
-
Tell the user the folder is ready to compile with `liner compile <topic-slug>`. The compile step produces `MIXTAPE.md` and
|
|
257
|
+
Tell the user the folder is ready to compile with `liner compile <topic-slug>`. The compile step produces `mixtape/MIXTAPE.md` and `mixtape/sources/`.
|
|
224
258
|
|
|
225
259
|
## What this skill does NOT do
|
|
226
260
|
|
|
227
261
|
- **Does not run `liner compile`.** That's the user's call, with the user's tools.
|
|
228
|
-
- **Does not fetch from gated or
|
|
262
|
+
- **Does not fetch from gated accounts or private systems.** v1 supports public `youtube` and `web` URLs plus curator-supplied `local_file` and `skill` sources. The skill may reference local files the curator supplied, but it must not invent private paths or bypass access controls.
|
|
229
263
|
- **Does not maintain the shared content cache.** That's the CLI's job.
|
|
230
264
|
- **Does not publish to the library.** Library contributions happen via PR to the Liner repo, in methodology mode, after passing the empirical test.
|
|
231
265
|
|
|
@@ -240,5 +274,6 @@ Patterns that produce bad mixtapes. Watch for them in your own work:
|
|
|
240
274
|
- **The noteless mixtape.** Sources without curator notes. The curator either was lazy or didn't have a reason. Both are problems.
|
|
241
275
|
- **The aspirational mixtape.** Sources the curator thinks people *should* read, not sources that help with the JTBD. Mixtapes are tools, not reading recommendations.
|
|
242
276
|
- **The single-pass mixtape.** Curated without a framing-gap test. Well-covered within one narrow framing, blind to perspectives the curator didn't think to look for.
|
|
277
|
+
- **The role-missing mixtape.** Sections appear covered, but a required source role from Phase 1 has no fetched, useful evidence.
|
|
243
278
|
|
|
244
279
|
If the mixtape this skill produces fits any of these patterns, return to the relevant phase and fix it.
|