candid-init

Technical.md と設定ジェネレーター

シニアテクニカルアーキテクトとして、コードベースを徹底的に監査します。Technical.md を作成する際の役割は、次のとおりです。

1. このプロジェクトの具体的なファイルとパスを参照する
2. アーキテクチャ上の決定事項と、その徹底方法を記録する
3. コード内で実際に見つかったパターンを例とともに記録する
4. 現状とベストプラクティスのギャップを特定する

一般的なテンプレートではなく、この特定のコードベースを理解するために何日も費やした人が書いたような内容にしてください。

作業レベル

レベル	所要時間	分析内容	出力
quick	約30秒	Grep/find によるパターン検出	約50行
medium	約1～2分	+ 主要ファイルを5～8個読む	約150行
thorough	約5～10分	+ サブエージェントがすべてのファイルを読む	約500行

デフォルト：thorough

thorough モードでは、5つの並列分析サブエージェント（ステップ6）、続いて5つの並列生成サブエージェント（ステップ9）を実行し、その後に統合します。

---

ワークフロー

ステップ1：既存ファイルの確認（Fail-Fast）

ls .candid/Technical.md .candid/config.json 2>/dev/null

Technical.md が存在する場合は、ユーザーに「上書き」「.new として作成」「キャンセル」のいずれかを尋ねます。 config.json が存在する場合は、ユーザーに「上書き」「既存のものを保持」「キャンセル」のいずれかを尋ねます。

ステップ2：作業レベルの決定

--effort フラグを確認します。デフォルトは thorough です。

ステップ3：フレームワークの検出

cat package.json 2>/dev/null | head -50
ls requirements.txt pyproject.toml go.mod Cargo.toml 2>/dev/null

検出内容	フレームワーク
react/next/vue を含む package.json	React
フロントエンド関連の記述がない package.json	Node.js
requirements.txt または pyproject.toml	Python
go.mod	Go
Cargo.toml	Rust
なし	Minimal

ステップ4：既存のツールの検出

ls .eslintrc* eslint.config.* .prettierrc* biome.json tsconfig.json .flake8 ruff.toml 2>/dev/null

重要： リンターが存在する場合、リンターが適用するルールはすべて省略します。Technical.md では、リンターでは確認できないアーキテクチャ、ドメインルール、パターンに焦点を当てます。

---

ステップ5：コードベースの詳細分析

プロジェクト固有のルールを生成するための中核となる手順です。作業レベルに応じて実行します。

5.1 ディレクトリ構造の分析（全レベル）

# Get full directory tree (3 levels)
find . -type d -maxdepth 3 | grep -v node_modules | grep -v .git | grep -v __pycache__ | grep -v venv | grep -v dist | grep -v build | sort

# Identify key directories
ls -d src/*/ lib/*/ app/*/ packages/*/ 2>/dev/null | head -20

抽出する項目：

• レイヤー構造：controllers/、services/、repositories/、models/ はありますか？
• 機能構造：features/、modules/、ドメインディレクトリはありますか？
• 共有コード：shared/、common/、utils/、lib/ はありますか？

5.2 ファイル命名パターン（全レベル）

# File suffixes
find . -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.js" \) 2>/dev/null | grep -v node_modules | sed 's/.*\///' | grep -oE '\.[a-z]+\.(ts|tsx|js)$' | sort | uniq -c | sort -rn | head -15

# Class/component naming
grep -rhoE "^export (default )?(class|function|const) [A-Z][a-zA-Z]+" --include="*.ts" --include="*.tsx" 2>/dev/null | grep -v node_modules | head -30

5.3 インポートグラフの分析（Medium + Thorough）

これはアーキテクチャルールにとって重要です。

# What imports what - build mental model of dependencies
grep -rh "^import.*from" --include="*.ts" --include="*.tsx" 2>/dev/null | grep -v node_modules | grep -oE "from ['\"][^'\"]+['\"]" | sort | uniq -c | sort -rn | head -30

# For each layer dir (controllers, services, ...), check what it imports — flags layer violations:
grep -rh "^import.*from" src/controllers/ --include="*.ts" 2>/dev/null | grep -v node_modules | head -20

# Check for cross-module imports (feature A importing from feature B)
grep -rh "^import.*from.*features/" --include="*.ts" 2>/dev/null | grep -v node_modules | head -20

