learn-codebase

コードベースの規約を確認する

現在のプロジェクトをスキャンし、さまざまなツールのエージェント向け指示ファイルを探して、規約を要約します。必要に応じて、見つかったスキルを .pi/settings.json に登録します。

ステップ 1：規約ファイルをスキャンする

プロジェクトのルートで、次のファイルとディレクトリを検索します。

# Agent instruction files (root-level)
for f in CLAUDE.md AGENTS.md COPILOT.md .cursorrules .clinerules; do
  [ -f "$f" ] && echo "FOUND: $f"
done

# Agent config directories
for d in .claude .cursor .github .pi; do
  [ -d "$d" ] && echo "FOUND DIR: $d/"
done

# Deeper convention files
[ -f ".github/copilot-instructions.md" ] && echo "FOUND: .github/copilot-instructions.md"

# Claude Code rules, skills, and commands
[ -d ".claude/rules" ] && echo "FOUND: .claude/rules/"
[ -d ".claude/skills" ] && echo "FOUND: .claude/skills/"
[ -d ".claude/commands" ] && echo "FOUND: .claude/commands/"

# Cursor rules
[ -d ".cursor/rules" ] && echo "FOUND: .cursor/rules/"

# Pi project skills
[ -d ".pi/skills" ] && echo "FOUND: .pi/skills/"

ステップ 2：読み取り、要約する

見つかった各ファイルを読み、主要な規約を抽出します。

1. ルートの指示ファイル（CLAUDE.md、AGENTS.md、.cursorrules など）— すべて読みます。これらがプロジェクトの主なルールです。
2. ルールディレクトリ（.claude/rules/、.cursor/rules/）— 各ルールファイルを読みます。
3. コマンド（.claude/commands/）— 各コマンドファイルを読みます。これらは Claude Code の再利用可能なプロンプトワークフローです（例：PR 作成、リリーススクリプト、レビュー用チェックリスト）。各コマンドの内容を要約します。
4. スキルディレクトリ（.claude/skills/、.cursor/skills/）— 利用可能なスキルを一覧表示し、その説明を読みます。
5. 設定ファイル（.claude/settings.json）— 権限と設定を記録します。

次の形式で、構造化した要約をユーザーに提示します。

## Project Conventions Summary

### Build & Run
- Package manager: [npm/pnpm/yarn/bun]
- Dev command: [command]
- Test command: [command]

### Code Style
- [Key style rules]

### Architecture
- [Key patterns, structure]

### Agent-Specific Rules
- [Any rules targeted at AI agents]

### Available Commands (from .claude/commands/)
- [command-name] — [what it does]

### Available Skills (from other tools)
- [List skills found in .claude/skills, .cursor/skills]

実用的な情報を優先します。定型文や明らかな規約は省略します。

ステップ 3：外部スキルを登録する

.claude/skills/ やその他のスキルディレクトリがある場合は、pi でも使えるように、スキルを .pi/settings.json に登録することを提案します。

{
  "skills": ["../.claude/skills"]
}

見つかったスキルのパスを使って .pi/settings.json を作成または更新するか、ユーザーに確認します。スキルが実際に見つかった場合にのみ行います。

ステップ 4：覚えておくべきことを確認する

要約の後、このプロジェクトで作業する際に覚えておくべき重要事項を 3～5 個強調します。これらは、忘れると違反しやすい規約です。たとえば、次のようなものです。

• 特定のコミットメッセージ形式
• 必須の共同著者行
• 必須のテストパターン
• 禁止パターンやアンチパターン
• パッケージマネージャーの指定（pnpm が必須の場合に npm を使わない）

ステップ 5：セキュリティと問題点をざっと確認する

コードベースをスキャンし、怪しい、不審、または危険に見えるものを確認します。完全な監査ではなく、ユーザーが把握しておくべき点を見つけるための簡易チェックです。仮定上の問題ではなく、実際の懸念事項を指摘します。

スキャン対象

次のチェックを実行し、不審な点があれば報告します。

ハードコードされたシークレットと認証情報

# Look for hardcoded secrets, API keys, tokens, passwords
rg -i --hidden -g '!{.git,node_modules,dist,build,.next,vendor,*.lock}' \
  '(api[_-]?key|secret|token|password|credential|auth)\s*[:=]\s*["\x27][^"\x27]{8,}' \
  --type-not binary -l 2>/dev/null | head -20

