core-workflow

コアワークフローパターン

包括的な開発ワークフローのリファレンスです。詳細なパターンを確認する際に、必要に応じて読み込みます。

ルールへのクイックリンク： スタック別およびタスク種別のチェックリストは ~/.claude/rules/ を参照してください。

---

セッションプロトコル

開始時のチェックリスト

# 1. Sync first: default branch from origin/HEAD, fetch + prune, fast-forward
git fetch --prune origin && git merge --ff-only "$(git symbolic-ref --short refs/remotes/origin/HEAD)"

# 2. Get context
git log -3

# 3. Check for existing work
ls tasks/*.md 2>/dev/null || echo "No active tasks"

日付を推測せず、環境コンテキストから今日の日付を取得してください。

終了時のチェックリスト

# 1. Verify by review: re-read the request and the whole diff (no test/type-check ladder)

# 2. Archive completed work
mv tasks/<completed-task>.md .archive/completed-tasks/

# 3. Commit with comprehensive message
git add -A  # all pending changes, any session's
git commit  # See Git Conventions below
git push    # or the configured push runner, when one is defined; never force

自分で起動した開発サーバーはすべて停止してください： lsof -ti:PORT | xargs kill（または Windows での同等のコマンド）

---

作業規模の見積もり

複雑さ	ワークフロー
簡単な修正（30 分未満）	直接実行
単一の機能（30 分〜2 時間）	タスクファイル + TodoWrite
複数フェーズの機能（数日）	プランモードを使い、その後 tasks/ にフェーズごとにタスクファイルを 1 つ作成
新規プロジェクト／アプリ	/init-project を実行し、その後、最初のフェーズでプランモードを使用

---

Git の規約

コミットの種類

feat | fix | refactor | perf | test | docs | chore

コミットメッセージの形式

type: Short summary (50 chars max)

## What Changed
- File X: Added feature Y
- File Z: Updated config for A

## Why
- User requested feature Y
- Config A needed update

## Verification
- Diff reviewed against the request, callers, and edge cases

タスク完了時の自動コミット

タスクまたは計画が完了したら、依頼されていなくても自動的にコミットしてください。

コミット前のチェック

# 1. Check this is a user-owned repo (not external)
git remote get-url origin | grep -q "travisjneuman" && echo "OK: User repo"

# 2. Check push is not blocked
git remote get-url --push origin | grep -q "no_push" && echo "SKIP: External repo"

ルール

条件	対応
ユーザー自身のリポジトリ	自動コミット + プッシュ
外部リポジトリ（no_push）	コミット禁止 - 読み取り専用
サブモジュール（外部）	コミット禁止 - 読み取り専用
未コミットのシークレットを検出	ブロック - ユーザーに警告

---

セキュリティチェックリスト

フロントエンド

• textContent を使用し、innerHTML は使用しない
• 外部データには unknown 型を使用する
• API キーを公開しない
• 外部リクエストには HTTPS を使用する
• 入力をサニタイズする

バックエンド

• すべてのエンドポイントで入力を検証する
• 保護されたルートに認証ガードを設ける
• パラメーター化クエリーを使用する（生の SQL は使用しない）
• シークレットを環境変数に保存する

---

パフォーマンス目標

指標	目標
初期バンドル	<100KB（gzip 圧縮後）
ページ読み込み	<1s
インタラクションのレイテンシー	<100ms
Lighthouse のパフォーマンス	95+
アクセシビリティ	WCAG AA 以上

---

アクセシビリティ（WCAG AA）

• セマンティックな HTML 構造
• 意味のある画像に代替テキストを設定する
• キーボード操作（Tab、Enter、Escape）
• フォーカスインジケーターを表示する
• 色のコントラスト比 >= 4.5:1
• インタラクティブ要素に ARIA ラベルを設定する
• タッチターゲット >= 44x44px

---

思考フレームワーク

複雑な選択には、構造化された意思決定を活用してください。

意思決定の種類	フレームワーク
長期的な影響	/consider:10-10-10
根本原因の分析	/consider:5-whys
優先順位付け	/consider:eisenhower-matrix
イノベーション	/consider:first-principles
リスクの特定	/consider:inversion
簡素化	/consider:occams-razor
集中	/consider:one-thing
トレードオフ	/consider:opportunity-cost
最適化	/consider:pareto
結果	/consider:second-order

---

デバッグプロトコル

一般的な問題

1. 問題を再現する
2. 関連するコードを読む
3. 根本原因を特定する
4. 根本原因を修正する
5. 差分と、修正によってすでに生成された出力を確認して検証する

断続的／複雑な問題

体系的なアプローチには debug-systematic スキルを使用してください。

---

構築と購入の方針

機能は自分たちで構築し、ユーティリティは活用します。

• 構築: すべての機能ロジック、ビジネスルール、UI/UX、データモデル
• 活用: 低レベルの抽象化（D3、Recharts、Lexical、Konva）
• 基準: 機能は自分たちで所有し、ライブラリには複雑さの処理を任せます

ライセンス要件

• 必須: MIT、Apache 2.0、BSD
• 使用禁止: GPL、AGPL（商用化を妨げます）

---

コミュニケーション基準

進捗報告

スパムのように頻繁に報告するのではなく、概要を伝えます。

「認証ミドルウェアを追加し（3 ファイル）、新しいフィールドでユーザーストアを更新しました。現在、ログインフローを確認しています。」

質問するタイミング

次の場合にのみ AskUserQuestion を使用します。

• 不可欠な選択肢が提示されておらず、結果に影響する場合
• 指示が矛盾しており、優先順位を判断できない場合
• 破壊的な操作や外部の対象を正確に特定できない場合
• 依頼者から与えられていない権限が必要な場合

それ以外の場合は、妥当な選択肢を選んで進め、前提を明示します。

率直さの原則

• 感情より論理を優先します
• 同意より正確さを優先します
• 社交辞令より率直なフィードバックを優先します
• 同意より最善の解決策を優先します

---

コンテキストの整理

トークン使用量の削減

• 長いログより、簡潔で要点を押さえた要約を使います
• 大きなドキュメントをデフォルトで @ 埋め込みしないでください
• パスと参照するタイミングを記載します
• 作業単位の完了後に /clear を使います

委任パターン

状況	アクション
コンテキストが 100k トークン超	プロンプトを作成し、新しいコンテキストに委任します
中程度の複雑さ	/create-prompt → /run-prompt
複数段階の機能	/create-meta-prompt
上限に近づいている	引き継ぎドキュメントの作成に /whats-next を使います

---

クイックリファレンス

よく使うコマンド

npm run dev          # Start dev server
npm run build        # Production build
npm run test         # Run tests (only when the user asks)
npm run type-check   # TypeScript check (only when the user asks)

ファイル命名規則

種類	規則	例
コンポーネント	PascalCase	UserCard.tsx
フック	use 接頭辞	useAuth.ts
ユーティリティ	camelCase	utils.ts
テスト	.test.ts	utils.test.ts

---

リソース

公式

• Claude Code ドキュメント
• Anthropic のベストプラクティス

コミュニティ

• awesome-claude-code
• awesome-claude-md

---

関連項目

• ~/.claude/docs/reference/checklists/ - タスクの種類別チェックリスト
• ~/.claude/docs/reference/stacks/ - 技術スタック別のパターン
• ~/.claude/docs/reference/tooling/ - ツール設定ガイド
• ~/.claude/skills/MASTER_INDEX.md - スキルの全カタログ
• ~/.claude/agents/README.md - エージェントディレクトリ