القائمة
製品開発の全般ルール。設計（プロダクト・UI・ドメイン・コード・API・DB）、.docs/ の製品ドキュメント運用、依頼の振り分け（要望・Issue・PR を signal / backlog / issue に振り分けて実装まで進めるフロー）。機能の設計・実装・ドキュメント作成/更新・作業依頼の受け付けのときに使う。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | dev |
| description | 製品開発の全般ルール。設計（プロダクト・UI・ドメイン・コード・API・DB）、.docs/ の製品ドキュメント運用、依頼の振り分け（要望・Issue・PR を signal / backlog / issue に振り分けて実装まで進めるフロー）。機能の設計・実装・ドキュメント作成/更新・作業依頼の受け付けのときに使う。 |
| argument-hint | [drift|links|next|features-sync|自然文|Issue番号] |
| user-invocable | true |
| disable-model-invocation | false |
このスキルを更新するときは CLAUDE.md の方針に従う。
外側（利用者）から内側（実装）への同心円で設計し、コードから読み取れない意図は .docs/ に記録する。.docs/ は開発対象の製品リポジトリの直下に置く（このスキルが入っているプラグインリポジトリではない）。
/product:dev {入力} は入力の種類で振り分ける。
drift / links / next / features-sync ⇒ サブコマンド#N・GitHub URL ⇒ request.md の「Workflow: 既存 Issue の続き」（Issue 取得から PR まで）signals/{slug} のパス ⇒ request.md の既存記録の更新・昇格Issue / PR の書式は gh-templates.md、スクリーンショットの手順は screenshot-upload.md。
Jesse James Garrett's UX 5 planes (Strategy, Scope). Ref: ux-five-planes.md
OOUI + UX 5 planes (Structure, Skeleton, Surface). Ref: ux-five-planes.md
操作順でなく、不安を解消する順に並べる。
URL はレイアウトの入れ子を反映し、リソース指向にする。パラメータ名は :id でなく単数リソース名（/users/:user/posts/:post）。詳細 ⇒ page-routing.md
Eric Evans's DDD (Strategic): aggregate, invariant, boundary. 概念モデルのみ、実装は Code Design。
Kent Beck's Simple Design: passes tests, reveals intent, no duplication, fewest elements.
as unknown as T や any を使いたくなったら設計の歪みinterface 構文は使わない、type で表すwith*() で新インスタンスwith*()詳細 ⇒ value-object.md
依存方向は Interface → Application → Domain → Infrastructure の一方向、逆転させない。
詳細 ⇒ architecture.md
T | Error を戻す、instanceof で判別詳細 ⇒ error-handling.md
Beck's Implementation Patterns ⇒ TS:
詳細 ⇒ react.md
詳細 ⇒ api.md
詳細 ⇒ database.md
.docs/ に製品ドキュメントを管理する。コードから読み取れない意思決定・声・計画を記録し、コードと矛盾がない状態を保つ。UX 5 planes の各層は .docs/ の成果物に対応する（⇒ ux-five-planes.md）。
以下は推奨であり、制約ではない。必要ならここに無いディレクトリやファイルを増やしてよい。揃えられるところは揃える（バラバラよりは統一されている方が探しやすい）というだけで、この構造に収まらないことを理由に記録をやめない。
製品が1つの場合はフラットに並べる。
.docs/
index.md 製品の方向性、解決する問題
value.md 解決する痛みと提供価値の深掘り（必要なら）
glossary.md 用語集
features.md 機能一覧（小規模）
features/ 機能ファイル分割（中〜大規模）
index.md
{slug}.md または NNN_{日本語名}.md
pages.md 画面一覧（画面数30以上、必要なら）
pages/ 画面ファイル分割（ルートファイル単位、必要なら）
user-flows.md ユーザー導線
stories/ 業務ストーリー（ロール横断のユースケース、必要なら）
sitemap.md URL一覧
architecture.md システム構成
integrations.md 外部システム連携（必要なら）
domain.md ドメインモデル（必要なら）
models/ ドメインモデル分割（テーブル数40以上、必要なら）
roles-and-permissions.md ロール権限（必要なら）
milestones.md リリース計画（必要なら）
capabilities.md ロール別できることサマリ（必要なら）
page-capabilities.md ロール × 画面の詳細できること（必要なら）
manual/ エンドユーザーマニュアル（必要なら）
backlogs/ プロダクトバックログ
decisions/ ADR（意思決定記録）
signals/ 顧客と社内の声
sources/ 一次情報（議事録・要件書・配布物）
notes/ 自由メモ
references/terms/ 業界用語のアトミック定義
drafts/ 検討中の草案
製品が複数ある場合は products/{product-name}/ で分ける。.docs/ 直下は全製品共通、products/{product-name}/ は製品固有。
対話から書く。コードから読み取れない意図・声・計画・価値。基本は Claude が対話で人間から得た情報を整理して書く。signals / backlogs の人間ゾーン（human-claude-zone.md）だけは人間が直接書ける。
コードから生成する。実装が正で、文書はその索引・要約。対話で得た補足や意図の追記・編集もする。
一次情報として残す。決定の根拠。
[[sources/minutes/YYYY-MM-DD-{topic}]] で逆リンクし、判断の出所を辿れるようにするドキュメントは相互リンクで繋がったナレッジグラフとして育てる。1ファイル＝1ノード、[[]]＝エッジ。
原則。
[[]] でリンクする。節（##）ごとに初出1回が目安[[slug]] または [[path/file|表示名]] を使う。Markdown リンク [text](path) は使わない[[正式名|本文の表記]]（例: [[単位数|単位]]、[[pl|PL]]）製品の外にある専門知識（業界用語・制度・会計・技術）は references/terms/{用語}.md に1用語1ファイルで定義する。フォーマットとルールは glossary.md を参照。
棲み分け。
ephemeral: true）も置く。詳細は notes.mdドキュメントは古くなる。定期的にサブエージェントで矛盾を検出し、ユーザーと一緒に何が正しいかを確認して更新する。
requireRole() の宣言と一致しているかコードと文書が矛盾する場合、コードを正とする。ただし人間に確認してから更新する。
対話から書く。
コードから生成する。
共通ルール。
/product:dev {sub} でドキュメント運用のタスクを呼び分ける。各サブコマンドは commands/{sub}.md に詳細を書く。
tasks.md に追記する。Workflow ファンアウトで網羅性を担保する。重い処理（300+ agent 規模）。[[wikilink]] を解決して未定義リンク・孤児ページ・循環参照を検出する。