# Path aliases in use
grep -rh "from '@/\|from '~/\|from 'src/\|from '#" --include="*.ts" --include="*.tsx" 2>/dev/null | grep -v node_modules | head -10

5.4 アーキテクチャパターンの検出（Thorough のみ）

バレルエクスポート（index.ts の数とサンプル）、依存性注入、ミドルウェア／デコレーターパターン、ドメイン固有ディレクトリを検出します。コマンドは reference/analysis-commands.md にあります。

5.5 エラー処理の分析（Medium + Thorough）

# Custom error classes
grep -rh "class.*Error\|extends Error\|extends.*Error" --include="*.ts" 2>/dev/null | grep -v node_modules | head -15

# Error response patterns
grep -rh "res.status.*json\|throw new\|catch.*error" --include="*.ts" 2>/dev/null | grep -v node_modules | head -20

# Error handling location (where are errors caught?)
grep -rl "try.*catch\|\.catch(" --include="*.ts" 2>/dev/null | grep -v node_modules | head -20

5.6 テストパターン（Medium + Thorough）

# Test file locations
find . -name "*.test.*" -o -name "*.spec.*" -o -name "*_test.*" 2>/dev/null | grep -v node_modules | head -20

# Test organization (colocated vs separate)
ls -d **/__tests__/ **/tests/ test/ tests/ 2>/dev/null | head -10

# Test naming patterns
grep -rh "describe(\|it(\|test(" --include="*.test.*" --include="*.spec.*" 2>/dev/null | grep -v node_modules | head -15

# Mock patterns
grep -rh "jest.mock\|vi.mock\|sinon\|@Mock" --include="*.test.*" --include="*.spec.*" 2>/dev/null | grep -v node_modules | head -10

5.7 API パターン（Medium + Thorough、Node／バックエンドの場合）

ルート定義、バリデーションパターン（zod/yup/joi/デコレーター）、認証ミドルウェアを検出します。コマンドは reference/analysis-commands.md にあります。

5.8 React パターン（Medium + Thorough、React の場合）

カスタムフック、状態管理ライブラリ、コンポーネントパターン（memo/forwardRef/lazy/Suspense）、イベントハンドラーの命名を検出します。コマンドは reference/analysis-commands.md にあります。

5.9 TypeScript の分析（Thorough のみ）

tsconfig の厳格さ、any／as any の使用回数、interface と type のどちらが好まれているかを検出します。コマンドは reference/analysis-commands.md にあります。

---

ステップ6：ファイル分析

ファイルの分析方法は、作業レベルによって異なります。

Medium モード：主要ファイルを5～8個読む

Read ツールを使って、代表的なファイルを調べます。

• エントリーポイント（1～2個）：src/index.ts、app/layout.tsx
• 最も多くインポートされているモジュール（2～3個）：インポート分析の結果から選びます
• 各レイヤーから1ファイルずつ（2～3個）：コントローラー、サービス、リポジトリ

抽出する項目：命名パターン、エラー処理、インポートの整理方法、引用する例。

詳細モード：サブエージェントによる包括的な分析

Explore サブエージェントを 5 つ並列で起動します（Task ツール、subagent_type: "Explore"）。各サブエージェントに正確なプロンプトを指定するには、reference/analysis-prompts.md（このスキルからの相対パス）を読み込んでください。

1. アーキテクチャとインポート
2. 命名とスタイル
3. エラー処理とセキュリティ
4. テストパターン
5. フレームワーク固有（React または Node のバリアント）

各サブエージェントは、ファイル名と行番号の根拠を添えて、ルール案を返します。

サブエージェントの結果の統合

すべてのサブエージェントが完了したら、調査結果を統合します。

1. 各サブエージェントから提案されたルールをすべて収集します
2. 類似するルールを重複排除します（最も根拠の確かなものを残します）
3. 次の基準でルールに優先順位を付けます。
   • パターンに従っているファイルの数（一貫性）
   • セキュリティへの影響
   • アーキテクチャ上の重要性
4. Technical.md に記載する上位 40～60 件のルールを選びます
5. カテゴリ別（アーキテクチャ、命名、エラー処理など）に整理します

---

ステップ 7：アーキテクチャ分析（詳細モードのみ）

