kanban

Codex 互換性に関する注意：

• Codex では、リポジトリのスキルを $skill-name で呼び出してください。このミラー版では、旧式の Claude の /skill-name 参照を書き換えています。
• タスクトラッカーの必須事項：ワークフローまたはスキルの手順を実行する前に、すべての手順のタスク追跡を作成または更新し、進捗に応じて同期してください。
• ユーザーへの質問を求めるプロンプトがある場合は、Codex でユーザーに直接質問してください。
• Claude 固有のモード切り替え指示がある場合は無視してください。
• 厳格な実行規約：ユーザーがスキルを明示的に呼び出した場合は、記載どおりにそのスキルのプロトコルを実行してください。
• サブエージェントの使用許可：スキルがユーザーによって呼び出された場合、または AI によって検出された場合に、そのプロトコルでサブエージェントが必要とされるなら、そのスキルの有効化によって、該当タスクに必要な spawn_agent サブエージェントの使用が許可されます。
• ユーザーが逸脱を事前に明示的に承認しない限り、プロトコルの手順を省略、並べ替え、統合しないでください。
• ワークフローのスキルでは、列挙された子スキルの手順をそれぞれ明示的に実行し、手順ごとの根拠を報告してください。
• 必須の手順やツールをこの環境で実行できない場合は、適応を試みる前に停止し、ユーザーに確認してください。

Codex でのプロジェクト参照資料の読み込み（フックなし）

Codex では、Claude のフックによるドキュメントの自動挿入は行われません。 コーディング、計画、デバッグ、テスト、レビューを行う際は、以下の案内に従ってプロジェクトのドキュメントを明示的に開いてください。

