diff --git a/graphify/skills/agents/references/extraction-spec.md b/graphify/skills/agents/references/extraction-spec.md index 388df7674..506b268da 100644 --- a/graphify/skills/agents/references/extraction-spec.md +++ b/graphify/skills/agents/references/extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/graphify/skills/amp/references/extraction-spec.md b/graphify/skills/amp/references/extraction-spec.md index 388df7674..506b268da 100644 --- a/graphify/skills/amp/references/extraction-spec.md +++ b/graphify/skills/amp/references/extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/graphify/skills/claude/references/extraction-spec.md b/graphify/skills/claude/references/extraction-spec.md index 388df7674..506b268da 100644 --- a/graphify/skills/claude/references/extraction-spec.md +++ b/graphify/skills/claude/references/extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/graphify/skills/claw/references/extraction-spec.md b/graphify/skills/claw/references/extraction-spec.md index 4b278b28d..dbdde15f4 100644 --- a/graphify/skills/claw/references/extraction-spec.md +++ b/graphify/skills/claw/references/extraction-spec.md @@ -15,6 +15,7 @@ Rules: - AMBIGUOUS: uncertain — flag it, do not omit - Code files: semantic edges AST cannot find. Do not re-extract imports. When adding `calls` edges: source is the caller, target is the callee, never reversed; keep `calls` within one language. - Doc/paper files: named concepts, entities, citations. Store rationale (WHY decisions were made) as a `rationale` attribute on the relevant node, not as a separate node. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms) and `file_type:"concept"` for named concepts. `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. +- JSON-Schema / contract files (`*.schema.json`, `events-*.json`, top-level `$schema` or `$defs`): extract the domain the schema describes — event types, payload names, enum values, field semantics. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`) — they recur once per definition and collapse into meaningless communities. Link a definition straight to its fields and values, never via the keyword that nested them. - Image files: use vision — understand what the image IS, not just OCR - DEEP_MODE (if --mode deep): be aggressive with INFERRED edges — indirect deps, shared assumptions, latent couplings. Mark uncertain ones AMBIGUOUS instead of omitting. - Semantic similarity: if two concepts solve the same problem or represent the same idea without a structural link (no import, call, or citation), add a `semantically_similar_to` edge marked INFERRED with confidence_score 0.6-0.95. Non-obvious cross-file links only. diff --git a/graphify/skills/codex/references/extraction-spec.md b/graphify/skills/codex/references/extraction-spec.md index 4b278b28d..dbdde15f4 100644 --- a/graphify/skills/codex/references/extraction-spec.md +++ b/graphify/skills/codex/references/extraction-spec.md @@ -15,6 +15,7 @@ Rules: - AMBIGUOUS: uncertain — flag it, do not omit - Code files: semantic edges AST cannot find. Do not re-extract imports. When adding `calls` edges: source is the caller, target is the callee, never reversed; keep `calls` within one language. - Doc/paper files: named concepts, entities, citations. Store rationale (WHY decisions were made) as a `rationale` attribute on the relevant node, not as a separate node. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms) and `file_type:"concept"` for named concepts. `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. +- JSON-Schema / contract files (`*.schema.json`, `events-*.json`, top-level `$schema` or `$defs`): extract the domain the schema describes — event types, payload names, enum values, field semantics. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`) — they recur once per definition and collapse into meaningless communities. Link a definition straight to its fields and values, never via the keyword that nested them. - Image files: use vision — understand what the image IS, not just OCR - DEEP_MODE (if --mode deep): be aggressive with INFERRED edges — indirect deps, shared assumptions, latent couplings. Mark uncertain ones AMBIGUOUS instead of omitting. - Semantic similarity: if two concepts solve the same problem or represent the same idea without a structural link (no import, call, or citation), add a `semantically_similar_to` edge marked INFERRED with confidence_score 0.6-0.95. Non-obvious cross-file links only. diff --git a/graphify/skills/copilot/references/extraction-spec.md b/graphify/skills/copilot/references/extraction-spec.md index 388df7674..506b268da 100644 --- a/graphify/skills/copilot/references/extraction-spec.md +++ b/graphify/skills/copilot/references/extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/graphify/skills/droid/references/extraction-spec.md b/graphify/skills/droid/references/extraction-spec.md index 388df7674..506b268da 100644 --- a/graphify/skills/droid/references/extraction-spec.md +++ b/graphify/skills/droid/references/extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/graphify/skills/kilo/references/extraction-spec.md b/graphify/skills/kilo/references/extraction-spec.md index 388df7674..506b268da 100644 --- a/graphify/skills/kilo/references/extraction-spec.md +++ b/graphify/skills/kilo/references/extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/graphify/skills/kiro/references/extraction-spec.md b/graphify/skills/kiro/references/extraction-spec.md index 4b278b28d..dbdde15f4 100644 --- a/graphify/skills/kiro/references/extraction-spec.md +++ b/graphify/skills/kiro/references/extraction-spec.md @@ -15,6 +15,7 @@ Rules: - AMBIGUOUS: uncertain — flag it, do not omit - Code files: semantic edges AST cannot find. Do not re-extract imports. When adding `calls` edges: source is the caller, target is the callee, never reversed; keep `calls` within one language. - Doc/paper files: named concepts, entities, citations. Store rationale (WHY decisions were made) as a `rationale` attribute on the relevant node, not as a separate node. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms) and `file_type:"concept"` for named concepts. `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. +- JSON-Schema / contract files (`*.schema.json`, `events-*.json`, top-level `$schema` or `$defs`): extract the domain the schema describes — event types, payload names, enum values, field semantics. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`) — they recur once per definition and collapse into meaningless communities. Link a definition straight to its fields and values, never via the keyword that nested them. - Image files: use vision — understand what the image IS, not just OCR - DEEP_MODE (if --mode deep): be aggressive with INFERRED edges — indirect deps, shared assumptions, latent couplings. Mark uncertain ones AMBIGUOUS instead of omitting. - Semantic similarity: if two concepts solve the same problem or represent the same idea without a structural link (no import, call, or citation), add a `semantically_similar_to` edge marked INFERRED with confidence_score 0.6-0.95. Non-obvious cross-file links only. diff --git a/graphify/skills/opencode/references/extraction-spec.md b/graphify/skills/opencode/references/extraction-spec.md index 388df7674..506b268da 100644 --- a/graphify/skills/opencode/references/extraction-spec.md +++ b/graphify/skills/opencode/references/extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/graphify/skills/pi/references/extraction-spec.md b/graphify/skills/pi/references/extraction-spec.md index 4b278b28d..dbdde15f4 100644 --- a/graphify/skills/pi/references/extraction-spec.md +++ b/graphify/skills/pi/references/extraction-spec.md @@ -15,6 +15,7 @@ Rules: - AMBIGUOUS: uncertain — flag it, do not omit - Code files: semantic edges AST cannot find. Do not re-extract imports. When adding `calls` edges: source is the caller, target is the callee, never reversed; keep `calls` within one language. - Doc/paper files: named concepts, entities, citations. Store rationale (WHY decisions were made) as a `rationale` attribute on the relevant node, not as a separate node. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms) and `file_type:"concept"` for named concepts. `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. +- JSON-Schema / contract files (`*.schema.json`, `events-*.json`, top-level `$schema` or `$defs`): extract the domain the schema describes — event types, payload names, enum values, field semantics. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`) — they recur once per definition and collapse into meaningless communities. Link a definition straight to its fields and values, never via the keyword that nested them. - Image files: use vision — understand what the image IS, not just OCR - DEEP_MODE (if --mode deep): be aggressive with INFERRED edges — indirect deps, shared assumptions, latent couplings. Mark uncertain ones AMBIGUOUS instead of omitting. - Semantic similarity: if two concepts solve the same problem or represent the same idea without a structural link (no import, call, or citation), add a `semantically_similar_to` edge marked INFERRED with confidence_score 0.6-0.95. Non-obvious cross-file links only. diff --git a/graphify/skills/trae/references/extraction-spec.md b/graphify/skills/trae/references/extraction-spec.md index 388df7674..506b268da 100644 --- a/graphify/skills/trae/references/extraction-spec.md +++ b/graphify/skills/trae/references/extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/graphify/skills/vscode/references/extraction-spec.md b/graphify/skills/vscode/references/extraction-spec.md index 388df7674..506b268da 100644 --- a/graphify/skills/vscode/references/extraction-spec.md +++ b/graphify/skills/vscode/references/extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/graphify/skills/windows/references/extraction-spec.md b/graphify/skills/windows/references/extraction-spec.md index 388df7674..506b268da 100644 --- a/graphify/skills/windows/references/extraction-spec.md +++ b/graphify/skills/windows/references/extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/tools/skillgen/expected/graphify__skills__agents__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__agents__references__extraction-spec.md index 388df7674..506b268da 100644 --- a/tools/skillgen/expected/graphify__skills__agents__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__agents__references__extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/tools/skillgen/expected/graphify__skills__amp__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__amp__references__extraction-spec.md index 388df7674..506b268da 100644 --- a/tools/skillgen/expected/graphify__skills__amp__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__amp__references__extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/tools/skillgen/expected/graphify__skills__claude__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__claude__references__extraction-spec.md index 388df7674..506b268da 100644 --- a/tools/skillgen/expected/graphify__skills__claude__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__claude__references__extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/tools/skillgen/expected/graphify__skills__claw__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__claw__references__extraction-spec.md index 4b278b28d..dbdde15f4 100644 --- a/tools/skillgen/expected/graphify__skills__claw__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__claw__references__extraction-spec.md @@ -15,6 +15,7 @@ Rules: - AMBIGUOUS: uncertain — flag it, do not omit - Code files: semantic edges AST cannot find. Do not re-extract imports. When adding `calls` edges: source is the caller, target is the callee, never reversed; keep `calls` within one language. - Doc/paper files: named concepts, entities, citations. Store rationale (WHY decisions were made) as a `rationale` attribute on the relevant node, not as a separate node. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms) and `file_type:"concept"` for named concepts. `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. +- JSON-Schema / contract files (`*.schema.json`, `events-*.json`, top-level `$schema` or `$defs`): extract the domain the schema describes — event types, payload names, enum values, field semantics. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`) — they recur once per definition and collapse into meaningless communities. Link a definition straight to its fields and values, never via the keyword that nested them. - Image files: use vision — understand what the image IS, not just OCR - DEEP_MODE (if --mode deep): be aggressive with INFERRED edges — indirect deps, shared assumptions, latent couplings. Mark uncertain ones AMBIGUOUS instead of omitting. - Semantic similarity: if two concepts solve the same problem or represent the same idea without a structural link (no import, call, or citation), add a `semantically_similar_to` edge marked INFERRED with confidence_score 0.6-0.95. Non-obvious cross-file links only. diff --git a/tools/skillgen/expected/graphify__skills__codex__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__codex__references__extraction-spec.md index 4b278b28d..dbdde15f4 100644 --- a/tools/skillgen/expected/graphify__skills__codex__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__codex__references__extraction-spec.md @@ -15,6 +15,7 @@ Rules: - AMBIGUOUS: uncertain — flag it, do not omit - Code files: semantic edges AST cannot find. Do not re-extract imports. When adding `calls` edges: source is the caller, target is the callee, never reversed; keep `calls` within one language. - Doc/paper files: named concepts, entities, citations. Store rationale (WHY decisions were made) as a `rationale` attribute on the relevant node, not as a separate node. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms) and `file_type:"concept"` for named concepts. `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. +- JSON-Schema / contract files (`*.schema.json`, `events-*.json`, top-level `$schema` or `$defs`): extract the domain the schema describes — event types, payload names, enum values, field semantics. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`) — they recur once per definition and collapse into meaningless communities. Link a definition straight to its fields and values, never via the keyword that nested them. - Image files: use vision — understand what the image IS, not just OCR - DEEP_MODE (if --mode deep): be aggressive with INFERRED edges — indirect deps, shared assumptions, latent couplings. Mark uncertain ones AMBIGUOUS instead of omitting. - Semantic similarity: if two concepts solve the same problem or represent the same idea without a structural link (no import, call, or citation), add a `semantically_similar_to` edge marked INFERRED with confidence_score 0.6-0.95. Non-obvious cross-file links only. diff --git a/tools/skillgen/expected/graphify__skills__copilot__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__copilot__references__extraction-spec.md index 388df7674..506b268da 100644 --- a/tools/skillgen/expected/graphify__skills__copilot__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__copilot__references__extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/tools/skillgen/expected/graphify__skills__droid__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__droid__references__extraction-spec.md index 388df7674..506b268da 100644 --- a/tools/skillgen/expected/graphify__skills__droid__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__droid__references__extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/tools/skillgen/expected/graphify__skills__kilo__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__kilo__references__extraction-spec.md index 388df7674..506b268da 100644 --- a/tools/skillgen/expected/graphify__skills__kilo__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__kilo__references__extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/tools/skillgen/expected/graphify__skills__kiro__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__kiro__references__extraction-spec.md index 4b278b28d..dbdde15f4 100644 --- a/tools/skillgen/expected/graphify__skills__kiro__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__kiro__references__extraction-spec.md @@ -15,6 +15,7 @@ Rules: - AMBIGUOUS: uncertain — flag it, do not omit - Code files: semantic edges AST cannot find. Do not re-extract imports. When adding `calls` edges: source is the caller, target is the callee, never reversed; keep `calls` within one language. - Doc/paper files: named concepts, entities, citations. Store rationale (WHY decisions were made) as a `rationale` attribute on the relevant node, not as a separate node. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms) and `file_type:"concept"` for named concepts. `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. +- JSON-Schema / contract files (`*.schema.json`, `events-*.json`, top-level `$schema` or `$defs`): extract the domain the schema describes — event types, payload names, enum values, field semantics. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`) — they recur once per definition and collapse into meaningless communities. Link a definition straight to its fields and values, never via the keyword that nested them. - Image files: use vision — understand what the image IS, not just OCR - DEEP_MODE (if --mode deep): be aggressive with INFERRED edges — indirect deps, shared assumptions, latent couplings. Mark uncertain ones AMBIGUOUS instead of omitting. - Semantic similarity: if two concepts solve the same problem or represent the same idea without a structural link (no import, call, or citation), add a `semantically_similar_to` edge marked INFERRED with confidence_score 0.6-0.95. Non-obvious cross-file links only. diff --git a/tools/skillgen/expected/graphify__skills__opencode__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__opencode__references__extraction-spec.md index 388df7674..506b268da 100644 --- a/tools/skillgen/expected/graphify__skills__opencode__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__opencode__references__extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/tools/skillgen/expected/graphify__skills__pi__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__pi__references__extraction-spec.md index 4b278b28d..dbdde15f4 100644 --- a/tools/skillgen/expected/graphify__skills__pi__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__pi__references__extraction-spec.md @@ -15,6 +15,7 @@ Rules: - AMBIGUOUS: uncertain — flag it, do not omit - Code files: semantic edges AST cannot find. Do not re-extract imports. When adding `calls` edges: source is the caller, target is the callee, never reversed; keep `calls` within one language. - Doc/paper files: named concepts, entities, citations. Store rationale (WHY decisions were made) as a `rationale` attribute on the relevant node, not as a separate node. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms) and `file_type:"concept"` for named concepts. `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. +- JSON-Schema / contract files (`*.schema.json`, `events-*.json`, top-level `$schema` or `$defs`): extract the domain the schema describes — event types, payload names, enum values, field semantics. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`) — they recur once per definition and collapse into meaningless communities. Link a definition straight to its fields and values, never via the keyword that nested them. - Image files: use vision — understand what the image IS, not just OCR - DEEP_MODE (if --mode deep): be aggressive with INFERRED edges — indirect deps, shared assumptions, latent couplings. Mark uncertain ones AMBIGUOUS instead of omitting. - Semantic similarity: if two concepts solve the same problem or represent the same idea without a structural link (no import, call, or citation), add a `semantically_similar_to` edge marked INFERRED with confidence_score 0.6-0.95. Non-obvious cross-file links only. diff --git a/tools/skillgen/expected/graphify__skills__trae__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__trae__references__extraction-spec.md index 388df7674..506b268da 100644 --- a/tools/skillgen/expected/graphify__skills__trae__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__trae__references__extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/tools/skillgen/expected/graphify__skills__vscode__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__vscode__references__extraction-spec.md index 388df7674..506b268da 100644 --- a/tools/skillgen/expected/graphify__skills__vscode__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__vscode__references__extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/tools/skillgen/expected/graphify__skills__windows__references__extraction-spec.md b/tools/skillgen/expected/graphify__skills__windows__references__extraction-spec.md index 388df7674..506b268da 100644 --- a/tools/skillgen/expected/graphify__skills__windows__references__extraction-spec.md +++ b/tools/skillgen/expected/graphify__skills__windows__references__extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source. diff --git a/tools/skillgen/fragments/references/shared/extraction-spec-compact.md b/tools/skillgen/fragments/references/shared/extraction-spec-compact.md index 4b278b28d..dbdde15f4 100644 --- a/tools/skillgen/fragments/references/shared/extraction-spec-compact.md +++ b/tools/skillgen/fragments/references/shared/extraction-spec-compact.md @@ -15,6 +15,7 @@ Rules: - AMBIGUOUS: uncertain — flag it, do not omit - Code files: semantic edges AST cannot find. Do not re-extract imports. When adding `calls` edges: source is the caller, target is the callee, never reversed; keep `calls` within one language. - Doc/paper files: named concepts, entities, citations. Store rationale (WHY decisions were made) as a `rationale` attribute on the relevant node, not as a separate node. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms) and `file_type:"concept"` for named concepts. `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. +- JSON-Schema / contract files (`*.schema.json`, `events-*.json`, top-level `$schema` or `$defs`): extract the domain the schema describes — event types, payload names, enum values, field semantics. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`) — they recur once per definition and collapse into meaningless communities. Link a definition straight to its fields and values, never via the keyword that nested them. - Image files: use vision — understand what the image IS, not just OCR - DEEP_MODE (if --mode deep): be aggressive with INFERRED edges — indirect deps, shared assumptions, latent couplings. Mark uncertain ones AMBIGUOUS instead of omitting. - Semantic similarity: if two concepts solve the same problem or represent the same idea without a structural link (no import, call, or citation), add a `semantically_similar_to` edge marked INFERRED with confidence_score 0.6-0.95. Non-obvious cross-file links only. diff --git a/tools/skillgen/fragments/references/shared/extraction-spec.md b/tools/skillgen/fragments/references/shared/extraction-spec.md index 388df7674..506b268da 100644 --- a/tools/skillgen/fragments/references/shared/extraction-spec.md +++ b/tools/skillgen/fragments/references/shared/extraction-spec.md @@ -18,6 +18,7 @@ Code files: focus on semantic edges AST cannot find (call relationships, shared Do not re-extract imports - AST already has those. Doc/paper files: extract named concepts, entities, citations. For rationale (WHY decisions were made, trade-offs, design intent): store as a `rationale` attribute on the relevant concept node — do NOT create a separate rationale node or fragment node. Only create a node for something that is itself a named entity or concept. Use `file_type:"rationale"` for concept-like nodes (ideas, principles, mechanisms, design patterns). `file_type` MUST be one of exactly these six values: `code`, `document`, `paper`, `image`, `rationale`, `concept`. Any other value is invalid and will be rejected. Code files: when adding `calls` edges, source MUST be the caller (the function/class doing the calling), target MUST be the callee. Never reverse this direction. `calls` edges MUST stay within one language: a Python function cannot `calls` a JS/TS/Go/Rust/Java symbol and vice versa — cross-language call edges are phantom artifacts, never emit them. +JSON-Schema / contract files (`*.schema.json`, `events-*.json`, anything with a top-level `$schema` or `$defs`): extract the domain the schema describes - event types, payload names, enum values, field semantics, the definitions it composes. NEVER emit a node whose label is a bare schema keyword (`description`, `type`, `enum`, `required`, `$ref`, `properties`, `additionalProperties`, `oneOf`, `items`, `format`, `pattern`, `minimum`, `title`, `$comment`, `$id`). Those are structure, not knowledge: each recurs once per definition, so they collapse into communities whose entire membership is `description ~ $ref ~ type`. Link a definition straight to its fields and values (`envelope` contains `event_id`, `dataClassification` contains `CUI`), never via the keyword that nested them. Image files: use vision to understand what the image IS - do not just OCR. UI screenshot: layout patterns, design decisions, key elements, purpose. Chart: metric, trend/insight, data source.