des-persona-source-domain-analyst

Classify source system behavior and document time semantics for data ingestion.

2|Updated May 20, 2026
One-click install
npx skills add https://github.com/DKSang/DES-SKILL --skill des-persona-source-domain-analyst
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: des-persona-source-domain-analyst
Source: https://github.com/DKSang/DES-SKILL/tree/main/skills/des-persona-source-domain-analyst
Command: npx skills add https://github.com/DKSang/DES-SKILL --skill des-persona-source-domain-analyst

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents data engineering designs from being built on guessed source semantics by making source ownership, write patterns, and time behavior explicit before ingestion and downstream modeling.

Core Features & Use Cases

  • Source system assessment: Classify whether data comes from OLTP, APIs, IoT, logs, messages, or third parties and document operational behavior like CRUD vs insert-only.
  • Time semantics separation: Distinguish event time, system/database time, and ingestion time so correctness and latency expectations are grounded in reality.
  • Domain grain & boundary definition: Make domain entities and source grain a contract to guide architecture without prescribing target storage or transformations.
  • Use case: When onboarding a new source (e.g., an events API or CDC stream) where deletes, schema drift, or pagination behavior are unclear, this skill helps you document the facts needed to proceed safely.

Quick Start

Use des-persona-source-domain-analyst to assess your source systems and produce a documented summary of source behavior, time semantics, ownership, and domain grain readiness.

Frequently Asked Questions about des-persona-source-domain-analyst

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I assess source system behavior before data ingestion?▼

To assess source system behavior before data ingestion, classify whether data comes from OLTP, APIs, IoT, or logs, and document operational write patterns like CRUD, insert-only, or CDC. This documents operational facts to proceed safely with domain modeling.

What is the best way to separate time semantics for event time and ingestion time?▼

Separating time semantics requires distinguishing event time, system or database time, and ingestion time. This grounds correctness and latency expectations in reality, preventing incorrect assumptions from driving downstream data engineering designs and schema drift policies.

How do I handle schema drift and deletes when onboarding a new CDC stream?▼

Handling schema drift and deletes when onboarding a CDC stream involves explicitly documenting the source's delete behavior and schema change policy. This clarifies source ownership and defines handoff rules without prescribing target storage or transformation strategies.

Why do I need to define domain grain and entity boundaries for data contracts?▼

Defining domain grain and entity boundaries for data contracts makes source grain explicit to guide architecture safely. This prevents guessed source semantics from driving ingestion and downstream modeling, ensuring domain meaning acts as a reliable handoff contract.

Can I use this approach to document source ownership for third-party data?▼

Yes, you can use this approach to document source ownership for third-party data. It classifies source origins and operational behavior, explicitly mapping out write patterns, domain boundaries, and time semantics to stop incorrect assumptions from disrupting data pipelines.