必ず読む資料：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフローおよびテストの設定）
• docs/project-reference/docs-index-reference.md（docs/project-reference/* カタログ全体への案内）
• docs/project-reference/lessons.md（常に適用されるガードレールとアンチパターン）

状況に応じて読む資料：

• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド／UI／スタイル／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様／テストケースの計画、または TC マッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査作業：code-review-rules.md および変更ファイルに応じた上記のドメイン資料

すべてのドキュメントをむやみに読まないでください。まず docs-index-reference.md を確認し、タスクに関連するファイルだけを開いてください。

簡単な概要

目標： 進捗追跡、フェーズのステータス、タイムラインの可視化機能を備えた、視覚的なプランダッシュボードを起動します。

ワークフロー：

1. 呼び出し — $kanban または $kanban plans/ で表示し、$kanban --stop で停止します
2. サーバーの起動 — server.cjs を run_in_background: true を指定したバックグラウンドタスクとして実行します
3. URL の報告 — JSON 出力を解析し、完全な URL（クエリ文字列を含む）をユーザーに表示します

主なルール：

• サーバーは必ず Claude Code のバックグラウンドタスクとして実行します（/tasks で確認できます）
• URL のパスとクエリ文字列を含む完全な URL を表示します。ホストとポートだけに省略しないでください
• 早期終了を防ぐため、timeout: 300000 を設定します

懐疑的な姿勢を保ち、批判的思考と順序立てた思考を適用してください。すべての主張には追跡可能な証拠と確信度（Idea は 80% 超）が必要です。

進捗追跡とタイムラインの可視化機能を備えたプランダッシュボードです。

使い方

• $kanban - ./plans ディレクトリのダッシュボードを表示します
• $kanban plans/ - 指定したディレクトリのダッシュボードを表示します
• $kanban --stop - 実行中のサーバーを停止します

機能

• 進捗バー付きのプランカード
• フェーズのステータス内訳（完了、進行中、保留中）
• タイムライン／ガントチャートの可視化
• アクティビティヒートマップ
• Issue およびブランチへのリンク

実行

重要： Bash ツールを使い、run_in_background: true を指定してサーバーを Claude Code のバックグラウンドタスクとして実行してください。これにより、サーバーが /tasks に表示され、KillShell で管理できるようになります。

このスクリプトが現在のワークスペース内にあるか、$HOME/.claude/skills/plans-kanban ディレクトリ内にあるかを確認してください。

• 現在のワークスペース内にある場合：$SKILL_DIR_PATH = ./.claude/skills/plans-kanban/
• ホームディレクトリ内にある場合：$SKILL_DIR_PATH = $HOME/.claude/skills/plans-kanban/

サーバーを停止する

--stop フラグが指定されている場合：

node $SKILL_DIR_PATH/scripts/server.cjs --stop

サーバーを起動する

それ以外の場合は、--foreground フラグを指定して、かんばんサーバーを CC のバックグラウンドタスクとして実行します（CC のタスク管理でプロセスが維持されます）。

# Determine plans directory
INPUT_DIR="{{dir}}"
PLANS_DIR="${INPUT_DIR:-./plans}"

# Start kanban dashboard (loopback-only by design)
node $SKILL_DIR_PATH/scripts/server.cjs \
  --dir "$PLANS_DIR" \
  --host localhost \
  --open \
  --foreground

重要： Bash ツールを呼び出す際は：

• run_in_background: true を設定して、CC のバックグラウンドタスクとして実行します
• timeout: 300000（5 分）を設定して、予期せず終了するのを防ぎます
• JSON 出力を解析し、URL をユーザーに伝えます

Bash ツール呼び出しの例：

{
    "command": "node .claude/skills/plans-kanban/scripts/server.cjs --dir \"./plans\" --host localhost --open --foreground",
    "run_in_background": true,
    "timeout": 300000,
    "description": "Start kanban server in background"
}

起動後、JSON 出力（例：{"success":true,"url":"http://localhost:3500/kanban?dir=..."}）を解析し、次の情報を伝えます：

• ブラウザーでアクセスするためのローカル URL
• サーバーが CC のバックグラウンドタスクとして実行中であること（/tasks で確認できます）

重要： 必ずパスとクエリ文字列を含む完全な URL を表示してください。host:port だけに省略しないでください。直接アクセスするには完全な URL が必要です。

今後の計画

$kanban コマンドは、VibeKanban に着想を得た AI エージェントのオーケストレーション機能へと進化します。

フェーズ 1（現在 - MVP）

• ✅ 進捗を追跡できるタスクボード
• ✅ プラン／タスクの視覚的な表示
• ✅ クリックしてプランの詳細を表示

フェーズ 2（Worktree との統合）

• タスクを作成 → git worktree を生成
• タスクにエージェントを割り当て
• worktree ごとにエージェントの進捗を追跡

フェーズ 3（完全なオーケストレーション）

• エージェントの並列実行を監視
• コードの差分／レビューインターフェース
• PR 作成ワークフロー
• エージェント出力のストリーミング
• コンフリクト検出

進捗を追跡：https://github.com/claudekit/claudekit-engineer/issues/189

---

[IMPORTANT] 作業を始める前に、タスク管理を使ってすべての作業を小さなタスクに分割してください。各ファイルを読むタスクも含めます。これにより、長いファイルによるコンテキストの喪失を防げます。簡単なタスクの場合、AI は必ず「省略してよいか」をユーザーに尋ねてください。

AI のミスを防ぐ — あらゆるタスクで避けるべき失敗パターン：

削除する前に、後続の参照先を確認してください。 コンポーネントを削除すると、ドキュメントやコードに古い情報が連鎖的に残ります。削除前に、参照しているファイルをすべて洗い出してください。 AI が生成した内容を実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で実在を確認してください。 編集後は依存関係をすべてたどってください。 定義を変更しても、それを元に導出される後続の変数や利用箇所を見落とすことがあります。必ず依存関係を最後までたどってください。 正しさを検証するときは、すべてのコードパスをたどってください。 コードの存在を確認しても、実行されることの確認にはなりません。正常系だけでなく、早期終了、エラー分岐、条件によるスキップも必ずたどってください。 デバッグ時は、修正前に「どちらの責任か」を確認してください。 バグの原因が呼び出し元（データの誤り）にあるのか、呼び出し先（処理の誤り）にあるのかをたどってください。責任のあるレイヤーを修正し、症状が現れている箇所にパッチを当てないでください。 既存の値は意図されたものと考え、変更する前に理由を確認してください。 定数、上限値、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受ける出力をすべて検証してください。 複数のスタックに関わる変更では、すべての出力を検証する必要があります。チェックがひとつ成功しても、すべて成功したことにはなりません。 全体を優先するデバッグ — 目についた箇所に飛びつかないでください。 障害を調査するときは、まず前提条件をすべて列挙してください（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）。コードレイヤーに関する仮説を立てる前に、それぞれを証拠と照らして確認してください。 変更は最小限に — 差分テストを適用してください。 バグ修正では、変更する各行がそのバグに直接関係している必要があります。隣接するコードのスタイル変更や改善はしないでください。機能強化タスクでは、改善を実装し、その内容を明示してください。 曖昧さを表面化させてからコーディングしてください — 黙って選択しないでください。 依頼に複数の解釈がある場合は、それぞれの工数見積もりを示して質問してください。全レコード対象、ファイルベース、または複雑な方法を前提にしないでください。

批判的思考の姿勢 — 批判的思考と順序立てた思考を適用してください。行動に移す前に、すべての主張について根拠をたどって確認し、確信度が 80% を超えている必要があります。 幻覚防止： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実さは率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信が、あらゆる幻覚の根本原因です。

必ず注意して批判的思考を適用してください。すべての主張について根拠をたどって確認し、行動に移すには確信度が 80% を超えている必要があります。幻覚防止：推測を事実として提示しないでください。

必ず注意してAI のミス防止策を適用してください。全体を優先してデバッグし、責任のあるレイヤーを修正し、コーディング前に曖昧さを表面化させ、コンテキスト圧縮後にファイルを読み直してください。

締めくくりの注意事項

重要・必ず注意 作業を始める前に、タスク管理を使って作業を小さな todo タスクに分割してください 重要・必ず注意 新しいコードを作成する前に、コードベース内で類似パターンを 3 件以上検索してください 重要・必ず注意 すべての主張について、根拠となる file:line を示してください（行動に移すには確信度が 80% を超えている必要があります） 重要・必ず注意 作業の品質を確認するため、最後にレビュー用の todo タスクを追加してください

[TASK-PLANNING] 行動に移る前に、タスクの範囲を分析し、タスク管理を使って小さな todo タスクとサブタスクに体系的に分割してください。

フックレス・プロンプト・プロトコルのミラー（自動同期）

ソース：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・厳守。いかなる理由があっても省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとします。プロジェクト固有の規約は、docs/project-config.json と docs/project-reference/ から確認してください。shared/sdd-artifact-contract.md の共通 AI-SDD を適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されているプロジェクト参照ドキュメントを開いてください。この共通コンテキストとローカルドキュメントを利用できる場合は、サポートされている任意の AI ツールで実行できます。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップ構成のほうが適しているかどうかも評価します
3. 確認（必須形式）： ユーザーが明示的にワークフロー／スキルを呼び出し、かつローカルプロトコルで明示的な呼び出しを確認とみなす場合を除き、次の構成でユーザーに直接質問します
   • 質問："どのワークフローを有効にしますか？"
   • 選択肢 1："[最適なワークフロー] を有効にする（推奨）"
   • 選択肢 2："カスタムワークフローを有効にする：[step1 → step2 → ...]"（1 行で理由を記載）
4. 有効化（確認後）： 標準ワークフローの場合は $workflow-start <workflowId> を呼び出し、カスタムステップの場合は手動で順に実行します
5. タスクを作成： ワークフローのすべてのステップについてタスク追跡を行います
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用します。すべての主張には追跡可能な根拠が必要であり、確信度が 80% を超える場合にのみ行動します。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信こそが、あらゆるハルシネーションの根本原因です。 AI の注意力に関する原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、指示の順守が長いコンテキストウィンドウでも保たれるよう、最も重要な 3 つのルールを冒頭と末尾の両方に配置します。 目標主導の実行： まず成功基準を定義し、検証が完了するまで繰り返し、観察可能なチェックに合格した場合にのみ終了します。 テストで意図を検証： テストでは、現在の挙動をなぞるだけでなく、ビジネスルール／不変条件を保護し、保護対象の意図が損なわれた場合に失敗するようにします。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分割し、タスク追跡を行います。最後のタスクとして「AI のミスと教訓を分析する」を追加します。

教訓の抽出 — 症状への対処ではなく、根本原因のみ：

1. 症状ではなく、失敗モード（推論／前提の誤り）を特定します。「誤った列挙値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
2. 一般性を検証します。この失敗モードは 3 つ以上のコンテキスト／コードベースに当てはまりますか？ 当てはまらない場合は、抽象度を 1 段階上げます。
3. 普遍的なルールとして記述します。プロジェクト固有の名前／パス／クラスを除き、どのコードベースでも役立つ内容にします。
4. 統合します。同じ失敗モードを共有する複数のミスは、1 つの教訓にまとめます。
5. 再発判定：「この注意書きがなければ、今後のセッションで再発するか？」いいえの場合は $learn を省略します。
6. 自動修正判定：「$code-review／$code-simplifier／$security／$lint で検出できるか？」はいの場合は、代わりにレビュー用スキルを改善します。
7. 両方の判定を通過した場合： $learn を実行するようユーザーに依頼します。 [TASK-PLANNING] [MANDATORY] ワークフローまたはスキルのステップを実行する前に、予定されているすべてのステップのタスク追跡を作成／更新し、各ステップの開始時と完了時に内容を同期してください。