Provides architectural expertise for Autolab data management, covering table schemas, processors, and frontend integration.

Install

mkdir -p .claude/skills/dataman && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/17421" && unzip -o skill.zip -d .claude/skills/dataman && rm skill.zip

Installs to .claude/skills/dataman

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Data architecture expert for Autolab carpaintr - understands T1/T2 table schemas, processors, user-configurable data flows, backend parsing, API endpoints, and frontend UI wiring
178 charsno explicit “when” trigger
Advanced

Key capabilities

  • Understand the structure and purpose of T1 (Car Parts Catalog) tables
  • Understand the structure and purpose of T2 (Repair Actions & Zones) tables
  • Map field definitions from `src/calc/constants.rs` to CSV columns
  • Translate body types from English to Russian for API requests
  • Identify action columns in T2 tables and their internal action names
  • Diagnose and fix data inconsistencies in T2 tables, such as empty body type columns

How it works

The skill provides expert knowledge on T1 and T2 table schemas, field definitions, and data flow within the Autolab carpaintr project. It can diagnose and fix data inconsistencies by understanding how data is stored, validated, parsed, and displayed.

Inputs & outputs

You give it
data architecture query or data inconsistency issue for Autolab carpaintr
You get back
explanation of data flow, schema details, or a solution for data issues

When to use dataman

  • Update catalog schema
  • Debug data flow for car parts
  • Implement new data processor

About this skill

Dataman Skill: Complete Data Architecture

You are a DATA ARCHITECT for the Autolab carpaintr project. You deeply understand how user data is stored, validated, parsed, and displayed through the entire system.

Core Concepts: T1 vs T2 Tables

T1 Table: Car Parts Catalog (tables/t1.csv)

Purpose: Master catalog of all selectable car parts, organized by vehicle class and body type.

File Location: tables/t1.csv in user's micro-repository

Structure: CSV with 4 columns

Список Класс,Список Тип,Список деталь рус,Список деталь eng,Список деталь укр
A,СЕДАН,Передний бампер,Front bumper,Передній бампер
A,СЕДАН,Капот,Hood,Капот
B,КУПЕ,Передняя дверь,Front door,Передня дверь

Field Definitions (from src/calc/constants.rs):

  • Список Класс (CAR_PART_CLASS_FIELD) - Vehicle class: A, B, C, D, SUV, etc.
  • Список Тип (CAR_PART_TYPE_FIELD) - Body type (Russian names from constants):
    • СЕДАН (sedan) → English: sedan
    • УНИВЕРСАЛ (wagon) → English: wagon
    • КУПЕ (coupe) → English: coupe
    • ВНЕДОРОЖНИК 5 дверный (SUV 5-door) → English: suv 5 doors
    • ХЕТЧБЕК 5 дверей (hatchback 5-door) → English: hatchback 5 doors
  • Список деталь рус (CAR_PART_DETAIL_RUS_FIELD) - Part name in Russian (e.g., "Передний бампер")
  • Список деталь eng (CAR_PART_DETAIL_ENG_FIELD) - Part name in English (e.g., "Front bumper")
  • Список деталь укр (CAR_PART_DETAIL_UKR_FIELD) - Part name in Ukrainian (most commonly used)

Backend Model: [cars.rs:65-83]

pub struct CarPart {
    pub class: String,           // e.g., "A"
    pub type_field: String,      // e.g., "СЕДАН"
    pub detail_rus: String,      // Russian name
    pub detail_eng: String,      // English name
    pub detail_ukr: String,      // Ukrainian name (preferred)
}

API Endpoint for T1 Data:

GET /api/v1/user/carparts/{class}/{body_type}
  • Returns filtered CarPart array for specific class + body type
  • Body type must be translated from English to Russian: sedanСЕДАН
  • Used in frontend to populate body parts selector

T2 Table: Repair Actions & Zones (tables/t2.csv)

Purpose: Detailed breakdown of repair actions (assemble, paint, repair, etc.) for each part and zone.

File Location: tables/t2.csv in user's micro-repository

ACTUAL Structure (verified from real data): CSV with 19 columns. A single row can apply to multiple body types via 8 separate body type columns (ТИП КУЗОВА1ТИП КУЗОВА8). Each row lists which body types it covers as cell values, not as filters.

Схема кузова,ТИП КУЗОВА1,ТИП КУЗОВА2,ТИП КУЗОВА3,ТИП КУЗОВА4,ТИП КУЗОВА5,ТИП КУЗОВА6,ТИП КУЗОВА7,ТИП КУЗОВА8,зона,деталь 1,деталь 2,программа,розібрати/зібрати,усунення перекосу,замінити,зняти/встановити,ремонт,фарбування
Рис.1,ХЕТЧБЕК 3 двери,ХЕТЧБЕК 5 дверей,КУПЕ,ЛИФТБЭК 5 дверей,СЕДАН,УНИВЕРСАЛ,ВНЕДОРОЖНИК 3 дверный,ВНЕДОРОЖНИК 5 дверный,Бампер задній,Бампер задній,,,,,,,, 
Рис.2дв.,ХЕТЧБЕК 3 двери,ХЕТЧБЕК 5 дверей,,ЛИФТБЭК 5 дверей,,,ВНЕДОРОЖНИК 3 дверный,ВНЕДОРОЖНИК 5 дверный,Двері багажника,Деталі дверей багажника,Каркас дверей зад.лів.,,розібрати/зібрати,усунення перекосу,,, ремонт,фарбування

