القائمة
Detect primitive obsession and missing domain/brand types; check that state is modeled via discriminated unions.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/s977043/river-review --skill type-driven-design-guardيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
6つの専門レビュアーロールを並列実行し、consensusLevel（複数ロールの合意度）と Tech Lead レポート（top3指摘・blindSpots・consensusSummary）で結果を統合する マルチエージェントレビュー entry skill。 Parallel multi-role review with consensus scoring (consensusLevel) and Tech Lead report. Use when a major release needs exhaustive multi-angle review, or when a single-perspective review is not enough and you want confidence that no reviewer angle was missed（重要リリース前の網羅レビュー・多視点の確証が 欲しいとき）。
検査器（linter / ガード / CI ゲート / バリデータ / フィルタ）そのものの検出力が差分で静かに落ちていないか、また新設した検査が実際に検出できることが実証されているかを diff-time で検出する。Check 1 unverified detection reduction（検査器の検出ロジック（正規表現・除外パターン・解決集合・allowlist・baseline）を変更して検出件数が減ったのに、減った 1 件ずつが誤検出であった根拠が示されないまま「誤検出を潰した」「N → M 件に減少」と改善として主張している）、Check 2 unproven guard detection power（新しい検査ロジック・CI ゲート・バリデーションを追加・変更したのに、検出すべき入力を注入して検出されること／検出すべきでない入力で黙ることを示す変異注入の証跡が無く、「追加した」「CI が緑」を検出力の証拠として扱っている）、の 2 Check を対象とする report-only。テスト自身のアサーションが実質何も検証していない構造は test-assertion-effectiveness、レビュー基準・品質ゲートの明示的な弱体化（ルールの削除・閾値の引き下げ・suppression entry 追加・lint ルールの無効化）は review-criteria-integrity、リファクタ完了主張一般の検証は refactor-claim-audit、workflow の permissions と action pin は gha-workflow-security、設定ファイルの構文・型の妥当性は config-json へ委譲する
pbi-input, plan, todo, test-cases 間の整合性をチェックし、実装着手前の仕様漏れを検知する
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| id | type-driven-design |
| name | Type-Driven Design Guard |
| description | Detect primitive obsession and missing domain/brand types; check that state is modeled via discriminated unions. |
| version | 0.1.0 |
| category | midstream |
| phase | midstream |
| applyTo | ["src/**/*.{ts,tsx}","app/**/*.{ts,tsx}","lib/**/*.{ts,tsx}","packages/**/*.{ts,tsx}"] |
| tags | ["typescript","type-driven-design","domain-modeling","midstream"] |
| severity | major |
| inputContext | ["diff","fullFile"] |
| outputKind | ["findings","actions"] |
| modelHint | balanced |
| dependencies | ["code_search"] |
Primary pattern: Reviewer Secondary patterns: Inversion Why: プリミティブ型の濫用やドメイン型の欠如をチェックリスト型で評価するが、TypeScript以外の変更では実行不要
any の排除や型アサーションの削減（typescript-strict のスコープ）。typescript-nullcheck のスコープ）。tsconfig.json の設定変更。このスキルは以下の条件がすべて満たされない限りNO_REVIEWを返す。
.ts, .tsx）の変更が含まれている*.spec.ts, *.test.ts, __tests__/**）のみではないゲート不成立時の出力: NO_REVIEW: type-driven-design — Type-Driven Design評価の対象となるTypeScriptコード変更が検出されない
code_search で確認）。string の引数が 1 つしかなく、他のプリミティブとの混入可能性がない場合。string / number にはブランド型 (UserId, OrderId, Price 等) を使う。boolean フラグや status: string で表現するのではなく、判別可能なユニオン型（Discriminated Union）でモデリングする。string / number が連続して並ぶ場合、引数が混入可能か確認する。<file>:<line> で追える内容）。code_search で確認し、根拠を示す。<file>:<line>: <message> 形式。コメントは日本語で返す。
例:
src/order.ts:15: userId と orderId が同じ string 型。引数の順序を間違えてもコンパイルエラーにならない。Fix: ブランド型 UserId / OrderId を導入(userId: string, orderId: string) のように同じプリミティブ型が複数の引数に並ぶ。status: 'pending' | 'active' | 'deleted' のようなリテラルユニオンが型エイリアスに切り出されていない。isLoading: boolean; isError: boolean; isSuccess: boolean のように boolean フラグが複数並び、排他性が型で表現されていない。type State = { loading: true } | { error: Error } | { data: Data } のような判別可能なユニオンが使えるのに使われていない。string / number を使っている。Bad:
function getOrder(userId: string, orderId: string): Order;
// userId と orderId が型レベルで区別されず、引数の順序ミスがコンパイルエラーにならない
Good:
type UserId = string & { readonly __brand: 'UserId' };
type OrderId = string & { readonly __brand: 'OrderId' };
function getOrder(userId: UserId, orderId: OrderId): Order;
// getOrder(orderId, userId) は型エラーになる
Bad:
type RequestState = {
isLoading: boolean;
isError: boolean;
data?: Data;
error?: Error;
};
// isLoading: true かつ data が存在する無効な状態が許可される
Good:
type RequestState =
{ kind: 'loading' } | { kind: 'error'; error: Error } | { kind: 'success'; data: Data };
// 無効な状態が型で表現不可能
Bad: status: 'pending' | 'processing' | 'shipped' | 'delivered' がインラインで重複定義。
Good: type OrderStatus = 'pending' | 'processing' | 'shipped' | 'delivered' と型エイリアスに切り出す。
string / number の引数が並ぶ場合、ブランド型パターン (type UserId = string & { readonly __brand: 'UserId' }) の導入を提案する。any や null 問題との混同。