← back to Cli Printing Press
fix(skills): surface novel-feature hand-code scope at Phase Gate 1.5 (#1501)
793d5b272608d95ff65a4c83d669be2ab1e0ba10 · 2026-05-16 01:19:57 -0700 · Trevin Chow
* fix(skills): surface novel-feature hand-code scope at Phase Gate 1.5
Closes #1450
Phase Gate 1.5 lacked a signal that approving "N novel features scored
>=5/10" committed the agent to ~50-150 LoC of hand-written Go per
feature, plus root.go wiring, for every transcendence row the generator
won't auto-emit. Users approved without seeing that scope, and the gap
surfaced later as validate-narrative / verify-skill failures.
Two coordinated edits:
* novel-features-subagent.md: Pass 3 gains a fifth force-answer question
("Buildability"), tagging each survivor `spec-emits` or `hand-code`.
The output contract requires the survivors table to extend the
rubric's transcendence format with a Buildability column; the
SKILL-side handler reads that column for the gate showcase.
* SKILL.md Phase Gate 1.5: the prose showcase now covers four
must-haves, with a new "Hand-code commitment" item that states the
auto-emitted vs hand-code split and lists the hand-code feature names
before the AskUserQuestion fires.
* fix(skills): align Step 1.5c transcendence table template with Buildability column
Greptile P1 on PR #1501: the canonical four-column transcendence table
template at Step 1.5c didn't carry the new Buildability column, so an
agent writing the manifest from that template would silently drop the
column and Phase Gate 1.5's hand-code count would lose its source of
truth in the manifest. Update the template to include Buildability and
fix the stale "already matches" wording.
* fix(skills): add Buildability column to rubric Transcendence Table Format
Greptile 2nd-pass on PR #1501: the subagent reads absorb-scoring.md as
its operational playbook, so the canonical Transcendence Table Format
also needs the new Buildability column. Without it, the subagent has no
guidance on where to place the column in its Survivors output, leaving
the manifest parse step's Buildability lookup brittle.
Clarify the relationship between the existing "How It Works" column (the
buildability proof sentence) and the new "Buildability" column (the
spec-emits / hand-code tag) so the two distinct concepts don't get
conflated.
* fix(skills): tighten Buildability wording per PR review
Two minor wording cleanups flagged in Greptile's 5/5 review:
* novel-features-subagent.md Output contract: now that absorb-scoring.md
also includes Buildability, "extends with one additional column" is
self-contradictory. Switch to "matching the rubric's format (which
includes the Buildability column)".
* SKILL.md Phase Gate 1.5: by gate time the agent reads the manifest,
not the archived brainstorm. Point at the manifest transcendence
table's Buildability column as the source of truth.
---------
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Files touched
M skills/printing-press/SKILL.mdM skills/printing-press/references/absorb-scoring.mdM skills/printing-press/references/novel-features-subagent.md
Diff
commit 793d5b272608d95ff65a4c83d669be2ab1e0ba10
Author: Trevin Chow <trevin@trevinchow.com>
Date: Sat May 16 01:19:57 2026 -0700
fix(skills): surface novel-feature hand-code scope at Phase Gate 1.5 (#1501)
* fix(skills): surface novel-feature hand-code scope at Phase Gate 1.5
Closes #1450
Phase Gate 1.5 lacked a signal that approving "N novel features scored
>=5/10" committed the agent to ~50-150 LoC of hand-written Go per
feature, plus root.go wiring, for every transcendence row the generator
won't auto-emit. Users approved without seeing that scope, and the gap
surfaced later as validate-narrative / verify-skill failures.
Two coordinated edits:
* novel-features-subagent.md: Pass 3 gains a fifth force-answer question
("Buildability"), tagging each survivor `spec-emits` or `hand-code`.
The output contract requires the survivors table to extend the
rubric's transcendence format with a Buildability column; the
SKILL-side handler reads that column for the gate showcase.
* SKILL.md Phase Gate 1.5: the prose showcase now covers four
must-haves, with a new "Hand-code commitment" item that states the
auto-emitted vs hand-code split and lists the hand-code feature names
before the AskUserQuestion fires.
* fix(skills): align Step 1.5c transcendence table template with Buildability column
Greptile P1 on PR #1501: the canonical four-column transcendence table
template at Step 1.5c didn't carry the new Buildability column, so an
agent writing the manifest from that template would silently drop the
column and Phase Gate 1.5's hand-code count would lose its source of
truth in the manifest. Update the template to include Buildability and
fix the stale "already matches" wording.
* fix(skills): add Buildability column to rubric Transcendence Table Format
Greptile 2nd-pass on PR #1501: the subagent reads absorb-scoring.md as
its operational playbook, so the canonical Transcendence Table Format
also needs the new Buildability column. Without it, the subagent has no
guidance on where to place the column in its Survivors output, leaving
the manifest parse step's Buildability lookup brittle.
Clarify the relationship between the existing "How It Works" column (the
buildability proof sentence) and the new "Buildability" column (the
spec-emits / hand-code tag) so the two distinct concepts don't get
conflated.
* fix(skills): tighten Buildability wording per PR review
Two minor wording cleanups flagged in Greptile's 5/5 review:
* novel-features-subagent.md Output contract: now that absorb-scoring.md
also includes Buildability, "extends with one additional column" is
self-contradictory. Switch to "matching the rubric's format (which
includes the Buildability column)".
* SKILL.md Phase Gate 1.5: by gate time the agent reads the manifest,
not the archived brainstorm. Point at the manifest transcendence
table's Buildability column as the source of truth.
---------
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
---
skills/printing-press/SKILL.md | 22 ++++++++++--------
skills/printing-press/references/absorb-scoring.md | 13 ++++++++---
.../references/novel-features-subagent.md | 26 +++++++++++++++++-----
3 files changed, 44 insertions(+), 17 deletions(-)
diff --git a/skills/printing-press/SKILL.md b/skills/printing-press/SKILL.md
index b0911a79..18cd6256 100644
--- a/skills/printing-press/SKILL.md
+++ b/skills/printing-press/SKILL.md
@@ -1336,15 +1336,18 @@ model → 2× candidates → adversarial cut. Step 1.5c is the motivation; do no
generate transcendence features inline here.
The transcendence table in the manifest (Step 1.5d) renders rows in this shape,
-which the subagent's `### Survivors` output already matches:
+which mirrors the subagent's `### Survivors` output. The `Buildability` column
+tags each row `spec-emits` or `hand-code` per
+[references/novel-features-subagent.md](references/novel-features-subagent.md)
+so the Phase Gate 1.5 hand-code count has a source of truth in the manifest:
```markdown
### Transcendence (only possible with our approach)
-| # | Feature | Command | Why Only We Can Do This |
-|---|---------|---------|------------------------|
-| 1 | Bottleneck detection | bottleneck | Requires local join across issues + assignees + cycle data |
-| 2 | Velocity trends | velocity --weeks 4 | Requires historical cycle snapshots in SQLite |
-| 3 | What did I miss | since 2h | Requires time-windowed aggregation no single API call provides |
+| # | Feature | Command | Buildability | Why Only We Can Do This |
+|---|---------|---------|--------------|------------------------|
+| 1 | Bottleneck detection | bottleneck | hand-code | Requires local join across issues + assignees + cycle data |
+| 2 | Velocity trends | velocity --weeks 4 | hand-code | Requires historical cycle snapshots in SQLite |
+| 3 | What did I miss | since 2h | hand-code | Requires time-windowed aggregation no single API call provides |
```
Minimum 5 transcendence features. These are the commands that differentiate the CLI.
@@ -1499,15 +1502,16 @@ The prose showcase and the `AskUserQuestion` are two separate turns. Print the s
**Part 1: Prose showcase (print before the AskUserQuestion)**
-The showcase exists so the user can decide approve / trim / add ideas without asking a follow-up. Cover three things:
+The showcase exists so the user can decide approve / trim / add ideas without asking a follow-up. Cover four things:
1. **Scope** — how many features absorbed across which tools, how many novel on top, how that stacks up against the best existing tool.
2. **Per-novel-feature readout** — one line each: feature name, what the user gets, and the specific evidence or persona that makes it worth building.
-3. **Anything the user should worry about before approving** — stubs, risky dependencies, expensive endpoints, low-confidence ideas.
+3. **Hand-code commitment** — of the M novel features, K will require hand-written Go after generate (each ~50-150 LoC plus `root.go` wiring). State the hand-code count and the auto-emitted count, then list the names of the hand-code features. The manifest transcendence table's `Buildability` column (populated from the subagent per [references/novel-features-subagent.md](references/novel-features-subagent.md) "Output contract") is the source of truth: count rows tagged `hand-code`; `spec-emits` rows are excluded from the hand-code total. Approving commits the agent to that scope, so the user must see it explicitly before the AskUserQuestion.
+4. **Anything else the user should worry about before approving** — stubs, risky dependencies, expensive endpoints, low-confidence ideas.
Show every novel feature that scored ≥5/10. Group by theme if there are more than ~12; never hide features behind "Plus N more" or "see full manifest." If zero qualified, say so plainly: "No novel features scored high enough to recommend. The absorbed features cover the landscape well."
-Format is otherwise yours — markdown headings, prose, a numbered list, whatever reads cleanly. The must-haves are the three things above and the ≥5/10 coverage rule.
+Format is otherwise yours — markdown headings, prose, a numbered list, whatever reads cleanly. The must-haves are the four things above and the ≥5/10 coverage rule.
**Part 2: AskUserQuestion**
diff --git a/skills/printing-press/references/absorb-scoring.md b/skills/printing-press/references/absorb-scoring.md
index 5d168a93..1e7eae0d 100644
--- a/skills/printing-press/references/absorb-scoring.md
+++ b/skills/printing-press/references/absorb-scoring.md
@@ -48,14 +48,21 @@ Apply to candidates that survive the kill/keep checks.
Survivors render as rows in the absorb manifest's transcendence table:
```markdown
-| # | Feature | Command | Score | How It Works | Evidence |
-|---|---------|---------|-------|-------------|----------|
-| 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 |
+| # | Feature | Command | Score | Buildability | How It Works | Evidence |
+|---|---------|---------|-------|--------------|--------------|----------|
+| N | Player comparison | compare "LeBron" "Curry" | 8/10 | hand-code | 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 — one sentence showing the
specific API endpoint or local data that powers the feature.
+The "Buildability" column tags whether the generator auto-emits the feature
+from the spec (`spec-emits`) or whether the agent must hand-write the Cobra
+file plus `root.go` wiring after generate (`hand-code`). See Pass 3 question 5
+in [novel-features-subagent.md](novel-features-subagent.md) for the
+classification rules. The Phase Gate 1.5 prose showcase counts `hand-code`
+rows from this column when reading out the hand-code commitment.
+
The "Evidence" column MUST cite specific findings from Phase 1 or Phase 1.5
research. "Power users would love this" is not evidence.
diff --git a/skills/printing-press/references/novel-features-subagent.md b/skills/printing-press/references/novel-features-subagent.md
index 883d2b7c..122a82e1 100644
--- a/skills/printing-press/references/novel-features-subagent.md
+++ b/skills/printing-press/references/novel-features-subagent.md
@@ -199,6 +199,17 @@ For EVERY surviving candidate, force-answer these in writing:
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.
+5. **Buildability:** Will the generator auto-emit this from the spec, or
+ will the agent need to hand-write a Cobra file plus `root.go` wiring
+ after generate? Tag exactly one value:
+ - `spec-emits` — the feature reuses an endpoint already in the spec
+ and the generator's emit path (endpoint mirror or `extra_commands`)
+ produces a working command without hand-edits.
+ - `hand-code` — the feature requires SQLite joins, cross-source
+ synthesis, custom output shapes, or any Go code beyond what the
+ generator emits today (~50-150 LoC per feature plus `root.go`
+ wiring). This is the default for transcendence features; most
+ candidates fall here.
Drop ~half. Target output: 4-8 survivors. Score survivors with the rubric's
4-dimension score; only keep features scoring >= 5/10.
@@ -216,9 +227,11 @@ order:
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.
+ transcendence table matching the rubric's "Transcendence Table
+ Format" section (which includes the **Buildability** column,
+ `spec-emits` or `hand-code` per Pass 3 question 5). Include score,
+ persona-served, the one-sentence buildability proof per the rubric,
+ and the buildability tag.
- `### Killed candidates` — table with columns: feature, kill reason,
closest-surviving-sibling.
4. `## Reprint verdicts` (REPRINT ONLY) — per-prior-feature: keep / reframe
@@ -234,8 +247,11 @@ Do not propose follow-up work.
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.
+ absorb manifest (Step 1.5d). The score, buildability proof, and
+ `Buildability` tag flow into the transcendence table; the persona-served
+ column is the audit trail. The `Buildability` column drives Phase Gate
+ 1.5's hand-code count: rows tagged `hand-code` are the agent's
+ post-generate scope commitment, rows tagged `spec-emits` are not.
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.
← ca4898a3 fix(cli): apply Bearer prefix in composed and cookie AuthHea
·
back to Cli Printing Press
·
fix(scorer): resolve binary at build/stage/bin/ before cliDi 2abbfec0 →