pdlc-skills を自分のプロジェクトで動かすには

目次

前の三回は図面でした。三層がそれぞれ何で、どこに落ち、どう噛み合うか。今回は向きを変えます——その図面を自分のプロジェクトに落とす回です。読み終えたら、導入できて、どのコマンドから始めればいいか分かって、機能を一つ最後まで通せるはずです。途中に飛ばされがちな一手があるので、そこだけ独立して扱います。飛ばすと前回の設計が丸ごと空回りするからです。

理論の部分はだいたい話し終えました。ここからは pdlc-skills が実際のプロジェクトの中でどう回るのかを見ていきます。

多くの人がまず同じ疑問を持ちます。先にテストを揃えるべきか。ドキュメントを先に全部書くのか。二、三年動いていて、コードが積み上がっていて、誰もあまり触りたがらない古いプロジェクトを取り込むとしたら、初日から技術的負債の返済が要るのか。

先に答えを言います。どれも要りません。導入は一行、一分で終わります。

本当に詰まるのは別のところです——導入し終わったあとの「で、次は？」。私が最初のプロジェクトを取り込んだときも、/pdlc- で始まるコマンドが一画面に並んでいるのを眺めたまま、どれを打てばいいのか分からず固まりました。この記事はその「で、次は？」に答えるものです。どのコマンドから始めるのか、そして絶対に飛ばしてはいけないのはどの一手か。

導入：一行のコマンド、二つの置き場所

# グローバル：このマシンの全プロジェクトで使える
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh | bash -s -- --global

# プロジェクト単位：このリポジトリの中だけで効く
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh | bash -s -- --project /path/to/my-project

前の三回で出していたのはずっとグローバルのほうでした。いちばん短く、失敗しにくいからです。ここではどんなときにプロジェクト単位が効くかを書きます。

二つの違いは置き場所だけです。~/.claude/plugins/pdlc/ か、<プロジェクト>/.claude/plugins/pdlc/ か。ただしそこから来る差は実際的です——プロジェクト単位で入れると、バージョンがリポジトリについて回ります。チームの誰かが clone すれば手元と同じバージョンになりますし、複数のプロジェクトを並行して開いていても、一度のグローバル更新で全部が同時に動いてしまうことがありません。

一人、一台、プロジェクトもそう多くない——ならグローバルで十分です。悩む必要はありません。

入ったかどうかは二段階で確認します。

ls ~/.claude/plugins/pdlc/            # グローバルで入れた場合
ls <プロジェクト>/.claude/plugins/pdlc/  # プロジェクト単位で入れた場合

skills/ references/ VERSION あたりが見えていれば大丈夫です。あとは Claude Code で /pdlc- と打って、候補に 38 個のコマンドが並べば導入完了です。

あなたはどの出発点にいるか

38 個が一度に並ぶと確かに気後れしますが、最初に覚えるのは三つだけで十分です。どれを選ぶかは、いま手元に何があるかで決まります。

出発点	最初のコマンド
新規プロジェクト、コードはまだ無い	/pdlc-bootstrap
既存プロジェクト、コードは山ほどある	/pdlc-adopt scan
すでに導入済み、日々の開発	/pdlc-feature

新規プロジェクトは /pdlc-bootstrap です。一行の説明を渡すと、技術スタックを選び、ディレクトリの骨組みとドキュメントの下書きを作ります。「X を作りたい」がまだ着想の段階のときに向いています。

既存プロジェクトが大半の人の状況で、いちばん見てほしい行でもあります。最初のコマンドは /pdlc-adopt scan。そして scan は全工程が読み取り専用です——技術スタック、サービス構成、データベース、既存テストを調べて、導入レポートとヘルスチェックを出すだけで、一バイトも書き換えません。

この設計は機能そのものより語る価値があると思っています。動いている古いコードを AI に触らせるのは、誰だって躊躇します。だから「見る」と「触る」を二つのコマンドに割りました。まず scan でレポートを出し、読んで納得してから /pdlc-adopt init でベースライン文書を生成する。試すコストがゼロになります。

ここだけは飛ばさない：先に「何をもって通ったとするか」を決める

この記事でいちばん重要な節です。

前回、状態ファイルの二つの枠の話をしました。一つ目の枠に入れてよいのは実際にコマンドを走らせて得た終了コードだけで、モデルの自己申告は二つ目の枠に切り離され、停止判定には決して関与しません。

すると疑問が出ます——その「コマンド」はどこから来るのか。

答えが /pdlc-test-setup です。やることは四つ。技術スタックの探索、コマンドが本当に走るかを一つずつ検証、docs/00_standards/test-commands.yml への書き込み、そしてテストディレクトリとローカルフックの用意。

リポジトリはこの一手の位置づけをはっきり書いています。全体の急所は「checks は終了コードしか認めず、モデルの自己申告は絶対に使わない」であり、しかしそこに至るまで、このファイルを立ち上げてくれるものは何も無い。それが無ければ客観化の経路まるごとが空になる、と。

ここには譲れない規律が一つあります。このファイルに書き込むコマンドは、必ず一度は実際に走らせ、終了コードを自分の目で見ていること。推測で書いたものは載せません。理由は、私がいちばん注目に値すると思っている一文です——

「一見正しそうだが走らない」コマンドは、空にしておくより悪い。

空なら、下流はこの段階に判定材料が無いと理解して、素直に空のままにします。走らない偽のコマンドは、各段階に偽の checks を渡し、それでもレポートは緑になります。この理屈には鏡像もあります。最も危険な「自動修復」は、いったん立っていたが壊れたチェックを黙って空にすること——ゲートはその場で緩み、こちらからは見えません。

