go

⛔ ITP ワークフロー — 停止してお読みください

思い込みで行動しないでください。このファイルを最初に読んでください。

これは構造化されたワークフローコマンドです。フェーズを順番に実行してください。

今すぐ行う最初で唯一のアクション：以下の TodoWrite を実行してください。

自己進化型スキル：このスキルは使用を通じて改善されます。指示に誤りがある、パラメーターがずれている、または回避策が必要になった場合は、先送りせず、このファイルをすぐに修正してください。実際に再現可能な問題がある場合にのみ更新してください。

⛔ 必須の最初のアクション：計画を考慮した Todo の統合

最初のアクションでは、既存の Todo を保持したうえで統合した TodoWrite を実行しなければなりません。

禁止事項：

• ❌ 計画ファイルや以前のセッションにある既存の Todo を上書きする
• ❌ ~/.claude/plans/*.md にある計画ファイルを無視する
• ❌ 既存の Todo を確認せずに、自分で Todo を作成する
• ❌ Step 0 を完了せずにコーディングに進む
• ❌ TodoWrite の前にブランチを作成する

完全な統合手順（Steps 0.1-0.5）と TodoWrite のテンプレートに従ってください：Todo 統合戦略

TodoWrite の完了後、以下の Preflight セクションに進んでください。

---

クイックリファレンス

呼び出されるスキル

スキル	フェーズ	目的
implement-plan-preflight	Preflight	ADR + Design Spec の作成
impl-standards	Phase 1	エラー処理、定数
adr-code-traceability	Phase 1	コードから ADR への参照
code-hardcode-audit	Phase 1	リリース前の検証
semantic-release	Phase 3	バージョンのタグ付けとリリース
pypi-doppler	Phase 3	PyPI への公開（該当する場合）

ファイルの場所

成果物	パス	備考
ADR	/docs/adr/$ADR_ID.md	永続的
Design Spec	/docs/design/$ADR_ID/spec.md	永続的、Preflight 後の SSoT
Global Plan	~/.claude/plans/<adj-verb-noun>.md	一時的 - 新しい計画で置き換えられます

Spec YAML Frontmatter

---
adr: YYYY-MM-DD-slug # Links to ADR (programmatic)
source: ~/.claude/plans/<adj-verb-noun>.md # Global plan (EPHEMERAL)
implementation-status: in_progress # in_progress | blocked | completed | abandoned
phase: preflight # preflight | phase-1 | phase-2 | phase-3
last-updated: YYYY-MM-DD
---

注：source フィールドは追跡可能性のためにグローバル計画のファイル名を保持しますが、新しい計画が作成された後は、そのファイルが存在しない場合があります。

ADR ID の形式

ADR_ID="$(date +%Y-%m-%d)-<slug>"

例：2025-12-01-clickhouse-aws-ohlcv-ingestion

フォルダー構成

/docs/
  adr/
    YYYY-MM-DD-slug.md          # ADR file
  design/
    YYYY-MM-DD-slug/            # Design folder (1:1 with ADR)
      spec.md                   # Active implementation spec (SSoT)

命名規則：ADR と Design フォルダーの両方に、同一の YYYY-MM-DD-slug を使用してください。

---

重要：必須ワークフローの実行

このワークフローは必須です。どのフェーズも省略しないでください。

タスクの複雑さにかかわらず、すべてのフェーズを順番に実行しなければなりません。

1. Step 0：TodoWrite の初期化（最初のアクション - 例外なし）
2. Preflight：ADR + Design Spec の作成
3. Phase 1：spec.md に従った実装
4. Phase 2：フォーマットとプッシュ
5. Phase 3：リリース（main/master ブランチの場合）

禁止されている行為：

• ❌ 「これは簡単だから、ワークフローを省略しよう」と判断する
• ❌ TodoWrite を実行せずに直接実装へ進む
• ❌ 「ドキュメントの修正」や「小さな変更」を理由に ADR／Design Spec を省略する
• ❌ フェーズを回避するために独自の判断を下す

タスクがこのワークフローには簡単すぎると思われる場合：立ち止まり、/itp:go を使わずに進めてよいかユーザーに確認してください。黙って省略してはいけません。

引数

$ARGUMENTS を解析します。

引数	短縮形	説明	デフォルト
slug	-	ADR ID に使用する機能名（例：clickhouse-aws-ohlcv-ingestion）	Global Plan のコンテキストから導出
--branch	-b	main/master から {type}/{adr-id} ブランチを作成	現在のブランチで作業
--continue	-c	進行中の作業を続行します。任意で決定事項を指定できます	最後の「推奨される次のステップ」
--release	-r	Phase 3 で semantic-release を有効にします（リリースには main で必須）	Phase 3 のリリースをスキップ
--publish	-p	Phase 3 で PyPI への公開を有効にします（公開には main で必須）	Phase 3 の公開をスキップ

詳しい使用例、ブランチの種類、slug の導出ルール：Arguments Reference

---

ワークフローのプレビュー

開始前にブランチを検出し、想定されるワークフローを表示します。 ブランチ検出スクリプトと条件表については、Workflow Preview を参照してください。

---

ステップ 0：Todo リストの初期化（完了済み）

冒頭の STOP 指示に従った場合、このステップは完了しています。

TodoWrite のテンプレートは Todo Merge Strategy にあります。まだ実行していない場合は、STOP して冒頭に戻ってください。

各 todo は、着手前に in_progress、完了時に completed にしてください。

事前確認ゲート（必須）

すべての Preflight todo が completed になるまで、Phase 1 に進むことはできません。

「Phase 1: 実装タスクの実行」を開始する前に：

1. すべての Preflight: todo が completed になっていることを確認します
2. /docs/adr/$ADR_ID.md に ADR ファイルが存在することを確認します
3. /docs/design/$ADR_ID/spec.md に設計仕様書が存在することを確認します

Preflight 項目が未完了の場合は、STOP して先に完了させてください。先に進んではいけません。

---

Preflight：成果物のセットアップ

必須の Skill ツール呼び出し：implement-plan-preflight -- 先に進む前に、今すぐ有効にしてください。

このスキルでは、ADR と設計仕様書の作成方法（MADR 4.0 の frontmatter、perspectives の分類、検証）について詳しく説明します。

Preflight の手順（スキルを使用）

1. P.0：最初に機能ブランチを作成（-b フラグが指定されている場合）-- いかなるファイル操作よりも前に必ず実行してください
2. P.1：必須の Skill ツール呼び出し：implement-plan-preflight -- ADR／仕様書の手順を確認するため、今すぐ有効にしてください
3. P.2：ADR ファイルを作成 -- パスは Quick Reference を参照してください
4. P.3：設計仕様書を作成 -- パスは Quick Reference を参照してください
5. P.4：チェックポイントを確認

P.0 を最初に行う理由：git checkout -b の前に作成したファイルは main/master に残ります。ADR／仕様書の作成前にブランチを作成しておく必要があります。

Preflight チェックポイント（必須）

STOP。Phase 1 に進む前に成果物が存在することを確認してください。 完全なチェックリストと検証スクリプトについては、Preflight Checkpoint を参照してください。

---

Phase 1：実装

1.1 再開プロトコル

新規開始と続行の両方で使用するエントリーポイントです。 続行の検出、ブランチの確認、同期チェックを含む完全なプロトコルについては、Phase 1 Protocols を参照してください。

1.2 仕様の実装

spec.md の各タスクを実行します。

1. todo リストで現在のタスクを in_progress にします
2. 変更を実装します
3. 正しく動作することを確認します
4. 完了状況を反映するように spec.md を更新します
5. タスクを completed にします
6. 次のタスクに進みます

1.3 エンジニアリング標準

スキルの実行順序（次の順序で順番に呼び出します）：

1. impl-standards -- エラー処理と定数のパターンを最初に適用します
2. adr-code-traceability -- 2番目にコードへ ADR 参照を追加します
3. code-hardcode-audit -- 最終監査を最後に実施します（Phase 2 の前）

必須の Skill ツール呼び出し：impl-standards -- 詳細な標準を確認するため、今すぐ有効化してください。

必須の Skill ツール呼び出し：adr-code-traceability -- コード内の ADR 参照を追加するため、今すぐ有効化してください。

必須の Skill ツール呼び出し：code-hardcode-audit -- リリース前に今すぐ有効化してください。

1.4 意思決定の記録

実装でユーザーの判断が必要な場合は、意思決定の記録プロトコルに従ってください：意思決定の記録

1.5 ステータス同期プロトコル

Spec の implementation-status に基づいて ADR の status を更新します。同期表とスクリプトの全文はこちら：ステータス同期プロトコル

Phase 1 の成功基準

• spec.md に従って実装が完了している
• すべての成果物が同期されている（ADR <-> spec <-> todo <-> code）
• 新しいファイルのヘッダーに ADR: {adr-id} が含まれている
• 自明でない変更にインラインの ADR: コメントがある

---

Phase 2：フォーマットとプッシュ

Prettier によるフォーマット、git push、ブラウザーでの表示を実行します。スクリプトの全文はこちら：Phase 2 スクリプト

Phase 2 の成功基準

• Markdown が Prettier でフォーマットされている
• GitHub にプッシュされている
• ファイルをブラウザーで表示できる

---

Phase 3：リリースと公開（main で -r または -p フラグが必要）

Phase 3 の実行には明示的なフラグが必要です。自動では実行されません。

エントリーゲートのロジックとブランチ固有のメッセージについては、Phase 3 ゲートロジックを参照してください。

3.1 リリース前の確認

リリース前に、次の項目を確認します。

• 設計仕様の成功基準項目がすべてチェック済みである
• 設計仕様のステータス値が更新されている（例：Accepted、Implemented）
• ADR と spec.md が最終実装と同期している
• バージョンフィールドで semantic-release のパターンが使用されている（動的なバージョン管理は不可）

3.2 セマンティックリリース（-r フラグの場合）

条件：-r または --release フラグが指定された場合にのみ実行します。

必須の Skill ツール呼び出し：semantic-release -- バージョンのタグ付けとリリースのため、今すぐ有効化してください。

• Local Release Workflow に従います（その後削除済み）
• Conventional commits -> tag -> release -> changelog -> push

3.3 PyPI への公開（-p フラグの場合）

条件：-p または --publish フラグが指定された場合にのみ実行します。

パッケージが PyPI にすでに存在する場合に限り：

• 必須の Skill ツール呼び出し：pypi-doppler -- 公開するため、今すぐ有効化してください

3.4 Earthly パイプライン

正規のパイプラインとして Earthly を使用します。ブロッキングせず、可観測性を優先し、GitHub Release の存在を確認し、統計とエラーを記録して、Pushover で通知し、GitHub Actions に組み込みます。

Phase 3 の成功基準

• ADR のステータスが accepted または implemented に更新されている
• semantic-release によるリリースが完了している
• フィーチャーブランチの場合：PR が作成され、Phase 3 はスキップされている

---

トラブルシューティング

問題	原因	解決策
TodoWrite が見つからない	最初の必須手順をスキップした	ファイルの先頭から開始し、TodoWrite を実行する
ADR ファイルが作成されない	プリフライトが未完了	Skill(itp:implement-plan-preflight) を実行する
ブランチが一致しない	間違ったブランチで作業している	git checkout で正しいブランチに切り替える
Phase 3 がスキップされた	main/master ではない	先に main にマージしてから /itp:go -r を実行する
semantic-release が失敗する	GITHUB_TOKEN がない	echo $GITHUB_TOKEN でトークンを確認する
Spec の検証に失敗する	frontmatter フィールドが不足している	クイックリファレンスで必須フィールドを確認する

実行後の振り返り

このスキルの完了後、タスクを終了する前に振り返ります。

0. 現在の場所を確認する。 — 編集前に、この SKILL.md の正式なパスを特定します（このスキル名で Glob を実行します）。すべての修正は、このファイルと同階層の references/ を対象とし、他のドキュメントは決して変更しません。
1. 何が失敗したか。 — 原因となった指示を修正します。再発する可能性がある場合は、アンチパターンとして追加します。
2. 予想以上にうまくいったことは何か。 — 推奨プラクティスにします。その理由も記録します。
3. 何が現状とずれているか。 — 実態に合わなくなったスクリプト、リファレンス、外部依存関係があれば、今すぐ修正します。
4. 記録する。 — すべての変更について、きっかけ、修正内容、根拠を含む進化ログのエントリーを残します。

先送りしないでください。次回の実行では、ここに残した内容が引き継がれます。