execute

実行

タスクを受け取り、難易度を分類し、適切な深さで考え、すぐに作業を開始します。

<output_language>

ユーザー向けの成果物、保存するアーティファクト、レポート、計画、生成するドキュメント、要約、引き継ぎメモ、コミット／メッセージの下書き、検証メモは、この正規のスキルファイルが英語で書かれていても、デフォルトで韓国語にします。

ソースコードの識別子、CLI コマンド、ファイルパス、スキーマキー、JSON／YAML のフィールド名、API 名、パッケージ名、固有名詞、引用したソースの抜粋は、必要な言語または原文のままにします。

ユーザーが明示的に別の言語を指定した場合、既存の成果物の一貫性を保つために別の言語を維持する必要がある場合、または機械可読な契約で正確な英語のトークンが必要な場合に限り、別の言語を使用します。ローカライズされたテンプレートや参考資料（たとえば *.ko.md や *.ko.json）がある場合は、ユーザー向けの成果物に優先して使用します。

</output_language>

• 明確な実装タスクには、適切な深さで考えながらすぐに取り組みます。
• 編集前にタスクの難易度を分類し、簡単な作業は軽く、難しい作業は十分な情報を踏まえて進めます。
• 診断、計画、レビュー、デプロイ、セキュリティ、または明示的なワークフローの依頼は、より適したスキルに振り分けます。

<routing_rule>

該当する依頼

• 成果物が明確な直接的なタスク指示：「ユーザー一覧にページネーションを追加する」「ダークモードの切り替え機能を実装する」。
• 明示的な実行依頼：「これを実行する」「これを構築する」「これが動くようにする」。
• 広範な計画を必要としない、範囲が限定された機能追加や変更の依頼：「これをリファクタリングする」「テストを追加する」「このコンポーネントを整理する」。

対象外

成果物の内容に応じて、関連する別の作業に振り分けます。

• 成果物が、ここで依頼されている新しい作業ではなく、報告された症状の根本原因と修正であるバグ報告。
• 成果物が、パイプラインの復旧であるリポジトリ全体のビルド、CI、またはデプロイの失敗。
• 成果物が、実装した変更ではなく、リリース可否の判断であるリリース前の準備状況の評価。
• 成果物が、要件文書またはアーキテクチャ文書である戦略計画やアーキテクチャの決定。
• 成果物が、リポジトリの情報に基づいて解釈したフィードバックレポートである、クライアントや顧客からの生のフィードバック。
• 成果物が、依頼された変更ではなく、脆弱性の指摘であるセキュリティ評価。
• 成果物が、そのワークフロー独自のアーティファクトである、明示的に指定された複数ステップのワークフロー。依頼を一般的な実行タスクとして扱わず、明示されたワークフローに従います。

</routing_rule>

境界ケース

• リクエストにバグ修正と新規作業が混在している場合、主な目的が新規作業であれば、execute が担当します。
• タスクの範囲が本当に不明確で、成果物を特定できない場合は、確認の質問を1つだけしてから実行します。
• ユーザーが「完了するまで続けて」「最高スコアに達するまで」など、永続的で完了が保証されるループを求めている場合や、Ralph 形式の反復を求めている場合は、1回限りの execute に黙って切り替えるのではなく、利用可能であれば Ralph に振り分けます。
• 作業中にアーキテクチャ上の判断が必要になった場合は、推測せずに作業を中断し、ユーザーに相談します。

</routing_rule>

<instruction_contract>

項目	契約
意図	タスクの難易度に応じて推論と検証の深さを調整しながら、明確なタスクを直接実行します。
トリガー	成果物を特定できる、直接的な実装、リファクタリング、テスト、クリーンアップ、または「これを動くようにする」といった依頼。
範囲	依頼された成果物について、コンテキストの収集、コードの編集、検証、最終的な韓国語での実行報告を担当します。
権限	ユーザーとプロジェクトの指示はこのスキルより優先されます。リポジトリ内のファイルと検証出力は証拠として扱います。
証拠	必要に応じて、ローカルファイルの読み取り、検索結果、差分、テスト／ビルド／lint の出力、実行時チェックを使用します。
ツール	ローカルの読み取り／編集／検索／シェルツールを使用します。破壊的な操作、認証情報を使う操作、本番環境への操作、外部への副作用を伴う操作は制限します。
ループ	最適化ループはありません。依頼ごとに1回だけ実行します。入力を検証し、難易度を分類し、適切な深さで検討して、実装、検証、報告を行います。対象を絞った検証が依頼範囲内で失敗している間のみ、手順4〜6を繰り返します。検証に合格するか、証拠を添えて真の阻害要因を報告した時点で終了します。
出力	実装した変更、または明確な阻害要因を、変更ファイル、検証の証拠、残存リスクとともに提示します。
検証	実装内容を証明できる最小限のコマンドを実行します。リスクに応じてのみ範囲を広げます。
停止条件	依頼された成果物を実装して検証した時点、または証拠を添えて真の阻害要因を報告した時点で終了します。

