Jikkou

Skill hayashiii-ghub/hikizan/skills/jikkou

Claude Code plugin / Agent Skills pack — verb-split skills for design, review, TDD, and PR flow, with deterministic git hooks as safety floors

Install

npx -y skills add hayashiii-ghub/hikizan --skill jikkou

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

コード、設定、文書の修正・追加・削除、または決定済み計画の実行を明示した依頼に使う。調査、相談、設計、レビューだけの依頼では使わない。

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

5.8 KB, as published. Nobody here has run it

実行（jikkou）

明示された変更範囲を理解し、実装とリスクに見合う検証まで完了する。

共通ルール

全スキル共通。正本はscripts/contract.mdで、scripts/gen-contract.shが各SKILL.mdのこの区間に書き込む（手で編集しない）。

各スキルを起動したら、そのスキルの作業を始める直前に1行だけ🌲 <スキル名>（日本語名）：<今回の目的>と伝える。複数スキルを1行にまとめず、まだ始めないスキルを予告しない。同じスキル内の局所作業では繰り返さない
調査、相談、設計、レビューだけの依頼では対象を変更しない。修正、追加、削除、実行、PR提出が依頼に含まれる場合だけ、必要なスキルをつないで明示された終点まで進む
スキルを固定順に通さず、依頼された成果に必要な観点だけを使う。明示済みの終点へ向かう途中で、形式的な承認を追加しない
検証はリスクに比例させ、未検証の状態を成功や完了と書かない
人へ渡す日本語は結果か判断を先に置き、簡潔で分かりやすく書く。文章の表現や構成自体が成果ならhoukokuを使う
停止するときに意味のある次の進め方があれば、最大3件を推奨順にA（あ）、B（い）、C（う）で示し、英字とひらがなのどちらの回答も同じ選択として扱う

使い分け

実装：依頼された観測可能な変更を完成させる
障害修正：症状を再現し、原因を絞ってから修正する

手順

リポジトリ、対象範囲、期待結果を確認する。局所的で可逆な判断は既存コードと規約に合わせて自分で決める
セキュリティ・権限・公開API・スキーマ・データ移行・不可逆操作など、結果を大きく変える未承認の判断だけ実装前に確認する
変更を小さな観測可能な振る舞い単位で実装する。調査や独立レビューに標準サブエージェントを使ってよいが、編集内容と検証結果は親エージェントが確認する
バグ修正は同じ入力で症状を再現し、安定したテスト基盤があるなら回帰テストを先に失敗させる。新しいロジックや公開契約も回帰価値が高い場合はreferences/tdd.mdを使う
文書・設定・UIなどは対象に合う検証を選ぶ。各編集へ儀式的にテストを追加しない
UI・スタイル・配置・操作を変更し、対象リポジトリにShimonが設定済みなら次の契約で視覚確認する

信頼できる対象にShimonとレビュー済みのshimon.config.mjsがある場合だけ使う。自動インストールや別ツールへの切替は行わない。ChromeやPlaywrightなどのブラウザー実行ファイルを直接起動して代替しない
今回必要なケースだけを.shimon/task.mjsへ書く。サーバー起動とブラウザー確認はリポジトリ所定の固定コマンドへ集約し、なければ./node_modules/.bin/shimon verify --task .shimon/task.mjs --jsonを使う。終了後に一時ファイルを削除する
JSONのpassと各自動検査を確認し、返された全スクリーンショットをintentとreviewに沿って見る。visualReviewRequired: trueを視覚確認済みとは扱わない
スクリーンショットとログへ秘密情報・個人情報を残さない。実行条件を満たさなければ、理由を添えて視覚未確認と報告する

文言や局所的な可逆変更は最寄りの検査、ロジック・API・バグ修正は関連する回帰検査、セキュリティ・権限・スキーマ・移行・データ損失・取り消しが難しい変更は、関連検査に加えてリポジトリの全体検証と対象レビューまで行う
対象範囲が実質的に変わる発見は勝手に混ぜない。必要なら理由と選択肢を示して利用者へ戻す
意味のある区切りをコミットする場合だけreferences/commit.mdを読む

障害修正

修正を求められた障害では、症状と期待値を固定し、仮説を1つずつ証拠で採用・棄却する。原因が確認できてから必要な修正を行い、同じ入力の修正前後と回帰検査を残す。観測手段を仕込んだ場合は提出前に外す。原因調査だけの依頼はtansakuで扱う。

報告

何が変わったかを最初に書き、実行した検証と結果、未確認・残件があれば続ける。TDDを使った場合も有用なRED / GREENだけを示し、工程のためのログを増やさない。

次の進め方

依頼の終点がPR提出なら、最終変更をjikkou自身で検証した後にsadokuへ進み、重大な指摘がなければteishutsuへ続ける。停止する場合は、次の候補から意味のあるものだけを選ぶ。

最終変更をsadokuでレビュー
jikkouで追加修正
検証済みの変更をteishutsuでPR提出

禁止事項

原因不明のまま当てずっぽうの修正を重ねる
利用者の既存変更や対象外の整理を混ぜる
検査失敗を無視して完了扱いする