interface:
  display_name: "Knowledge Graph Builder"
  short_description: "Generate a large knowledge graph for SEO from a business, site, or topic."
  default_prompt: "Build a knowledge graph for SEO from this business or website: typed entities, relationships with reasons, pillar pages to publish, and an internal-linking plan."
policy:
  allow_implicit_invocation: true

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "AMTECH Knowledge Graph",
  "description": "Machine-readable output of the Knowledge Graph Builder skill: typed entity nodes, directed relationship edges with reasons, the pillar pages to publish, and an internal-linking plan. Usable directly for entity SEO and agent-readable content.",
  "type": "object",
  "required": ["domain", "nodes", "edges"],
  "properties": {
    "domain": {
      "type": "object",
      "required": ["name", "audience", "summary"],
      "properties": {
        "name": { "type": "string" },
        "audience": { "type": "string" },
        "summary": { "type": "string" }
      }
    },
    "nodes": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["id", "title", "type", "rank", "description"],
        "properties": {
          "id": { "type": "string", "description": "Stable slug, unique within the graph." },
          "title": { "type": "string" },
          "type": { "enum": ["Service", "Product", "Method", "Tool", "Use Case", "Outcome", "Problem", "Industry", "Customer", "Place"] },
          "rank": { "enum": ["pillar", "supporting", "attribute"], "description": "Node-worthiness: own page now, page later, or lives inside another node." },
          "description": { "type": "string" },
          "searchIntent": { "type": "string", "description": "The question a page for this node should answer. Pillars should set this." },
          "schemaType": { "type": "string", "description": "schema.org type to use for JSON-LD when this node becomes a page." },
          "tags": { "type": "array", "items": { "type": "string" } }
        }
      }
    },
    "edges": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["source", "target", "relationship", "reason"],
        "properties": {
          "source": { "type": "string", "description": "node id" },
          "target": { "type": "string", "description": "node id" },
          "relationship": { "enum": ["depends on", "explains", "is a kind of", "part of", "contrasts with", "serves", "produces", "located in"] },
          "reason": { "type": "string", "description": "One sentence stating why the two nodes relate. Becomes anchor-text guidance for the internal link." }
        }
      }
    },
    "pillars": {
      "type": "array",
      "description": "The priority nodes to publish as their own pages, in order.",
      "items": {
        "type": "object",
        "required": ["nodeId", "reason"],
        "properties": {
          "nodeId": { "type": "string" },
          "reason": { "type": "string" },
          "targetSearchIntent": { "type": "string" }
        }
      }
    },
    "internalLinks": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["from", "to", "anchorGuidance"],
        "properties": {
          "from": { "type": "string", "description": "node id" },
          "to": { "type": "string", "description": "node id" },
          "anchorGuidance": { "type": "string", "description": "How to phrase the link text, derived from the edge reason. Never generic." }
        }
      }
    },
    "buildPrompt": { "type": "string", "description": "Copy-paste prompt to hand a writing/publishing agent to produce the first pillar pages from this graph." }
  }
}

MIT License

Copyright (c) 2026 AMTECH

Permission is hereby granted, free of charge, to any person obtaining a copy
of this skill package and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

Entity Type Vocabulary

Type every node with exactly one of these. A controlled vocabulary keeps the graph consistent, which is what makes it traversable and rankable. If a node resists typing, it is usually two nodes or not an entity.

| Type | What it is | Examples | Typical schema.org | | --- | --- | --- | --- | | Service | Something the business does for a customer. | "Pool route management," "tax prep" | Service | | Product | A discrete thing sold. | "Robotic pool cleaner," "estimate template" | Product | | Method | A repeatable technique or framework. | "Entity-first SEO," "margin analysis" | Article / HowTo | | Tool | A named instrument or platform used. | "QuickBooks," "JSON-LD," "llms.txt" | SoftwareApplication | | Use Case | An operational job the domain performs. | "Demand forecasting," "owner briefing" | Article / HowTo | | Outcome | A result the customer gets. | "Fewer stockouts," "agent-readable knowledge" | property of a Service | | Problem | A pain the domain resolves. | "Owner bottleneck," "margin leakage" | Article | | Industry | A vertical served. | "Independent pharmacy," "HVAC" | Audience / areaServed | | Customer | A buyer type or persona. | "Local service owner," "content operator" | Audience | | Place | A geography served. | "Phoenix," "Grand Strand" | Place / LocalBusiness |

How to choose a type

