Claude Code初回リポジトリ監査チェックリスト: 編集前20分で迷子を防ぐ

既存コードに入った直後のClaude Codeは、親切すぎる新人のように見えます。READMEを読み、package.jsonを読み、関連ファイルを探してくれますが、どこまで触ってよいかを決めないまま依頼すると、最初の差分から大きくなります。このチェックリストは、最初の編集前にコードベースの地図を作るためのものです。

読者の検索意図は「Claude Codeを既存リポジトリで安全に使いたい」です。だから記事のゴールは、機能を作ることではなく、入口、危険領域、検証コマンド、収益CTAを20分で見える状態にすることです。

関連して読む記事: claude-code-getting-started-complete, claude-code-existing-codebase-map, claude-code-harness-lite-workflow.

なぜ最初にこの型を作るのか

Claude Codeは、作業の境界が明確なときに一番強くなります。よい境界は、読んでよいファイル、編集してよいファイル、実行してはいけない操作、作業を終える証拠を名前で示します。この境界がないと、初心者向けの小さな依頼でも大きな書き換えになり、コンテンツ変更が無料PDF、Gumroad、導入相談の導線を静かに壊すことがあります。

この型は収益作業にも効きます。技術的な証拠と読者側の証拠を同じチェックに入れるからです。ローカルでbuildできても、違う読者を違う商品へ送っているページは未完成です。scope、command、public URL、CTAを残す運用なら、明日も記憶ではなく記録から改善できます。

実務で使うワークフロー

1. README、package.json、ルーティング入口だけを先に読む
2. generated、billing、auth、migrations、.env を保護領域として書き出す
3. 今日触ってよいファイルを3つ以下に絞る
4. build、test、公開URL確認のうち最小の証拠を選ぶ
5. 記事やLPなら無料PDF、Gumroad、導入相談のリンクも監査対象に入れる

場面	安全な進め方	確認方法
Astro記事サイト	新規記事を作る前に content collection、slug、heroImage、CTAコンポーネントを確認します。本文だけでなく記事末尾の有料導線も監査します。	build, diff, URL
React管理画面	ダッシュボードの小さな表示崩れなら、対象コンポーネント、CSS、スクリーンショット検証だけに閉じます。認証や課金には触りません。	screenshot, test
APIリポジトリ	最初はエンドポイントの経路とテストコマンドを読むだけにして、DB migration や秘密情報を編集対象から外します。	log, command, handoff

最初の確認は短くします。監査が作るべきものは巨大なレポートではなく判断です。20分後も判断が曖昧なら、編集を始めるのではなく、追加で読むべき1ファイルを決めます。

そのまま使えるプロンプトとコード

このリポジトリで最初の編集をする前に監査してください。編集はまだしないでください。入口ファイル、危険領域、触ってよいファイル、最小の検証コマンド、公開URLとCTA確認を返してください。

const audit = {
  repo: "customer-portal",
  intent: "first safe Claude Code session",
  scope: ["README.md", "package.json", "src/routes"],
  protected: [".env", "billing/", "migrations/"],
  proof: ["npm.cmd run build", "git diff --stat"],
};

export function readyForFirstEdit(report) {
  return report.scope.length > 0 &&
    report.protected.length > 0 &&
    report.proof.some((command) => command.includes("build"));
}

console.log(readyForFirstEdit(audit));

このコードはわざと小さくしています。運用上の考えを、scopeがあるか、保護領域があるか、少なくとも1つの検証コマンドがあるかという確認可能な形に変えるためです。記事公開、アプリ開発、デバッグ、チーム引き継ぎに合わせて形を変えられます。

3つの実例

Astro記事サイト

新規記事を作る前に content collection、slug、heroImage、CTAコンポーネントを確認します。本文だけでなく記事末尾の有料導線も監査します。

大事なのは証拠です。1つのコマンド、1つの表示ページ、または読者に届いたことを示す1つのメモを残します。

React管理画面

ダッシュボードの小さな表示崩れなら、対象コンポーネント、CSS、スクリーンショット検証だけに閉じます。認証や課金には触りません。

大事なのは証拠です。1つのコマンド、1つの表示ページ、または読者に届いたことを示す1つのメモを残します。

APIリポジトリ

最初はエンドポイントの経路とテストコマンドを読むだけにして、DB migration や秘密情報を編集対象から外します。

大事なのは証拠です。1つのコマンド、1つの表示ページ、または読者に届いたことを示す1つのメモを残します。

よくある失敗例

• 最初から「全部直して」と頼むと、監査と実装が混ざります。
• build が通っても公開URLやCTAが別記事に向いていれば未完了です。
• 保護領域を書かないと、便利な修正が事故に変わります。

もう1つの見落としは多言語のずれです。英語版では正しい商品導線を説明していても、別言語では古いCTAが残ることがあります。だから公開確認では frontmatter の lang だけでなく、h1、本文冒頭、CTAの言語まで見ます。

無料PDF、Gumroad、導入相談へのつなぎ方

基本操作を手元に置きたい場合は 無料チートシート から始めてください。設定、権限、CLAUDE.md、CI/CD まで整えたい読者には Setup Guide が合います。レビュー、デバッグ、リファクタリングの入力を毎回考えている読者には 50 Prompt Templates を勧めます。チーム展開や収益導線まで含む設計が必要なら 導入相談 に進むのが自然です。商品一覧を比較したい場合は products も確認できます。

すべての読者をいきなり有料商品へ送る必要はありません。初心者には摩擦の低いPDFが合います。同じプロンプトを繰り返す中級者はテンプレートに近く、権限、CLAUDE.md、hooks、MCP、CI/CDで止まる読者はSetup Guideに近い。チームや運用設計の相談は導入相談に近いです。

公開前後に見る検証ポイント

この記事では、h1、本文冒頭、heroImage、内部リンク、Gumroadリンク、相談導線が同じ意図でつながるかを確認対象にします。HTTP 200 だけでは完了にせず、読者が次の行動を選べる状態かを見ます。

多言語公開では、日本語、英語、中国語、韓国語、スペイン語、フランス語、ドイツ語、ポルトガル語、ヒンディー語、インドネシア語を別々に確認します。slugが一致しても本文が古い場合があります。モバイル幅のスクリーンショットなら、冒頭本文とCTAを同時に見られるため発見が早くなります。

次に見るべき数字

次に見る数字は、このslugのPDF開始、Gumroadクリック、products訪問、training訪問、検索流入、国別比率、記事からCTAへのクリック率です。PVが増えてもGumroadクリックが増えないなら商品対応を強めます。技術記事から相談訪問が増えるなら、読者は一般チュートリアルではなくワークフロー設計を求めています。公開後の改善では、記事単体の順位だけを見ず、どの段落のあとに読者が商品導線へ進んだかを見ます。無料PDFで止まるなら初心者向けの説明を厚くし、Gumroadで止まるなら商品名ではなく解決できる作業を具体化します。相談ページまで進んで離脱するなら、誰向けの相談か、何を持ち帰れるか、英語商品との関係をさらに明確にします。特に多言語記事では、英語版のGumroad商品が主軸であることを隠さず、読者が英語教材へ進む理由を本文中で説明します。日本語読者には、無料PDFで操作を試し、Setup Guideで設定を固め、必要なら相談で自分の運用に落とすという順番を明示します。この順番があると、広告的な押し売りではなく、次の作業を選ぶ案内になります。最後に、公開後のスクリーンショットで冒頭とCTA付近を見直し、本文の約束とボタンの行き先がずれていないことを確認します。これで記事はPVだけでなく次の行動まで評価できます。