端末操作 は何をしますか？
ユーザーが実際のリポジトリ実行を希望する場合にこれを使用します：コマンドの実行、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関連の作業ではリポジトリパスとブランチを指定する
- プッシュの主張にはターゲットブランチと正確な結果を含める