Graph Designer

Documents

graph-designer

Graph Designer is an Agent Skill for documents published in the yifanfeng97/Hyper-Extract repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.

Design YAML extraction templates for graph types (graph, hypergraph, temporal_graph, spatial_graph). Use when user says: "design graph", "create knowledge graph", "extract relationships", "temporal data", "spatial data". Trigger: User wants to extract entity relationships, multi-party events, or time/location-based data. Skip: User wants simple record extraction (use record-designer instead).

View on GitHub ↗

QUICK START

How to use this skill

Bring this guide into your coding agent with a prompt tailored to the tool you use.

Open your project in Codex.
Copy and paste the prompt below.
Review files and risks before approving any action.

Prompt to paste

Inspect the Agent Skill at https://github.com/yifanfeng97/Hyper-Extract/blob/HEAD/hyperextract-skills/graph-designer/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/graph-designer, but wait for my approval before writing files or running scripts.

Copying this prompt does not install or run the skill. Review third-party files before use.

Graph Designer: graph/hypergraph/temporal/spatial

Input from Brainstorm

Receive design specs from brainstorm:

Entity types and fields
Relation types and fields
Hypergraph grouping strategy
Time/location requirements

Workflow

Confirm type based on brainstorm specs
Design entities (output.entities)
Design relations (output.relations)
Configure identifiers (identifiers)
Set display (display)
Write guideline (guideline)
Review and output YAML

Critical: Output vs Guideline

Key Principle: Schema defines "WHAT", Guideline defines "HOW TO DO WELL". DO NOT repeat schema definitions in guideline.

Guideline Should Have	Guideline Should NOT Have
Extraction strategy ("extract valuable entities")	Field definitions ("name should be...")
Quality requirements ("maintain naming consistency")	Type descriptions ("type field is...")
Creation conditions ("only when text explicitly states")	Reference requirements ("must reference name field")
Common mistakes to avoid	Schema field descriptions

Type Confirmation

Type	relation_members	Additional Config
graph	`{source, target}`	-
hypergraph (simple)	`participants` (string)	-
hypergraph (nested)	`[group_a, group_b]` (list)	-
temporal_graph	+ type	`time_field`
spatial_graph	+ type	`location_field`
spatio_temporal	+ both	`time_field` + `location_field`

Output Template

language: en

name: [TemplateName]
type: [type]
tags: [...]
description: '...'

output:
  entities:
    description: '...'
    fields:
      - name: name
        type: str
      - name: category
        type: str
  relations:
    description: '...'
    fields:
      # Type-specific fields

guideline:
  target: 'You are a [domain] expert...'
  rules_for_entities: [...]
  rules_for_relations: [...]

identifiers:
  entity_id: name
  relation_id: '...'
  relation_members: ...

display:
  entity_label: '{name} ({category})'
  relation_label: '...'

Display Design Principles

Important: display.label is used for graph visualization. Edges connect two nodes (source/target), so the edge label should NOT repeat this information.

Design Principles

Principle	entity_label	relation_label
Node	Show core identifier	-
Edge	-	Show relation type + optional dimensions
Spatio-temporal	-	Show relation type + location + time

Recommended relation_label by Type

Type	relation_label	Example
graph	`{relation_type}`	`owns`
hypergraph	`{event_name}` or `{outcome}`	`Battle of Red Cliffs`
spatio_temporal_graph	`{relation_type}@{location}({event_date})`	`meets@Beijing(1985)`

Length Reference

entity_label: Recommended 5-20 characters
relation_label: Recommended 10-30 characters

Quick Config Reference

Binary Relations (graph)

identifiers:
  relation_members:
    source: source
    target: target

Hypergraph Simple

identifiers:
  relation_members: participants  # STRING

Hypergraph Nested

identifiers:
  relation_members: [group_a, group_b]  # LIST

Temporal

identifiers:
  time_field: event_date

Spatial

identifiers:
  location_field: location

Cases by Type

Important: Load only the case matching user's selected type.

Type	Case File
graph	cases/corporate-ownership.yaml
hypergraph	cases/battle-analysis.yaml
spatio_temporal_graph	cases/biography-events.yaml

Reference Files

Important: Check these files only when needed for the specific design task.

Topic	When to Check
references/entity.md	When designing output.entities
references/relation.md	When designing output.relations
references/hypergraph.md	For hypergraph type only
references/dimensions.md	For temporal_graph/spatial_graph types

Design Checklist

Entities

Entity types cover key concepts?
Entity granularity appropriate?
Multi-type nodes handled?
No redundant fields?

Relations

Relation types semantically clear?
source/target reference entities?
No ambiguous relations?

Guideline (Must Check)

No field definitions repeated from schema?
Extraction strategy defined?
Quality requirements specified (naming consistency)?
Creation conditions clear ("only when text explicitly states")?
Common mistakes warned?

Hypergraph

Participant count reasonable?
Grouping strategy clear?
Outcome defined?

Identifiers

entity_id references name field?
relation_id template correct?
relation_members configured?
time/location_field specified?

Multi-language

zh descriptions use pure Chinese (no English terms like entity(...))
en descriptions use pure English (no Chinese characters)

Entity-Relation Consistency

source/target types match entities definition

Relation Type Design

For generic templates: Use open-ended description

en: 'Relation type, concisely describing the connection between entities'

For domain-specific templates: Can use predefined types

en: 'Relation type: type_a/type_b/type_c'