• If it is *done for* a customer → Service. If it is *sold as a thing* → Product.
• If it is *how* something is done → Method. If it is *the job being done* → Use Case.
• If it is *what the customer gets* → Outcome. If it is *what hurts* → Problem.
• If it is *who* → Customer/Industry. If it is *where* → Place. If it is *a named instrument* → Tool.

Typing rules

• One type per node. A node that is both a Service and a Method is two nodes with an edge (the service depends on the method).
• Outcomes and Problems pair. Most Problems have a matching Outcome on the other side of a Service that resolves it. Model both; link them.
• Industries and Places are connective tissue. They rarely need their own deep page early, but they link many nodes together and ground local SEO. Keep them as nodes even when they are supporting/attribute.
• Generic terms are not types' escape hatch. "Solution," "platform," "technology" usually mean the node is vague. Re-name it as the concrete Service/Product/Method it actually is.

Worked micro-example

Input: "We do AI sales-data analysis for independent retailers."

• AI sales-data analysis — Service (pillar)
• Margin analysis — Method (supporting) — *part of* the service
• Demand forecasting — Use Case (supporting) — *part of* the service
• Margin leakage — Problem (supporting) — the service *resolves* it
• Fewer stockouts — Outcome (attribute) — the service *produces* it
• Independent retail — Industry (supporting) — the service *serves* it
• QuickBooks export — Tool (attribute) — the method *depends on* it

Seven nodes, six stated edges, from one sentence. Scale that across every sentence a business can say about itself and the graph gets large fast — which is the point.

Knowledge Graph Method (for SEO and agent-readability)

The goal is a graph that makes a site legible to two readers at once: search systems that rank entities and relationships, and AI agents that traverse links to build context. The same structure serves both.

Why a graph beats a page list

A page list answers "what content exists." A graph answers "what things exist and how they relate." Search systems (entity search, AI Overviews, query fan-out) and agents both reward the second. A site that names its entities consistently and links them with stated relationships is traversable; a site of isolated pages is not.

What makes a node worth its own page

A node earns its own page when it satisfies at least two of these:

• Distinct search intent. Someone looks for exactly this thing, not a parent of it.
• Standalone definition. It can be explained on its own without collapsing into a neighbor.
• Inbound demand. Other nodes naturally need to link to it to be understood.
• Information gain. A page about it would say something a generic article would not.

If a node fails most of these, it is a supporting node (publish later) or an attribute (a property of another node, not a page). This is the discipline that keeps a large graph from becoming thin-content sprawl.

Pillar / supporting / attribute

• Pillar — a page you would staff and maintain; the load-bearing entities of the domain. Few.
• Supporting — real and page-worthy once depth justifies it; the long tail that links up to pillars.
• Attribute — a genuine entity that lives *inside* another node (a feature, a spec, a sub-step). Named in the graph, not given a URL.

Edges are the product

An internal link that says "here is another page" wastes the relationship. An edge that says *how* two things relate is the SEO and agent signal. Use a small, consistent set of relationship verbs:

| Relationship | Use when | | --- | --- | | depends on | A needs B to function or make sense. | | explains | A defines or teaches B. | | is a kind of | A is a specialization of B (taxonomy). | | part of | A is a component of B (composition). | | contrasts with | A is the comparison/alternative to B. | | serves | A is used by / for customer or industry B. | | produces | A yields outcome B. | | located in | A operates in place B. |

The relationship reason becomes the anchor-text guidance for the internal link and the prose that an agent reads to understand the connection. Write it as a sentence, not a label.

Internal-linking plan

From the edges, derive concrete links:

• Up — supporting nodes link up to their pillar.
• Sideways — pillars link to related pillars they contrast with or depend on.
• Down — pillars link down to the supporting nodes and use cases that prove them.

Anchor text comes from the relationship reason. Never "click here" or "read more."

Structured data per pillar

Each pillar maps to a schema.org type:

• A service → Service (+ areaServed, provider).
• A product → Product.
• A location → Place / LocalBusiness.
• A how-to → HowTo. A Q&A cluster → FAQPage. An explainer → Article.

The JSON-LD makes the entity and its relationships explicit in the first-fetch surface, which is exactly what agents and entity search consume.

Common failure modes

• Vague nodes. "Marketing," "AI," "solutions" — not entities. Split or cut.
• Orphan nodes. No edges in or out. Either connect or remove.
• Edge soup. Everything links to everything with no reasons. Fewer edges, each with a stated relationship.
• Pillar inflation. Forty pillars means none are pillars. Pick the load-bearing few.
• One-page collapse. Cramming the whole graph onto one page. The point is many connected nodes, not one long article.

