Git Push

Step 2: プロジェクトの品質チェックを自動検出・実行

プロジェクトルートのファイル構成からツールチェインを自動検出し、 利用可能なチェックを順に実行する。

検出ロジック

以下の優先順で検出する。該当しないものはスキップする。

Node.js プロジェクト（package.json が存在）:

パッケージマネージャーの検出順: bun.lock → pnpm-lock.yaml → yarn.lock → package-lock.json。 該当するロックファイルのマネージャーを使用する。いずれもなければ npm を使用する。

Python プロジェクト（pyproject.toml / setup.py / setup.cfg が存在）:

Rust プロジェクト（Cargo.toml が存在）:

Go プロジェクト（go.mod が存在）:

Ansible プロジェクト（ansible.cfg または playbook.yml が存在）:

Docker プロジェクト（Dockerfile または compose.yml / docker-compose.yml が存在）:

Makefile / Taskfile（Makefile / Taskfile.yml が存在）:

lint, check, test, build ターゲットが定義されていれば実行する。

チェック実行の原則

• 検出されたチェックの一覧と実行順をユーザーに提示し、AskUserQuestion で承認を得てから実行する。
• チェックをスキップしたい場合はユーザーが指定できる。
• 各チェックの実行結果（成功/失敗）をリアルタイムで表示する。
• 1つでもチェックが失敗した場合は push を中止する。 失敗内容をユーザーに報告し、修正を促す。
• プロジェクトの種別が検出できない場合、または該当するチェックが1つもない場合は、チェックをスキップして Step 3 に進む。

Step 3: push の実行

すべてのチェックに通過したら（またはチェック不要の場合）:

1. push コマンドをユーザーに提示する
2. AskUserQuestion で最終確認を行う
3. 承認を得たら push を実行する

git push <remote> <branch>

初回 push（tracking branch がない場合）

git push -u <remote> <branch>

force push について

• --force や --force-with-lease はユーザーが明示的に要求した場合のみ使用する。
• スキルから自発的に force push を提案しない。
• main / master ブランチへの force push をユーザーが要求した場合は、リスクを警告する。

出力フォーマット

各ステップの結果を以下の形式で表示する:

## Push 前チェック

**ブランチ:** feature/xxx → origin/feature/xxx
**コミット数:** 3 件

### push 対象コミット
- abcdef1 feat(auth): ログイン機能を追加
- abcdef2 fix(auth): バリデーションの修正
- abcdef3 test(auth): ログインのテストを追加

### 品質チェック
- ✓ build
- ✓ lint
- ✗ test（失敗）