In HM7.0, I found the following:
Void TComTrQuant::xTransformSkip( Pel* piBlkResi, UInt uiStride, Int* psCoeff, Int width, Int height )
{

assert( width == height );
UInt uiLog2TrSize = g_aucConvertToBit[ width ] + 2;

#if FULL_NBIT

UInt uiBitDepth = g_uiBitDepth;

#else

UInt uiBitDepth = g_uiBitDepth + g_uiBitIncrement;

#endif

UInt iTransformShift = MAX_TR_DYNAMIC_RANGE - uiBitDepth - uiLog2TrSize;
Int j,k;
for (j = 0; j < height; j++)
{

for(k = 0; k < width; k ++)
{

psCoeff[j*height + k] = piBlkResi[j * uiStride + k] << iTransformShift;

}

}

}

Where MAX_TR_DYNAMIC_RANGE is defined as 15 and uiLog2TrSize is always equal to 2 since transform skip can only be applied to 4x4 intra blocks.
15-2=13 and consequently HM and draft text match.

The question is, how does this goes together with the restriction in bit_depth_luma/chroma_minus8 semantics?
"bit_depth_luma/chroma_minus8 shall be in the range of 0 to 6, inclusive."

modification over spec and software

Thanks for pointing out this problem. We have modified the spec and the corresponding code as in the attachments.
The negative shift value is allowed by simply modifying the direction of shifting.

Thanks for both patches (Draft and HM).
Btw, the problem could be broadened like mentioned Benjamin as :
iTransformShift = MAX_TR_DYNAMIC_RANGE - uiBitDepth - uiLog2TrSize;
and there are plenty of combinations where iTransformShift can be negative when uiBitDepth>10. Please note that we get a misnamed variable that is Unsigned Integer UInt iTransformShift in xQuant(), xDequant(),(no more issue with the provided patch in xTransformSkip(), xITransformSkip()) but we have an Integer Int iTransformShift in xRateDistOptQuant() and setErrScaleCoeff() thus wrapping errors may occur with negative values in xQuant(), xDequant().
Please correct me if I'm wrong, but it seems that this negative value if UInt iTransformShift is converted to Int (suggestion) in xQuant() and xDeQuant() is not a big deal as derived values used for shifting are always positive though (like min(iQBits)=10 or min(iQBitsC)=3 or min(qBits8)=2, note that there is no problem with iShift in xDeQuant()).
Besides the patch fixes the described Transform Skip issue too.
Any comment and correction is welcome.

Text issue is fixed in draft 7 (JCVTC-I1003_d3.doc)

Shouldn't there be a rounding offset (0.5) added for the case where a right shift occurs? This would be more consistent with the inverse transform process. Adding the offset would make the transform bypass process equivalent to using a transform equal to
128 * [ 1 0 0 0; 0 1 0 0; 0 0 1 0; 0 0 0 1]

transform skip patch + overflow transformShift fix + typo fix

I think that you are right Frank.
I have just posted a new patch with:
+ previous transform_skip.patch
+ your suggestion
+ my suggestion (UInt iTransformShift --> Int iTransformShift for xQuant/xDequant)
+ a typo fox
over HM7.1rc1

SW fixed in r2483

As both D7 and SW are now fixed, I think that all points addressed by this ticket are fixed thus ticket should be closed.

Correct. Text issue is fixed in draft 7 (JCVTC-I1003_d3.doc)