Unless you are using 2000i2, you will not be able to create a family table model of the skeleton.

An additional problem you will run into is placing the doors in different positions in different views - you will have to use a different family table assembly model of the aaa.asm to substitute in the different versions of the subassemblies that actually contain the skeleton that you are substituting.

Current

aaa.asm

        sub1.asm

                skel.prt

        sub1.asm

                skel.prt

        sub1.asm

                skel.prt

becomes family table models

aaa_case1.asm

        sub1_open.asm

                skel_open.prt

        sub1_closed.asm

                skel_closed.prt

        sub1_open.asm

                skel_open.prt

and

aaa_case2.asm

        sub1_closed.asm

                skel_closed.prt

        sub1_closed.asm

                skel_closed.prt

        sub1_open.asm

                skel_open.prt

Where aaa_case1 and aaa_case2 are instances of aaa.asm that refer to instances sub1_closed and sub1_open of sub1.asm, which in turn refer to instances skel_closed and skel_open of skel.prt

On the drawing you have models aaa_case1.asm and aaa_case2.asm, and you will not be able to attach balloons from one model on another (only on the model that is actually filling out the repeat region that is creating the BOM balloons).

But like I said, if you used a defined Pro/Engineer skeleton, you will not be able to make the family table instances of skel.prt unless you move to 2000i2. No guarantees on 2000i2 letting you take an existing skeleton model and modify it though, but that's the release that will allow skeleton models to contain family table instances.

As you referred to as well, you will need to set up the skeleton with the family_table_control parameter and layout_control parameter to keep the instances from being modified when people change the layout and affect the generic model.