terminal-ops

name	terminal-ops
description	ECC のためのエビデンスファーストな repo 実行ワークフロー。ユーザーがコマンドの実行、repo の確認、CI 障害のデバッグ、狭い修正のプッシュを希望し、何を実行して何を検証したかの正確な証明を求める場合に使用します。
origin	ECC

Terminal Ops

ユーザーが実際の repo 実行を求める場合にこれを使用します: コマンド実行、git 状態の検査、CI やビルドのデバッグ、狭い修正、そして何が変更され何が検証されたかを正確に報告します。

このスキルは意図的に一般的なコーディングガイダンスよりも狭いものです。エビデンスファーストな terminal 実行のオペレーターワークフローです。

スキルスタック

関連する場合、以下の ECC ネイティブスキルをワークフローに取り込みます:

• 変更後の正確な証明ステップには verification-loop
• 正しい修正にリグレッションカバレッジが必要な場合は tdd-workflow
• シークレット、認証、外部入力が関わる場合は security-review
• タスクが CI 実行、PR 状態、リリース状態に依存する場合は github-ops
• 検証済みの成果を永続的なプロジェクトコンテキストに捕捉する必要がある場合は knowledge-ops

使用タイミング

• ユーザーが "fix"、"debug"、"これを実行"、"repo を確認"、"push" と言った場合
• タスクがコマンド出力、git 状態、テスト結果、または検証されたローカル修正に依存する場合
• 答えがローカル変更済み、ローカル検証済み、コミット済み、プッシュ済みを区別する必要がある場合

ガードレール

• 編集前に検査する
• ユーザーが audit/review のみを求めている場合は読み取り専用に留まる
• 即興のアドホックラッパーよりも repo ローカルスクリプトやヘルパーを優先する
• 証明コマンドを再実行するまで fixed と主張しない
• ブランチが実際にアップストリームに移動しない限り pushed と主張しない

ワークフロー

1. 作業サーフェスを解決する

以下を確定する:

• 正確な repo パス
• ブランチ
• ローカル diff 状態
• 要求されたモード:
  • inspect
  • fix
  • verify
  • push

2. まず失敗しているサーフェスを読む

何かを変更する前に:

• エラーを検査
• ファイルまたはテストを検査
• git 状態を検査
• 盲目的に再読み込みする前に、既に提供されているログやコンテキストを使う

3. 修正を狭く保つ

1 回に 1 つの主要な障害を解決する:

• 最小限の有用な証明コマンドを最初に使う
• ローカル障害が対処された後でのみ、より大きなビルド/テストパスにエスカレート
• コマンドが同じシグネチャで失敗し続ける場合、広範なリトライを止めてスコープを狭める

4. 正確な実行状態を報告する

正確なステータス用語を使う:

• inspected
• changed locally
• verified locally
• committed
• pushed
• blocked

出力フォーマット

SURFACE
- repo
- ブランチ
- 要求モード

EVIDENCE
- 失敗コマンド / diff / テスト

ACTION
- 何が変更されたか

STATUS
- inspected / changed locally / verified locally / committed / pushed / blocked

落とし穴

• ライブ repo 状態が読める場合、古い記憶から作業しない
• 狭い修正を repo 全体の churn に広げない
• 破壊的な git コマンドを使わない
• 関連のないローカル作業を無視しない

検証

• 応答が証明コマンドまたはテストを明示している
• git 関連作業は repo パスとブランチを明示する
• push の主張にはターゲットブランチと正確な結果が含まれる