printing-press-reprint

/printing-press-reprint

在当前机器/引擎配置下重新生成已有的 printed CLI。用户需提供 CLI 名称以及（可选的）重新印制原因。本 Skill 会确保历史 CLI 在本地可用，评估并推荐是复用还是重做历史调研，随后带着必要上下文转交给 /printing-press。创新特性（novel-features）子 Agent 会利用这些上下文对比当前机器配置对历史特性进行调和评估——是保留、重构还是附带理由废弃，全程透明可追溯。

/printing-press-reprint notion
/printing-press-reprint cal.com  新的 MCP intent surface 已上线，而旧版 CLI 仅支持端点镜像
/printing-press-reprint allrecipes

何时运行

Printing Press 发生重大升级（如新增 MCP surface、新鉴权模式、新传输层、评分标准变更），相比手动打磨能给该 CLI 带来更显著的提升。
已发布的 CLI 存在已知系统性缺陷，且可通过重新印制来彻底修复。
用户希望针对当前机器配置和用户画像重新评估历史创新特性，而不是原封不动照搬。

对于一次性的代码质量修复，优先使用 /printing-press-polish——它不会重做调研或重建原稿。

环境准备

PRESS_HOME="${PRINTING_PRESS_HOME:-$HOME/printing-press}"
PRESS_LIBRARY="$PRESS_HOME/library"
PRESS_MANUSCRIPTS="$PRESS_HOME/manuscripts"

# 中途流水线调用方可能会在 args 包中传递 printing_press_bin: <abs-path>。
# 优先使用该路径，以便 reprint 继承父级 Skill 预检选定的二进制文件，而不是通过 PATH 重新解析。
PRINTING_PRESS_BIN="${PRINTING_PRESS_BIN:-}"
if [ -z "$PRINTING_PRESS_BIN" ] && [ -n "${ARGUMENTS:-}" ]; then
  PRINTING_PRESS_BIN="$(printf '%s\n' "$ARGUMENTS" | sed -nE 's/^[[:space:]]*printing_press_bin:[[:space:]]*(.+)$/\1/p' | head -1)"
fi
if [ -z "$PRINTING_PRESS_BIN" ]; then
  PRINTING_PRESS_BIN="$(command -v cli-printing-press 2>/dev/null || true)"
fi

if [ -z "$PRINTING_PRESS_BIN" ]; then
  echo "cli-printing-press binary not found."
  echo "Install with:  go install github.com/mvanhorn/cli-printing-press/v4/cmd/cli-printing-press@latest"
  return 1 2>/dev/null || exit 1
fi
echo "PRINTING_PRESS_BIN=$PRINTING_PRESS_BIN"

阶段 A — 解析与本地/远端状态对账

按 /printing-press-import 的方式解析用户传入的参数：获取一次公共库的 registry.json，然后按“精确匹配 → 规范化匹配 → 模糊匹配”顺序查找。参数可以是 API slug（如 notion）、品牌名（如 cal.com）、旧版 <api>-pp-cli 命名格式或足够接近的字符串。

从匹配到的注册表中提取：API_SLUG（取自 .name）和 LIB_PATH（取自 .path，例如 library/productivity/cal-com）。阶段 B 会使用 $LIB_PATH 拉取公共补丁。对于“本地存在 | 远端不存在”的未发布项目，$LIB_PATH 保持为空——阶段 B 的拉取逻辑遇到此空值会自动短路跳过。

随后检查本地存在状态，并通过读取两份出处清单（provenance manifest）中的 run_id 与 generated_at 与公共库进行对账：

本地状态	公共注册表状态	处理动作
不存在	不存在	终止 — 没有可重新印制的内容；建议使用 `/printing-press <api>` 进行全新的印制
不存在	存在	调用 `/printing-press-import <api>`，然后继续
存在	不存在	继续 — 本地未发布的 CLI；跳过导入
存在且 `run_id` 相同	存在	跳过导入直接继续
存在且公共库 `generated_at` 更新	存在	通过 `AskUserQuestion` 询问是否导入；由用户决定
存在且本地 `generated_at` 更新	存在	终止 — 本地包含未发布的工作；提示用户先发布或丢弃更改

当调用 /printing-press-import 时，让其自行处理备份、覆盖、构建校验以及模块路径重写。等待其干净返回后再继续。

阶段 B — 校验可调和的历史上下文

定位撰写流水线需要感知到的两个产物：调研数据（驱动创新特性的 Pass 2(d) 阶段）和补丁数据（由 /printing-press-amend 记录的发布后手动修复，例如 Open API 规范未列出的实测 API 特性/古怪行为）。