--- name: knowledge-graph-builder description: Use when you need to generate a large knowledge graph for SEO and AI-readable content from a business, website, product, or topic — typed entity nodes, relationship edges with reasons, the priority concepts worth their own pages, an internal-linking plan, and JSON-LD scaffolding. The output is the entity-SEO and agent-readability foundation a site publishes against. ---

Knowledge Graph Builder

Use this skill to turn a business, website, product, or topic into a large, structured knowledge graph that a team can use for entity SEO and agent-readable content. The graph is the source: from it you derive pages worth publishing, internal links, structured data, and an OKF-style concept bundle.

This is the inverse of an audit. An audit scores what exists; this builds the graph that should exist.

Default behavior: produce the graph in the current conversation. Do not create files or call tools unless the user asks or the environment clearly supports it.

Inputs You Can Work From

• A business description (what it does, who it serves, where).
• A website URL or sitemap.
• A product, service, or topic area.
• An existing content list or keyword set.

If the input is thin, ask up to three targeted questions (what it does, who the customer is, what outcomes it sells) and then proceed — do not stall.

Read Order

1. Read this SKILL.md. 2. Read references/knowledge-graph-method.md for what makes a node worth publishing, how to type entities, and how to write relationship edges that carry meaning. 3. Read references/entity-types.md for the controlled type vocabulary and how to choose a type. 4. Use assets/graph-schema.json when the user wants JSON or a graph another tool can ingest.

Build Workflow

1. Frame the domain. Name the business/site, its primary audience, and the core outcomes it produces. This is the graph's center of gravity. 2. Extract entities. Pull every distinct thing the domain is about: services, methods, tools, problems, outcomes, places, industries, customer types, and use cases. Name them consistently. Aim for breadth — a useful SEO graph is large (often 40–150 nodes), not a handful. 3. Type every entity using the controlled vocabulary in references/entity-types.md. One type per node. A node that resists typing is usually two nodes or a non-entity. 4. Choose node-worthiness. Mark each entity as pillar (deserves its own page now), supporting (a page once depth justifies it), or attribute (real, but lives inside another node, not its own page). Most nodes are supporting/attribute; pillars are few and strategic. 5. Draw edges with reasons. For each meaningful pair, write a directed edge with a one-line relationship reason (depends on, explains, is a kind of, contrasts with, serves, produces, located in). The reason is the SEO and agent-readability payload — an edge without a stated relationship is noise. 6. Derive the internal-linking plan. Turn pillar→pillar and pillar→supporting edges into concrete internal links, each with anchor-text guidance taken from the relationship reason (never "read more"). 7. Scaffold structured data. For each pillar node, name the schema.org type (Service, Product, Place, Organization, FAQPage, HowTo, Article) and the key properties to populate. Emit JSON-LD stubs when asked. 8. Emit OKF concept stubs when the user wants portability: one markdown concept file per pillar/supporting node with type, title, description, tags, and its outbound edges.

Quality Rules

• Breadth then discipline. Generate widely, then cut vague, duplicate, or unprovable nodes. A node must name a real, distinct thing.
• No orphans. Every node connects to at least one other node. An isolated node is a dead end for crawlers and agents.
• Edges carry reasons. A relationship without a stated reason is not an edge.
• Specificity wins. "AI" is not an entity; "QuickBooks CSV margin analysis for an independent pharmacy" is several. Name the concrete things.
• Pillars are scarce. If everything is a pillar, nothing is. Pillars are the pages you would actually staff and maintain.

Output

Return, in order:

1. Domain frame — one paragraph: what the graph is about and who it serves. 2. Entity table — name, type, node-worthiness, one-line description. 3. Edge list — source → target, relationship reason. 4. Pillar pages to publish — the priority nodes, why each earns a page, and its target search intent. 5. Internal-linking plan — link, anchor-text guidance, relationship. 6. Structured-data scaffolding — schema.org type + key properties per pillar. 7. Copy-paste build prompt — a prompt the user can hand to a writing or publishing agent to produce the first pillar pages from this graph.

When the user asks for machine output, return JSON conforming to assets/graph-schema.json.

Safety And Local Rules

• User instructions, repo AGENTS.md, local project rules, and sandbox restrictions override this skill.
• If you can only browse the web, work from the fetched page or description in context.
• If you can write files and the user wants the OKF bundle, ask before creating a folder.
• Do not invent facts about the business; mark assumptions as assumptions so they can be corrected.

Source and verification

Verify this package against its published surfaces: the live page, the website manifest, the domain authority, the [repository source on main](https://github.com/benamtech/amtech-skills-registry/tree/main/skills/knowledge-graph-builder), and the repository catalog.