
Currently, the format for that could be quite simple:
type;name;value;max (for attributes);
e.g.
attr;attribute_name;2;4;
abil;ability_name;2d6<4;;
etc.
For the character sheet update, additional columns and types could be added.
The simplicity of parsing a CSV file is deceptive. At least XML is well-defined. CSV, on the other hand... is it a "comma separated value" file, or a "character separated value" file? Comma may be the gold standard, but I've seen pipes used as well, and the OP's examples use semicolons. What do you do if a cell contains your separating character? It's normal to enclose the cell in double quotes, but I've seen other escaping methods (such as a backslash before the offending character), and what if the cell also contains a double quote? Two? What about newlines? Usually, a newline indicates a new record in a CSV, but I've seen CSV formats where newlines are permitted if they're escaped... which goes back to the escaping problem from before. Does "escaped" mean we enclose the record in quotes (that could result in a a cell containing a quote throwing off the record boundaries), or something else? If we escape with a backslash, does that mean a newline-within-a-cell ends one line with a backslash, or do we use \n? Or maybe \\n? What about other languages? Japanese uses 『double hook brackets,』 for example.
Worse, nearly every program capable of reading CSV files has different rules for parsing them. It isn't a well-defined file format.
Finally, as someone who has relatively recently been forced to work with similar files as part of my job, I object strongly to any file which represents tabular data in a format such as record type,record data -- a file containing tabular data should contain one type of record. Tabular files containing disparate record types are almost as bad as vertical tables in a relational database.