Let me say first of all that Komorebi is incompatible with WinAMP skins. There's just too many differences between their functions and controls. Until I can reconcile the differences (may be never) Komorebi will not read WinAMP skins.

That being said, let's proceed to describe how to make a new skin.

During development, skin sets should be deposited in separate subdirectories under the skins subdirectory under komorebi. Komorebi will automatically scan for all available skins. Each set of skin contains bitmaps plus a spec.txt file describing the skin. When you've finished, you can zip it up for distribution.

spec.txt is divided up into sections, with their section labels between [] brackets. Lines preceded by # are comments, and will be ignored by the parser. The first few lines of spec.txt describe the skin.

[Name]
XP Olive

[Designer]
Bo-Yi Lin

[Version]
V1.0

[Desc]
Windows XP, Olive color scheme.

[Controls]
# All numbers must be positive integers
# Characters can be upper or lower case

Now we get to defining button controls and stuff. These are defined in 2 sections, [Main] and [Alt]. Each skin can have 2 views that can be toggled between quickly. However, the alternate view is entirely optional. Main view parameters are specified under the [Main] section, and alternate view parameters are specified under the [Alt] section. But you'd probably want to know about the bitmaps first. They can be in 8-, 16-, or 24-bit. 24-bit is preferred for precise color control (especially important for masks), while 8-bit produces smaller file sizes. Here is a list of all possible relevant bitmaps:

main panels: m_panel.bmp, a_panel.bmp
sliders: m_bslider.bmp, m_pslider.bmp, m_vslider.bmp, a_bslider.bmp, a_pslider.bmp, a_vslider.bmp
thumbs: thumbs: m_bthumb.bmp, m_pthumb.bmp, m_vthumb.bmp, a_bthumb.bmp, a_pthumb.bmp, a_vthumb.bmp
status: m_av.bmp, m_tag.bmp, m_pm, a_av.bmp, a_tag.bmp, a_pm
time: m_time.bmp, m_sep.bmp, a_time.bmp, a_sep.bmp
track: m_alpha.bmp, a_alpha.bmp
animation: m_anim.bmp, a_anim.bmp

As you can see, bitmaps for the main view have m_ prefix, while those for the alternate view have a_ prefix. However, the most basic working skin will require only 1 bitmap: m_panel.bmp. If a particular control is not visible, Komorebi will not even attempt to load the associated bitmap. If a_panel.bmp is missing, the alternate-view bitmap loading sequence will be skipped. Since the procedure for making the main view is the same as for the alternate view, we'll focus on making a main view.

As mentioned before, you need just 1 bitmap for the very basic skin. However, this bitmap contains a series of 6 bitmaps arranged vertically. I will start with the topmost bitmap at #1:
Bitmap 1: You draw how the window and buttons will look like when the window goes out of focus.
Bitmap 2: For showing the default behavior for window and buttons when the window is in focus.
Bitmaps 3-5 are used only for button drawing.
Bitmap 3: This is for when the button is set. The behavior is much the same as a checked checkbox.
Bitmap 4: This is for hot tracking, or mouseover.
Bitmap 5: This is for depressed buttons, or what I would call actuated buttons.
Bitmap 6: Here is the mask you use to specify the freeform window. Black part will be drawn, while the white part will transparent. There is a tolerance level here of about 16 for R,G,B, so the panel can be saved as a 8-bit bitmap.
Now you could of course create just 1 bitmap and copy it to the others, but that creates very static looking buttons. The slider bars (just the bar, not buttons) are there just for reference. You will actually create them separately.

m_panel.bmp

The corresponding entries in spec.txt are:

play v 141 112 44 21
stop v 220 112 44 21
pause v 271 112 21 21
home v 113 112 21 21
end v 192 112 21 21
random v 252 63 21 21
loop v 223 63 21 21
options v 281 63 21 21
help v 310 63 21 21
queue v 165 63 21 21
tlist v 114 63 44 21
cover v 194 63 21 21
close v 314 6 21 21
mini v 291 6 21 21
ui v 268 6 21 21
menu v 7 9 17 16

