git commit を安全側で実行したいとき、機密ファイルやhook無視を防ぎたいときに使う。
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Purpose & Output Contractの最小の実成果物をmain contextで作成する。effect別のparse/open・secret・irreversible・corrupt guardだけを実行し、現物path・digest・開き方を提示してからaccept-as-is/light/standard/detailedを記録する。accept-as-isはその場でhandoff完了とし、後続sectionを実行しない。
以下の既存workflow・goal-seek・評価・修正sectionはlight/standard/detailedが記録されてsemantic_evaluator_startedへ遷移した場合だけ実行する。release/exhaustiveは別の明示eventを必要とする。
base Skill (run-build-skill) の commit ステップを wrap し、機密ファイル混入・hook bypass・force-push を防止する。
入力: なし (base から呼ばれる)
出力: 安全側で実行された git commit の結果、または BLOCK 理由
完了条件: commit 成功または BLOCK 理由が提示されている。
run-build-skill の commit 手順を base とし、前後に安全チェックを追加。.env, credentials.json, *.pem を git add 対象に含めない。git push --force は常に BLOCK。base Skill (run-build-skill) の commit ステップを wrap する実行系。固定手順ではなく、下記ゴール・チェックリストへ向けて反復する（正本 run-build-skill/references/goal-seek-paradigm.md）。
機密ファイル混入・hook bypass・force-push のいずれもないことが決定論的に確認されたうえで git commit が成功している、または BLOCK 理由が提示されている。
base の commit を上書きせず前後に安全フックを被せ、LLM の文字列マッチに頼らない決定論検査で危険な commit/push を未然に止めるため。
pre-commit-secret-scan.py が exit 0（.env / credentials.json / *.pem 等が add 対象に含まれない）--no-verify / --no-gpg-sign が含まれないgit push --force が発生していないrun-build-skill) の commit が成功、または上記いずれか不合格時に BLOCK 理由を提示している正本の 6 ステップ（現状評価→手順生成→実行→検証→Anchor Step→反復/差し戻し）に従う。固有差分は下記局面で未達チェックを埋める。決定論検査は script に寄せ、検査不合格は即 BLOCK（再試行で握り潰さない）。
機密ファイル検出 (決定論スキャン):
python3 plugins/harness-creator/skills/wrap-git-commit-safe/scripts/pre-commit-secret-scan.py \
--repo-root "$(git rev-parse --show-toplevel)" \
--commit-args "$@"
exit 2 で BLOCK。LLM の文字列マッチに依存しない決定論的検査。
hook bypass 検出: ユーザー指示や script に --no-verify / --no-gpg-sign が含まれていないか確認。検出時は BLOCK。
base の commit 実行: base (run-build-skill) の commit 手順を呼ぶ。
run-build-skilltemplates/commit-template.md — commit message を整形するときに Read06-classification-and-naming.md (wrap-* prefix), 01a-build-flow.md Step3まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。
run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。
確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。
生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。
Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。