skillgen: tell extraction subagents not to emit JSON-Schema keyword nodes

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.