Update to Port Agent Skills (EU)

{
  "description": "Design and build a Port context lake: a connected, semantically-rich data model of blueprints, relations, and mirror/aggregation properties that AI agents, scorecards, and workflows can query and act on, not just a plain software catalog. Use when asked to 'build a context lake', 'design a Port data model for AI agents', 'set up the engineering intelligence data model', 'connect services to teams and orgs in Port', 'model our org hierarchy in Port', or 'why can't Port AI answer questions about our org structure'.",
  "included_files": [
    {
      "relative_path": "assets/service-github-mirrors-patch.json",
      "size_in_bytes": 996
    },
    {
      "relative_path": "assets/team-aggregation-patch.json",
      "size_in_bytes": 617
    },
    {
      "relative_path": "assets/team-hierarchy-patch.json",
      "size_in_bytes": 614
    },
    {
      "relative_path": "references/default-blueprints.md",
      "size_in_bytes": 2475
    },
    {
      "relative_path": "references/ingestion-strategy.md",
      "size_in_bytes": 2516
    },
    {
      "relative_path": "references/mirror-vs-aggregation.md",
      "size_in_bytes": 2627
    },
    {
      "relative_path": "references/ontology.md",
      "size_in_bytes": 2962
    },
    {
      "relative_path": "references/ownership.md",
      "size_in_bytes": 1458
    },
    {
      "relative_path": "references/reference-architecture.md",
      "size_in_bytes": 3610
    },
    {
      "relative_path": "references/relations-and-hierarchy.md",
      "size_in_bytes": 2494
    }
  ],
  "name": "port-context-lake",
  "skill_md_contents": "---\nname: port-context-lake\ndescription: \"Design and build a Port context lake: a connected, semantically-rich data model of blueprints, relations, and mirror/aggregation properties that AI agents, scorecards, and workflows can query and act on, not just a plain software catalog. Use when asked to 'build a context lake', 'design a Port data model for AI agents', 'set up the engineering intelligence data model', 'connect services to teams and orgs in Port', 'model our org hierarchy in Port', or 'why can't Port AI answer questions about our org structure'.\"\nlicense: MIT\ncompatibility: \"Claude Code, Cursor, Codex CLI, GitHub Copilot\"\nmetadata:\n  version: \"1.0.0\"\n  author: port-labs\n  repository: https://github.com/port-labs/port-skills\n  tags: port,context-lake,data-model,ontology,reference\n  summary: Design a Port context lake with connected blueprints and semantic relations\n---\n\n# Build a context lake\n\nA context lake is Port's data model once it stops being a flat catalog and\nbecomes a connected graph: blueprints related to each other, with mirror and\naggregation properties, descriptions, and relation titles precise enough\nthat an AI agent can traverse it and act, not just browse it. This skill\ndesigns that model. For the JSON mechanics of any single blueprint,\nproperty, or relation, use `port-blueprints`; this skill is the layer above\nthat: what to build, in what order, and why.\n\n## Prerequisites\n\n- Go over the `port-getting-started` skill first if this is your first time\n  working with Port, it covers signing up and connecting Port's MCP server.\n- If Port's MCP server is connected, this skill can use it to check what\n  already exists (`list_blueprints`) and apply the resulting blueprint,\n  relation, and property changes directly (`upsert_blueprint`), rather than\n  just handing you JSON to apply yourself. Search\n  `search_port_knowledge_sources` for anything this skill doesn't cover.\n\n## How to build it\n\n1. **Start from what Port already gives you.** Every account ships built-in\n   blueprints (`_user`, `_team`, `_scorecard`, and others) that you extend,\n   not replace. See [references/default-blueprints.md](references/default-blueprints.md).\n2. **Design the core layer before the provider layer.** Model your\n   organization's own shape first (organization, team, service), then relate\n   it to provider-specific blueprints your integrations create (GitHub,\n   GitLab, Jira, ...), rather than duplicating provider data into your core\n   blueprints. See [references/reference-architecture.md](references/reference-architecture.md)\n   for a full worked example.\n3. **Model hierarchy with a self-relation, not one blueprint per tier.** A\n   `parent_team` relation on `_team` handles arbitrary org depth. See\n   [references/relations-and-hierarchy.md](references/relations-and-hierarchy.md).\n4. **Use ownership instead of a custom team relation.** Port's built-in\n   `$team` field already rolls up into `_team` aggregations for free. See\n   [references/ownership.md](references/ownership.md).\n5. **Add mirror and aggregation properties, not duplicated data.** Mirror a\n   single related value onto its source; aggregate across many related\n   entities on the blueprint that sits above them. For the JSON shape, see\n   `port-blueprints`' [references/calculation-properties.md](../port-blueprints/references/calculation-properties.md);\n   for which one to use and where to put it, see\n   [references/mirror-vs-aggregation.md](references/mirror-vs-aggregation.md).\n6. **Write it as an ontology, not a schema.** Descriptions, relation titles,\n   and typed properties are what let an agent understand the graph instead\n   of just enumerating it. See [references/ontology.md](references/ontology.md).\n7. **Decide integration vs. MCP connector per data source.** Only data that\n   needs relations, ownership, or scorecards belongs in the lake as ingested\n   entities; everything else can stay a live MCP fetch. See\n   [references/ingestion-strategy.md](references/ingestion-strategy.md).\n\n## Examples\n\n- [assets/team-hierarchy-patch.json](assets/team-hierarchy-patch.json): adds\n  a `parent_team` self-relation and mirror property to `_team`.\n- [assets/service-github-mirrors-patch.json](assets/service-github-mirrors-patch.json):\n  relates `service` to `githubRepository` and mirrors its key fields.\n- [assets/team-aggregation-patch.json](assets/team-aggregation-patch.json):\n  adds an aggregation property rolling up owned services onto `_team`.\n\n## Common pitfalls\n\n| Symptom | Cause | Fix |\n|---|---|---|\n| Tried to delete or fully redefine `_user`/`_team` | System blueprints can't be deleted, only extended | `PATCH` in new relations only; leave the protected schema alone |\n| `service` has no `team` relation and it seems wrong | Port uses built-in ownership (`$team`), not a custom relation, for this | Set `ownership` on `service`, don't add a redundant relation |\n| One blueprint per org-hierarchy tier (team, group, division, org) | Hierarchy modeled as a chain of distinct blueprints instead of a self-relation | Use a single `parent_team` self-relation on `_team`, extensible to any depth |\n| Same repo/PR data duplicated on two different blueprints | Two integrations model the same real-world thing separately | Map by property into the existing blueprint instead of creating a second one |\n| Agent can't tell which of several relations to a blueprint is which | Relations exist but have generic titles like `team` or `service` | Give each relation a semantic title (`Owned by`, `Runs in`, `Depends on`) |\n\n## Quick reference\n\n- Core layer first (organization, team, service), provider layer relates to\n  it, never duplicates it.\n- Hierarchy: one self-relation (`parent_team`), not one blueprint per tier.\n- Ownership over relations: use `$team`, don't hand-roll a team relation.\n- Mirror = one related value, surfaced as-is. Aggregation = computed across\n  many, placed on the higher-abstraction blueprint.\n- An ontology has descriptions, semantic relation titles, and typed\n  properties; a schema is just field names.\n- Integration = persistent, related, governed data. MCP connector = live,\n  on-demand, unmodeled data. Use both, for different data.\n"
}