mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-18 14:53:05 +08:00
d66b5fa480
Add files present in zh-CN but missing from ja-JP: - commands: claw, context-budget, devfleet, docs, projects, prompt-optimize, rules-distill (7 files) - skills: regex-vs-llm-structured-text, remotion-video-creation, repo-scan, research-ops, returns-reverse-logistics, rules-distill, rust-patterns, rust-testing, skill-comply, skill-stocktake, social-graph-ranker, swift-actor-persistence, swift-concurrency-6-2, swift-protocol-di-testing, swiftui-patterns, team-builder, terminal-ops, token-budget-advisor, ui-demo, unified-notifications-ops, video-editing, videodb (+reference/*), visa-doc-translate, workspace-surface-audit, x-api (37 files) Result: ja-JP now has 517 files vs zh-CN 412 files. zh-CN parity: 0 missing files (complete parity achieved).
110 lines
4.3 KiB
Markdown
110 lines
4.3 KiB
Markdown
---
|
||
name: terminal-ops
|
||
description: ECCのための証拠優先のリポジトリ実行ワークフロー。ユーザーがコマンドの実行、リポジトリの確認、CIの失敗のデバッグ、正確な実行と検証の証明を伴う狭い修正のプッシュを必要とする場合に使用する。
|
||
origin: ECC
|
||
---
|
||
|
||
# ターミナルオペレーション
|
||
|
||
ユーザーが実際のリポジトリ実行を必要とする場合にこのスキルを使用する：コマンドの実行、git状態の確認、CIまたはビルドのデバッグ、狭い修正の実施、変更と検証内容の正確なレポート。
|
||
|
||
このスキルは意図的に汎用的なコーディングガイダンスよりも範囲が狭い。これは証拠優先のターミナル実行操作ワークフローである。
|
||
|
||
## スキルスタック
|
||
|
||
関連する場合、これらのECCネイティブスキルをワークフローに組み込む：
|
||
|
||
* `verification-loop` は変更後の正確な検証ステップに使用
|
||
* `tdd-workflow` は正しい修正に回帰カバレッジが必要な場合に使用
|
||
* `security-review` はキー、認証、外部入力が絡む場合に使用
|
||
* `github-ops` はタスクがCI実行、PRステータス、またはリリース状態に依存する場合に使用
|
||
* `knowledge-ops` は検証結果を永続的なプロジェクトコンテキストに保存する必要がある場合に使用
|
||
|
||
## 使用場面
|
||
|
||
* ユーザーが「修正」「デバッグ」「これを実行」「リポジトリを確認」「プッシュ」と言う場合
|
||
* タスクがコマンド出力、git状態、テスト結果、または検証済みのローカル修正に依存する場合
|
||
* 答えが以下を区別する必要がある場合：ローカルで変更済み、ローカルで検証済み、コミット済み、プッシュ済み
|
||
|
||
## 安全策
|
||
|
||
* 編集前に確認する
|
||
* ユーザーが監査/レビューのみを要求している場合は読み取り専用を維持する
|
||
* アドホックなラッパーではなく、リポジトリローカルのスクリプトとヘルパーを優先する
|
||
* 検証コマンドが再実行されるまで、修正済みと主張しない
|
||
* ブランチが実際に上流にプッシュされるまで、プッシュ済みと主張しない
|
||
|
||
## ワークフロー
|
||
|
||
### 1. 作業サーフェスを特定する
|
||
|
||
以下を明確にする：
|
||
|
||
* 正確なリポジトリパス
|
||
* ブランチ
|
||
* ローカル差分の状態
|
||
* 要求されたモード：
|
||
* 確認
|
||
* 修正
|
||
* 検証
|
||
* プッシュ
|
||
|
||
### 2. まず失敗サーフェスを読み取る
|
||
|
||
何かを変更する前に：
|
||
|
||
* エラーを確認する
|
||
* ファイルまたはテストを確認する
|
||
* git状態を確認する
|
||
* 盲目的に再読み込みする前に、提供されたログまたはコンテキストを使用する
|
||
|
||
### 3. 修正を狭い範囲に保つ
|
||
|
||
一度に1つの主な失敗に対処する：
|
||
|
||
* 最初に最小限の有用な検証コマンドを使用する
|
||
* ローカルの失敗が解決した後のみ、より大きなビルド/テストプロセスにエスカレートする
|
||
* コマンドが同じ特性で失敗し続ける場合、広範囲なリトライを停止して絞り込む
|
||
|
||
### 4. 正確な実行状態をレポートする
|
||
|
||
正確な状態語を使用する：
|
||
|
||
* 確認済み
|
||
* ローカルで変更済み
|
||
* ローカルで検証済み
|
||
* コミット済み
|
||
* プッシュ済み
|
||
* ブロック済み
|
||
|
||
## 出力フォーマット
|
||
|
||
```text
|
||
サーフェス
|
||
- リポジトリ
|
||
- ブランチ
|
||
- 要求されたモード
|
||
|
||
証拠
|
||
- 失敗したコマンド / 差分 / テスト
|
||
|
||
アクション
|
||
- 変更した内容
|
||
|
||
状態
|
||
- 確認済み / ローカルで変更済み / ローカルで検証済み / コミット済み / プッシュ済み / ブロック済み
|
||
```
|
||
|
||
## 落とし穴
|
||
|
||
* ライブなリポジトリ状態を読み取れる場合に古い記憶に頼らない
|
||
* 狭い修正をリポジトリ全体の変更に拡大しない
|
||
* 破壊的なgitコマンドを使用しない
|
||
* 関連のないローカル作業を無視しない
|
||
|
||
## 検証
|
||
|
||
* レスポンスには検証コマンドまたはテストを示す
|
||
* gitに関する作業にはリポジトリパスとブランチを示す
|
||
* プッシュの主張には対象ブランチと正確な結果を含める
|