printing-press-reprint

/printing-press-reprint

現在のマシンで、既存の印刷済み CLI を再生成します。ユーザーは CLI 名と、任意で再印刷する理由を指定します。このスキルは、以前の CLI がローカルに存在することを確認し、以前の調査を再利用するかやり直すかを提案したうえで、現在のマシンに照らして過去の機能を調整するために novel-features サブエージェントが必要とするコンテキストを引き継いで /printing-press を実行します。各機能は理由を明示して維持、再構成、または削除し、理由を示さずに変更することはありません。

/printing-press-reprint notion
/printing-press-reprint cal.com  the new MCP intent surface landed and the prior CLI ships endpoint-mirror only
/printing-press-reprint allrecipes

実行するタイミング

• Printing Press が大幅にアップグレードされ（新しい MCP サーフェス、新しい認証モード、新しいトランスポート、評価基準の変更など）、手作業での調整よりもこの CLI の改善効果が大きい場合。
• 公開済み CLI に、再印刷で解消できる既知の全体的な不足がある場合。
• 以前の新機能をそのまま引き継ぐのではなく、現在のマシンと現在のペルソナに照らして再評価したい場合。

単発のコード品質修正には、/printing-press-polish を優先してください。調査をやり直したり、原稿を再構築したりすることはありません。

セットアップ

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

# Mid-pipeline callers may pass printing_press_bin: <abs-path> in the args
# bundle. Prefer it so reprint keeps using the parent skill's preflight-selected
# binary instead of re-resolving through 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 スラッグ（notion）、ブランド名（cal.com）、以前の <api>-pp-cli 形式、またはそれに近い名前を指定できます。

一致したレジストリエントリから、API_SLUG（.name から取得）と LIB_PATH（.path から取得。例：library/productivity/cal-com）を記録します。フェーズ B では公開パッチの取得に $LIB_PATH を使用します。「present | absent」の未公開行では、$LIB_PATH は空のままにします。その場合、フェーズ B の取得処理はすぐに終了します。

次に、ローカルに存在するものを確認し、両方の来歴マニフェストの run_id と generated_at を読み取って、公開ライブラリと照合します。

ローカル	公開レジストリ	対応
なし	なし	停止 — 再印刷するものはありません。新規に印刷するには /printing-press <api> を提案します
なし	あり	/printing-press-import <api> を実行し、その後続行します
あり	なし	続行 — 未公開のローカル CLI です。インポートはスキップします
あり、run_id が同じ	あり	インポートせずに続行します
あり、公開側の generated_at が新しい	あり	AskUserQuestion でインポートを提案し、ユーザーに判断してもらいます
あり、ローカル側の generated_at が新しい	あり	停止 — ローカルに未公開の作業があります。先に公開するか破棄するようユーザーに伝えます

/printing-press-import を実行するときは、バックアップ、上書き、ビルド検証、モジュールパスの書き換えを任せます。続行する前に、問題なく完了するまで待ちます。

フェーズ B — 調整可能な過去のコンテキストを確認

執筆パイプラインが把握すべき 2 つの成果物を特定します。調査結果は novel-features のパス 2(d) に使われ、パッチは /printing-press-amend で記録された公開後の手動修正（仕様からは分からなかった、実環境で発見された 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 の来歴情報が導入される前に構築されています。サブエージェントはこれを初回の印刷として扱い、パス 2(d) の再印刷時の調整処理は実行されません。読み取るものがないためです。状況を説明し、次のように尋ねます。

公開済みの <api> は、research.json の来歴情報が導入される前に構築されました。 これがないと、novel-features サブエージェントは初回の印刷として扱うため、照合するものがありません。劣化した状態で再印刷を続けますか（実質的にはバイナリ名を維持した新規印刷ですか）？

ユーザーが拒否した場合は終了します。続行する場合は、この状態を記録し、引き継ぎプロンプトに劣化した状態での再印刷であることを記載します。

パッチの検出

到達可能であれば公開先からローカルのパッチインデックスを更新し、その後ローカルから読み取ることで、下流の参照が永続的になります。公開コピーに対して修正が適用されていても再生成がトリガーされていない可能性があるため、run_id が一致していてもローカルコピーが遅れることがあります。この手順はそのギャップを埋めます。

