ワンクリックでManusで任意のスキルを実行

code-review

スター3

フォーク0

更新日2026年7月18日 03:09

実装が完了した後・PR 作成前に、変更差分を白紙の subagent にレビューさせて Critical / Important / Minor の三分類で findings を返すゲート用スキル。観点は spec 準拠、責務逸脱、依存方向違反、null/error handling、命名、test coverage、副作用混入、unused code、performative comment / dead code 残し、AI 生成パターン (self-consistent assertion 等は `test-review` 参照)。実装直後・「コードレビューして」「PR 出す前にチェック」「実装見て」「これで OK?」「マージ前確認」のような要請、`pr-review-respond` での修正完了直後、いずれでも必ず起動すること。本スキルは subagent によるセルフ・コードレビューで、CodeRabbit / Devin / 人間レビュアーの代替ではなく **PR 起票前のセーフティネット**。findings は実装者 (= 本スキル呼出側) に返り、修正後に `verify-done` を経て PR 起票へ。subagent には書き手の前提知識を持ち込ませない。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

kanade0404

kanade0404/resume

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

関連職種SOC

SOC 職業分類に基づく

ソフトウェア品質保証アナリスト・テスターコンピュータ・数学職·SOC 15-1253

ファイルエクスプローラー

3 ファイル

SKILL.md

readonly

このリポジトリの他の Skills

同じリポジトリ

career-grilling

kanade0404/resume