IMPORTANT — Body type values are Russian (same format as T1):

  • ХЕТЧБЕК 3 двери (hatchback 3 doors)
  • ХЕТЧБЕК 5 дверей (hatchback 5 doors)
  • СЕДАН (sedan)
  • УНИВЕРСАЛ (wagon)
  • КУПЕ (coupe)
  • ЛИФТБЭК 5 дверей (liftback 5 doors)
  • ВНЕДОРОЖНИК 3 дверный (suv 3 doors)
  • ВНЕДОРОЖНИК 5 дверный (suv 5 doors)

IMPORTANT — Action columns store the action name as a string (not a number): The action columns (розібрати/зібрати, ремонт, etc.) contain either the action name string (non-empty = action supported) or empty string (action not applicable). Not numeric labor times — those come from separate lookup tables.

Header/section rows: Rows where деталь 2 is empty and ALL action columns are empty are section header markers (e.g., "Кришка багажника" with програма = "программа"). They group sub-parts but are not themselves actionable.

Field Definitions (from src/calc/constants.rs):

Core Fields:

  • зона (T2_ZONE) - Repair zone identifier (e.g., "Кришка багажника", "Бампер задній")
  • деталь 1 (T2_PART_1) - Primary part name or group name (required, cannot be empty)
  • деталь 2 (T2_PART_2) - Sub-part name. If empty: part is ungrouped (group=null, name=деталь 1). If filled: group=деталь 1, name=деталь 2
  • Схема кузова (T2_BLUEPRINT) - Reference to visual blueprint/schema name
  • ТИП КУЗОВАn (T2_BODY = "ТИП КУЗОВА") - 8 columns; backend filters by checking if ANY ТИП КУЗОВАn value matches the requested body type (using k.contains("ТИП КУЗОВА"))

Action Fields:

  • розібрати/зібрати (T2_ACTION_ASSEMBLE) → internal action name: "assemble"
  • усунення перекосу (T2_ACTION_TWIST) → internal action name: "twist"
  • замінити (T2_ACTION_REPLACE) → internal action name: "replace"
  • зняти/встановити (T2_ACTION_MOUNT) → internal action name: "mount"
  • ремонт (T2_ACTION_REPAIR) → internal action name: "repair"
  • фарбування (T2_ACTION_PAINT) → internal action name: "paint"

Backend Model: [t2.rs:127-135]

pub struct T2PartEntry {
    pub name: String,           // Part name (деталь 2 if exists, else деталь 1)
    pub group: Option<String>,  // Group name (деталь 1) if деталь 2 exists
    pub actions: HashSet<String>, // Internal action codes: "assemble","twist","replace","mount","repair","paint"
    pub car_blueprint: String,  // Schema reference
    pub zone: String,           // Zone identifier
}

API Endpoint for T2 Data:

GET /api/v1/user/carparts_t2/{class}/{body_type}
  • body_type is the English URL param (e.g., hatchback 3 doors)
  • Backend converts it to Russian via body_type_into_t1_entry() before filtering T2
  • Filtering matches ANY ТИП КУЗОВАn column (column name contains "ТИП КУЗОВА")
  • Used to populate repair action selector and calculations

Processors: User-Configurable Calculation Logic

What Are Processors?

Processors are user-written JavaScript functions that customize calculation outputs. They allow users to define repair timelines, costs, and pricing logic without modifying the backend.

