Imported from vladm3105/aidoc-flow-framework (
platforms/claude-code-plugin/skills/gate-check/SKILL.md). Install upstream withnpx skills add vladm3105/aidoc-flow-framework --skill gate-check. Copyright stays with the author.
gate-check
Purpose
Run the correct CHG approval gate for a change to an existing SDD artifact:
determine the affected layers, select the matching gate, run that gate's
checks against the gate error catalog, produce a pass/fail gate report, and
prepare the GATE_APPROVAL_FORM for the approver. It is the verification
companion to the ../doc-chg/SKILL.md family, which authors the CHG record.
CRITICAL — authority boundary: this skill prepares and verifies; it is never the approving authority. It records check results and fills the approval form, but a human grants approval by signing per the change level's approval matrix. The skill must not mark a change "approved".
Layer: cross-cutting governance utility (CHG overlay, not a lifecycle layer).
When to Use
Use gate-check when:
- Modifying an existing SDD artifact through the CHG process (C2/C3 changes).
- Verifying a change to the
framework/spec itself — run GATE-SPEC. - Verifying a change's gate checks before requesting human sign-off.
- Preparing the gate approval form for a change.
Do not use it for:
- C1 changes (typo/formatting) — no gate applies; fix and commit.
- Creating fresh artifacts in a clean flow — use the layer skills and
../doc-validator/SKILL.md. - Authoring the CHG record itself — use
../doc-chg/SKILL.md.
Behavior
The framework ships no runtime code — this skill is the gate runner, applying the declarative gate definitions against the change.
1. Determine affected layers
From the CHG record (or the change under review), list every layer the change touches. A change may enter at one gate and cascade downstream.
2. Select the gate (by affected layers)
| Affected layers | Artifacts | Gate |
|---|---|---|
| L1-L2 | BRD, PRD | GATE-01 |
| L3-L5 | EARS, BDD, ADR | GATE-03 |
| L6-L7 | SPEC, TDD | GATE-06 |
| L8 | IPLAN | GATE-08 |
| Code | Source code | GATE-CODE |
— (target = the framework/ spec) |
templates / governance / registry / VERSION | GATE-SPEC |
A change entering upstream cascades to each downstream gate in sequence
(GATE-01 → GATE-03 → GATE-06 → GATE-08 → GATE-CODE); run every gate its layers
span. Source-to-entry routing (Upstream/External → GATE-01, Midstream →
GATE-03, Design → GATE-06, Execution → GATE-08, Feedback → GATE-CODE) is in
${CLAUDE_PLUGIN_ROOT}/framework/governance/chg/README.md.
GATE-SPEC is selected by target, not by layer. If the change edits the
framework/ spec itself (change_source: spec), it is a meta change — run
GATE-SPEC alone (gates/GATE-SPEC_FRAMEWORK.md); it does not cascade into
the artifact gates. A change to an engine's own authoring guidance or runtime is
not a spec change and does not enter GATE-SPEC.
3. Run the gate's checks
For each selected gate, run its entry criteria, blocking error checks
(E), and warning checks (W) from that gate's definition file, applying the
codes from ${CLAUDE_PLUGIN_ROOT}/framework/governance/chg/gates/GATE_ERROR_CATALOG.md. Examples:
GATE-03 verifies EARS/BDD/ADR upstream-tag counts and syntax; GATE-06 verifies
SPEC TDD-Ready ≥ 90% and SPEC↔TDD coverage; GATE-CODE requires a root-cause
analysis. Also apply cross-gate ROUTE-Echecks (no skipped gate, correct
entry per source) and VAL-E schema checks.
For GATE-SPEC, run the record-level checks you can verify from the CHG
record — GATE-SPEC-E001 (provenance: why/trigger), E002 (semver_impact
set; major ⇒ C3), E003 (never C1, ≥ C2), E004 (C3 ⇒ gate_approval gate +
approver). Report the CI-enforced checks E005–E008 (VERSION bump, both
FRAMEWORK_SPEC_VERSION match, conformance green, CHANGELOG updated) as items
the pipeline verifies — note them in the report; do not fake their pass. The
human approval (E004's sign-off) is the platform's protected-branch review.
4. Produce the gate report
Emit a pass/fail report per gate: each E-check (pass/fail) with its code, each W-check (addressed/not), and a gate result of PASS / PASS WITH WARNINGS / FAIL. Any failing E-check means the gate fails — list the codes and the catalog resolution for each. Do not soften a failing check.
5. Prepare the approval form
Populate ${CLAUDE_PLUGIN_ROOT}/framework/governance/chg/templates/GATE_APPROVAL_FORM.md from the
report: change summary, scope (layers/artifacts), per-gate validation results,
risk and rollback sections, and the required-approver rows for the change
level. Leave all signature, decision, and final-approval fields blank for
the human approver — the skill never fills them.
Exit: all E-checks pass and the form is ready for the approvers named in the change level's matrix. The change proceeds only after a human signs.
Related Resources
- CHG overview & source routing:
${CLAUDE_PLUGIN_ROOT}/framework/governance/chg/README.md - Gate definitions:
${CLAUDE_PLUGIN_ROOT}/framework/governance/chg/gates/GATE-01_BUSINESS_PRODUCT.md·GATE-03_REQUIREMENTS_ARCHITECTURE.md·GATE-06_DESIGN_TEST.md·GATE-08_IPLAN.md·GATE-CODE_IMPLEMENTATION.md·GATE-SPEC_FRAMEWORK.md(framework-spec change — meta) - Error codes:
${CLAUDE_PLUGIN_ROOT}/framework/governance/chg/gates/GATE_ERROR_CATALOG.md - Approval form:
${CLAUDE_PLUGIN_ROOT}/framework/governance/chg/templates/GATE_APPROVAL_FORM.md - CHG authoring:
../doc-chg/SKILL.md - Traceability after a change:
../doc-validator/SKILL.md