button_name visibility x y cx cy

Currently you can use slider controls for volume/balance/position adjustments. These are of course optional. If you don't want to show them, make them invisible and optionally zero out the values.

m_pslider.bmp

m_pthumb.bmp

You will need two bitmaps for each slider. One is the slider panel itself, the other one is a thumb. The slider panel bitmap is actually two bitmaps, one stacked ontop of another. The top bitmap is the template. The bottom bitmap is a mask. The mask is a black&white picture. Make sure that the white part is all white (0xFFFFFF) and the black part is all black (0x000000), otherwise the colors may bleed through. For slider controls, it is essential that you use 24-bit bitmaps.
Slider panel: Since slider panels can have variable color lighting, the white part of the mask is where the light shines through. If you don't want ANY lighting, just make the mask all black so that no light will shine through.
Slider thumb: You can see the bitmap is a series of 4 bitmaps. Bitmap 1 is the normal state. Bitmap 2 is for hot tracking. Bitmap 3 is for actuated state. Final bitmap is for transparency. The slider thumb has variable transparency, which means the slider thumb can be of irregular shape. White part will be drawn, while the black part specifies transparency.
For horizontal bitmaps, try making the thumb the same height as the slider panel so that it can be correctly aligned. Similar consideration should be made for vertical bitmaps.

This is how you define the sliders in spec.txt:

balance v h 32 112 808000 008000 808000
volume v v 10 46 008000 808000 800000
position v h 133 90 008000 808000 800000
ballt v 23 112 8 7
balrt v 68 112 8 7
volup v 11 36 7 8
voldn v 11 124 7 8
posrw v 115 90 17 16
posff v 314 90 17 16

slider_name visibility orientation x y clrbegin clrmiddle clrend

For the XP skin, you can see that I'm not using transparent lighting or freeform thumb. But examples can be found in the "Classic Dark" skin.

To have a working time/value display, you need to make 2 bitmaps. One specifies the value bitmaps from 0 to 9, plus a blank digit, and the other is a colon separator.

m_time.bmp

m_sep.bmp

This is how you define time display in spec.txt:

time v 31 43

time visibility x y

You have two choices when making a track display. One is using a windows font, the other is using a alphanumeric bitmap. It has the following syntax:

track visibility character x y cx cy delta interval [bgclr fontclr]

We'll examine the main view first. This is how you define a font display in spec.txt:

track v f 117 38 211 18 3 250 FAFAFA 728855

If you want to use a bitmap font for, say, the alternate view, we can look at the following example found in the "Dark Classic" skin.

a_alpha.bmp

This is how you define a font display in spec.txt:

# track v b 92 29 160 16 3 250 202020

Row 1:  !"#$%&'()*+,-./0123456789:;<=>?
Row 2: @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
Row 3: `abcdefghijklmnopqrstuvwxyz{|}~o

Komorebi uses 2 status displays to provide certain feedbacks. The AV display signals whether the current track is an audio or video file. The tag display signals whether the current track has a tag or dictionary entry.

m_av.bmp

The AV bitmap is 3 bitmaps stacked on top of another, in the order of None, Video, Audio.

m_tag.bmp

The Tag bitmap is also 3 bitmaps stacked on top of another, in the order of None, Dictionary, Tag.

m_pm.bmp

Ditto for the playmode bitmap. The order is Stop, Play, Pause.

This is how you define status displays in spec.txt:

tag v 82 78
av v 56 78
pm v 32 78

status_name visibility x y

You can have an animated bitmap sequence while the clip is playing. It's not used in the XP skins, but you can find the example in "Classic Dark" skin.

m_anim.bmp

This is how you define the animation display in spec.txt:

anim v 16 85 9 250

anim visibility x y cy interval

Skins are placed in a unique subdirectory under the skins\ for easy development. However for distribution it is more convenient to pack it in a zip archive. Just rename the extension of your skin archive from .zip to .ksz, and Komorebi will find it.

Well, hopefully the parser will warn you of any syntax errors and notify you of any missing bitmaps before barfing. But it's not anywhere near foolproof yet so good luck.