/gate-check

name: gate-check
description: |
  Final quality gate before reporting task completion (Gate 3).
  Fills confidence assessment, runs supplementary verification for <95% items, completes self-check checklist.
  Writes PASS/FAIL result to subtask.md, then calls autoworker:dispatch for routing.

autoworker:gate-check — Pre-Completion Self-Check (Gate 3)

**Trigger**: Called by autoworker:dispatch when all tests are complete. **Pure assessment skill — does not make routing decisions.**

Execution Flow

1. Pre-Check

Glob `subtask_*.md` (exclude subtask_template.md) →
  0 found → stop, prompt to create subtask
  1 found → use directly (backward compatible)
  multiple → grep `status:` to filter:
    - Files without status field treated as active (backward compatible)
    - Exactly 1 active → use it
    - 0 active → list all files + status, prompt user to choose
    - >1 active → report anomaly
→ Read → check "Test Results" section

• Test results section is empty → **FAIL**, prompt to complete tests and call `autoworker:checkpoint` first
• Has test results → continue

1.5. Acceptance Criteria Traceability

Read subtask's "Acceptance Criteria" table, check whether each metric was measured in L1-L4 test results:

• Metric not measured → that change point's confidence < 95% (Step 3 will trigger supplementary verification)
• All metrics have corresponding test results → continue
• No acceptance criteria table (legacy subtask format) → skip this step

2. Fill Confidence Assessment Table

In subtask.md's "Confidence Assessment" section, fill in for each change point:

| Change point | Test level | Confidence | Verification method | Unverified/Risk | |-------------|-----------|------------|-------------------|-----------------|

Confidence inference basis:

• Has L4 pass + meaningful output → 95%+
• Has L2 but no L4 → 70-85%
• Only L1 → 50-70%
• Untested → 30%

3. Supplementary Verification for < 95% Items

When the table above has < 95% items: 1. Design supplementary verification commands (specific, executable) 2. **Execute immediately** 3. Fill in results 4. Update confidence

Record in subtask.md's "< 95% Supplementary Verification" table.

**Boundary for "requires user confirmation"** — only scenarios depending on human senses qualify:

• "Selector may have changed" → launch browser and check — NOT "requires user confirmation"
• "API might not work" → curl it — NOT "requires user confirmation"
• "Config might be wrong" → write a script to load and check — NOT "requires user confirmation"
• UI appearance, interaction feel → legitimate "requires user confirmation"

When all items are >= 95%, write "All >= 95%, no supplementary verification needed".

4. Gate 3 Self-Check Checklist

In subtask.md's "Gate 3 Self-Check" section, check each item and provide evidence:

• [ ] **Verification depth**: Test results section has L2+ records
• Evidence: <state which is the highest layer reached>
• [ ] **L4 = user path**: L4 operation path = actual user usage path
• Evidence: <state what L4 did, compare with how user would use it>
• [ ] **Supplementary verification complete**: All < 95% items had supplementary verification executed
• Evidence: <how many items supplemented, or "all >= 95%">
• [ ] **Instruction file tested**: If SKILL.md / config files were changed, they were actually trigger-tested
• Evidence: <how verified, or "no instruction files changed">
• [ ] **Coverage complete**: Every modified file has a corresponding verification item
• Evidence: <how many files changed, how many verified>

**Can't write evidence = didn't do it = can't check the box = FAIL**.

5. Chain Integrity Check

Answer each question (any No → FAIL):

1. **Is the chain fully traced?** From config/code change → to user-perceivable effect, is there a verification point at every link? 2. **Any "should be fine" links?** Anything you feel "obviously works" but haven't actually run? 3. **Does verification path = user path?** Is your verification method consistent with how users actually use it?

6. Write Result and Invoke autoworker:dispatch

**PASS (all self-checks pass + all >= 95%)**:

Edit subtask.md: 1. Append `Gate result: PASS` at the end of "Progress Log" section 2. Change `status: active` to `status: completed` (if status field exists)

Output:

Gate 3 PASS
- Confidence: all >= 95%
- Self-check: 5/5 passed
- Chain: complete
→ Invoking autoworker:dispatch

**FAIL loop limit**: If already consecutively FAIL 2 times (check "Progress Log" for `Gate result: FAIL` count), on the 3rd FAIL, do not invoke autoworker:subtask-update. Instead output a complete failure report to the user and let them decide next steps.

**FAIL (any self-check fails or has < 95% that can't be self-resolved)**:

Edit subtask.md, append at end of "Progress Log" section:

Gate result: FAIL

Output:

Gate 3 FAIL
- Failed items: <specifics>
- Needs additional work: <specifics>
→ Invoking autoworker:dispatch

**Both cases always invoke `autoworker:dispatch`. No routing decisions — autoworker:dispatch reads Gate result and decides next step.**

7. Chain: Immediately Invoke autoworker:dispatch

**After outputting the result, immediately invoke `autoworker:dispatch`. Do not wait for user instructions, do nothing else.**

Important Notes

• **gate-check is pure assessment**: Only assesses + writes results, does not make routing decisions
• **Evidence is a hard constraint**: Each self-check item must have traceable evidence — "I think it's fine" doesn't count
• **Gate result format is fixed**: Must be `Gate result: PASS` or `Gate result: FAIL` — autoworker:dispatch reads this exact format
• **Don't ask user "should I supplement?"**: Autonomously executable supplementary verification goes directly through autoworker:dispatch → autoworker:subtask-update loop