Technical.md を有用にするアーキテクチャルールを作成します。

7.1 レイヤー境界の分析

ディレクトリ構造とインポート分析に基づいて、次を特定します。

Layer Structure Detected:
├── src/controllers/  → HTTP layer (should only import services)
├── src/services/     → Business logic (can import repos, not controllers)
├── src/repositories/ → Data access (can import models, not services)
└── src/models/       → Data models (no internal imports)

次のようなルールを生成します。

• "src/controllers/ 内のコントローラーは、src/repositories/ から直接インポートしてはいけません。サービスを経由してください"
• "src/services/ 内のサービスは、src/controllers/ からインポートしてはいけません"

7.2 モジュール境界の分析

機能ベースの構造（例：src/features/auth/、src/features/billing/、src/shared/）が検出された場合は、同様にモジュール間のルールを生成します。例：「機能モジュール間で直接インポートしてはいけません。横断的な関心事には src/shared/ を使用してください。」

7.3 違反の検出

コードベースで実際の違反を探します。

# Example: Find files in controllers/ that import from repositories/
grep -rl "from.*repository\|from.*repositories" src/controllers/ 2>/dev/null

違反が見つかった場合は、記録します。

• 「アーキテクチャ違反が見つかりました：src/controllers/UserController.ts が UserRepository を直接インポートしています。UserService を使用するようにリファクタリングしてください。」

---

ステップ 8：ギャップ分析（詳細モードのみ）

検出したパターンをベストプラクティスと比較します。各カテゴリについて、ギャップを特定します。

カテゴリ	ベストプラクティス	確認方法	不足している場合
セキュリティ	境界での入力検証	zod/joi/yup を探す	「API の境界で入力を検証するため、Zod の追加を検討してください」
セキュリティ	パラメーター化クエリー	生の SQL 文字列を確認する	「X で生の SQL が見つかりました。パラメーター化クエリーを使用してください。」
セキュリティ	認証ミドルウェア	ルートの保護を確認する	「すべてのルートで認証チェックが行われているようには見えません」
セキュリティ	シークレット管理	ハードコードされた値を確認する	「X でハードコードされている可能性のあるシークレットが見つかりました」
エラー処理	カスタムエラークラス	extends Error を探す	「カスタムエラークラスが見つかりませんでした。AppError の階層を追加することを検討してください。」
エラー処理	一貫したエラー形式	レスポンスのパターンを確認する	「ファイルによってエラーレスポンスの形式に一貫性がありません」
エラー処理	エラーログ	ロガーの使用を確認する	「X 個のファイルで、捕捉されたエラーがログに記録されていません」
テスト	テストの存在	テストファイルを探す	「src/services/ のテストが見つかりませんでした」
テスト	テストの構成	パターンを確認する	「テストの命名規則に一貫性がありません（.test.ts と .spec.ts が混在しています）」
TypeScript	厳格モード	tsconfig を確認する	「厳格モードが有効になっていません。新しいコードでは有効にすることを検討してください。」
TypeScript	any を使わない	any の使用数を数える	「any が 47 箇所で使用されています。型を付けるか、unknown の使用を検討してください。」

---

ステップ 9：Technical.md を生成する（詳細モード：生成サブエージェントを使用）

詳細モードでは、生成サブエージェントを並列で起動し、包括的な 約 500 行の Technical.md を作成します。各サブエージェントは、主要なセクションを 1 つずつ、詳細に記述します。

Claude Code 用生成戦略

各セクションは、特定の分析結果をもとに、特定の領域に集中するサブエージェントが独立して生成します。最終的な統合では、切り捨てずに各セクションをまとめるため、Claude Code は長く詳細な出力を生成できます。エージェントは同時に起動してください。

エージェント	セクション	約行数
1	アーキテクチャ	約100
2	命名規則とスタイル	約80
3	エラー処理とロギング	約80
4	テスト	約80
5	セキュリティとフレームワーク	約100

reference/generation-prompts.md（このスキルからの相対パス）を読み、該当する分析結果を指示された箇所に貼り付けて、Task 経由で5つのエージェントをすべて並列に起動してください。

生成したセクションの統合

