plans-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. サーバーを起動 — CLI オプションでプランディレクトリを指定します
2. ダッシュボードを閲覧 — 進捗バー、フェーズのステータス、アクティビティヒートマップを備えたプランカードを表示します
3. プランを確認 — ガント形式のタイムライン、優先度インジケーター、イシュー／ブランチへのリンクを表示します

主なルール：

• 初回使用前に npm install が必要です（gray-matter）
• すぐにアクセスするには $kanban スラッシュコマンドを使用してください
• plan.md ファイルを含むディレクトリをスキャンします

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

plans-kanban

進捗追跡とタイムライン表示機能を備えたプランダッシュボードサーバーです。

⚠️ インストールが必要です

このスキルには npm の依存関係が必要です。 以下のいずれかを実行してください。

# Option 1: Install via ClaudeKit CLI (recommended)
ck init  # Runs install.sh which handles all skills

# Option 2: Manual installation
cd .claude/skills/plans-kanban
npm install

依存関係： gray-matter

インストールしないと、プランの詳細を表示した際に Error 500 が発生します。

目的

以下の機能を備えた、プランディレクトリ閲覧用のビジュアルダッシュボードです。

• プランごとの進捗追跡
• タイムライン／ガント形式の表示
• フェーズのステータスインジケーター
• アクティビティヒートマップ

クイックスタート

# View plans dashboard
node .claude/skills/plans-kanban/scripts/server.cjs \
  --dir ./plans \
  --open

# Explicit local host
node .claude/skills/plans-kanban/scripts/server.cjs \
  --dir ./plans \
  --host localhost \
  --open

# Background mode
node .claude/skills/plans-kanban/scripts/server.cjs \
  --dir ./plans \
  --background

# Stop all running servers
node .claude/skills/plans-kanban/scripts/server.cjs --stop

スラッシュコマンド

すぐにアクセスするには $kanban を使用してください。

$kanban plans/           # View plans dashboard
$kanban --stop           # Stop kanban server

機能

ダッシュボード表示

• 進捗バー付きのプランカード
• フェーズのステータス内訳（完了、進行中、保留）
• 最終更新日時
• イシューおよびブランチへのリンク
• 優先度インジケーター

タイムライン表示

• プランのガント形式タイムライン
• 期間の追跡
• アクティビティヒートマップ

デザイン

• ダークモード対応のグラスモーフィズム UI
• レスポンシブなグリッドレイアウト
• 温かみのあるアクセントカラー

CLI オプション

オプション	説明	デフォルト
--dir <path>	プランディレクトリ	-
--port <number>	サーバーポート	3500
--host <addr>	バインドするホスト	localhost
--open	ブラウザーを自動で開く	false
--background	バックグラウンドで実行	false
--stop	すべてのサーバーを停止	-

アーキテクチャ

scripts/
├── server.cjs               # Main entry point
└── lib/
    ├── port-finder.cjs      # Port allocation (3500-3550)
    ├── process-mgr.cjs      # PID management
    ├── http-server.cjs      # HTTP routing
    ├── plan-parser.cjs      # Plan.md parsing
    ├── plan-scanner.cjs     # Directory scanning
    ├── plan-metadata-extractor.cjs  # Rich metadata
    └── dashboard-renderer.cjs       # HTML generation

assets/
├── dashboard-template.html  # Dashboard HTML template
├── dashboard.css           # Styles
└── dashboard.js            # Client interactivity

HTTP ルート

ルート	説明
/ or $kanban	ダッシュボード表示
$kanban?dir=<path>	特定のディレクトリのダッシュボード
/api/plans	プランデータの JSON API
/api/plans?dir=<path>	特定のディレクトリの JSON API
/assets/*	静的アセット
/file/*	ローカルファイルの提供

ローカルアクセス

ローカルファイルの提供によるネットワークへの公開を明示的に承認していない場合は、localhost で起動してください。

{
    "success": true,
    "url": "http://localhost:3500/kanban?dir=...",
    "port": 3500
}

プランの構造

ダッシュボードは、plan.md ファイルを含むディレクトリを検索します。

plans/
├── 251215-feature-a/
│   ├── plan.md              # Required - parsed for phases
│   ├── phase-01-setup.md
│   └── phase-02-impl.md
├── 251214-feature-b/
│   └── plan.md
└── templates/               # Excluded by default

トラブルシューティング

ポートが使用中：サーバーは 3500-3550 の範囲でポート番号を自動的に増やします。

プランが見つからない：ディレクトリに plan.md ファイルが含まれていることを確認してください。

リモートアクセスが拒否される：このダッシュボードはローカルでの使用を想定しています。ネットワークへの公開を明示的に承諾している場合を除き、--host localhost を維持してください。

PID ファイル：/tmp/plans-kanban-*.pid にあります。

---

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

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

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

MUST ATTENTION 批判的思考を適用してください。すべての主張には追跡可能な証拠が必要です。行動に移すのは確信度が 80% を超えてからです。幻覚を防ぐため、推測を事実として提示してはいけません。

MUST ATTENTION AI のミス防止を適用してください。全体を優先したデバッグ、責任のあるレイヤーでの修正、実装前の曖昧さの明確化、コンパクション後のファイル再読を徹底してください。

締めくくりの注意事項

IMPORTANT MUST ATTENTION 作業を始める前に、タスク追跡を使って作業を小さな TODO タスクに分割してください。 IMPORTANT MUST ATTENTION 新しいコードを作成する前に、コードベースで類似パターンを 3 件以上検索してください。 IMPORTANT MUST ATTENTION すべての主張に file:line の証拠を示してください（行動に移すのは確信度が 80% を超えてから）。 IMPORTANT MUST ATTENTION 作業の品質を検証するため、最後のレビュー用 TODO タスクを追加してください。 IMPORTANT MUST ATTENTION プランのフロントマターに Test Specifications セクションと story_points を含めてください。

[TASK-PLANNING] 行動を起こす前に、タスクの範囲を分析し、タスク追跡を使って小さな TODO タスクとサブタスクに体系的に分割してください。

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

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

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

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとします。プロジェクト固有の規約は docs/project-config.json と docs/project-reference/ から確認してください。共有 AI-SDD は shared/sdd-artifact-contract.md を適用します。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つ以上のコンテキスト／コードベースに当てはまりますか？ 当てはまらない場合は、抽象度を一段階上げます。
3. 普遍的なルールとして記述します。プロジェクト固有の名前／パス／クラスを取り除きます。どのコードベースでも役立つ内容にしてください。
4. 統合します。同じ失敗モードに起因する複数の間違いは、1つの教訓にまとめます。
5. 再発ゲート：「このリマインダーがなければ、今後のセッションで再発しますか？」— いいえの場合は $learn をスキップします。
6. 自動修正ゲート：「$code-review／$code-simplifier／$security／$lint で検出できますか？」— はいの場合は、代わりにレビューのスキルを改善します。
7. 両方のゲートを通過した場合は、ユーザーに $learn の実行を依頼します。 [TASK-PLANNING] [MANDATORY] ワークフローまたはスキルのステップを実行する前に、計画したすべてのステップについてタスク追跡を作成／更新し、各ステップの開始時と完了時に同期を保ってください。