インデックスは 2 つの形式のいずれかで提供されます。パッチごとのディレクトリ .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
  # Fetch the legacy shape if present, but do not treat a 404 as proof that no
  # patches exist. Current library entries may carry only the per-patch
  # directory below.
  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

  # Fetch the current directory shape independently. This is the required
  # fallback when `.printing-press-patches.json` is absent.
  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"   # atomic: a dropped transfer never leaves corrupt JSON
        else
          rm -f "$tmp"
        fi
      done
  fi
fi

# Count from the first non-empty shape locally; PATCHES_SOURCE is what Phase D reads.
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> には、以前に出力された CLI に対して $PATCH_COUNT 件の記録されたパッチがあります。これらをウォッチリストとしてブリーフに引き継いでください。再生成と公開検証は記録を読み取り、記録されたファイルまたは宣言された呼び出しサイト / pp:patch マーカーが失われている場合はフェイルクローズします — インデックスを、カスタマイズがまだ出荷されているという主張として扱わないでください。

Phase D のために $PATCHES_SOURCE と $PATCH_COUNT を保持します。

Phase 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)

macOS/Linux 間で移植性を保ち、generated_at が持つマイクロ秒精度を許容するよう、python3 でリサーチの暦上の経過日数を計算します（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 変更があれば言及し、サブエージェントの Pass 2 がそれを拾えるようにすべきです
• 120 日超 → やり直しを推奨します

経過日数だけから API の変更を予測しないでください — シグナルを説明し、ユーザーが上書きできるようにします。/printing-press の Phase 0 のバイナリバージョンバンプ再検証はマシンデルタ側を独立して処理します。ここで重複させないでください。

AskUserQuestion で尋ねます。

1. 以前のリサーチを再利用 — 以前のブリーフを維持します。サブエージェントは以前の新規機能を現在のペルソナに対して再スコアリングします
2. リサーチをやり直す — /printing-press の Phase 1 をゼロから再実行します。サブエージェントは依然として以前の新規機能を Pass 2(d) の入力として取り込みます
3. 先に見せて — 以前のブリーフの見出し + 新規機能リストを表示し、その後オプション 1 と 2 の間で再度尋ねます

Phase D — /printing-press への引き継ぎ

/printing-press を呼び出す前に、以前の CLI のスコアカードとマニフェストを使用して、再印刷が最初の印刷では使えなかったはずのスペック拡充を提供すべきかどうかを判断します。再印刷は新規印刷よりも優れた証拠を持ちます。どの構造的次元が弱かったか、どの 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 が空の場合、拡充のプロンプトなしで続行し、以前のスコア証拠なしで再印刷を進めていることを伝えます。再印刷の理由だけからプロンプトをでっち上げないでください。

SCORECARD_JSON が利用可能な場合、生成前のスペック編集に対応する次元のみを検査し、すでに 10/10 とスコアリングされている次元はスキップします。

• 以下の mcp_remote_transport、mcp_token_efficiency、mcp_tool_design、および mcp_surface_strategy が 10 未満の場合、/printing-press フェーズ 2 のセクション Pre-Generation MCP Enrichment によって引き上げることができます。例:
  • remote transport が 10 未満の場合: 再生成の前に mcp.transport: [stdio, http] または 同等の OpenAPI x-mcp.transport を提案します。
  • token efficiency、tool design、または surface strategy が 10 未満の場合: /printing-press フェーズ 2 の MCP surface decision を提案します。これには明確なマルチステップ ワークフロー向けの intents や、大規模な surface 向けの Cloudflare パターンが含まれます。
• auth_protocol が 10 未満の場合、またはエコシステムに正規の環境変数があるのに CLI が slug 由来の環境変数を使用したという以前のマニフェストの証拠がある場合は、 Pre-Generation Auth Enrichment によって引き上げることができます。正規の auth.env_vars または OpenAPI x-auth-env-vars のガイダンスをスペックに 取り込むことを提案します。
• data_pipeline_integrity が 10 未満の場合は、以前の CLI または調査によって 同期可能なリソースが示されている場合にのみ、エンリッチメントの機会となります。その場合は、 スコアだけをローカルストアが存在すべき証拠として扱うのではなく、ハンドオフを関連する /printing-press フェーズ 2 の sync/cache enrichment decision に向けてください。