# .env files committed to repo (should be gitignored)
git ls-files --cached | grep -iE '\.env($|\.)' 2>/dev/null

安全でないコードパターン

# eval(), exec(), dangerouslySetInnerHTML, innerHTML assignments, shell injection vectors
rg --hidden -g '!{.git,node_modules,dist,build,.next,vendor,*.lock}' \
  -e '\beval\s*\(' -e '\bexec\s*\(' -e 'dangerouslySetInnerHTML' \
  -e '\.innerHTML\s*=' -e 'child_process' -e '\$\(.*\$\{' \
  --type-not binary -l 2>/dev/null | head -20

# Unparameterized SQL (string concatenation in queries)
rg --hidden -g '!{.git,node_modules,dist,build,.next,vendor,*.lock}' \
  -e 'query\s*\(\s*[`"'"'"'].*\$\{' -e 'execute\s*\(\s*[`"'"'"'].*\+' \
  --type-not binary -l 2>/dev/null | head -20

不審な依存関係

# Check for install/postinstall scripts in dependencies (supply chain risk)
[ -f package.json ] && cat package.json | grep -E '"(pre|post)install"' 2>/dev/null

# Look for wildcard or git dependencies (unpinned)
[ -f package.json ] && rg '"[*]"|"git[+:]|"github:' package.json 2>/dev/null

# Very outdated lock file vs package.json mismatch
[ -f package-lock.json ] && [ package.json -nt package-lock.json ] && echo "WARN: package.json newer than lockfile"
[ -f pnpm-lock.yaml ] && [ package.json -nt pnpm-lock.yaml ] && echo "WARN: package.json newer than lockfile"

過度に寛容な設定

# CORS wildcards, disabled security headers, permissive CSP
rg --hidden -g '!{.git,node_modules,dist,build,.next,vendor,*.lock}' \
  -e "origin:\s*['\"]?\*" -e 'Access-Control-Allow-Origin.*\*' \
  -e "cors.*true" -e 'unsafe-inline' -e 'unsafe-eval' \
  --type-not binary -l 2>/dev/null | head -10

# Disabled TLS verification, insecure flags
rg --hidden -g '!{.git,node_modules,dist,build,.next,vendor,*.lock}' \
  -e 'NODE_TLS_REJECT_UNAUTHORIZED.*0' -e 'rejectUnauthorized.*false' \
  -e 'verify.*false' -e 'insecure.*true' \
  --type-not binary -l 2>/dev/null | head -10

ファイル権限と機密ファイル

# Private keys, certificates, or database files in repo
git ls-files --cached 2>/dev/null | grep -iE '\.(pem|key|p12|pfx|jks|keystore|sqlite|db)$' | head -10

# Check .gitignore exists and covers basics
if [ -f .gitignore ]; then
  for pattern in '.env' 'node_modules' '.DS_Store'; do
    grep -q "$pattern" .gitignore || echo "WARN: .gitignore missing $pattern"
  done
else
  echo "WARN: No .gitignore file found"
fi

報告方法

重要度タグを付けて、専用のセクションに調査結果を提示します。率直に伝え、問題をぼかさない一方で、誤検知も避けます。

## 🚩 Security & Code Smell Findings

### [P0] Hardcoded API key in src/config.ts
Line 42 has a Stripe secret key directly in source code.
This should be in an environment variable, not committed.

### [P1] .env file tracked by git
`.env.production` is committed and contains database credentials.
Add to `.gitignore` and rotate the exposed credentials.

### [P2] eval() usage in src/utils/parser.ts
Used to parse user-supplied expressions. Consider a safe parser
like `JSON.parse()` or a sandboxed evaluator instead.

### ✅ Nothing Concerning
[If sweep is clean, say so explicitly — don't manufacture findings.]

重要度の目安（レビュー基準と同じ）：

• [P0] — 現実に危険な状態です。シークレットの漏えいや SQL インジェクション、RCE の攻撃経路などが該当します。すぐに修正してください。
• [P1] — 実質的なリスクがあります。誰かに実害が及ぶ可能性があり、早めに修正すべきです。
• [P2] — 把握しておく価値があります。緊急ではありませんが、ユーザーに知らせるべきです。

次のものは指摘しないでください。

• テスト目的で eval／exec を使っているテストファイル
• 開発専用であることが明らかな安全でない設定（開発サーバーの localhost CORS など）
• このコードベースで具体的な悪用経路のない、理論上の問題
• 既知の CVE がない、単に古いだけの依存関係