メニュー
ELD SpecのLaw Card・Term Card作成統合スキル。ビジネス上の「守るべき条件」（Law）およびドメインの語彙（Vocabulary/Term）を標準フォーマットで文書化する。使用タイミング: 新しいLaw/Termを追加する時、既存Law/Termを更新する時、Law Catalog/Vocabulary Catalogに新規エントリを追加する時、Grounding Mapを更新する時、Discovery後にCard化する時。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | eld-spec-card |
| description | ELD SpecのLaw Card・Term Card作成統合スキル。ビジネス上の「守るべき条件」（Law）およびドメインの語彙（Vocabulary/Term）を標準フォーマットで文書化する。使用タイミング: 新しいLaw/Termを追加する時、既存Law/Termを更新する時、Law Catalog/Vocabulary Catalogに新規エントリを追加する時、Grounding Mapを更新する時、Discovery後にCard化する時。 |
| Value | Scope | Description |
|---|---|---|
law | Law Card only | Law Cardを作成・更新する |
term | Term Card only | Term Cardを作成・更新する |
both | Law + Term | Law CardとTerm Cardの両方を作成（default） |
| 種別 | 定義 | 例 |
|---|---|---|
| Invariant | どの状態でも常に成り立つ条件（状態制約） | available = total - reserved |
| Pre | 操作を受け付けるための条件（入力制約） | orderQty ≤ available |
| Post | 操作後に必ず成り立つ条件（出力制約） | reserved' = reserved + orderQty |
| Policy | 裁量・例外・外部状況を含む判断規則 | 「VIPは上限緩和」 |
## LAW-<domain>-<name> (ID)
- Type: Invariant | Pre | Post | Policy
- Scope: <module/usecase/endpoint/job>
- Statement: <自然言語 1〜3行>
- Formal-ish: <疑似式 / 型 / predicate（任意だが曖昧さ削減に有効）>
- Terms (required):
- <このLawが参照するTerm ID。最低1つ必須>
- 例: TERM-inventory-available, TERM-order-quantity
- Exceptions:
- <例外条件と理由。無ければ "None">
- Violation Handling:
- Severity: S0|S1|S2|S3
- When Violated: reject | compensate | warn | quarantine | audit
- Owner: <責任者/チーム>
- Verification (at least one):
- Test: <unit/property/test-case>
- Runtime Check: <assertion/guard>
- Observability (at least one):
- Telemetry: law.<domain>.<law_name>.(applied|violated|latency_ms|coverage)
- Log/Event: <event name / fields>
境界ケースの扱い（区間の開閉、同値・同時刻の順序、ゼロ・空の扱い、丸め方向）は実装判断に残さず、Lawとして決定・明文化する。 例: 「区間は半開 [start, end) — Aの終了時刻 == Bの開始時刻は重複ではない」
| レベル | 説明 |
|---|---|
| S0 | ビジネス停止レベル |
| S1 | 重大な機能障害 |
| S2 | 部分的な機能劣化 |
| S3 | 軽微・改善レベル |
/eld-spec-link で Law <-> Term の関係を記録## LAW-inv-available-balance
- Type: Invariant
- Scope: `inventory.reserveStock` / `inventory.releaseStock`
- Statement: 利用可能在庫は総在庫から予約済み在庫を引いた値に等しい
- Formal-ish: `∀t: available(t) = total(t) - reserved(t)`
- Terms:
- TERM-inventory-available（利用可能在庫）
- TERM-inventory-total（総在庫）
- TERM-inventory-reserved（予約済み在庫）
- Exceptions:
- None
- Violation Handling:
- Severity: S1
- When Violated: quarantine（出荷停止）| audit（反例保存）
- Owner: inventory-team
- Verification:
- Test: `prop_inventory_balance` (PBT)
- Runtime Check: `assert_balance()` in post-commit hook
- Observability:
- Telemetry: `law.inventory.available_balance.violated_total`
- Log/Event: `inventory.balance.violation` with `{expected, actual, diff}`
Law Card作成後、Law Catalogに追加:
| ID | Type | Scope | Severity | Owner | Status |
|----|------|-------|----------|-------|--------|
| LAW-inv-available-balance | Invariant | inventory.* | S1 | inventory-team | Active |
| Law ID | Type | Test | Runtime Check | Telemetry | Notes |
|--------|------|------|---------------|-----------|-------|
| LAW-inv-available-balance | Invariant | prop_inventory_balance | assert_balance | law.inventory.* | - |
/eld-spec-link で Law <-> Term の関係を管理| 種別 | 定義 | 例 |
|---|---|---|
| Term（用語） | ビジネス上の概念・名詞 | 「利用可能在庫」「注文」 |
| Type（型） | 技術的な型・構造 | OrderId, Quantity |
| Value（値制約） | 値の範囲・形式 | 1 ≤ qty ≤ 100 |
| Context（文脈） | 用語が使われる文脈 | 「在庫管理」「注文処理」 |
## TERM-<domain>-<name> (ID)
### 基本情報
- Meaning: <定義（1〜2文）>
- Context: <使用される文脈・ドメイン>
- Synonyms: <同義語があれば列挙>
- Non-goals: <この用語が意味しないもの>
### 型・形状
- Type/Shape: <技術的な型表現>
- Constraints: <値制約>
- Example Values: <具体例>
### 境界と接地
- IO Boundaries: <どこで入力/出力されるか>
- Validation: <境界での検証方法>
- Normalization: <正規化処理>
- Observable Fields: <ログ/テレメトリで観測するフィールド>
### 関連Law
- Related Laws (at least one for S0/S1 Terms):
- <関連するLaw ID>
/eld-spec-link で Term <-> Law の関係を記録## TERM-inventory-available
### 基本情報
- Meaning: 現時点で注文に割り当て可能な在庫数量
- Context: 在庫管理、注文処理
- Synonyms: 有効在庫、販売可能在庫
- Non-goals: 物理的な在庫数（予約済みを含む）
### 型・形状
- Type/Shape: `AvailableStock = Brand<number, 'AvailableStock'>`
- Constraints: `available ≥ 0`, `available ≤ total`
- Example Values: 0, 50, 1000
### 境界と接地
- IO Boundaries:
- Input: 在庫API、管理画面
- Output: 注文API、商品詳細
- Validation: `z.number().nonnegative().max(MAX_STOCK)`
- Normalization: 小数点以下切り捨て
- Observable Fields: `inventory.available`, `inventory.available_diff`
### 関連Law
- Related Laws:
- LAW-inv-available-balance（利用可能在庫の計算式）
- LAW-pre-order-quantity（注文数量上限）
Term Card作成後、Vocabulary Catalogに追加:
| ID | Meaning | Context | Type | Owner | Status |
|----|---------|---------|------|-------|--------|
| TERM-inventory-available | 利用可能在庫 | 在庫管理 | S1 | inventory-team | Active |
/eld-spec-link で Term <-> Law の関係を管理| チェック項目 | 確認内容 |
|---|---|
| 意味明確性 | Meaningが1〜2文で明確か |
| 境界定義 | IO Boundariesが具体的か |
| 検証実装 | Validationが実装されているか |
| 観測可能 | Observable Fieldsが設定されているか |
| Law紐付け | S0/S1 TermにRelated Lawsがあるか |
| Law孤立 | すべてのLawにTerms参照があるか |
| Verification | Test/Runtime Checkが最低1つあるか |
| Observability | Telemetry/Log/Eventが最低1つあるか |
デザインシステムの構築・運用を体系的に行うスキル。ドキュメント（要件定義・ブランドガイドライン）からDesign Tokens・コンポーネント体系・ガバナンスまでを一貫して設計する。思考フレームワーク（Double Diamond・Atomic Design・Design Tokens 3層）の適用、暗黙的デザイン判断の形式知化（DDR/QOC/RFC）、UIインベントリ収集（手動+MCP自動化）を統合する。ゼロから体系的に構築する用途向け。既存の単発UIから再利用可能な構造を抽出するにはrelational-design-pluginのdesign-system-backflowスキルを使用すること。Use when: 「デザインシステムを構築して」「デザインシステムを設計して」「デザイントークンを定義して」「デザイン原則を策定して」「UIインベントリを作って」「デザインガバナンスを設計して」「デザイン判断を記録して」と言われた時。
iOS/Androidモバイルアプリのデザインを体系的に行うスキル。Apple HIG・Material Design 3などプラットフォームガイドラインに準拠し、ナビゲーション・レイアウト・コンポーネント・モーション・アクセシビリティを適切に設計する。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「モバイルアプリをデザインして」「iOSアプリのUIを設計して」「Androidアプリの画面を作って」「モバイルのナビゲーションを設計して」「タッチUIを改善して」「アプリのアクセシビリティを対応して」と言われた時。
Webアプリの個別画面・コンポーネントのデザインを体系的に行うスキル。デザインプロセス・レイアウト・コンポーネント設計・インタラクション・アクセシビリティなどWebデザインの確立された手法を適用する。デザインシステム全体の構築・運用はdesign-system-builderスキルを使用すること。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「Webアプリをデザインして」「UIを設計して」「画面をデザインして」「レスポンシブ対応して」「アクセシビリティを改善して」「コンポーネントを設計して」「カラーパレットを決めて」と言われた時。
Use this skill when a design assumption, user segment, business goal, constraint, or product requirement has changed and you need to analyze which design hypotheses, decisions, artifacts, copy, or components should be retracted or revised. Requires a Relational Design trace session with recorded observations/relations/hypotheses/decisions to analyze against — not a general "redo this design" request.
Use this skill to critique an existing UI, frontend implementation, wireframe, flow, or visual design through Relational Design relations: user state, business intent, action risk, trust, information density, reversibility, accessibility, and implementation constraints. This is a relation-based critique, not a general design-methodology review — for platform-guideline or design-system compliance review, use design-plugin instead.
Use this skill after creating or reviewing a design artifact to extract reusable design-system knowledge: semantic tokens, components, variants, interaction rules, copy patterns, accessibility constraints, and governance notes. This only backflows structure out of an artifact that already exists — to build or govern a design system from scratch (Design Tokens layers, Atomic Design, DDR/QOC/RFC, UI inventory), use design-plugin's design-system-builder instead.