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.zipInstalls 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 wiringKey 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
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ТИП КУЗОВАnvalue matches the requested body type (usingk.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_typeis 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
ТИП КУЗОВАncolumn (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:
| Parameter | Type | Description |
|---|---|---|
x | object | Sandbox with mkRow() helper |
carPart | T2PartEntry | Selected car part with name, group, actions |
tableData | object | All loaded table rows keyed by table name (e.g., tableData["Арматурные работы"]["СНЯТИЕ ДЛЯ РЕМОНТА"]) |
repairAction | string | Selected Ukrainian repair type from repair_types.csv (e.g., "Ремонт без фарбування"), NOT a T2 internal code |
files | object | Loaded YAML/JSON files from global/ |
carClass | string | E.g., "A", "B" |
carBodyType | string | E.g., "sedan", "suv 5 doors" |
carYear | number | Vehicle year |
carModel | string | E.g., "Camry" |
paint | string | Paint color selected |
pricing | object | Currency 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.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| dataman (this skill) | 0 | 2mo | Review | Advanced |
| sql-queries | 18 | 4mo | No flags | Intermediate |
| senior-data-engineer | 21 | 7mo | Review | Advanced |
| powerbi-modeling | 11 | 5mo | No flags | Intermediate |
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.
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.
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.
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.
fuzzy-matching
dadbodgeoff
Multi-stage fuzzy matching pipeline for entity reconciliation. PostgreSQL trigram pre-filter, salient overlap check, and multi-factor similarity scoring.
query-writing
langchain-ai
For writing and executing SQL queries - from simple single-table queries to complex multi-table JOINs and aggregations