ハンドオフの前に、具体的な機会ごとに AskUserQuestion を使用してください。質問は 自由形式の書き直しではなく、スコアカードの証拠と名前付きの正規セクションを中心に組み立ててください。例:

以前のスコアカードでは mcp_remote_transport: 5/10 が示されています。再生成の前に MCP transport のエンリッチメントを提案します。/printing-press フェーズ 2 の Pre-Generation MCP Enrichment を信頼できる情報源として使用しますか？

選択肢:

1. ハンドオフにエンリッチメントを適用する - 選択したスペック編集を /printing-press のプロンプトに含めて、フェーズ 2 が生成前にスペックを更新できるようにします。
2. この再プリントではスキップする - この次元についてスペックを変更しないままにします。
3. まずスコアの証拠を表示する - 関連するスコアカードの行を出力してから、 選択肢 1 と 2 の間で再度質問します。

エンリッチメントを自動適用しないでください。以前のスコアカードにすでに mcp_remote_transport: 10/10 がある場合は、冗長な MCP transport の質問をしないでください。 ユーザーがいずれかの機会を承諾した場合は、## Reprint Spec Enrichment セクションを /printing-press ハンドオフに追加してください。簡潔に保ってください: 弱い 次元、承諾されたエンリッチメント、および実行する正規の /printing-press フェーズ 2 セクションを記載します。正規のエンリッチメントのテキストをここで重複させないでください。

/printing-press <api> を呼び出し、これらをプロンプトにバンドルしてください:

1. ヘッダー行: ユーザーがすでに再生成を選択したことを述べ、 /printing-press フェーズ 0 の library-check が「Generate a fresh CLI」を選択し、 fresh-vs-improve を再プロンプトしないようにします。

2. 調査モード: フェーズ C から (reuse または redo)。/printing-press フェーズ 0 の既存の reuse ロジックがこれを使用します。

3. ユーザーの自由形式の再プリント理由: 逐語的に User context ブロックに記載します。これはブリーフに ## User Vision として伝播し、 新規機能サブエージェントへの Pass 2(e) 入力になります — 「MCP サポートを改善したい」に 対する適切なフックとして、ブレインストーミングをそれに応じてバイアスさせます。

4. Reprint spec enrichment — 上記のスコアカード駆動のプロンプトで 承諾された機会が見つかった場合にのみ。## Reprint Spec Enrichment 見出しの下に 含めます。

5. Prior patches — フェーズ B で $PATCH_COUNT > 0 が見つかった場合にのみ。 ## Prior Patches 見出しの下に含めます。

   このセクションの冒頭に、次のフレーミング文を逐語的に記載してください:

   The following were hand-fixed against the prior printed CLI. They are informational — the machine may have absorbed some of these upstream since the patch was applied. Stay aware so the fresh code doesn't silently regress the underlying API truth or architectural pattern, but do not treat as a re-apply checklist. 次に、$PATCHES_SOURCE のパッチを要約します。各項目は、単なる summary ではなく、各パッチの reason と validated_outcome から読み取れる、パッチが示す本質（API の事実、アーキテクチャパターン、複数ファイルにまたがる規約）を先に述べてください。 パッチのメタデータ（id、files）は補足情報として括弧内に記載してもかまいませんが、見出しにはしないでください。

   パッチ数に応じてセクションの規模を調整してください。

   • 1–3 個のパッチ：パッチごとに短い段落を 1 つ記述し、本質を先に述べてから、どのように実装されたかを説明します。以下の例にならってください。

     Linear の個人用 API キーは、Bearer プレフィックスを付けずに Authorization: lin_api_… としてそのまま指定します。OAuth トークンには Authorization: Bearer <token> を使用します。従来の CLI には auth set-token しかなく、デフォルトで Bearer 形式になっていたため、公開後に config.go の生ヘッダーパスと auth set-api-key を追加するパッチが適用されました （linear-auth-api-key-vs-oauth-token）。

   • 4–9 個のパッチ：パッチごとに、本質を先に述べる同じ形式の簡潔な文を 1 つ記述します。
   • 10 個以上のパッチ：認証、ページネーション、クエリのエンコード、MCP の追加、ヘルパー、分類器、エラーエンベロープなど、カテゴリごとにテーマ別に要約します。各テーマについて、根拠として 2～3 個のパッチ id を挙げながら、2～3 文で説明してください。すべての項目を本文中に列挙しないでください。

   セクションの最後に、関連領域で作業する際に後続のエージェントが特定のパッチを詳しく確認できるよう、参照先を示してください。

   パッチの詳細：$PATCHES_SOURCE 内のパッチごとのファイルを参照してください（各 <id>.json は単独で完結するパッチです。従来の単一配列形式の .printing-press-patches.json にも同じフィールドが patches[] の下に格納されています）。