LIB_TARGET="$PRESS_LIBRARY/$API_SLUG"
LIB_RESEARCH="$LIB_TARGET/research.json"
MAN_RESEARCH=$(ls -1t "$PRESS_MANUSCRIPTS/$API_SLUG"/*/research.json 2>/dev/null | head -1)

调研数据缺失

如果两个调研路径均不存在，说明已发布的 CLI 早于 research.json 出处机制引入之前。子 Agent 会将本次运行视为首次印制，且不会触发 Pass 2(d) 重新印制对账——因为没有可读取的内容。向用户提示并询问：

已发布的 <api> 构建于 research.json 出处机制引入之前。缺少该文件时，创新特性子 Agent 会将其视为首次印制，无法进行历史对账。是否作为降级重新印制继续执行（本质上是保留原二进制名称的全新印制）？

如果用户拒绝，则退出。如果继续，记录缺失状态，以便在交接 Prompt 中注明本次为降级重新印制。

补丁发现

网络可达时，从公共库刷新本地补丁索引，然后进行本地读取，确保下游引用持久有效。可能有人对公共副本提交了修正（amend）但未触发重新生成，因此即使 run_id 匹配，本地副本也可能滞后；本步骤旨在抹平这一差异。

索引有两种形式存在：单补丁独立目录 .printing-press-patches/（当前规范）或旧版单数组文件 .printing-press-patches.json（尚未规范化的旧版 CLI）。网络可达时务必同时检查这两种形式。当目录包含补丁文件时优先使用目录，但在读取目录兜底前，切勿因为旧版单文件索引不存在而直接将 PATCH_COUNT 设为 0。

PATCHES_DIR="$LIB_TARGET/.printing-press-patches"
PATCHES_LEGACY="$LIB_TARGET/.printing-press-patches.json"
if [[ -n "$LIB_PATH" ]]; then
  # 若存在则拉取旧版格式文件，但不要把 404 当作不存在任何补丁的证据。
  # 当前库条目可能仅包含下方的单补丁目录。
  tmp=$(mktemp)
  if gh api -H "Accept: application/vnd.github.v3.raw" \
       "repos/mvanhorn/printing-press-library/contents/$LIB_PATH/.printing-press-patches.json" \
       > "$tmp" 2>/dev/null; then
    mv "$tmp" "$PATCHES_LEGACY"
  else
    rm -f "$tmp"
  fi

  # 独立拉取当前的目录格式。这是当 `.printing-press-patches.json` 不存在时的必要兜底方案。
  listing=$(gh api "repos/mvanhorn/printing-press-library/contents/$LIB_PATH/.printing-press-patches" 2>/dev/null || true)
  if jq -e 'type == "array"' <<<"$listing" >/dev/null 2>&1; then
    mkdir -p "$PATCHES_DIR"
    jq -r '.[] | select(.name | endswith(".json")) | "\(.name)\t\(.download_url)"' <<<"$listing" \
    | while IFS=$'\t' read -r name url; do
        tmp=$(mktemp)
        if curl -fsSL "$url" -o "$tmp" 2>/dev/null; then
          mv "$tmp" "$PATCHES_DIR/$name"   # 原子操作：传输中断绝不会残留损坏的 JSON
        else
          rm -f "$tmp"
        fi
      done
  fi
fi

# 从本地第一个非空的格式中统计数量；PATCHES_SOURCE 即为阶段 D 读取的目标。
if [[ -d "$PATCHES_DIR" ]]; then
  DIR_PATCH_COUNT=$(find "$PATCHES_DIR" -maxdepth 1 -name '*.json' ! -name '_meta.json' | wc -l | tr -d ' ')
else
  DIR_PATCH_COUNT=0
fi
if [[ "$DIR_PATCH_COUNT" != "0" ]]; then
  PATCH_COUNT="$DIR_PATCH_COUNT"
  PATCHES_SOURCE="$PATCHES_DIR"
elif [[ -f "$PATCHES_LEGACY" ]]; then
  PATCH_COUNT=$(jq '(.patches // []) | length' "$PATCHES_LEGACY" 2>/dev/null || echo 0)
  PATCHES_SOURCE="$PATCHES_LEGACY"
else
  PATCH_COUNT=0
  PATCHES_SOURCE="$PATCHES_DIR"
fi

如果 $PATCH_COUNT == 0 或不存在索引（早于补丁契约的旧版 CLI），跳过本小节剩余内容——在交接提示中不包含补丁块。

如果 $PATCH_COUNT > 0，在继续前向用户打印一行提示：

公共库中的 <api> 包含 $PATCH_COUNT 个针对此前 printed CLI 的历史补丁记录。这些补丁将作为关注清单（仅供参考，非强行重新应用指令）带入简报，避免新代码无意中退化掉已在线验证的修复。

保存 $PATCHES_SOURCE 与 $PATCH_COUNT 供阶段 D 使用。

阶段 C — 调研时效性建议

从最近的历史 research.json 中提取 researched_at，并从 .printing-press.json 中提取 printing_press_version 与 generated_at：

RESEARCHED_AT=$(jq -r '.researched_at // empty' "$MAN_RESEARCH" 2>/dev/null)
PRESS_VERSION=$(jq -r '.printing_press_version // empty' "$LIB_TARGET/.printing-press.json" 2>/dev/null)
GENERATED_AT=$(jq -r '.generated_at // empty' "$LIB_TARGET/.printing-press.json" 2>/dev/null)

使用 python3 计算调研的日历天数，以确保跨 macOS/Linux 的可移植性，并兼容 generated_at 带有的微秒级精度（BSD date -f 不支持小数秒；而 python3 在所有支持的平台上均内置）：

AGE_DAYS=$(python3 -c "
from datetime import datetime, timezone
ts = '$RESEARCHED_AT'.replace('Z', '+00:00')
print(int((datetime.now(timezone.utc) - datetime.fromisoformat(ts)).total_seconds() // 86400))
" 2>/dev/null)

向用户展示这两个信号——调研时间天数和旧版机器版本。时间阈值属于经验参考，而非硬性门槛：

30 天以内 → 建议复用，通常很安全
30–120 天 → 建议复用；用户应在重新印制原因中说明已知的 API 变动，以便子 Agent 的 Pass 2 捕获
超过 120 天 → 建议重新调研

不要单凭天数预测 API 变动——只需展示信号并由用户选择覆盖。/printing-press 阶段 0 中的二进制版本升级重新校验逻辑会独立处理机器版本差异，无需在此重复。

使用 AskUserQuestion 发起询问：

复用历史调研 — 保留历史简报；子 Agent 针对当前用户画像重新评估历史创新特性的得分
重新调研 — 从头重新运行阶段 1；子 Agent 仍会把历史创新特性作为 Pass 2(d) 的输入导入
先让我预览 — 显示历史简报的标题和创新特性列表，然后再在选项 1 和 2 之间重新询问

阶段 D — 交接至 `/printing-press`

在调用 /printing-press 之前，利用此前 CLI 的记分卡（scorecard）和清单（manifest）来决定重新印制是否需要提供首次印制时无法利用的 OpenAPI 规范补充增强（spec enrichment）。重新印制比全新印制拥有更充分的证据：它知晓哪些结构维度薄弱、是由哪个 Printing Press 版本生成的旧版 CLI，以及用户填写的重新生成原因。

查找此前原稿运行产生的最新记分卡 JSON。若不存在记分卡产物，则针对本地库副本运行一次全新的结构记分卡检测：

SCORECARD_SOURCE=$(ls -1t "$PRESS_MANUSCRIPTS/$API_SLUG"/*/proofs/scorecard.json 2>/dev/null | head -1)
SCORECARD_JSON=""
if [[ -n "$SCORECARD_SOURCE" ]]; then
  SCORECARD_JSON=$(cat "$SCORECARD_SOURCE" 2>/dev/null || true)
elif [[ -d "$LIB_TARGET" ]]; then
  SCORECARD_SOURCE=$(mktemp)
  if "$PRINTING_PRESS_BIN" scorecard --dir "$LIB_TARGET" --json > "$SCORECARD_SOURCE" 2>/dev/null; then
    SCORECARD_JSON=$(cat "$SCORECARD_SOURCE" 2>/dev/null || true)
  fi
  rm -f "$SCORECARD_SOURCE"
  SCORECARD_SOURCE=""
fi

如果 SCORECARD_JSON 为空，则在不提示规范补全增强的情况下继续，并说明重新印制将在没有历史评分证据的情况下推进。切勿单凭重新印制原因凭空捏造 Prompt。

当 `S

你可能还喜欢

benchmark-methodology

240Kwriting-content

Use after competitive-platform-analysis has produced a tiered competitor set. Scores each competitor across nine weighted dimensions (positioning, voice, visual craft, offer packaging, evidence, enterprise-readiness, thought leadership, pricing, client's strategic tension) with explicit 1–5 rubrics and a tension-plot. Precedes competitive-report-structure.