ターミナルオペレーションズ は何をしますか？
ユーザーが実際のリポジトリ実行（コマンドの実行、git状態の調査、CIやビルドのデバッグ、狭い修正の実施、そして何が変更され何が検証されたかを正確に報告すること）を求める場合にこれを使用してください。
このスキルは、一般的なコーディングガイダンスよりも意図的に範囲を限定しています。エビデンスファーストなターミナル実行のためのオペレーターワークフローです。
スキルスタック
関連する場合、以下のECCネイティブスキルをワークフローに取り込んでください：
verification-loop：変更後の正確な証明手順用tdd-workflow：適切な修正にリグレッションカバレッジが必要な場合security-review：シークレット、認証、外部入力が関係する場合github-ops：タスクがCI実行、PR状態、リリース状況に依存する場合knowledge-ops：検証済みの成果を持続可能なプロジェクトコンテキストに取り込む必要がある場合
使用時
- ユーザーが「修正」「デバッグ」「これを実行」「リポジトリを確認」「プッシュ」と言った場合
- タスクがコマンド出力、git状態、テスト結果、検証済みのローカル修正に依存する場合
- 回答で「ローカルで変更」「ローカルで検証」「コミット」「プッシュ」を区別する必要がある場合
ガードレール
- 編集前に調査すること
- ユーザーが監査/レビューのみを依頼している場合は読み取り専用を維持すること
- 即席のアドホックラッパーよりも、リポジトローカルのスクリプトとヘルパーを優先すること
- 証明コマンドが再実行されるまでは「修正済み」と主張しないこと
- ブランチが実際に上流に移動しない限り「プッシュ済み」と主張しないこと
ワークフロー
1. 作業面の解決
以下を確定します：
- 正確なリポジトリパス
- ブランチ
- ローカルの差分状態
- 要求されたモード：
- 調査
- 修正
- 検証
- プッシュ
2. まず障害面を読む
何かを変更する前に：
- エラーを調査する
- ファイルまたはテストを調査する
- git状態を調査する
- 既に提供されているログやコンテキストがあれば、それを盲目的に再読み込みする前に使用する
3. 修正は狭く保つ
一度に一つの支配的な障害を解決します：
- 最初は最も小さな有用な証明コマンドを使用する
- ローカルの障害が対処された後にのみ、より大きなビルド/テストパスにエスカレーションする
- コマンドが同じシグネチャで失敗し続ける場合は、広範な再試行を停止し、範囲を狭める
4. 正確な実行状態を報告する
正確なステータスワードを使用します：
- 調査済み
- ローカルで変更済み
- ローカルで検証済み
- コミット済み
- プッシュ済み
- ブロック済み
出力形式
SURFACE
- リポジトリ
- ブランチ
- 要求されたモード
EVIDENCE
- 失敗したコマンド / 差分 / テスト
ACTION
- 変更内容
STATUS
- 調査済み / ローカルで変更済み / ローカルで検証済み / コミット済み / プッシュ済み / ブロック済み
落とし穴
- ライブのリポジトリ状態を読み取れるのに、古いメモリから作業しないこと
- 狭い修正をリポジトリ全体の混乱に広げないこと
- 破壊的なgitコマンドを使用しないこと
- 無関係なローカル作業を無視しないこと
検証
- 応答は証明コマンドまたはテストを指定していること
- git関連の作業はリポジトリパスとブランチを指定していること
- プッシュの主張にはターゲットブランチと正確な結果が含まれていること