カナエを作る #9：CLAUDE.md は写さず、短く書く。最初の Issue は、ルールを置くための Issue

2026年11月01日

前回（#8）で、リポジトリとボードを作りました。今回は、Issue を書く前のもう1つの準備です。

Claude Code が従うルールの CLAUDE.md と、Issue を作るスキルの /issue を用意します。

写さない

CLAUDE.md の元になるものは、すでにあります。ただ、行数を比べると、こうなっていました。

ハコヅミとワダチの CLAUDE.md には、作った機能ごとの細かい決まりが積み重なっています。ログインの処理や、管理画面の作りといった内容です。これらは、まだ何も作っていないカナエには関係がありません。

そこで、丸ごと写さず、今決まっていることだけを書きました。

デプロイや認証の話は、環境構築で決まったときに足します。行数の上限の値も、まだ決めていないので、「環境構築で決める」と書いています。

仕様の細かいところは書かず、原本の Notion の開発メモを指すだけにしました。同じことを2か所に書くと、ずれるからです。

/issue スキルは、ワダチのものを基にしました。ハコヅミのものとの違いは、それぞれのサービスの前提が書かれた数行だけでした。

カナエでは、その部分を外して、カナエのボードとマイルストーンを指すようにしています。下書きを作り、人の確認を受けてから Issue を作る流れは同じです。AC を最終的に決めるのは、人です。

/implement スキルは、ここでは作りません。テストのコマンドもまだないので、環境構築で作ります。

ここで、順番の問題が出ました。

カナエのルールでは、作業は Issue から始め、develop への変更は PR を通します。ところが、そのルールを書いた CLAUDE.md を置く作業も、develop への変更です。

そこで、ルールを置く作業自体を、ルールに沿って進めました。Issue を手で作り、ブランチを切り、PR を出します。

#2 が Issue ではなく PR なのは、GitHub では Issue と PR が同じ番号を使うからです。

CI はまだないので、この PR で動くチェックはありません。中身の確認は、人が読むだけです。

PR をマージして受入も済み、Issue を書く準備が整いました。

次は、いよいよIssue にまとめる工程です。企画の深掘りで決めた機能と、残りの環境構築を Issue にしていきます。