terminal-ops

Topics in the source

• ターミナルオペレーション
• スキルスタック
• 使用場面
• 安全策
• ワークフロー
• 1. 作業サーフェスを特定する
• 2. まず失敗サーフェスを読み取る
• 3. 修正を狭い範囲に保つ

ユーザーが実際のリポジトリ実行を必要とする場合にこのスキルを使用する：コマンドの実行、git状態の確認、CIまたはビルドのデバッグ、狭い修正の実施、変更と検証内容の正確なレポート。 このスキルは意図的に汎用的なコーディングガイダンスよりも範囲が狭い。これは証拠優先のターミナル実行操作ワークフローである。 関連する場合、これらのECCネイティブスキルをワークフローに組み込む： verification-loop は変更後の正確な検証ステップに使用 tdd-workflow は正しい修正に回帰カバレッジが必要な場合に使用 security-review はキー、認証、外部入力が絡む場合に使用 github-ops はタスクがCI実行、PRステータス、またはリリース状態に依存する場合に使用 knowledge-ops は検証結果を永続的なプロジェクトコンテキストに保存する必要がある場合に使用 ユーザーが「修正」「デバッグ」「これを実行」「リポジトリを確認」「プッシュ」と言う場合 タスクがコマンド出力、git状態、テスト結果、または検証済みのローカル修正に依存する場合 答えが以下を区別する必要がある場合：ローカルで変更済み、ローカルで検証済み、コミット済み、プッシュ済み 編集前に確認する ユーザーが監査/レビューのみを要求している場合は読み取り専用を維持する アドホックなラッパーではなく、リポジトリローカルのスクリプトとヘルパーを優先する 検証コマンドが再実行されるまで、修正済みと主張しない ブランチが実際に上流にプッシュされるまで、プッシュ済みと主張しない 以下を明確にする： 正確なリポジトリパス ブランチ ローカル差分の状態 要求されたモード： 確認 修正 検証 プッシュ 何かを変更する前に： エラーを確認する ファイルまたはテストを確認する git状態を確認する 盲目的に再読み込みする前に、提供されたログまたはコンテキストを使用する 一度に1つの主な失敗に対処する： 最初に最小限の有用な検証コマンドを使用する ローカルの失敗が解決した後のみ、より大きなビルド/テストプロセスにエスカレートする コマンドが同じ特性で失敗し続ける場合、広範囲なリトライを停止して絞り込む 正確な状態語を使用する： 確認済み ローカルで変更済み ローカルで検証済み コミット済み プッシュ済み ブロック済み ライブなリポジトリ状態を読み取れる場合に古い記憶に頼らない 狭い修正をリポジトリ全体の変更に拡大しない 破壊的なgitコマンドを使用しない 関連のないローカル作業を無視しない レスポンスには検証コマンドまたはテストを示す gitに関する作業にはリポジトリパスとブランチを示す プッシュの主張には対象ブランチと正確な結果を含める