← back to Cli Printing Press
feat(skills): brainstorm novel features via Task subagent (#533)
13995da78c4d061fcd3c26492cd93b25465a774e · 2026-05-03 16:16:25 -0700 · Trevin Chow
Files touched
M skills/printing-press/SKILL.mdM skills/printing-press/references/absorb-scoring.mdA skills/printing-press/references/novel-features-subagent.md
Diff
commit 13995da78c4d061fcd3c26492cd93b25465a774e
Author: Trevin Chow <trevin@trevinchow.com>
Date: Sun May 3 16:16:25 2026 -0700
feat(skills): brainstorm novel features via Task subagent (#533)
---
skills/printing-press/SKILL.md | 44 ++--
skills/printing-press/references/absorb-scoring.md | 197 ++++------------
.../references/novel-features-subagent.md | 250 +++++++++++++++++++++
3 files changed, 325 insertions(+), 166 deletions(-)
diff --git a/skills/printing-press/SKILL.md b/skills/printing-press/SKILL.md
index 5422cb42..0182fc19 100644
--- a/skills/printing-press/SKILL.md
+++ b/skills/printing-press/SKILL.md
@@ -1176,13 +1176,12 @@ who uses this service, what their rituals are, and what questions they can't ans
today. "What can SQLite do?" is the wrong question. "What would make a power user
say 'I need this'?" is the right one.
-Read [references/absorb-scoring.md](references/absorb-scoring.md) Step 1.5c.5 for
-the **User-First Feature Discovery** framework: identify 2-4 specific user personas,
-map their rituals and frustrations, identify service-specific content patterns, then
-generate features that serve those personas.
+The actual brainstorming runs as a Task subagent in Step 1.5c.5 below — customer
+model → 2× candidates → adversarial cut. Step 1.5c is the motivation; do not
+generate transcendence features inline here.
-After the user-first pass, also check for compound use cases that are only possible
-with local data:
+The transcendence table in the manifest (Step 1.5d) renders rows in this shape,
+which the subagent's `### Survivors` output already matches:
```markdown
### Transcendence (only possible with our approach)
@@ -1195,15 +1194,30 @@ with local data:
Minimum 5 transcendence features. These are the commands that differentiate the CLI.
-### Step 1.5c.5: Auto-Suggest Novel Features
-
-**This step runs automatically.** Read [references/absorb-scoring.md](references/absorb-scoring.md)
-for the gap analysis framework, scoring dimensions, and candidate generation process.
-
-**On reprints, the same reference file's "Reprint Reconciliation" section runs as a forcing
-function**: every prior novel feature is re-scored against the current personas and tagged
-keep / reframe / drop with a one-line justification. Prior features are never silently
-absorbed and never silently dropped.
+### Step 1.5c.5: Auto-Suggest Novel Features (subagent)
+
+**Always spawn the subagent — first prints and reprints alike.** The subagent
+is the only path that produces this step's outputs (customer model, candidate
+list, adversarial cut, killed-candidate audit trail). There is no manual
+fallback. Specifically, do not:
+
+- hand-curate the transcendence list from a prior manifest, even when the
+ prior looks complete. Prior `research.json` is INPUT to Pass 2(d), never
+ a substitute for the spawn.
+- fall back to inline brainstorming inside the SKILL.
+- skip on cost grounds. With a strong prior the subagent confirms or
+ reframes; with no prior it generates from scratch. Run it either way.
+- treat disclosure as authorization. Announcing a skip in the gate showcase
+ does not make the skip legal.
+
+Read [references/novel-features-subagent.md](references/novel-features-subagent.md)
+for the prior-research discovery snippet, input bundle, prompt template, and
+output contract. Run the discovery snippet as written — do not substitute an
+`ls` of the manuscripts directory. The snippet's `none` branch (no prior
+research) is a first print, not a skip signal.
+
+The only legitimate non-spawn outcome is the pre-flight HALT (brief lacks
+user research) defined in the reference file.
### Step 1.5d: Write the manifest artifact
diff --git a/skills/printing-press/references/absorb-scoring.md b/skills/printing-press/references/absorb-scoring.md
index e1427a32..8da6a1cd 100644
--- a/skills/printing-press/references/absorb-scoring.md
+++ b/skills/printing-press/references/absorb-scoring.md
@@ -1,62 +1,19 @@
-# Absorb Scoring: Auto-Suggest Novel Features
+# Absorb Scoring Rubric: Novel Features
-> **When to read:** This file is referenced by Phase 1.5 of the printing-press skill.
-> Read it during Step 1.5c.5 to run gap analysis, score candidates, and populate the transcendence table.
+> **When to read:** This file is the scoring rubric for the novel-features
+> subagent (Phase 1.5 Step 1.5c.5). It defines kill/keep checks, the
+> 4-dimension score, the transcendence table format, and reprint verdict
+> rules. The subagent reads this file as part of its operational playbook —
+> the SKILL no longer applies it inline.
+>
+> Brainstorming flow (personas, candidate generation, gap analysis, cut pass)
+> lives in [novel-features-subagent.md](novel-features-subagent.md). This
+> file owns the static rubric only.
-### Step 1.5c.5: Auto-Suggest Novel Features
+## Kill/keep checks
-**This step runs automatically.** No user interaction. Synthesize ALL research gathered so far (Phase 1 brief + Phase 1.5a ecosystem search + Phase 1.5b absorb manifest) into evidence-backed feature recommendations.
-
-#### User-First Feature Discovery
-
-Before generating features from technical capabilities, think about the humans
-who will use this CLI. The best transcendence features come from understanding
-user rituals and service-specific content patterns, not from asking "what can
-SQLite do?"
-
-##### Step 1: Identify specific user personas (2-4 personas)
-
-Don't say "developers" or "users." Name specific people with specific habits:
-
-- "Someone who checks HN every morning before standup"
-- "A hiring manager scanning Who's Hiring threads monthly"
-- "A movie buff deciding what to watch tonight"
-- "A developer about to post their Show HN launch"
-
-Draw these from the Phase 1 brief's "Users" and "Top Workflows" sections. Each
-persona represents a feature surface.
-
-##### Step 2: Map each persona's rituals and frustrations
-
-For each persona, answer:
-- **What do they do repeatedly?** (daily/weekly/monthly rituals with this service)
-- **What question do they wish they could answer but can't?** (This IS the feature.)
-- **What's tedious about their current workflow?** (This IS the automation opportunity.)
-
-Example (HN):
-- Persona: "Morning HN checker"
-- Ritual: Opens HN, scans top stories, opens a few
-- Question they can't answer: "What hit the front page while I was coding?"
-- Feature: `hn since 2h` — one command, no setup
-
-##### Step 3: Identify service-specific content patterns
-
-Every service has unique content types, categories, or workflows that define its
-identity. These are feature surfaces that generic "CRUD + analytics" thinking misses:
-
-- HN: Show HN, Ask HN, Who's Hiring, Who's Looking (each is a feature surface)
-- Spotify: Playlists, Discover Weekly, Wrapped/year-end stats
-- GitHub: PRs, Issues, Actions, Discussions (each has its own workflows)
-- TMDb: Collections/franchises, Watch providers, Trending
-
-For each content pattern, ask: "What would the power user of THIS specific
-feature want that no existing tool provides?"
-
-##### Step 4: Self-vet before presenting
-
-Run every candidate feature through these 5 kill/keep checks. Do this BEFORE
-scoring, BEFORE presenting to the user. Cut ruthlessly — the user should only
-see features that can actually ship.
+Apply these to every candidate BEFORE scoring. Cut ruthlessly — survivors must
+be features that can actually ship.
| Check | Kill condition | Keep/reframe action |
|-------|---------------|-------------------|
@@ -67,100 +24,15 @@ see features that can actually ship.
| **Verifiability** | Feature can't be tested in dogfood. No way to verify the output is correct without manual inspection or domain expertise. | **Flag** as low-confidence. Keep only if the value is high enough to justify manual QA. |
| **Reimplementation** | Feature synthesizes API responses locally instead of calling the API. Hand-rolled response builders, hardcoded JSON returned as an "API result," endpoint stubs that return constants, or aggregations computed in-process when the API has an aggregation endpoint. | **Cut or rewrite.** A printed CLI that pretends to call the API is strictly worse than the API call it replaces. The one exception is features that read from the local SQLite store (`stale`, `bottleneck`, `health`, `reconcile`); those are local-data commands, not fake API calls. Dogfood's `reimplementation_check` enforces this at generation time. |
-**For each surviving feature, write one sentence proving it's buildable:**
-"This uses [specific API endpoint or local data] to compute [specific output]
-with no external dependencies."
-
-If you can't write that sentence, the feature fails the vet.
-
-#### Reprint Reconciliation
-
-**Run only when this is a reprint** — when a prior `research.json` exists at
-`$PRESS_LIBRARY/<api>/research.json` (provenance) or under
-`$PRESS_MANUSCRIPTS/<api-slug>/*/research.json` (archived runs). Skip on first
-prints.
-
-Agents are non-deterministic. The user-first discovery above runs from current
-research and can miss strong features the prior CLI shipped — even when the
-agent has otherwise referenced the prior CLI elsewhere in this session. This
-step is a forcing function: prior novel features become candidate input, not
-gospel and not noise.
-
-##### Step 1: Load the prior list
-
-```bash
-PRIOR_RESEARCH=""
-if [ -f "$PRESS_LIBRARY/<api>/research.json" ]; then
- PRIOR_RESEARCH="$PRESS_LIBRARY/<api>/research.json"
-elif [ -d "$PRESS_MANUSCRIPTS/<api-slug>" ]; then
- PRIOR_RESEARCH=$(ls -1t "$PRESS_MANUSCRIPTS/<api-slug>"/*/research.json 2>/dev/null | head -1)
-fi
-```
-
-From the prior `research.json`, pull `novel_features` (planned) and
-`novel_features_built` (actually shipped). For each prior feature, capture
-command, description, prior score, and whether it was built or remained a
-stub.
-
-##### Step 2: Score each prior feature against the current personas
-
-Use the personas from User-First Feature Discovery Steps 1–3. For every prior
-feature, answer:
-
-- **Persona fit:** Which current persona does this feature serve? Name them
- explicitly. "None" is a valid answer and triggers a drop.
-- **Still buildable:** Pass the Step 4 kill/keep checks against the current
- spec, auth, and scope. API drift since last print may have killed it.
-- **Shipped quality:** Planned-but-not-built features get extra scrutiny — the
- prior run already failed to land them.
-
-Re-score on the same 4 dimensions (Domain Fit, User Pain, Build Feasibility,
-Research Backing). Do not inherit the prior score; re-derive from current
-research and current personas.
-
-##### Step 3: Verdict and feed into the candidate pool
+**Buildability proof.** For each surviving feature, write one sentence:
-Tag each prior feature with one verdict, then add it (or don't) to the same
-candidate pool that user-first discovery and gap analysis populate:
+> "This uses [specific API endpoint or local data] to compute [specific output] with no external dependencies."
-| Verdict | When | Pool action |
-|---------|------|-------------|
-| **Keep** | Persona fit, score ≥ 5/10, buildable | Add with prior `command` reused so the reprint stays compatible |
-| **Reframe** | Right idea, wrong shape — persona fit exists but command/scope drifted | Add with a new `command`/`description`; flag the rename |
-| **Drop** | No persona fit, score < 5/10, or unbuildable now | Exclude; record one-line reason for the manifest |
-
-##### Step 4: Surface in the absorb manifest
-
-In the transcendence table, add a `Source` column for reprint runs:
-`prior (kept)`, `prior (reframed from <old-command>)`, or `new`. Below the
-table, list dropped prior features with their one-line justifications so the
-user can override the drop at the Phase 1.5 gate review.
-
-#### Gap Analysis
-
-After the user-first discovery, run these technical analyses to find anything
-the persona work missed:
-
-1. **Cross-entity queries** — What joins across synced tables produce insights no single API call can?
-
-2. **User pain points** — From Phase 1 research: npm README "limitations" sections, GitHub issues on competitor repos, community docs mentioning workarounds
-
-3. **Competitor edges** — From the absorb manifest: what does the BEST competitor tool uniquely offer? Can we beat it?
-
-4. **Agent workflow gaps** — What would an AI agent using this CLI wish it could do in one command instead of multiple?
-
-5. **Self-brainstorm** — Answer these questions using the research context gathered so far. Do NOT ask the user — answer them yourself from the research brief, absorb manifest, and ecosystem findings:
- - Based on the research brief's top workflows and user profiles, what workflows does the typical power user of this API do that aren't covered in the absorbed features?
- - Based on competitor repo issues, community pain points, and ecosystem gaps found in Phase 1/1.5, what are the most annoying limitations that a CLI with SQLite could fix?
- - Based on the NOI and domain archetype, what single "killer feature" would make a power user install this CLI over any alternative?
- - (Only when `USER_BRIEFING_CONTEXT` is non-empty) Based on the user's stated vision, what features directly serve their stated goals that the absorbed features don't already cover?
- - (Only when DeepWiki codebase analysis is available) Based on the codebase architecture DeepWiki revealed, what compound use cases become possible that the public API docs don't suggest? Look for internal data relationships, queue/worker patterns, or event systems that could power novel CLI features.
+If you can't write that sentence, the feature fails the vet.
-#### Generate, Vet, and Score
+## Score (4 dimensions, raw 0-10)
-1. **Generate** 5-12 candidate features from the user-first discovery + reprint reconciliation (when applicable) + gap analysis.
-2. **Vet** each through the Step 4 kill/keep checks. Cut or reframe failures.
-3. **Score** survivors on 4 dimensions:
+Apply to candidates that survive the kill/keep checks.
| Dimension | Points | Scoring |
|-----------|--------|---------|
@@ -171,9 +43,9 @@ the persona work missed:
**Normalize:** `score_10 = round(raw / 10 * 10)`. Include features scoring >= 5/10.
-#### Add to Transcendence Table
+## Transcendence Table Format
-Add each qualifying feature as a new row:
+Survivors render as rows in the absorb manifest's transcendence table:
```markdown
| # | Feature | Command | Score | How It Works | Evidence |
@@ -181,6 +53,29 @@ Add each qualifying feature as a new row:
| N | Player comparison | compare "LeBron" "Curry" | 8/10 | Joins player_stats + team + season tables in local SQLite | ESPN community requests, espn_scraper lacks cross-player queries |
```
-The "How It Works" column is the buildability proof from Step 4 — one sentence
-showing the specific API endpoint or local data that powers the feature.
-The "Evidence" column MUST cite specific findings from Phase 1 or Phase 1.5 research.
+The "How It Works" column is the buildability proof — one sentence showing the
+specific API endpoint or local data that powers the feature.
+
+The "Evidence" column MUST cite specific findings from Phase 1 or Phase 1.5
+research. "Power users would love this" is not evidence.
+
+## Reprint verdict rules
+
+Reprints occur when a prior `research.json` exists at
+`$PRESS_LIBRARY/<api>/research.json` (provenance) or under
+`$PRESS_MANUSCRIPTS/<api-slug>/*/research.json` (archived runs). The subagent
+loads prior `novel_features` (planned) and `novel_features_built` (shipped),
+re-scores each against the current personas, and tags every prior feature with
+exactly one verdict:
+
+| Verdict | When | Pool action |
+|---------|------|-------------|
+| **Keep** | Persona fit, score ≥ 5/10, buildable | Add with prior `command` reused so the reprint stays compatible |
+| **Reframe** | Right idea, wrong shape — persona fit exists but command/scope drifted | Add with a new `command`/`description`; flag the rename |
+| **Drop** | No persona fit, score < 5/10, or unbuildable now | Exclude; record one-line reason for the manifest |
+
+**Surface in the manifest.** Reprint runs add a `Source` column to the
+transcendence table: `prior (kept)`, `prior (reframed from <old-command>)`, or
+`new`. Below the table, list dropped prior features with their one-line
+justifications so the user can override the drop at the Phase 1.5 gate review.
+Prior features are never silently absorbed and never silently dropped.
diff --git a/skills/printing-press/references/novel-features-subagent.md b/skills/printing-press/references/novel-features-subagent.md
new file mode 100644
index 00000000..883d2b7c
--- /dev/null
+++ b/skills/printing-press/references/novel-features-subagent.md
@@ -0,0 +1,250 @@
+# Novel Features Subagent
+
+> **When to read:** This file is referenced by Phase 1.5 Step 1.5c.5 of the
+> printing-press skill. It owns the input bundle contract, the Task subagent
+> invocation, the subagent prompt template, and the output parsing rules for
+> novel-feature brainstorming.
+
+## Invariants
+
+The subagent spawns once per absorb step, in every printing-press run. The
+only legal non-spawn outcome is the pre-flight HALT defined below.
+
+- A missing prior `research.json` is a first print, not a skip signal — the
+ subagent still spawns; only Pass 2(d) (reprint reconciliation) is omitted.
+- A complete-looking prior manifest is not a skip signal either — Pass 2(d)
+ re-scores prior features against the current personas, which is the
+ entire reason the reprint case exists. Strong priors make the spawn more
+ valuable, not less.
+- Hand-curating from a prior manifest, falling back to inline brainstorming
+ in SKILL.md, or disclosing a skip in the gate showcase are violations of
+ this contract, not exits from it.
+- Run the prior-research discovery snippet below as written. Do not
+ substitute a hand-eyeballed `ls` of the manuscripts directory; the
+ snippet's path (`$PRESS_MANUSCRIPTS/<api-slug>/*/research.json`) is at the
+ run-id level, not inside the `research/` subdirectory.
+
+## Pre-flight check
+
+Before spawning, confirm the Phase 1 brief has both:
+- a populated `Users` section with concrete user types, AND
+- a populated `Top Workflows` section with named rituals.
+
+If either is missing or pro-forma ("developers", "general users", "anyone using
+the API"), do NOT spawn the subagent. The brainstorm will fabricate plausible
+personas instead of grounding in research. Loop back to Phase 1 user research
+and return here.
+
+## Input bundle
+
+Assemble these values before spawning. Substitute into the prompt template
+below.
+
+| Variable | Value |
+|----------|-------|
+| `${BRIEF_PATH}` | `$RESEARCH_DIR/<stamp>-feat-<api>-pp-cli-brief.md` — also embeds DeepWiki findings (`## Codebase Intelligence`) and user briefing (`## User Vision`) when present |
+| `${ABSORB_MANIFEST_CONTENT}` | Inline markdown: the absorbed-features table built in Step 1.5b. The on-disk manifest at `<stamp>-feat-<api>-pp-cli-absorb-manifest.md` is not written until Step 1.5d, so paste the table content directly into the prompt. |
+| `${RUBRIC_PATH}` | Absolute path to `references/absorb-scoring.md` (the scoring rubric) |
+| `${API_SPEC_SUMMARY}` | Inline 1-paragraph summary: API surface (endpoint families), auth shape, NOI domain |
+| `${PRIOR_RESEARCH_PATH}` | Result of the prior-research discovery snippet below, or the literal string `none` |
+
+**Prior-research discovery.** Run before assembling the bundle to set
+`${PRIOR_RESEARCH_PATH}`:
+
+```bash
+PRIOR_RESEARCH=none
+if [ -f "$PRESS_LIBRARY/<api>/research.json" ]; then
+ PRIOR_RESEARCH="$PRESS_LIBRARY/<api>/research.json"
+elif [ -d "$PRESS_MANUSCRIPTS/<api-slug>" ]; then
+ CANDIDATE=$(ls -1t "$PRESS_MANUSCRIPTS/<api-slug>"/*/research.json 2>/dev/null | head -1)
+ [ -n "$CANDIDATE" ] && PRIOR_RESEARCH="$CANDIDATE"
+fi
+```
+
+User vision and DeepWiki findings are not separate variables — they live
+inside the brief. The subagent detects their presence by checking for the
+`## User Vision` and `## Codebase Intelligence` sections in
+`${BRIEF_PATH}`.
+
+## Subagent invocation
+
+One Task tool call. Do not split passes across multiple invocations — the cut
+pass must see the candidates it generated.
+
+```
+Agent({
+ description: "Novel-features brainstorm + adversarial cut",
+ subagent_type: "general-purpose",
+ prompt: <Subagent prompt template below, with ${...} placeholders substituted>
+})
+```
+
+## Subagent prompt template
+
+````
+You are a novel-features brainstorming agent for the Printing Press, a system
+that generates CLIs for APIs. Your job is to propose the differentiating
+features for ONE printed CLI and then ruthlessly cut the weak ones.
+
+You will run THREE PASSES IN ORDER. The third pass is not optional and is not
+a polish pass — it is the cut.
+
+## Inputs (read these before Pass 1)
+
+- Brief (read from disk): ${BRIEF_PATH}
+- Scoring rubric (read): ${RUBRIC_PATH} (kill/keep checks, score dimensions, table format, reprint verdicts)
+- Prior research.json: ${PRIOR_RESEARCH_PATH} (read from disk if real path; literal `none` means first print)
+- API spec summary: ${API_SPEC_SUMMARY} (inline)
+
+Inline absorb manifest (features ALREADY covered — do not re-propose):
+
+${ABSORB_MANIFEST_CONTENT}
+
+The brief may contain `## User Vision` and `## Codebase Intelligence`
+sections. Detect their presence after reading the brief; they gate Pass 2
+sources (e) and (f).
+
+If `${PRIOR_RESEARCH_PATH}` is a real path, this is a REPRINT and Pass 2 step
+(d) is mandatory.
+
+## Pass 1: Customer pass
+
+Write down WHO the user of this CLI is BEFORE proposing any features. Output
+under heading `## Customer model`.
+
+- 2-4 named personas. NOT "developers" or "users" — concrete people with
+ concrete habits drawn from the brief's Users + Top Workflows sections.
+ Good: "Someone who checks HN every morning before standup."
+ Good: "A hiring manager scanning Who's Hiring threads monthly."
+ Bad: "API users."
+- For each persona, write three short paragraphs:
+ - **Today (without this CLI):** What do they do today to accomplish their
+ weekly ritual with this API? What tabs do they have open? What scripts do
+ they re-run? What questions can they NOT answer?
+ - **Weekly ritual:** The repeated workflow that defines their relationship
+ with this service.
+ - **Frustration:** The single most tedious or impossible part of the ritual.
+
+If you cannot do this from the brief alone — if you find yourself inventing
+personas to keep going — STOP and return ONLY:
+
+```
+## Failure: brief lacks user research
+
+The Phase 1 brief does not contain enough Users / Top Workflows detail to
+ground a customer model. Re-run Phase 1 user research before spawning this
+subagent again.
+```
+
+Do not proceed to Pass 2 with fabricated personas.
+
+## Pass 2: Generate pass
+
+Output under heading `## Candidates (pre-cut)`. Generate ~2× the features you
+expect to ship — aim for 8-16 candidates total.
+
+Sources for candidates (label each candidate with its source):
+
+(a) **Persona-driven:** For each persona's frustration from Pass 1, propose
+ the one-command feature that resolves it.
+
+(b) **Service-specific content patterns:** What unique content types or
+ workflows define this service's identity (e.g., HN's Show HN / Ask HN /
+ Who's Hiring; Spotify's Discover Weekly / Wrapped; GitHub's
+ Discussions; TMDb's Collections / Watch Providers)? Propose features
+ that exploit each.
+
+(c) **Cross-entity local queries:** What joins across synced tables produce
+ insights no single API call can?
+
+(d) **Reprint reconciliation** (only if `${PRIOR_RESEARCH_PATH}` is a real
+ path): Load the prior `novel_features` and `novel_features_built`
+ arrays. For each prior feature, score it against the current personas
+ using the rubric. Add to candidates with verdict tag `prior-keep`,
+ `prior-reframe`, or `prior-drop`. The prior list is candidate input,
+ not gospel and not noise.
+
+(e) **User briefing** (only if the brief contains a `## User Vision`
+ section): Propose features that directly serve the user's stated vision
+ but are not already covered by the absorb manifest.
+
+(f) **DeepWiki** (only if the brief contains a `## Codebase Intelligence`
+ section): Propose features that exploit internal data relationships,
+ queue/worker patterns, or event systems that the public API docs don't
+ suggest.
+
+For each candidate capture: name, command, one-line description, persona
+served, source label from the list above.
+
+Apply the rubric's kill/keep checks (LLM dependency, external service, auth
+gap, scope creep, verifiability, reimplementation) inline. Reframe or cut
+obvious failures NOW so they don't waste Pass 3 attention.
+
+## Pass 3: Adversarial cut pass
+
+This is the pass that exists because brainstorms without it produce flabby
+lists. Output under heading `## Survivors and kills`.
+
+For EVERY surviving candidate, force-answer these in writing:
+
+1. **Weekly use:** Would the named persona actually run this command at
+ least weekly? "Monthly", "occasionally", or "depends" is a soft kill.
+2. **Wrapper vs leverage:** Is this a thin renaming of one API endpoint
+ the user could call directly with a generic client? If yes, kill it —
+ wrappers do not justify transcendence rows.
+3. **Transcendence proof:** Does this feature get its power from local
+ SQLite, a cross-source join, agent-shaped output, or a service-specific
+ content pattern? If the answer is "none of the above", it is not
+ transcendent.
+4. **Sibling kill:** Name the closest candidate you killed and why. If
+ you cannot, you didn't generate enough candidates — return to Pass 2
+ and add more.
+
+Drop ~half. Target output: 4-8 survivors. Score survivors with the rubric's
+4-dimension score; only keep features scoring >= 5/10.
+
+For every killed candidate, record a one-sentence kill reason. Killed
+candidates are PART of the output, not silent.
+
+## Output contract
+
+Return a single markdown document with these top-level sections, in this
+order:
+
+1. `## Customer model` — personas from Pass 1.
+2. `## Candidates (pre-cut)` — full Pass 2 list with source labels and
+ inline kill/keep verdicts from the rubric.
+3. `## Survivors and kills`
+ - `### Survivors` — features scoring >= 5/10, formatted as a
+ transcendence table per the rubric's "Transcendence Table Format"
+ section. Include score, persona-served, and the one-sentence
+ buildability proof per the rubric.
+ - `### Killed candidates` — table with columns: feature, kill reason,
+ closest-surviving-sibling.
+4. `## Reprint verdicts` (REPRINT ONLY) — per-prior-feature: keep / reframe
+ / drop, with one-line justification, per the rubric's reprint verdict
+ rules.
+
+Do not include any other sections. Do not summarize. Do not editorialize.
+Do not propose follow-up work.
+````
+
+## Output handling in SKILL.md
+
+After the subagent returns:
+
+1. **Parse `### Survivors`** — these become the transcendence rows in the
+ absorb manifest (Step 1.5d). The score and buildability proof go into the
+ transcendence table; the persona-served column is the audit trail.
+2. **Parse `## Reprint verdicts`** (if present) — record dropped prior features
+ under the transcendence table per the rubric's reprint surface rule, so the
+ user can override drops at the Phase 1.5 gate review.
+3. **Audit trail** — save the full subagent response (including `## Customer
+ model`, `## Candidates (pre-cut)`, `### Killed candidates`) to
+ `$RESEARCH_DIR/<stamp>-novel-features-brainstorm.md`. The Customer model and
+ Killed candidates do NOT go into the manifest, but they MUST be persisted
+ for retro/dogfood debugging.
+4. **Failure handling** — if the subagent returned the `## Failure: brief lacks
+ user research` envelope, HALT Phase 1.5 immediately. Do not fall back to
+ inline brainstorming. Surface the failure to the user and re-run Phase 1
+ user research.
← f2450385 feat(skills): browser-capture fallback options (chrome-MCP,
·
back to Cli Printing Press
·
fix(cli): session_handshake auth correctness pass (#534) 96dd07c0 →