Record Designer

Documents

record-designer

Record 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 record types (model, list, set). Use when user says: "design model template", "create item list extraction", "extract items", "deduplicate entities". Trigger: User wants to extract structured records, lists, or deduplicated entities. Skip: User mentions graph, relations, or knowledge graph (use graph-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/record-designer/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/record-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.

Record Designer: model/list/set

Input from Brainstorm

Receive design specs from brainstorm:

What fields to extract
Field types and requirements
Deduplication needs (for set)

Workflow

Confirm type (model/list/set)
Design fields (output.fields)
Configure identifiers (identifiers.item_id for set)
Set display (display.label)
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 key information for...")	Field definitions ("field_a is for...")
Quality requirements ("maintain format consistency")	Type descriptions ("type field should be...")
Deduplication rules (for set type)	Required/optional clarifications
Common mistakes to avoid	Default value explanations

Type Confirmation

Type	Identifiers	Use Case
model	Not needed	Single object
list	Not needed	List of items
set	`item_id` required	Deduplicated entities

Output Template

language: en

name: [TemplateName]
type: [model/list/set]
tags: [...]
description: '...'

output:
  description: '...'
  fields:
    - name: field_name
      type: str/int/float/list
      description: '...'
      required: true/false
      default: '...'

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

identifiers: {}  # Or item_id for set

display:
  label: '{field_name}'

Type-Specific Output

model

type: model
identifiers: {}  # Not needed

list

type: list
identifiers: {}  # Not needed

set

type: set
identifiers:
  item_id: [deduplication field]

Cases by Type

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

Type	Case File
model	cases/earnings-summary.yaml
list	cases/product-features.yaml
set	cases/entity-registry.yaml

Reference Files

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

Topic	When to Check
references/field.md	When designing output.fields
references/identifier.md	For set type only

Design Checklist

All fields have clear semantic meaning?
Field types are appropriate (str/int/float/list)?
Required vs optional is reasonable?
Default values are safe/meaningful?
For set: item_id can uniquely identify records?
Display label references correct fields?

Guideline (Must Check)

No field definitions repeated from schema?
Extraction strategy defined?
Quality requirements specified?
Common mistakes warned?
For set: deduplication rules clear?

Multi-language

zh descriptions use pure Chinese
en descriptions use pure English