一键在 Manus 中运行任何 Skill

design-review

星标3

分支0

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

ソフトウェア設計の成果物（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 違反対応）は範囲外で、本スキルは「読んで指摘する」レビュー専用である。

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

kanade0404

kanade0404/resume

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

相关职业SOC

基于 SOC 职业分类

软件开发工程师计算机与数学类职业·SOC 15-1252

文件资源管理器

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 は禁止 — 原因分類してユーザに返す。

2026-07-183

code-review

kanade0404/resume

実装が完了した後・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 には書き手の前提知識を持ち込ませない。

2026-07-183

commit

kanade0404/resume

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

kanade0404/resume

要件が確定した後、実装に入る前に、構造選択・I/O 境界・依存方向・外部制約を**会話 / 一時ファイル**で検討するスキル。設計ドキュメントを永続化することは目的としない — コードを読めばわかる範囲は書かず、**コードを読んでもわからない外部要因・制約・選択肢と却下理由のみ ADR に蒸留**する (ADR 化は `adr-writer` の責務)。設計の検討内容は temp scratchpad (`<work-dir>/design-scratch.md` 等、配布先で gitignore 推奨) に書き、PR マージ後は破棄。要件 → 実装の間、`pr-review-respond` で VALID_DEFER を新規 issue 化する時、「設計どうする」「アーキ考えて」「どこに置く」「依存方向は」「I/O 境界どこ」「先にデザインして」のような要請、いずれでも必ず起動すること。本スキルは設計の **検討と決定の蒸留** までで、実装・テスト・ADR 文面化は別スキルに渡す。詳細仕様の永続化や spec ファイル化は意図的にしない。

2026-07-183

name	design-review
description	ソフトウェア設計の成果物（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 違反対応）は範囲外で、本スキルは「読んで指摘する」レビュー専用である。
allowed-tools	["Read","Glob","Grep","Bash","Agent","TaskCreate","TaskUpdate","TaskList","AskUserQuestion","mcp__plugin_serena_serena__find_symbol","mcp__plugin_serena_serena__get_symbols_overview","mcp__plugin_serena_serena__search_for_pattern","mcp__plugin_serena_serena__list_dir","mcp__plugin_serena_serena__find_file","mcp__plugin_serena_serena__read_file"]

Design Review

設計成果物を 書き手バイアスのない別エージェント に白紙で読ませ、software-design の 13 レンズに沿った checklist を機械的に当てて構造化された findings を返すスキル。

書き手バイアス排除の鉄則：

同じセッション / 同じ context の主エージェントにレビューさせない。 「書きながら自分でセルフレビュー」は読み返しているだけで、隠れた前提に気づけない。
必ず Agent ツールで subagent を dispatch し、白紙でレビュー資料を読ませる。
subagent にも "13 レンズの checklist を順に当てよ" と指示する。 主観で読み流させない。

software-design を実行した直後、ADR をドラフトした直後、PR に含まれる設計関連の差分が固まった時に併用する。

ワークフロー

Step 1 — レビュー対象の同定

入力から以下を確定する。曖昧なら AskUserQuestion で確認する。

種別	例
ADR	`docs/adr/0007-*.md`
Design Proposal	`software-design` skill が直前に出した文書
設計コード差分	集約 / モデル / ports & adapters の追加・改変
アーキテクチャ図 / モデル図	C4, ER, シーケンス
既存設計の妥当性	指定モジュールに対する general review

スコープを 1 リクエスト 1 種別に絞る。 「全部見て」は subagent 側で焦点が散る。

Step 2 — 適用レンズの選択

対象種別に応じて、skills/software-design/references/ の中から当てる checklist を選ぶ。本スキルの references/checklist.md がレンズごとの設問集を持つ。

対象	適用レンズ（既定）
ADR	adr, architecture, ddd（決定が触れる範囲）
Domain model	ddd, data-model, security
Module / class 構造	philosophy, functional-core, tdd
Aggregate / repository	ddd, data-model
Error handling 戦略	functional-core (FP/Railway), philosophy
アーキテクチャ提案	architecture, ddd, adr
Auth / 入力検証	security, data-model
全般（種別不明）	philosophy, ddd, security, adr の 4 本を必ず + 内容に応じて追加

Step 3 — Subagent dispatch

Agent ツールを使い、general-purpose subagent に以下のテンプレートで投げる。本スキルが書き手代わりに評価しない：

あなたは <対象名> を白紙で読むレビュー実行者です。書き手の意図は知らない前提で、
書かれているテキスト / コードだけから判断してください。

## レビュー対象
<ファイルパス・該当範囲・コードブロック>

## 適用 checklist
以下のレンズについて、`skills/software-design/references/<lens>.md` の "レビュー観点" 節を
順に当ててください。レンズ:
- <lens-1>
- <lens-2>
- ...

## チェックの仕方
各観点について次のいずれかを返す:
- ○ 充足している（短い根拠 1 行）
- × 充足していない（issue 1 行 + Fix 提案 1 行 + 該当 path:line）
- ? 判断不能（追加情報が必要 — 何が要るか 1 行）

## 出力形式
レンズごとに H2 を立て、観点ごとに箇条書きで上記 ○/×/? を並べる。
最後に "Summary" 節を立て、Critical / Major / Minor の数を集計し、
merge OK / changes requested / 要議論 を判定する。findings は捏造しない。
読みづらいなら "?" で素直にエスカレーションする。