では飛ばすとどうなるか。走らせるコマンドが無い → 一つ目の枠は規約上どうしても空 → 停止判定に根拠が無い → 「客観的な検証」だと思っていたものが、最初からずっとモデルの自己満足だった、ということになります。前回の設計の土台は、この一手にあります。

ついでに言うと、このファイルは古くなります。スクリプトの改名、ツールの世代交代、サブプロジェクトの増減で実態とずれます。張り付いて見ている必要はありません。下流の段階が「コマンドが走らない」に出くわすと知らせてくれるので、そのときに /pdlc-test-setup --refresh を回せば十分です。

最初の機能を通す

土台ができたら、着手は一言で済みます。

/pdlc-feature ログインに電話番号認証を追加

あとは PRD → 設計 → TDD → 実装 → レビューと進み、各段階で一度止まって引き継ぎます。バグ修正も同じ形で /pdlc-fix、いまどこまで来たかを見たいなら /pdlc-status。

日常はこの三つで足ります。 残りの 35 個は細かく制御したくなったとき——設計の段階だけやり直したい、コードレビューだけ一度かけたい、データベース設計を足したい——に掘りにいくものです。そのとき探せば間に合います。

ディスクに増えるもの、git に入れるべきもの

一周まわると docs/ の下に一式のディレクトリが増えます。要件、設計、テスト、デプロイ、レビューがそれぞれの位置に並び、加えて docs/.pdlc-state/ に機能ごとの JSON が一つずつ入ります。

前者は文書なので、コミットするかは好みで構いません。ただし一つだけ、必ず入れるべきものがあります。

docs/.pdlc-state/ は git にコミットしてください。.gitignore に入れてはいけません。

見た目はキャッシュそのものです。ドット始まりのディレクトリに、機械が読む JSON の束。つい素通りしたくなります。しかしこれはキャッシュではなく、引き継ぎ物です。セッションを変える、マシンを変える、人が変わって引き継ぐ——そのときに「この機能はどこまで進んで、前の段階は通ったのか」を言えるのは、これしかありません。git に入れないのは、セッションを開き直すたびに記憶を失うのと同じですし、チームでは相手からこちらの進捗が見えません。

リポジトリはこれを「プロジェクト納品の監査記録」と位置づけています。監査記録として扱えば、無視しようとは思わなくなります。

既存プロジェクトを取り込むときの二つの規律

古いコードベースから入ってきた場合、単独で知っておく価値のある規律が二つあります。この二つが、そもそも現実的かどうかを決めるからです。

一つ、文書だけを作り、コードには触らない。 取り込みの過程で業務コードは一行も変更せず、ベースライン文書を逆生成するだけです。

二つ、増分で取り込む。 既存コードはまとめて「ベースライン済み」と印を付け、新しい機能だけが完全なフローを通ります。過去の負債を先に返せとは言われません。

効いているのは二つ目です。プロセス系のツールが初日に死ぬのを何度も見てきました。取り込んだ途端に既存の違反が数百件出て、その数字を見た時点で人は諦めます。既存を囲って新規だけ管理する——それがこのフローに二日目を迎えさせる条件です。

使わないほうがいい場面

境界も書いておきます。使い捨てのスクリプト、動かして消すデモ、純粋なドキュメントリポジトリ——そこでは使わないほうがいい。プロセスのコストが回収できません。これは長く生き、引き継がれ、品質に責任を負うプロジェクトのためのものです。

判断は単純です。このプロジェクトを三か月後に開く人がいるか。 いるなら価値があり、いないなら手を出さないほうがいい。

ひと通り、そのままなぞる

ここまでを一枚のリストに畳みます。そのまま実行できます。

1. 入れる：curl … | bash -s -- --global（複数プロジェクトやチーム作業なら --project <パス> に替える）
2. 確かめる：ls ~/.claude/plugins/pdlc/、そして Claude Code で /pdlc- を打って 38 個並ぶか見る
3. 出発点を見極める：新規なら /pdlc-bootstrap、既存なら /pdlc-adopt scan でレポートを読み、納得したら /pdlc-adopt init
4. 土台を立てる：/pdlc-test-setup——ここは飛ばさない。以降の「通ったかどうか」が本物か偽物かを決める一手です
5. 着手する：/pdlc-feature 一行の要件、進捗はいつでも /pdlc-status
6. コミットする：docs/.pdlc-state/ も一緒に入れる

4 だけが「後回しにできそうで、できない」ものです。あとは順番どおりで構いません。

次回：放っておいても自分で進めるのか

導入し、始め、土台を立て、最初の機能を通す——一本の線が終わりました。この記事から一つだけ持ち帰るとしたら、これにしたいと思います。走り出す前に「何をもって通ったとするか」を決めておく。 順序が逆になると、その後の自動化はすべて空回りになります。

次回はこの連載の本命です。導入も済み、動いてもいる。では、見張っていなくても一周ずつ自分で進められるのか。 収束ループの仕組み、契約、そして譲れない四つのガードレールを扱います——口で言い聞かせても Token 消費が止まらず、最後は硬い予算に受け止めてもらった、私自身の失敗も含めて。

---

試してみる：

curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh | bash -s -- --global

リポジトリはこちら：https://github.com/kanfu-panda/pdlc-skills

役に立ったら star をいただけると励みになります ⭐

---

この記事は自分が実際にプロジェクトを取り込んだ順序どおりに書きました。詰まった箇所ほど言葉を足しています。通せたら教えてください。どこかで止まった場合もぜひ教えてください、次の版に反映します。