Receber por email
← Voltar para o catálogo

gate-check

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.

16estrelas
Atualizado há 7 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add phj128/autoworker

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/gate-check-phj128/svg)](https://www.skillteca.com.br/skills/gate-check-phj128)

Skills relacionadas

Ver todas de Desenvolvimento →

Alerta por categoria

Receba novas skills de Desenvolvimento toda segunda

1 email curto, só com as skills novas de Desenvolvimento. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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
Compartilhar X LinkedIn