Agent の subagent_type は general-purpose（特化エージェントが既にあるなら指定）。出力をそのまま受け取り、本スキル側で書き直さない（バイアスを混ぜないため）。

Step 4 — 主エージェントが集約

subagent から返ってきた findings を、ユーザ向け最終出力に整形する。整形時にやること：

重複統合: 同じ issue が複数レンズで出ているなら 1 件にまとめる（Lens 名タグを [philosophy/deep-module] [ddd/aggregate] のように複数つける）
Critical / Major / Minor 振り分け: subagent の判定を尊重するが、明らかにレベル違いが見えたら主エージェントが調整。理由を 1 行残す。
Open Questions の昇格: subagent が "?" にした項目は最終出力の "Open Questions" に集める。ユーザに判断を返す。
Strengths: ○ で良かったところを最低 1 件残す。「悪いとこだけ列挙」はレビュー疲れを招く。

Step 5 — 必要に応じて再 dispatch

以下の場合は同じ subagent に 続報を依頼せず、新しい subagent を立てて やり直す：

subagent が checklist を一部スキップした
"?" が多すぎて判断材料が足りなかった
レンズ選択が誤っていた

「同じ subagent に追加質問」をしないのは、初回読みの白紙性を維持するため。

出力フォーマット

# Design Review

## Summary
判定: <merge OK / changes requested / 要議論>
主要懸念（最大 3）: ...

## Critical (blocks merge)
- [path:line] [<lens-tag>] [<lens-tag>]: <issue>
  - Fix: <提案>
  - Reviewer note: <subagent の根拠 1 行>

## Major (should fix)
- ...

## Minor / Style
- ...

## Open Questions
- [<lens-tag>]: <subagent が "?" にした項目>

## Strengths
- ...

## Reviewed lenses
- <lens-1>: ○ N / × N / ? N
- <lens-2>: ...

## Reviewer
- subagent: general-purpose（white-paper read）
- 主エージェント: 集約のみ（レビュー判断はしていない）

<lens-tag> 例（software-design と整合）: philosophy/deep-module, data/mutable-mix, tm/key, fp/exception-as-control, ddd/aggregate-boundary, tdd/untestable, rop/result-leak, arch/quantum, xunit/double-overuse, cqrs/asymmetry, es/state-loss, adr/missing-options, secure/primitive。

このスキルがやらないこと

設計の "提案"。 提案は software-design の担当。本スキルは "読んで指摘" のみ。
コード書き換え。 Fix は提案テキスト。実装は別ステップ / 別スキル。
書き手（同セッションの主エージェント）による直接評価。 必ず subagent dispatch。
テスト本体のレビュー。 test-review の担当。
調査作業（先行事例 / 学術調査）。 research-practices の担当。
subagent の出力を主エージェントが書き直して "正しく" すること。 出力は集約のみ。指摘内容を主エージェントの判断で握りつぶさない。
複数の対象を 1 回でレビューすること。 スコープを 1 種別に絞り、必要なら複数回呼ぶ。

良いレビューの例

# Design Review

## Summary
判定: changes requested
主要懸念: (1) ADR-0007 が Considered Options に却下案を 1 案しか書いていない、
(2) `Order` 集約が `Customer` と同一トランザクションで更新されている、
(3) Email がプリミティブ string のまま service 層を流れている。

## Critical (blocks merge)
- [packages/orders/src/use_cases/place_order.ts:42] [ddd/aggregate-boundary]: 1 トランザクションで `Order` と `Customer` の双方を更新している。
  - Fix: `Customer.creditUsed` を更新するのは domain event `OrderPlaced` を outbox に書き、別トランザクションで反映する。集約境界に書き戻す動機を ADR に切り出す。
  - Reviewer note: `Repository.beginTx()` 配下に複数集約の `save()` が並ぶのを検出。

- [packages/orders/src/api/place_order.ts:18] [secure/primitive]: 受け取った `email: string` がそのまま `OrderService.placeOrder(email, ...)` に渡っている。
  - Fix: API 入口で `Email.parse(raw)` を通し、`Email` 型として service に渡す。`OrderService` の引数を `Email` に変更。

## Major (should fix)
- [docs/adr/0007-event-sourcing-for-orders.md:24] [adr/missing-options]: Considered Options に "ES なし、状態 + audit_log" 案がない。
  - Fix: 当該案を Pros/Cons つきで追記し、却下根拠を Decision に書く。

## Minor / Style
- [packages/orders/src/domain/order.ts:7] [philosophy/deep-module]: `OrderManager` という名前は "manage" を含む。
  - Fix: 役割が "発注の整合確認" なら `OrderPlacement` のような具体名に。

## Open Questions
- [arch/quantum]: ADR-0007 が "Order と Inventory は同期 RPC で繋ぐ" としているが、これだと量子は実質 1 つになる。意図して同期にしている?

## Strengths
- ドメインプリミティブ `Money(amount, currency)` の不変性とコンストラクタ検証は徹底できている。
- `Result<T, OrderError>` の Err sum type に網羅性チェックがコンパイル時に効いている。

## Reviewed lenses
- adr: ○ 4 / × 1 / ? 0
- ddd: ○ 5 / × 1 / ? 0
- security: ○ 3 / × 1 / ? 0
- architecture: ○ 3 / × 0 / ? 1
- philosophy: ○ 6 / × 1 / ? 0

## Reviewer
- subagent: general-purpose (white-paper read)
- 主エージェント: 集約のみ