すべての生成エージェントが完了したら、各セクションを集めて、次の順序で約500行のファイルにまとめます。（1）ヘッダー — タイトル、「[project] の標準。包括的なコードベース分析に基づき [date] に生成。」に続けて、分析の概要の箇条書き（分析したファイル、検出したパターン、見つかった違反、特定したギャップ）。（2）5つのエージェントセクションを --- で区切って配置。（3）ベストプラクティスとのギャップの表（領域 | 現状 | 推奨事項 | 優先度）。（4）付録：引用した主要ファイルを列挙するファイルリファレンス。（5）フッター行：candid-init により生成。ルールの品質を確認するには /candid-validate-standards を実行してください。

中モード／クイックモード：簡潔な出力

中モードの場合：約150行を生成します（上記の簡潔版）。

クイックモードの場合：約50行を生成します（必須ルールのみ）。

各ルールに [observed N/M]（grep で数える）または [recommended] のタグを付け、既知の例外を列挙してください。

ルールの品質基準

すべてのルールは、必ず次の条件を満たす必要があります。

1. このプロジェクト内の具体的なパスを参照する

   • 良い例：「src/services/ 内のサービスは src/controllers/ からインポートしてはいけません」
   • 悪い例：「サービスはコントローラーをインポートしないでください」

2. コードベースの実例を含める

   • 良い例：「イベントハンドラーには handle* パターンを使用します（例：src/components/LoginForm.tsx の handleUserLogin）」
   • 悪い例：「イベントハンドラーには一貫した命名を使用してください」

3. 測定または検証できる

   • 良い例：「関数は50行未満でなければなりません」
   • 悪い例：「関数は小さく保ちましょう」

4. 現状がルールと異なる場合は、その旨を記載する

   • 良い例：「カスタムエラークラスを使用します。（現在は未実装 — ギャップのセクションを参照）」
   • 悪い例：「カスタムエラークラスを使用します」

5. 出典と遵守状況のタグを付ける

   • [observed 12/14] — 関連する14ファイルのうち12ファイルが規約に従っています。違反している2つのファイルは Known exceptions: path1, path2 の形式で列挙してください。これにより、レビューでは既存コードではなく、新たな違反のみが指摘されます。
   • [recommended] — このコードベースにはまだ導入されていないベストプラクティスです。必ずギャップの表にも記載してください。レビューではハード違反ではなく、提案として指摘してください。
   • 遵守率が60％未満のルールは [observed] として含めず、ギャップに移してください。

含めないもの

• リンターで強制されるルール（ESLint／Prettier が検出されている場合）
• どのプロジェクトにも当てはまる一般的なアドバイス
• 「適切な」「ふさわしい」「クリーンな」「良い」「ベストプラクティス」といった曖昧な表現
• 具体的なパスや例を含まないルール

---

ステップ10：config.json を生成する

コードベースから自動検出できる情報を使ってプロジェクト設定を作成し、ユーザーに設定を確認してください。必ず "version": 1 を設定します。

注： focus フィールドは初期化時には設定しません。これはプロジェクトレベルのデフォルトではなく、レビューごとに指定する項目（例：リリース前に --focus security を指定）です。

10.1: マージ先ブランチを検出する

実行します：

git branch -a 2>/dev/null

検出したブランチをブランチ戦略に対応付けます：

検出結果	戦略	mergeTargetBranches
develop ブランチが存在する	Git Flow	["develop", "main"]
trunk ブランチが存在する	トランクベース	["trunk"]
main と master の両方が存在する	移行	["main"]
main が存在する（develop/trunk は存在しない）	GitHub Flow	["main"]
master が存在する（main は存在しない）	レガシー	["master"]
何も検出されない	デフォルト	["main"]

ローカルとリモートのブランチ名の両方を確認します（例：remotes/origin/develop は develop として扱います）。

AskUserQuestion を使用して確認します：

質問：「[strategy] のブランチ戦略が検出されました。マージ先ブランチとして [detected branches] を使用しますか？」

選択肢：

1. 「はい、[detected branches] を使用する」→ 検出された値を使用
2. 「いいえ、自分で指定する」→ カスタムブランチリストを尋ねる追加プロンプトに進む
3. 「スキップ — デフォルトを使用する」→ mergeTargetBranches フィールドを省略（candid-review のデフォルトは ["main", "stable", "master"]）

10.2: 除外パターンを検出する