</instruction_contract>

<argument_validation>

ARGUMENT がない、または成果物を特定するには曖昧すぎる場合は、簡潔に質問します。

What should I execute?
- Task or feature to implement
- Target files or area
- Any constraints or requirements

質問を重ねすぎないでください。確認は1回までとし、その後は作業を開始します。

</argument_validation>

<difficulty_classification>

検討する前に難易度を分類します。以下の指標を使用してください。

難易度	指標	推論の深さ
容易	単一ファイル、明確な範囲、慣れたパターン、機械的な変更	1〜3ステップ
中程度	複数ファイル、多少の曖昧さ、中程度の範囲、コンテキストの収集が必要	4〜6ステップ
高難度	複数領域にまたがる、アーキテクチャへの影響、未知の分野、複雑な相互作用	7ステップ以上

複合タスク（例：「リファクタリング＋テスト追加」）は、最も難しいサブタスクに基づいて分類します。複合タスクは1つの成果物として扱い、個別の作業には分けません。

判断に迷う場合は、1段階上の難易度にします。少し考えすぎるほうが、作業をやり直すより低コストです。

</difficulty_classification>

<mandatory_reasoning>

適応型の構造化された推論

実装の前に、内部で構造化された推論を行います。ステップ数は難易度に応じて調整します。

容易（1〜3ステップ）：

1. 具体的に何を変更する必要があるか
2. どこを変更するか
3. どのように検証するか

中程度（4〜6ステップ）：

1. 範囲と成果物の明確さ
2. 関連コードの調査計画
3. 実装方針
4. エッジケースやリスク
5. 検証戦略
6. （任意）代替案の比較

高難度（7ステップ以上）：

1. 範囲と成果物の明確さ
2. コードベースのコンテキストと依存関係
3. 設計方針
4. 実装の分解
5. エッジケースと障害モード
6. 横断的な影響
7. 検証戦略
8. 必要に応じて、修正、分岐、より深い分析

開始前に、分類を簡潔に伝えます。

Difficulty: [easy/medium/hard] — [one-line reason]

</mandatory_reasoning>

<execution_rules>

中核となる原則：熟考するより、実行する

• 考えたら実装を開始してください。選択肢を提示したり、確認を待ったりしないでください。
• どちらの方法も妥当な判断ポイントが生じた場合は、よりシンプルな方法を選び、その旨を記してください。
• ユーザーへの確認のために作業を止めるのは、タスク自体（何をするか）が曖昧な場合に限ります。進め方（どうするか）が曖昧なだけなら止めないでください。
• 依頼された範囲に留めてください。依頼されていない改善を追加しないでください。

実装

• 編集する前に、関連するコードを読んでください。
• 成果物を実現するために必要な、最小限の変更を加えてください。
• 変更後に、対象を絞った検証（必要に応じて型チェック、テスト、ビルド）を実行してください。
• 検証に失敗した場合は、範囲内で修正してください。壊れた状態のままにしないでください。

</execution_rules>

手順	タスク	ツール
1	入力を検証する — 成果物を特定する	-
2	難易度を分類する（簡単／中程度／難しい）	-
3	内部で構造化された推論を行い、適切な深さで考える	内部推論
4	関連するコードを調べる	Read/Grep/Glob
5	実装する	Edit/Write
6	検証する（型チェック／テスト／ビルド）	Bash
7	結果と変更したファイルを報告する	-

必要に応じて手順4～6を繰り返してください。目標は、一度で済ませることではなく、成果物が機能することです。

<completion_report>

実行後、簡潔に報告してください：

## Done

**Task**: [what was executed]
**Difficulty**: [easy/medium/hard]
**Changes**: [list of changed files]
**Validation**: [what was verified and result]

未検証の項目がある場合は、その内容と理由を記載してください。

</completion_report>

実行チェックリスト：

• 引数を検証した — 成果物が明確である
• 難易度を分類した
• 構造化された推論を適切な深さで行った
• 編集する前に関連するコードを読んだ
• 実装が完了した
• 検証（型チェック／テスト／ビルド）を実行した
• 結果を変更したファイルとともに報告した

禁止事項：

• 選択肢を提示して返答を待つこと（これは実行であり、診断ではありません）
• 簡単なタスクを考えすぎること（簡単なタスクは最大1～3ステップ）
• 難しいタスクを十分に考えないこと（難しいタスクは最低7ステップ以上）
• 依頼された範囲を超えて作業すること
• 検証を実行せずに完了したと主張すること