Correction:
Actual result is "not run"

Are you sure your system is configured correctly?  It ran fine on October 11th on our CI system:

/tmp/build_root/m64/bin/cts/glcts --deqp-case=ES3-CTS.shaders.shader_integer_mix.prototypes-extension
dEQP Core GL-CTS-2.0 (0x0052484b) starting..
  target implementation = 'intel-gbm'

Test case 'ES3-CTS.shaders.shader_integer_mix.prototypes-extension'..
  Pass (Pass)

DONE!

Test run totals:
  Passed:        1/1 (100.00%)
  Failed:        0/1 (0.00%)
  Not supported: 0/1 (0.00%)
  Warnings:      0/1 (0.00%)

Yes. Result was Pass with mesa-10.6.7.

Result is "Not run" on BSW and SKL with Mesa 11.0.3:

Platform: SKY LAKE Y A0 
CPU : Intel(R) Core(TM) m5-6Y57 CPU @ 1.10GHz (family: 6, model: 78  stepping: 3)
MCP : SKL-Y  D1 2+2 (ou ULX-D1)
QDF : QJK9 
CPU : SKL D0
Chipset PCH: Sunrise Point LP C1       
CRB : SKY LAKE Y LPDDR3 RVP3 CRB FAB2
Reworks : All Mandatories + FBS02,FBS03, F23, O-02 & O-06
BIOS : SKLSE2R1.R00.X097.B02.1509020030
ME FW : 11.0.0.1173
Ksc (EC FW): 1.19

Platform: Braswell M
CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping: 4)
SoC : BSW D0
QDF : K6XC
CRB : BRASWELL RVP Fab2
Mandatory Reworks : All 
Feature Reworks: F28, F32, F33, F35, F37
Optional reworks : O-01a; O-02, O-03

Linux distribution: Ubuntu 14.04 LTS 64 bits
kernel 4.3.0-rc4-drm-intel-nightly+ c38f2c24fb6484fc6900efa6f8d968e8ee964e9c from git://anongit.freedesktop.org/drm-intel
Mesa - 11.0.3 from http://cgit.freedesktop.org/mesa/mesa/
xf86-video-intel - 2.99.917 from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/
Libdrm - 2.4.65 from http://cgit.freedesktop.org/mesa/drm/
Libva - 1.6.1 from http://cgit.freedesktop.org/libva/
vaapi intel-driver - 1.6.1 from http://cgit.freedesktop.org/vaapi/intel-driver
Cairo - 1.14.2 from http://cgit.freedesktop.org/cairo
Xorg Xserver - 1.17.2 from http://cgit.freedesktop.org/xorg/xserver

commit c38f2c24fb6484fc6900efa6f8d968e8ee964e9c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Oct 9 14:50:43 2015 +0200
drm-intel-nightly: 2015y-10m-09d-12h-49m-56s UTC integration manifest

I confirm result is not run on SKL-Y with:
- Mesa master commit 6f3954618b0fe273af76af79ce9ec56566b79b2a from http://cgit.freedesktop.org/mesa/mesa/, kernel 4.3.0-rc5-drm-intel-nightly+ (f14b17b) from git://anongit.freedesktop.org/drm-intel
- Mesa 11.0.4 from http://cgit.freedesktop.org/mesa/mesa/, kernel 4.3.0-rc6-drm-intel-nightly+ (ab48d30) from git://anongit.freedesktop.org/drm-intel

There may be some confusion due to the naming of tests.  Mesa CI successfully runs:

es3-cts.shaders.shader_integer_mix.prototypes-extension

That is different from:
es3-cts@shaders@shader_integer_mix@prototypes

as listed below.

I've confirmed that es3-cts.shaders.shader_integer_mix.prototypes returns "NotSupported" on all the platforms we test.

However, contrary to cprigent's comments below, es3-cts.shaders.shader_integer_mix.prototypes ALSO skips on 10.6.

This test is the only skipped test in our CTS runs, so it makes sense for someone (Ian?) with knowledge of the suite to confirm that this behavior is valid.

(In reply to Mark Janes from comment #5)
> There may be some confusion due to the naming of tests.  Mesa CI
> successfully runs:
> 
> es3-cts.shaders.shader_integer_mix.prototypes-extension
> 
> That is different from:
> es3-cts@shaders@shader_integer_mix@prototypes
> 
> as listed below.
> 
> I've confirmed that es3-cts.shaders.shader_integer_mix.prototypes returns
> "NotSupported" on all the platforms we test.
> 
> However, contrary to cprigent's comments below,
> es3-cts.shaders.shader_integer_mix.prototypes ALSO skips on 10.6.
> 
> This test is the only skipped test in our CTS runs, so it makes sense for
> someone (Ian?) with knowledge of the suite to confirm that this behavior is
> valid.

That's confusing.  We support GL_EXT_shader_integer_mix on all Gen6+ platforms on desktop OpenGL and OpenGL ES, and we have since that extension was born.

Looking at the code of the test, it seems the "prototypes" subtest can run in one of two modes.  There's a mode that tries to use the extension, and there's a mode that tries to use GLES 3.1.  My guess is that we're running the GLES 3.1 mode.

Does the test run and pass if the GLES version is forced to 3.1?

Pretty sure Jordan fixed this in the test suite. I see a commit from him in the desktop CTS.

(In reply to Matt Turner from comment #7)
> Pretty sure Jordan fixed this in the test suite. I see a commit from him in
> the desktop CTS.

Yes, the fix was commit 5dfe39ce2dac7e4e4dfd12b7f9d82d3090ca8d14,
and it was merged in to the CTS master branch in commit
6cf248e7c18d4883a0b37b22eb558ce79c296bc1, but I don't
know how that branch relates to the actual ES or desktop
CTS releases.