File Location: procs/*.js in user's micro-repository

Purpose: Transform raw T1/T2 data into formatted calculation rows with labor time/cost estimates.

Processor Structure

File Example: procs/bumper_repair.js

module.exports = {
  // Unique name displayed in results
  name: "Front Bumper Repair",

  // Order of execution (lower first)
  orderingNum: 0,

  // Category for grouping
  category: "Body Panels",

  // Which T1 tables this processor depends on
  // Prevents processor from running if table missing
  requiredTables: ["t1", "bumper_details"],

  // Which repair types this processor supports
  // Empty array = all types supported
  requiredRepairTypes: ["paint", "repair"],

  // Required global files (yaml/json)
  requiredFiles: ["pricing_rules.yaml"],

  // Determines if processor should execute
  // Returns boolean
  shouldRun: (x, carPart, tableData, repairAction, files, carClass, carBodyType, carYear, carModel, paint, pricing) => {
    return carPart.name.includes("Bumper") && repairAction === "paint";
  },

  // Main calculation logic
  // Returns array of output rows
  run: (x, carPart, tableData, repairAction, files, carClass, carBodyType, carYear, carModel, paint, pricing) => {
    const baseTime = tableData.t1[repairAction] || 0;
    const adjustedTime = baseTime * 1.1; // 10% increase

    return [
      x.mkRow({
        name: `Paint "«деталь»" bumper`,  // «деталь» gets replaced with actual part name
        evaluate: adjustedTime.toString(),
        tooltip: "Includes sanding and two coats"
      })
    ];
  }
};

Processor Parameters

When run() or shouldRun() is called:

ParameterTypeDescription
xobjectSandbox with mkRow() helper
carPartT2PartEntrySelected car part with name, group, actions
tableDataobjectAll loaded table rows keyed by table name (e.g., tableData["Арматурные работы"]["СНЯТИЕ ДЛЯ РЕМОНТА"])
repairActionstringSelected Ukrainian repair type from repair_types.csv (e.g., "Ремонт без фарбування"), NOT a T2 internal code
filesobjectLoaded YAML/JSON files from global/
carClassstringE.g., "A", "B"
carBodyTypestringE.g., "sedan", "suv 5 doors"
carYearnumberVehicle year
carModelstringE.g., "Camry"
paintstringPaint color selected
pricingobjectCurrency and pricing preferences

requiredRepairTypes must use Ukrainian repair type names matching repair_types.csv values:

requiredRepairTypes: ["Ремонт без фарбування", "Ремонт з зовнішнім фарбуванням"]
// NOT: ["repair", "paint"]  ← WRONG, these are T2 internal codes

requiredRepairTypes: [] (empty) means the processor runs for ALL repair types. The is_supported_repair_type() function returns true when the array is empty.

requiredTables must match the table filename without extension (e.g., "Арматурные работы" for Арматурные_работы.csv). Case-sensitive, word-order matters.

Row Output Structure

Each processor returns array of rows:

x.mkRow({
  name: string,           // Display name (supports «word» replacement)
  evaluate: string,       // JavaScript expression to evaluate
  tooltip: string         // Hover tooltip
})

Name Substitution: Words in «guillemets» or "quotes" are replaced:

  • Input: "Painting «деталь» with color \"color\""
  • Output: "Painting Front bumper with color red"
  • Supported: деталь (part name), color (selected paint)

Evaluate Expression: Executed with eval() in sandbox context. Can use:


Content truncated.

When not to use it

  • Tasks unrelated to Autolab carpaintr data architecture
  • Tasks not involving T1/T2 table schemas or processors
  • Tasks not related to user-configurable data flows, backend parsing, API endpoints, or frontend UI wiring

Limitations

  • Specific to Autolab carpaintr project
  • Focuses on T1/T2 table schemas and processors
  • Requires knowledge of `src/calc/constants.rs` for field definitions

How it compares

This skill offers specialized expertise in the unique data architecture of Autolab carpaintr, including specific CSV structures, field mappings, and backend models, providing targeted solutions beyond general data management.

Compared to similar skills

dataman side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
dataman (this skill)02moReviewAdvanced
sql-queries184moNo flagsIntermediate
senior-data-engineer217moReviewAdvanced
powerbi-modeling115moNo flagsIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

sql-queries

anthropics

Write correct, performant SQL across all major data warehouse dialects (Snowflake, BigQuery, Databricks, PostgreSQL, etc.). Use when writing queries, optimizing slow SQL, translating between dialects, or building complex analytical queries with CTEs, window functions, or aggregations.

1888

senior-data-engineer

davila7

World-class data engineering skill for building scalable data pipelines, ETL/ELT systems, and data infrastructure. Expertise in Python, SQL, Spark, Airflow, dbt, Kafka, and modern data stack. Includes data modeling, pipeline orchestration, data quality, and DataOps. Use when designing data architectures, building data pipelines, optimizing data workflows, or implementing data governance.

2179

powerbi-modeling

github

Power BI semantic modeling assistant for building optimized data models. Use when working with Power BI semantic models, creating measures, designing star schemas, configuring relationships, implementing RLS, or optimizing model performance. Triggers on queries about DAX calculations, table relationships, dimension/fact table design, naming conventions, model documentation, cardinality, cross-filter direction, calculation groups, and data model best practices. Always connects to the active model first using power-bi-modeling MCP tools to understand the data structure before providing guidance.

1161

data-quality-frameworks

wshobson

Implement data quality validation with Great Expectations, dbt tests, and data contracts. Use when building data quality pipelines, implementing validation rules, or establishing data contracts.

628

fuzzy-matching

dadbodgeoff

Multi-stage fuzzy matching pipeline for entity reconciliation. PostgreSQL trigram pre-filter, salient overlap check, and multi-factor similarity scoring.

825

query-writing

langchain-ai

For writing and executing SQL queries - from simple single-table queries to complex multi-table JOINs and aggregations

723

Search skills

Search the agent skills registry