別個の「これは再生成です」というマーカーは渡さないでください。novel-features サブエージェントはすべての生成時に無条件で実行され、独自の検出用スニペットを使って過去の調査を見つけます。Phase A でインポートされたパスは、サブエージェントが確認するパスと完全に一致します。Pass 2(d) は、既存の research.json がある場合に毎回実行されます。

ライブラリの保持に関する契約は、このスキルではなく、/printing-press Phase 5.6（「ライブラリへの昇格」）が担います。既存のライブラリのマニフェストで novel_features > 0 となっている場合（または internal/cli/、internal/syncer/、internal/store/ に手書きのファイルがある場合）、Phase 5.6 はまず "$PRINTING_PRESS_BIN" regen-merge "$LIB_TARGET" --fresh "$CLI_WORK_DIR" --json をドライランし、新しいツリーで以前の新規成果が再構築されたかどうかを判定します。新しいツリーに以前の新規成果がすべて含まれていれば、Phase 5.6 はスワップパスを使い、生成ファイルのバージョン差分を想定内の上書きとして扱います。そうでなければ、再生成後も固有の手書き成果が保持されるよう、昇格を regen-merge --apply 経由で行います。また、本物の NOVEL-COLLISION や参照先の欠落がある場合は、確認のために処理を停止します。これは、/printing-press Phase 3 の**手編集は regen-merge 可能でなければなりません。**セクションにある regen-merge を優先する指針に沿ったものです。今後その Phase の編集で振り分けルールが変わる場合は、同じ PR でこの段落も更新してください。このルールを実行する主要なエントリーポイントは再生成スキルです。

引き継ぎの前に、再生成したマニフェストファイルと、追跡対象の公開済みツリーを比較してください。$LIB_TARGET/manifest.json または $LIB_TARGET/tools-manifest.json が存在する場合は、それぞれを $CLI_WORK_DIR 内の新しく生成された対応ファイルと比較し、差分があれば引き継ぎプロンプトに示してください。差分は自動的に上書きを承認するものではなく、調整が必要なチェックポイントとして扱ってください。追跡対象の手編集を保持するか、仕様や調査入力に反映するか、再生成された値を意図的に採用するかは、担当者が判断します。追跡対象のマニフェストフィールド、ツールのメタデータ、説明が失われる場合、黙って処理を続けないでください。 帰属の管理も引き続き /printing-press が担います。引き継ぎでは同じ API スラッグに対して生成を実行し、生成／昇格の処理では既存のライブラリマニフェストの永続的な creator を維持したうえで、異なる場合は再配布者を contributors[] に追加する必要があります。creator、contributors[]、README の署名、SKILL の author:、または NOTICE を手作業で編集して修正しないでください。最新の Printing Press バイナリで再実行し、マニフェスト優先のガードによって作業ツリーと昇格後のツリーが一貫して書き換えられるようにしてください。

引き継ぎ後

以降は printing-press のフローが進めます。その作業を要約せず、進行中のフェーズをユーザーに確認できるようにしてください。

/printing-press がサブエージェントの事前チェックによる HALT で停止した場合（brief に具体的な Users／Top Workflows の内容がない場合）、再利用された以前の brief はサブエージェントが必須とするスキーマより古いものです。フェーズ C で Redo research を選択して再実行することを推奨してください。