Interviews the user relentlessly to build career self-knowledge for a job change, career profile work, or negotiation prep. Grounds every question first in the private Obsidian vault (profile/*.md, prior grill logs, grill-ledger.md) and this repo's docs/resume-update-plan.md / docs/action-plan.md gaps, then extracts concrete episodes, chained "why" reasoning, blind spots against the user's own written record, and a decision journal with mandatory confidence follow-ups. Extends the grilling one-question-at-a-time engine; never uses selection-style dialog tools (AskUserQuestion). Use for career or job-change consultation, career grilling, resume grilling, or filling profile/*.md stubs — trigger phrases include "キャリア壁打ち", "キャリア相談", "転職相談", "経歴の壁打ち", "career grilling", "career interview", "profileを埋めたい", "暗黙知を掘り出して". Writes nothing to the private vault without prior /add-dir, and never writes compensation figures, employer/target-company names, or reasons for leaving into this public repository.

2026-07-193

adr-writer

kanade0404/resume

設計検討から出てきた決定について「これは ADR (Architecture Decision Record) に値するか」を判定し、値する場合のみ [adr-tools](https://github.com/npryce/adr-tools) の `adr new` コマンドで Michael Nygard 形式の ADR を生成するスキル。**コードを読めばわかる決定は ADR にしない**。値する基準は (1) 将来「なぜこうした?」と疑問になりうる (2) 容易に変更できない one-way door (3) 別の選択肢があり却下したのいずれか。番号採番・slug 生成・テンプレ展開・supersede リンクの相互更新は全て `adr new` / `adr new -s` / `adr new -l` に委譲する。`design` Step 4 から呼ばれる主経路、設計判断を残したい時、「これ ADR にして」「決定記録残して」「architecture decision」「設計判断のドキュメント」のような要請、いずれでも必ず起動すること。本スキルは ADR 単体の生成と判定までで、設計検討自体や実装には関与しない。詳細仕様や API ドキュメントの代わりに ADR を使うことは推奨しない (ADR は「決定」の記録、「使い方」のドキュメントではない)。adr-tools が未インストールの場合は導入手順を提示し、勝手に install しない。

2026-07-183

ci-self-heal

kanade0404/resume

PR 作成後・push 後の CI が失敗した際に、ログから root cause を特定し、修正コミットを当てて再 push する自己修復ループを駆動するスキル。**root cause 不明なまま再試行しない** (NO FIXES WITHOUT ROOT CAUSE)。3 連続失敗で停止し、architecture を疑ってユーザに escalate (3-failure architecture gate)。`pr-review-respond` Phase E から呼ばれる主経路、`gh pr create` 直後で CI が回り始めた時、CI が赤になった時、「CI 直して」「ビルド失敗してる」「テストが落ちてる on CI」「pipeline 緑にして」のような要請、いずれでも必ず起動すること。本スキルは CI ログ取得 → root cause 仮説 → 修正 → 再 push → 再 watch のループ駆動と、停止判断を担う。修正コード自体は呼出側スキル (`tdd` / `tidy-first` / `code-review`) を経由する。flaky / 環境問題と判定したら retry-to-green は禁止 — 原因分類してユーザに返す。

git commit を「観測 → ガード → 明示パス staging → ファイル経由メッセージ → 検証」の固定順で作る skill。`git add -A` / `git add .` / heredoc を使わないため、permission / hook で汎用コマンドが拒否される環境でもブロックされずに完走する。「commit して」「コミット作って」「この変更コミットしといて」「stage して commit」「きりのいいところで commit 切って」「一区切りだから記録して」のような要請、および tdd / tidy-first / shipping の各サイクル終端の commit 作成で必ず起動すること。commit までが責務 — push・PR 作成は `shipping`(検証ループ付き)または `commit-commands:commit-push-pr` に、リリースタグは RELEASING.md の手順に、structural / behavioral の分割判断は `tidy-first` に渡す。履歴書き換え (amend / rebase / squash / reset / revert) と commit 取り消しは範囲外 — 新規 commit を作る要請だけを扱う。

2026-07-183

design-review

kanade0404/resume

ソフトウェア設計の成果物（ADR、ドメインモデル、モジュール構造、アーキテクチャ提案、設計差分、`software-design` skill の提案）を、書き手バイアスのない別エージェントに白紙で読ませて構造化された指摘を返すレビュー専用スキル。philosophy of software design (Ousterhout)、immutable data model (kawasima)、TM法 (佐藤正美)、関数型プログラミング、DDD (Vlad Khononov)、TDD (Kent Beck)、Railway Oriented Programming (Scott Wlaschin)、Fundamentals of Software Architecture、xUnit Test Patterns、CQRS、Event Sourcing、ADR (Nygard)、Secure by Design の 13 レンズを checklist で当てる。「設計レビューして」「ADR レビューして」「設計で抜け落ちている観点ない?」「別エージェントで読み直して」「設計の最終チェック」「この提案で行く?」「集約境界これで OK?」「Result への置き換え、抜けない?」「Secure by Design 観点で監査して」「ADR の Negative consequences 薄い」のような要請、`software-design` の Proposal/ADR 最終確認、PR の設計関連ドキュメント / コード境界の妥当性確認、設計セッション後の「セルフレビューでない外部視点」が必要な場面で必ず起動する。Agent ツールで subagent を dispatch して評価し、書き手（同セッションの主エージェント）にレビューさせない。テスト本体のレビューは `test-review`、調査は `research-practices`、Skill 本体の作成・トリガ調整は `skill-builder` 担当のため、それらの目的が明確な依頼ではこのスキルを起動しない。実装を書き換える作業（コード修正、リファクタリング実施、lint 違反対応）は範囲外で、本スキルは「読んで指摘する」レビュー専用である。

2026-07-183

name	code-review
description	実装が完了した後・PR 作成前に、変更差分を白紙の subagent にレビューさせて Critical / Important / Minor の三分類で findings を返すゲート用スキル。観点は spec 準拠、責務逸脱、依存方向違反、null/error handling、命名、test coverage、副作用混入、unused code、performative comment / dead code 残し、AI 生成パターン (self-consistent assertion 等は `test-review` 参照)。実装直後・「コードレビューして」「PR 出す前にチェック」「実装見て」「これで OK?」「マージ前確認」のような要請、`pr-review-respond` での修正完了直後、いずれでも必ず起動すること。本スキルは subagent によるセルフ・コードレビューで、CodeRabbit / Devin / 人間レビュアーの代替ではなく PR 起票前のセーフティネット。findings は実装者 (= 本スキル呼出側) に返り、修正後に `verify-done` を経て PR 起票へ。subagent には書き手の前提知識を持ち込ませない。
claudecode	{"allowed-tools":["Read","Bash","Task"]}

Code Review

規律: 書き手に評価させない。書き手の頭の中を持ち込まない subagent にコードだけを読ませて、PR 起票前に最後の盲点を炙り出す。

pr-review-respond が外部レビュアー (CodeRabbit / Devin / 人間) のフィードバックに対応するスキルなのに対し、本スキルは PR を出す前 に同種のレビューを内製する。外部レビュアーの仕事を奪うのではなく、自明な指摘で PR を汚さないため。

いつ起動するか

実装が GREEN になった直後 (TDD の REFACTOR 後 or 直接編集後)
pr-review-respond Phase C で VALID 修正を当てた直後
PR 起票前 (gh pr create の直前)
ユーザに「コードレビュー」「PR 前確認」「実装見て」と言われた時

逆に 起動しない:

WIP の途中段階 (REFACTOR 前 / 全テスト未 pass)
単純な typo / format 修正のみ
既に PR が出ている (それは pr-review-respond の領域)

ワークフロー

Step 1 — 差分の特定

git diff --name-only <base>...HEAD       # 変更ファイル
git diff <base>...HEAD                   # 全 diff
git log --oneline <base>..HEAD           # commit ヒストリ

<base> は PR の予定 base ブランチ (default main / master)。

Step 2 — Subagent への入力

Task tool で feature-dev:code-reviewer または pr-review-toolkit:code-reviewer を起動 (利用可能な方)。なければ general-purpose。

プロンプトに必ず含める:

「あなたはコードレビュアーです。実装者の前提知識は持ち込まない」
変更ファイル一覧と diff
関連 ADR / spec があればパス参照
観点リスト (下記)
severity 三分類フォーマット
"performative agreement 禁止" / 「妥当性を verify してから指摘する」

Step 3 — レビュー観点

## 観点

1. Spec / Requirements 準拠 — 実装が要件を満たしているか / 過剰実装はないか (YAGNI)
2. 責務 — 変更で増えた module/class/function は単一責務か / 既存責務と重複していないか
3. 依存方向 — 不安定 → 安定 の方向か / domain → infra になっていないか / 循環参照は無いか
4. Error / Null Handling — 失敗パスが明示的か / silent failure / catch-and-ignore はないか / 復旧可能なエラーと不能なエラーの区別がついているか
5. 副作用 — 純関数化できる部分が外部 I/O と混在していないか
6. 命名 — 1 識別子 1 概念 / data/result/info のような曖昧名はないか / 動詞句で関数名 / 名詞句で型名
7. Test Coverage — 変更箇所のテストが新規 or 更新されているか / 既存テストが破壊されていないか / AI 生成パターン (self-consistent assertion / oracle copy-paste 等) はないか
8. Dead Code / Unused — 未使用 import / 到達不能分岐 / コメントアウトされたコード / 過去の feature flag 残骸
9. Performative Comments — コードを音読しただけのコメント / TODO/FIXME 新規追加
10. Convention — CLAUDE.md / 既存 ADR / 既存コードの慣例と矛盾していないか

## Severity

- Critical: マージするとバグ / セキュリティ / 重大な技術的負債を生む → ブロック
- Important: PR 前に対処すべき / マージ可能だが reviewer に説明が必要 → 対処を要求
- Minor: 改善余地はあるが PR 後でも良い / 取捨選択は実装者

Step 4 — Findings の収集

subagent からの戻り値を以下の構造で受け取る：

## Critical
- [<file>:<line>] [<観点>] <issue 1 行>
  - Suggested action: <具体的な修正提案 1 行>

## Important
- ...

## Minor
- ...

## What's good
- ...

Step 5 — 判定と次の手

状態	次の手
Critical = 0 / Important = 0	PASS — `verify-done` を経て PR 起票へ
Critical = 0 / Important > 0	PASS_WITH_FIXES — Important を対処してから再 review
Critical > 0	FAIL — 実装に戻る

呼出側に判定と findings をそのまま返す。本スキル内で修正はしない。

Step 6 — Pushback の余地

subagent の指摘が技術的に不適切と判断した場合、receiving-code-review の規律に従い:

「You're absolutely right!」式の自動同意は禁止
INVALID と判定する正当化を 1 文で書ける場合のみ pushback (YAGNI / 既存方針 / 前提誤り / トレードオフ)
pushback したものはユーザ報告に明示する (黙って無視しない)

出力フォーマット

## Code Review

### Scope
- Base: <branch>
- Files changed: <n>
- Commits: <n>

### Findings
- Critical: <n>
- Important: <n>
- Minor: <n>

### Critical (blocks)
- [<file>:<line>] [<観点>] <issue> → <action>

### Important (fix or 説明)
- ...

### Minor
- ...

### Pushback (subagent 指摘を却下)
- [<観点>] <subagent 指摘> → 却下理由: <YAGNI / 既存方針 / 前提誤り / トレードオフ>

### What's good
- ...

### Verdict
- PASS / PASS_WITH_FIXES / FAIL
- Next: PR 起票へ / Important 対処 / 実装に戻る

出力する成果物 / 出力しない成果物

出力する成果物

10 観点 × severity 三分類の findings リスト (Critical / Important / Minor / What's good の固定構造)
Verdict (PASS / PASS_WITH_FIXES / FAIL + 次の手 1 行)
Pushback リスト (subagent 指摘を却下した分は根拠 1 行と共に明示)

出力しない成果物

修正コード差分: findings のみ返し、修正は呼出側 (実装フェーズ)。
テスト実行結果 / Verification ブロック: テスト実行と完了判定は verify-done 領域、本スキルは静的レビューのみ。
PR 起票 (gh pr create) コマンド or 結果: PR 起票は commit-commands:commit-push-pr 等の別経路。
CodeRabbit / Devin 互換のスキャン結果: 依存スキャン / セキュリティスキャンは外部レビュアーの領域、本スキルからは出さない。
同一 subagent での再 review 結果: 修正後は新規 subagent dispatch、過去 agent の再利用出力はない。
subagent 指摘の盲信受容: pushback 候補は出力に明示、根拠なしの自動同意は出さない。

既知の限界

subagent の context window 制限: 大規模 diff (数千行) は 1 subagent で全件読めない。ファイル単位で分割 dispatch する運用余地。本スキルは 1 dispatch で完結する規模を前提。
静的レビューの限界: 実行時の振る舞い (race / leak / 性能) は静的レビューで検出不能。verify-done のテスト実行 + 必要なら専用ツール (profiler / sanitizer) で補う。
Solo dev 向け: チーム運用では subagent レビューに加えて人間レビューが必須。本スキルは「人間レビューの前段」として位置付ける場合も使える。
subagent agent type の可用性: feature-dev:code-reviewer 等が利用できない環境では general-purpose にフォールバック。観点リストの効果は同等。