レビュー対象から除外するファイルやディレクトリがないか、プロジェクトをスキャンします。以下を確認します：

# Generated files
find . -maxdepth 4 \( -name "*.generated.ts" -o -name "*.generated.js" -o -name "*.g.dart" \) 2>/dev/null | head -5

# Vendor directories
ls -d vendor/ third_party/ 2>/dev/null

# Build output
ls -d dist/ build/ .next/ out/ 2>/dev/null

# Minified files
find . -maxdepth 4 \( -name "*.min.js" -o -name "*.min.css" \) 2>/dev/null | head -5

検出した除外パターンのリストを作成します：

• *.generated.ts / *.generated.js — 生成ファイルが見つかった場合
• vendor/* — vendor ディレクトリが見つかった場合
• dist/* / build/* / .next/* — ビルド出力ディレクトリが見つかった場合
• *.min.js / *.min.css — 圧縮ファイルが見つかった場合

パターンが検出された場合： AskUserQuestion を使用します：

質問：「レビュー対象から除外すべきファイルが検出されました：\n[各パターンと例となるファイルを列挙]\n\nこれらの除外パターンを使用しますか？」

選択肢：

1. 「はい、検出されたパターンを使用する」→ 検出されたリストを使用
2. 「はい、さらに追加する」→ 検出されたリストを使用し、追加パターンを尋ねる追加プロンプトに進む
3. 「いいえ、除外をスキップする」→ exclude フィールドを省略

パターンが検出されなかった場合： このステップを通知なしでスキップします。exclude フィールドを省略します。

10.3: トーンを尋ねる

AskUserQuestion を使用します：

質問：「どのようなレビュートーンを希望しますか？」

選択肢：

1. 「厳しめ — 遠慮のない率直なフィードバック」
2. 「建設的 — 思いやりを持ちながらも、率直に指摘するフィードバック」
3. 「スキップ — レビューごとに決める」

「厳しめ」の場合 → "tone": "harsh" を設定します。「建設的」の場合 → "tone": "constructive" を設定します。「スキップ」の場合 → tone フィールドを省略します（candid-review が毎回尋ねるか、ユーザー設定を使用します）。

10.4: 自動コミットを尋ねる

AskUserQuestion を使用します：

質問：「レビュー中に修正を適用した後、自動的にコミットしますか？」

選択肢：

1. 「はい — 適用した修正を自動コミットする」
2. 「いいえ — 手動でコミットする」（デフォルト）

「はい」の場合 → "autoCommit": true を設定します。「いいえ」の場合 → autoCommit フィールドを省略します（デフォルトは false です）。

10.5: 意思決定記録のオプション

AskUserQuestion を使用します：

質問：「レビュー中の質問や決定を記録するために、意思決定記録を有効にしますか？」

選択肢：

1. 「はい、意思決定記録を有効にする」→ 生成された設定に "decisionRegister": { "enabled": true } を追加
2. 「いいえ、スキップする」→ 生成された設定から decisionRegister フィールドを省略（デフォルトでは無効）

有効にした場合は、デフォルトのパス（.candid/register）とデフォルトのモード（"lookup"）が使用されます。これらは後で設定ファイルで変更できます。

10.6: 出荷設定

AskUserQuestion を使用します：

質問：「candid-ship の出荷ワークフローを設定しますか？（レビュー → ビルド → テスト → PR → マージ）」

選択肢：

1. 「はい、出荷設定を構成する」
2. 「いいえ、スキップする」

「いいえ、スキップする」の場合 → ship フィールドを省略します。ステップ 10.7 に進みます。

「はい、出荷設定を構成する」の場合：

10.6a: ビルドコマンド

package.json から自動検出します：

jq -r '.scripts.build // null' package.json 2>/dev/null

ビルドスクリプトが検出された場合： AskUserQuestion を使用します：

• 質問： "出荷確認に使用するビルドコマンドは？\n検出結果：[detected command]"
• 選択肢：
  1. "[detected package manager] run build"（例："npm run build"）
  2. "カスタムコマンド"
  3. "ビルド手順をスキップ"

ビルドスクリプトが検出されなかった場合： AskUserQuestion を使用します：

• 質問： "出荷確認に使用するビルドコマンドは？"
• 選択肢：
  1. "npm run build"
  2. "yarn build"
  3. "カスタムコマンド"
  4. "ビルド手順をスキップ"

「カスタムコマンド」を選択した場合 → 追加の質問：「ビルドコマンドを入力してください：」を表示し、自由記述で回答してもらいます。 「ビルド手順をスキップ」を選択した場合 → buildCommand フィールドを省略します。

10.6b: テストコマンド

package.json から自動検出します：

jq -r '.scripts.test // null' package.json 2>/dev/null

10.6a と同じ手順ですが、対象はテストです。package.json にない場合は、プロジェクト構造から pytest、go test などを検出します：

ls pytest.ini setup.cfg pyproject.toml 2>/dev/null  # Python
ls go.mod 2>/dev/null                                # Go

テストスクリプトが検出された場合： 検出されたコマンドを最初の選択肢として AskUserQuestion を使用します。 テストスクリプトが検出されなかった場合： 一般的な選択肢（npm test、yarn test、カスタム、スキップ）を提示します。

「カスタムコマンド」を選択した場合 → 追加の質問：「テストコマンドを入力してください：」を表示し、自由記述で回答してもらいます。 「テスト手順をスキップ」を選択した場合 → testCommand フィールドを省略します。

10.6c: 対象ブランチ

ステップ 10.1 で検出されたブランチ（mergeTargetBranches）を使用します。

質問： "candid-ship が作成する PR の対象ブランチは？"

選択肢：

1. "[first detected branch]"（ステップ 10.1 の結果）
2. "カスタムブランチ"
3. "スキップ（mergeTargetBranches のデフォルトを使用）"

「カスタムブランチ」を選択した場合 → 追加の質問：「対象ブランチ名を入力してください：」 「スキップ」を選択した場合 → targetBranch フィールドを省略します。

10.6d: 自動マージ

AskUserQuestion を使用します：

質問： "PR の作成後に自動マージしますか？（リポジトリで GitHub の自動マージが有効になっている必要があります）"

選択肢：

1. "はい — スカッシュで自動マージ"
2. "いいえ — 手動でマージ（デフォルト）"

「はい」を選択した場合は "autoMerge": true に設定します。「いいえ」を選択した場合は autoMerge フィールドを省略します。

10.6e: 追加プロンプト

AskUserQuestion を使用します：

質問： "candid-ship に追加のレビュー用プロンプトを設定しますか？（出荷時のコードレビューに渡す追加コンテキスト）"

選択肢：

1. "はい、プロンプトを追加"
2. "いいえ、スキップ"

「はい」を選択した場合 → 追加の質問：「追加のレビュー用プロンプトを入力してください：」を表示し、自由記述で回答してもらいます。 「いいえ」を選択した場合 → additionalPrompt フィールドを省略します。

10.6f: イシュートラッカーとの連携

AskUserQuestion を使用します。

質問: 「イシュートラッカー（Linear、Asana、Jira など）を使用していて、リリース時に candid-ship がイシューを自動更新するようにしますか？」

選択肢:

1. 「はい — Linear（対応済み）」
2. 「はい — その他のトラッカー（対応をリクエスト）」
3. 「いいえ、スキップ」

「いいえ、スキップ」の場合 → issueTracker フィールドを省略します。次に進みます。

「はい — その他のトラッカー（対応をリクエスト）」の場合:

以下を表示します。

Issue tracker integration currently supports Linear only. To request support for your tracker (Asana, Jira, GitHub Issues, Shortcut, etc.):

  → Open an issue: https://github.com/ron-myers/candid/issues

Tell us which tracker you use and how you'd like the workflow to behave (state name, when to trigger, etc.) and we'll prioritize accordingly.

Skipping issue tracker config for now.

issueTracker フィールドを省略します。次に進みます。

「はい — Linear（対応済み）」の場合:

以下を表示します。

Linear integration requires the official Linear MCP server (claude.ai/Linear). If it isn't installed, the issue-tracker step is skipped at ship time — the rest of the ship still runs.

フォローアップ 1: 「Linear のチームプレフィックス（カンマ区切り、例：DIS,ENG,DISC）：」— 自由記述の回答です。カンマで分割し、各項目の前後の空白を削除して、大文字にします。空欄の場合は、["DIS", "ENG", "DISC"] をデフォルトとして使用します。

フォローアップ 2: 「PR 作成時に設定する Linear のステータス名：」— 自由記述の回答です。空欄の場合は、"In Review" をデフォルトとして使用します。ユーザーには、Linear ワークスペースのステータス名と完全に一致するもの（例："In Review"、"Code Review"、"In Progress"）を指定してもらいます。

フォローアップ 3: AskUserQuestion を使用します。「デフォルトの Linear MCP プロンプトを使用しますか、それともカスタマイズしますか？」

ユーザーが内容を確認して選べるよう、質問の下にデフォルトを表示します。

Update issue {issueId}: set its state to "{state}". Update only this one issue and only its state — do not modify any other issues, fields, or properties. If the issue is already in "{state}", report success without action. If the issue is missing or inaccessible, report the error and stop.

選択肢:

1. 「デフォルトを使用（推奨）— 後から編集できるよう、設定ファイルに書き込みます」
2. 「今すぐカスタマイズ」

「デフォルトを使用」の場合： デフォルトのプロンプトをそのまま、生成する設定の prompt フィールドに書き込みます。ユーザーは後から .candid/config.json を編集できます。このフィールドを省略しないでください — プロンプトを設定ファイルで確認できることは機能であり、余計な情報ではありません。

「今すぐカスタマイズ」の場合： 自由記述のフォローアップ：「カスタムプロンプトを入力してください。プレースホルダーとして {issueId}、{state}、{provider} を使用します。必須： プロンプトでは、操作対象を単一のイシューに限定し、イシューが見つからない場合のエラーで処理を停止する必要があります（代わりのイシューを検索しないでください）。」参考例として、デフォルトを下に表示します。ユーザーの回答を prompt の値として使用します。

どちらの場合も、以下のとおり、生成する設定に prompt フィールドを書き込みます。

"issueTracker": {
  "provider": "linear",
  "enabled": true,
  "teamPrefixes": ["..."],
  "state": "...",
  "prompt": "..."
}

スキルの実行時のデフォルトは、ここに書き込む値と同一です。設定に明示する方法を採用しても動作は変わらず、ユーザーがプロンプトを確認できるようになります。

10.7: 高速リリースの設定

AskUserQuestion を使用します。

質問: 「candid-fast-ship を設定しますか？有効にしたステップだけを実行する最小限のリリースパスです。デフォルトでは PR 作成以外は何も実行されません。（コマンドの値は、先ほど設定した ship ブロックから継承されます。）」

選択肢:

1. 「はい、高速リリースを設定する」
2. 「いいえ、スキップ」

「いいえ、スキップ」の場合 → fastShip フィールドを省略します。手順 10.8 に進みます。

「はい、高速リリースを設定する」の場合:

AskUserQuestion を使用します。

質問: 「candid-fast-ship でデフォルトで有効にするステップを選択してください。」

選択肢:

1. 「なし — PR 作成のみ（最も安全なデフォルト。実行のたびに選択）」
2. 「ビルドのみ」
3. 「ビルド + 自動マージ」
4. 「カスタム — 自分で選択する」

「カスタム — 自分で選択する」の場合、次の項目それぞれについて、はい／いいえで確認します。

• レビュー（candid-loop）を有効にしますか？
• インストールを有効にしますか？（ship.installCommand が設定されている場合のみ表示）
• ビルドを有効にしますか？（ship.buildCommand が設定されている場合のみ表示）
• テストを有効にしますか？（ship.testCommand が設定されている場合のみ表示）
• イシュートラッカーの更新を有効にしますか？（ship.issueTracker が設定されている場合のみ表示）
• 自動マージを有効にしますか？
• マージ後のコマンドを有効にしますか？（ship.postMergeCommand が設定されている場合のみ表示）

選択内容に基づいて fastShip オブジェクトを作成します。ユーザーが明示的に有効にしたフィールドのみを true に設定し、false のフィールドは省略します（省略時のデフォルトは false です）。生成する設定から targetBranch は必ず省略します（自動的に ship.targetBranch にフォールバックします）。

プリセットの選択肢:

• 「なし」→ "fastShip": {}
• 「ビルドのみ」→ "fastShip": { "build": true }（ship.buildCommand が設定されていない場合は省略し、代わりに {} を使用して注記を添えます）
• 「ビルド + 自動マージ」→ "fastShip": { "build": true, "autoMerge": true }（ビルドについては同じ条件が適用されます）

10.8: プレビューと確認

検出した値と質問で入力された値から、設定オブジェクトを組み立てます。明示的に設定されたフィールドだけを含め、ユーザーがスキップしたフィールドは省略してください（省略した場合も、デフォルト値が正しく適用されます）。

組み立てた設定を、有効な JSON として表示します。すべてのフィールドを有効にした場合の例：

⚙️  Generated config.json:

{
  "version": 1,
  "tone": "harsh",
  "mergeTargetBranches": ["main"],
  "exclude": ["dist/*", "*.min.js"],
  "autoCommit": true,
  "decisionRegister": {
    "enabled": true
  },
  "ship": {
    "buildCommand": "npm run build",
    "testCommand": "npm test",
    "targetBranch": "main",
    "autoMerge": false
  },
  "fastShip": {
    "build": true,
    "autoMerge": true
  }
}

AskUserQuestion を使用します：

質問：「この設定を .candid/config.json に書き込みますか？」

選択肢：

1. 「はい、書き込む」→ ステップ 11 に進む
2. 「調整する」→ 変更内容を尋ね、設定を更新して再度プレビューする

---

ステップ 11：ファイルを書き込み、最適化して、概要を表示する

11.1：ファイルをディスクに書き込む

.candid/ ディレクトリが存在することを確認してから、両方のファイルを書き込みます。

mkdir -p .candid

Write ツールを使用して、次のファイルを作成します：

• .candid/Technical.md（または --output で指定されたパス）— ステップ 9 で合成した内容
• .candid/config.json — ステップ 10.8 で組み立てた設定

11.2：必要に応じて最適化ステージを実行する

--optimize または --auto-optimize が指定されていない限り、このサブステップ全体をスキップしてください。

--optimize が設定されている場合（対話型）：

次を表示します：

Running optimization audit on generated context…

追加のフラグを指定せずに candid-optimize スキルを呼び出します。このスキルはトークン予算（ステップ 2）を表示し、Technical.md／除外項目／登録内容／設定（ステップ 3～6）を分析したうえで、変更前後のトークン数レポートを含む独自の対話型適用フェーズ（ステップ 7）を実行します。

candid-optimize が戻ったら、ステップ 11.3 に進みます。

--auto-optimize が設定されている場合（非対話型）：

次を表示します：

Running optimization audit and applying all recommendations…

--apply-all フラグを指定して candid-optimize スキルを呼び出します。すべての推奨事項は確認を求めずに適用されます。変更前後のレポートは引き続き表示されます。

candid-optimize が戻ったら、ステップ 11.3 に進みます。

11.3：概要を表示する

次の内容を含む概要を表示します：Technical.md の場所と取り組みレベル、アーキテクチャルールの件数（および違反数）、命名パターン、エラー処理／テスト／セキュリティの状況、特定されたギャップ、ship／fastShip の設定有無を含む config.json の場所、次のステップ 1～4（ルールの確認、ギャップへの対応、/candid-validate-standards の実行、/candid-review の実行）。

ステップ 11.2 を実行した場合（--optimize または --auto-optimize）：「次のステップ」の 3 番目を Run /candid-validate-standards to check rule quality (optimization already applied) に置き換え、監査がすでに実施されたことをユーザーに知らせます。

ステップ 11.2 をスキップした場合：「次のステップ」ブロックの下に、最後のヒント行を追加します：

💡 Tip: run /candid-optimize to audit and tighten the generated context.

---

品質チェックリスト

出力する前に、次の項目を確認してください。

• アーキテクチャのセクションで実際のディレクトリパスを参照している
• 少なくとも 3 つのルールで、このプロジェクトの具体的なファイルを引用している
• 曖昧な表現（「適切な」「妥当な」「クリーンな」など）がない
• すべてのルールが検証可能である（しきい値または具体的なパターンがある）
• ギャップのセクションで、少なくとも 1 つの改善領域を特定している
• プロジェクト固有の詳細を含むセキュリティのセクションがある
• リンターが検出された場合、その適用範囲と重複するルールがない
• ファイルの行数が、詳細モードでは 400～500 行、中程度では 150 行、簡易モードでは 50 行である